Схема scrum — ежедневная работа внутри спринта

В этой, 12 статье из серии «Менеджмент цифрового мира», я продолжаю рассказ о схеме Scrum, начатый в предыдущей статье «Итерации Scrum – целостная схема, а не прикольная картинка».

Схема приведена на рисунке. В прошлой статье мы обсудили изменения, которые потребовал переход к инкрементальной поставки ценности, и процедуру планирования, начинающую спринт. А в эта посвящена организации работы внутри спринта. Казалось бы, что об этом писать? Делаешь себе задачи и делаешь, и получаешь результат ☺ На самом деле, там тоже много интересных особенностей, обеспечивающих успех метода.

Итак, мы рассмотрели подготовку и запуск спринта. После этого идет период ежедневного выполнения задач, в котором люди работают самостоятельно и автономно. Средством организации является доска Scrum, на которую помещены задачи. Сотрудник берет себе задачу, помечает на ней себя как ответственного и перемещает ее на доске в колонку, соответствующую выполняемым задачам, и затем ее выполняет. Колонок с выполняемыми задачами на доске может быть несколько, при этом в зависимости от разделения труда в команде, сотрудник может выполнять несколько этапов, или передавать задачу другим сотрудникам. Передача задач тоже происходит посредством доски, а не в прямой коммуникации: задача перемещается в колонку готовности к следующей фазе. И так – пока задача не окажется в колонке сделанных. О способах организации доски я подробно писал в статье «Доска - визуализация текущего состояния работы», и здесь останавливаться не буду.

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

Возникает вопрос: а какую задачу член команды должен взять с доски, когда он закончил предыдущую? Ответ: ту, взятие им которой наилучшим образом продвинет спринт к завершению. Это вопрос личного выбора, при котором он учитывает текущую ситуацию, представленную на доски, свои собственные компетенции и компетенции других членов команды. При этом, естественно могут быть приняты определенные правила, которые призваны облегчить выбор, сделать его быстрым. Например, правило выбирать самую важную задачу. Но правила могут быть и более сложными, например, в начале спринта приоритет может отдаваться задачам, которые на планировании оценили как наиболее рискованные по реализации, в том числе длительным, а в конце спринта, наоборот, небольшим задачам, чтобы уменьшить количество незавершенных задач. Могут быть правила, по которым при скоплении задач на поздних этапах исполнения часть членов команды переключались на них. То есть, если говорить об IT разработчики начинали заниматься тестированием, если тестировщики вдруг не успевают. Особую остроту это приобретает, если используются WIP- лимиты. Могут быть и другие правила.

Как правило, sprint backlog фиксируется при планировании. Однако, в конкретных командах может быть необходимо уметь включать в спринт дополнительные задачи, например, если команда не только создает новый функционал, но и устраняет ошибки в старом, или обрабатывает какие-то срочные обращения клиентов или поручения руководства.

Если срочные задачи появляются регулярно, то на такие задачи обычно выделяется резерв мощности команды при планировании спринта. Сгорание этого резерва можно отдельно рисовать на Burndown Chart снизу-вверх.

Управления срочными задачами также желательно вести через доску, а не прямыми поручениями. Задача может быть просто повешена на доску, если ее содержание ясно. Если требуются дополнительные пояснения, то хорошая практика – подождать до очередного Daily Scrum для информации всей команде.

Если задача имеет большой объем, то с Product Owner обсуждают не только ее содержание, но и изъятие соответствующего объема запланированных задач из числа тех, которые еще не начали выполнение. При этом важно, чтобы эти изменения не нарушили достижения целей спринта. Если изменения столь велики, что цель спринта не достигается, то текущий спринт следует прервать, и начать новый спринт, восстановив осмысленность движения.

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

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

