Delivery Manager в Fozzy group
  • Как мы создали свой подход к разработке без привязки к спринтам

    Доброго времени суток Михаил.

    Понравилось описание вашего процесса, понятно и развернуто, спасибо!

    Интересно было бы почитать, как именно выглядел у вас Scrum (вижу описание текущего процесса, но не понятно как он выглядел при Scrum), какие минусы вы видели в «чистом» подходе и как приняли решение от него уйти.
    Из того что понял — не устраивала фиксированная длина итераций, так как вы привязывали релизы к спринтам или наоборот.
    Критиковать не буду, так как не могу знать всех причин и специфики работы с вашей командой и продуктом, но не совсем понимаю, какие изменения вы внесли в Scrum для достижения результата описанного в «Итоге».

    Мы не раздуваем команды для поддержания максимальной эффективности и разнообразия разработки. Кроме того, такой подход мотивирует нас разрабатывать унифицированные компоненты.

    Если я правильно понимаю, преимущество пришло по наследству из Scrum?

    Мы поддерживаем гибкую разработку, сохраняя при этом глубину понимания продукта благодаря отдельному PDM на каждом продукте.

    Если я правильно понимаю, также взяли роль из Scrum, но там роль имела наименование Product Owner.

    Мы «живем» релизами, а не спринтами, что позволяет осязать продукт нашей работы и быть более гибкими.

    Вы не пробовали менять длину спринта, и осязать продукт по итогам каждого демо спринта?

    PDM во многом берет на себя роль PM для лучшего понимания продукта и подводных камней каждой фичи.

    Есть ли у вас тут какие то отличия от Scrum?

    Facilitator (PM) поддерживает эффективность процессов и бесперебойность «производства».

    В его ответственность входит что либо, что не входит в роль Scrum Master?

    И еще пара вопросов, если вас не затруднит:
    У вас был выделенный Scrum Master во время Scrum?
    Вы тестируете только весь релиз, не тестируя каждую фичу отдельно?

    Ранее, когда мы работали по Scrum, мы не ощущали привязки спринтов к реальной ценности, которую команда должна нести бизнесу и пользователям.

    Вы пробовали как то решать эту проблему в рамках Scrum?

    Более того, выпуск версии приложения не всегда совпадал с рамками спринта, что приводило к смещению или следующего спринта, или релиза.

    Не подумайте что это критика, мне правда интересно, у нас скажем, по необходимости берется в спринт таска «Релиз x.x», которая может быть выполнена в середине спринта, и не обязательно ждать демо, чтобы провести релиз на прод.
    Не возникает ли у вас «плавание» темпа разработки?
    Сколько в среднем занимает разработка одного релиза?
    У вас проводились ретроспективы во времена Scrum? Какие вопросы на них поднимали?
    Какой опыт имели ваши менеджеры до текущего проекта (agile/watefall/etc)?

    Підтримав: Gramm