Методологический франкенштейн

Собрали. Запустили. Передумали

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

Но дальше клиент просит регулярные демо, разработку заваливают срочными тасками, а приёмке нужна документация и соблюдение договорных этапов. Иногда приходится менять процесс или собирать франкенштейна из нескольких. Причины разбирать не буду, всех случаев не описать. Буду рассуждать, что с чем можно смэтчить.

Что можно смешать

Scrum + Kanban

Работаем спринтами, проводим планирование и ревью. Плюсуются WIP-лимиты, слежение за cycle time и блокировками. Если тестирование забито, разработчики перестают набирать новые задачи. Сначала разбираем очередь. Спринты остаются, цель спринта тоже. Канбан поможет контролировать поток, но не будет отменять договорённости команды.

Waterfall + Scrum

В договоре ТЗ, бюджет, сроки и приёмка. Внутри команда работает спринтами, показывает демо, тестирует интеграции до сдачи этапа. В заказной разработке встречала регулярно. Главное не путать закрытый спринт со сданным этапом. Новые хотелки клиента также оцениваем отдельно, не записываем в бэклог за счёт команды.

FFF + Kanban

Берём приоритетный бэклог, ограничиваем WIP, выпускаем готовые фичи. Канбан показывает загрузку и узкие места, ФФФ позволяет менять состав релиза. Но право резать фичсет должно быть согласовано с клиентом. Иначе фиксируется тупо вообще всё, кроме нервной системы проджекта.

Что не смешивать

FFF + Fixed Scope

Фичсет по методологии гибкий, а в контракте прописаны функции, сроки и критерии приёмки. Сократить объём без согласия клиента не получается. И ФФФ существует в процессах команды, а обязательства выполняем по фикс скоупу. Вместо управления объёмом проджект согласовывает исключения из договора, причём клиент совершенно не обязан идти навстречу. Почитайте мою отдельную статью об этом.

Scrum + частые ASAP

Согласовали план спринта, потом прилетела срочная фича, руководство добавило ещё задач, разработчика вообще забрали на соседний проект. К концу спринта половина запланированного не готова. Если срочняки прилетают ежедневно, нужно резервировать под них ёмкость или менять организацию работы. Скрам допускает пересмотр состава задач, но постоянная смена цели спринта с ним сочетаться не будет.

Waterfall + изменения без оценки

Согласовали требования, оценили объём, начали разработку. Клиент меняет бизнес-логику, добавляет экраны и новые интеграции. Команда всё принимает, но сроки и бюджет никто не пересчитывает. Водопад не запрещает изменения, но их нужно оценивать и согласовывать. Иначе к релизу будет больший набор фич по старой смете.

И как это может работать

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

Можно закрыть спринт, при этом этап не сдан. Можно показать фичу на демо, а потом месяц исправлять интеграцию. Лучше заранее согласовывать критерии готовности, приёмки и порядок изменения требований. А заодно определять кто может менять приоритеты.

Если посреди проекта решили вдруг переехать со скрама на канбан, уже стоит посмотреть на причину. Потому что зависшие ревью, срочные задачи и отсутствие аналитика не исчезнут. Тут кстати вполне достаточно WIP-лимитов, ну и выстроить правила работы с беклогом.

Об авторе статьи

Аня Каргина

Я менеджерка проектов. Пишу о работе с клиентами и командами, делюсь опытом и наблюдениями.

К началу статьи