Однако, запрету отвлекать есть важная причина, характерная для любых задач умственного труда: их выполнение требует погружения и сосредоточения, и нарушение этого представляет собой существенные накладные расходы. По опыту, задача на 2-3 часа требует около получаса погружения, поэтому если исполнителя пару раз отвлекли, то время выполнения возросло в полтора раза. Эти цифры – из моего опыта, но я слышал аналогичные цифры в разных докладах на конференциях, а быстрый поиск выдал, например, эту статью, в которой приведена близкая цифра со ссылкой на исследования.

Если члены команды видят реальные потери производительности из-за частых отвлечений, это следует обсудить на ретроспективе и договориться о правилах работы. Отметим, кстати, этот прием: если кто-то увидел проблему, он начинает немедленно возмущаться и пытаться решить, а фиксирует возникшее напряжение. А потом высказывает его на соответствующей встрече, в данном случае это ретроспектива, а в случае острой проблемы – daily scrum. А результатом обсуждения чаще является не просто выраженное намерение исправиться, похожее на детское «я больше не буду» или «я буду стараться», а правило, учитывающее разные классы ситуаций: «отвлекать можно в случаях 1-2-3, а в остальных не надо», или «отвлекать можно, если отложенное решение несет такие-то риски».

Хотя работа каждого члена команды идет автономно, необходима синхронизация движения. Для этого служит ежедневная встреча – Daily Scrum. В свое время он назывался StandUp meeting, потому что рекомендовалось проводить его стоя вокруг доски. Эта рекомендация по-прежнему актуальна, если команда сидит вместе, но в случае распределенной команды это невозможно. Отметим, сидеть в одном помещении, лучше – отдельном для команды также крайне важно. А проведение митинга стоя, а не сидя способствует, во-первых, тому, чтобы члены команды оторвались от своей текущей работы, а, во-вторых, не затягивали митинг. Это – статус, а не обсуждение работы.

Если на встрече выяснилось, что какая-либо задача требует отдельного обсуждения, то надо зафиксировать, и далее ответственный за задачу должен его отдельно организовать, например, сразу после митинга. Превращение Daily Scrum в обсуждение задач, а не статус – наиболее распространенная ошибка. Рекомендация продолжительности для Daily Scrum – 15 минут, и если команда систематически превышает его, то стоит подумать о причинах и способах сокращения. Что касается времени проведения, то его команда выбирает самостоятельно, с учетом индивидуального расписания работы ее членов. В те времена, когда все начинали работу одновременно, следуя корпоративным традициям хорошим вариантом было утро сразу после начала рабочего дня, но эти времена ушли в прошлое. Может быть выбрано время перед или после обеда, если команда обедает примерно в одно время. На Daily Scrum важно участие всех членов команды, и даже если по каким-то причинам они не могут быть лично, желательно дистанционное участие.

Процедура Daily Scrum следующая: люди говорят о том, что было сделано накануне с прошлой встречи, о том, чем предполагают заниматься, и о том, какие есть препятствия для движения вперед. Коротко. Как легко догадаться, при 15 минутах на команду из 7 человек каждому будет не более 2 минут. Поэтому препятствия – фиксируются и назначаются нужные обсуждения. В каком порядке говорят люди? Есть два подхода, наиболее простой – говорить по кругу. Другой порядок – на основе расположения задач на доске, начиная от крайне правой колонки, поскольку чем задача продвинулась дальше по этапам, тем важнее ее завершение.

Кроме статуса по текущим задачам Product Owner информирует команду о срочных задачах, включенных в спринт, и других важных изменениях. Но это не должно существенно увеличивать размер Daily Scrum, если требуется длительное обсуждение, то о его времени надо отдельно договориться.

Доска с задачами должна быть актуальна в любой момент для того, чтобы член команды мог выбрать очередную задачу. Но это относится к основной доске. Если команда использует электронную и физическую доску одновременно, или физическую доску и таск-трекер, то Daily Scrum является также точкой синхронизации досок, и по его итогам принято обновлять Burndown Chart. Процедура здесь произвольна, это вопрос самоорганизации команды, но забывать об этом не следует.

На этом я завершаю рассказ о работе внутри спринта, в следующей статье мы будем говорить про его завершение - Демо и Ретро. Продолжение следует...