Недавно один знакомый Скрам-Мастер написал мне письмо с просьбой помочь ответить на ряд любопытных вопросов. Когда-то я обучал эту команду на этапе «запуска Agile». Потом, к моему сожалению, дальше не было возможности с ними поработать достаточно продолжительно. И вот спустя пол-года они оказываются в ситуации, которая, наверняка, знакома многим другим командам.

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

В последние 2-3 месяца у почти всех скрам-команд на нашем проекте укоренилась такая ситуация, когда мы заведомо знаем, что часть (в среднем половина) взятых в спринт историй не будет закрыта. Так мы и ходим из спринта в спринт, имея бёрндаун чарт, который никогда не доходит до нуля и почти никогда не закрывая все стори.
Эта ситуация имеет много причин, но критических мы пока выделили две:
1) Наши спринты по длительности “2х-недельные”. НО пятница у нас объявлена не скрам-днем [Тимофей: BugFixing Friday], что оставляет на разработку 8 дней. Также общее спринт ревью приходится на последний день спринта, причем оно проходит на билде, в который нужно залить за день до ревью (что оставляет 7 дней). Добавив ещё пару задержек, у нас получается максимум 6 эффективных рабочих дней.
Это мало. За это время сделать с нуля среднюю историю нереально. И все это прекрасно понимают, но…
2) Никто не может убедительно доказать, что не заканчивать взятые в спринт истории – это очень плохо. Напротив, бытует мнение, что циклы девелоперов и тестеров в любом случае независимо от длины спринта будут смещены, и что в любом случае часть историй не будет завершена (упрощенно это выглядит так: неделю идет кодинг нового функционала, затем он неделю тестируется, но за это время кодится новый функционал, который не релизится в этом спринте и переходит в следующий). Все будто боятся, что девелоперам будет нечего делать.
И этой точке зрения сложно что-то противопоставить, не имея реального опыта работы с проектами, на которых истории не перетекают из спринта в спринт, а берутся и заканчиваются в одном и том же спринте.

С первым вопросом почти все понятно и в самом письме содержится большая часть ответа :-). Если у вас  всего 6 эффективных рабочих дней в спринте, то вариантов у вас не так уж и много. Побуду «капитаном Очевидность»:

• Оптимизировать совместную работу над одной Историей Пользователя, чтобы в течение этого короткого отрезка все-таки успевать доделывать целиком среднюю историю
• Разбивать Истории на более мелкие, чтобы можно было успевать и в тоже время были промежуточные видимые результаты в каждом спринте
• Отказаться от не-Cкрам дней и брать всю работу в план спринта, делать все видимым в Бэклоге
• Увеличить длину спринта, чтобы получить больше эффективных дней

Возможно, применение одного из этих советов уже само по себе поменяет  ситуацию к лучшему. Хотя, как правильно заметил автор письма, это лишь симптомы и проблема кроется во втором вопросе: «почему не заканчивать взятые в спринт истории плохо?».

Итак, во-первых, брать в итерацию работы, которые вы заведомо знаете, что не сделаете – это прямая де-мотивация команды. Говорить о commitment (совместных обещаниях) тем более не приходится – как мы можем пообещать то, что не собираемся сделать? Как результат – у людей вообще может снизится желание работать.

Во-вторых, отдельно стоит обратить внимание на то, что Реальную Скорость Работы Команды мы меряем все-таки по сделанным историям. Получается, что «наружу» для Владельца Продукта и компании скорость очень маленькая. К тому же, среднее время финального выпуска (lead time) одной новой функции у вас судя по всему месяц или больше, если функция делается на протяжении нескольких спринтов по две недели.

Если эти данные устраивают бизнес, то ОК, но не забываем еще и о факторе точности планирования. За итерацию у вас делается 50% запланированного, значит на долгосрочные планы тоже нужно закладывать 50% погрешности :-). Спросите Владельца Продукта как ему такой аргумент?

В третьих, начиная работать в стиле Agile и по Scrum-методологии, команда и заказчики согласились разделять ценности и принципы, описанные в Agile Manifesto. В манифесте и описании Scrum методологии неоднократно упоминается, что выпуск работающего ПО является одной из главных ценностей и цель работы в Спринте выпустить потенциально готовую к отгрузке версию. Почему и бизнес и команда это забывают и соглашаются с утверждением о том, «что циклы девелоперов и тестеров в любом случае независимо от длины спринта будут смещены»??? Это можно сказать «традиционная» проблема команд, которые переходят от старых традиций разработки (читай waterfall, да простят меня холиварщики) к новым для компании подходам, на основе итеративной-инкрементальной разработки (читай Agile и Scrum).

Более того, у команды, о которой идет речь, есть Критерии Готовности (Done-критерии), выработанные на уровне всей компании. Получается, технические критерии готовности каждой истории заведомо нарушаются еще при планировании? Может стоит всем напомнить о критериях и тогда окажется, что действительно, вся проблема в длине спринта? 🙂

Ну и напоследок, когда-то я публиковал описание упражнения «Переверни Монетку». Если смотреть на результаты этого упражнения, то становится видно, что отказ от традиционного «бери больше, кидай дальше, отдыхай пока летит» и переход к работе малыми пачками или вообще сосредоточении на одной функции и доведении ее до конца, дает общее ускорение выпуска продукта. Повторяя вышесказанное, если вы сможете гарантированно делать две истории в итерацию, это во много раз лучше с разных сторон.

Получается, что одним из препятствий этому является страх отказа от традиций: «Все будто боятся, что девелоперам будет нечего делать». По мне, так  пусть будут сидеть без дела, лишь бы это помогло улучшению общей ситуации. Может стоит просто попробовать? 🙂.

Надеюсь эти мысли вдохновят автора письма и его команду, а также помогут читателям. Отдельная просьба активно комментировать и кидать ссылки на другие статьи, где тоже объясняется «почему не заканчивать взятые в спринт истории плохо». Следите за будущими статьями, мы еще не раз затронем эту и многие другие интересные темы.