Недавно один знакомый Скрам-Мастер написал мне письмо с просьбой помочь ответить на ряд любопытных вопросов. Когда-то я обучал эту команду на этапе «запуска 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-критерии), выработанные на уровне всей компании. Получается, технические критерии готовности каждой истории заведомо нарушаются еще при планировании? Может стоит всем напомнить о критериях и тогда окажется, что действительно, вся проблема в длине спринта? 🙂

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

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

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

Кейс о Короткой длине спринтов о том, Почему не заканчивать историю в спринте плохо, и Истинных проблемах этого
Tagged on:             
  • Тим, спасибо за, как всегда, полезный и информативный пост.

    Еще одно наблюдение на тему девелоперы против тестировщиков: бытует мнение, что задача тестировщиков — найти ошибки, чтобы девелоперы могли их исправить. Что в корне неправильно! Это как раз и закладывает основу смещения циклов разработки и тестирования и размазывает поставку полноценно реализованной истории на 3 спринта: (1) — сделали первое приближение, (2) — протестировали, (3) — исправили баги.

    Задача тестировщиков — подтвердить готовность системы к релизу. И от девелоперов она должна выходить уже такой — готовой. Критерии готовности здесь очень помогают.

    • Дима, отличное дополнение.

      Мне тоже кажется, что корни зла нужно искать в Done Criteria. Могу поверить, что регрессионное тестирование не влазит в спринт, но чтобы простая верификация. Про возможную автоматизацию Acceptance Testing я уже молчу 🙂

  • Pingback: Боремся с бесконечными итерациями « XP Injection()

  • Mikalai Alimenkou

    В комментарий не влез. Написал отдельным постом: http://xpinjection.com/2011/11/29/stop-endless-iterations/.

  • Всё же не убедил.
    Исходная проблема в том, что истории длинее спринта. Речь я так понял не идет о «бесконечных историях», просто остаются истории, по которым закрыта часть задач.
    1) Не вижу демотивации. Работа идет, идет по плану, финиш виден.
    2) Если такие истории есть постоянно, то скорость работы будет реальная. Да, мы не закрыли часть историй этого спринта, но мы закрыли примерно столько же с прошлого
    3) А кто говорит о неработающем релизе? Просто этот функционал войдет в следующий. Сейчас это незадействованый (но оттестированый) код.
    4) Короткие истории это супер, но не ясно чем исскуственное деление логичной атомарной «длинной» истории может помочь процессу.

    • Ws171913

      1. демотивация в том, что обещали и не сделали. И то что ситуация стабильна совсем не значит, что она хорошая
      2. все правда. но с другой стороны, зачем себя обманывать?
      3. если код оттестированый, то проблемы нет. и релиз работает. но почему тогда функционал не закрыт? раз не закрыт, то что-то все же не работает, а значит о работающем релизе тоже говорить нельзя
      4. исскуственно и не надо. но если стабильно половина истории остается, значит стабильно половину историй делим между спринтами. не лучше ли тогда уже делить сознательно. Кроме того если история большая, а мы не в состоянии поделить ее на этапы разработки, то и над коректной разработкой вероятно не задумались. Принимая практики  постояной интеграции и каждодневных commitов так или иначе работу надо делить на более или менее завершенные части.

      • Vitalii

        Грубо говоря, вопрос в том, что есть история — то, что влазит в спринт или законченый кусок бизнес требований. Можно и так и эдак, но у каждого варианта свои минусы. Третий вариант — увеличивать спринт (или отказываться от такового). Я предпочитаю, чтобы история таки отражала бизнес, а не процесс.