Заметки по внедрению Scrum — что обязательно приведет к провалу итерации, если ничего не предпринимать

Ниже несколько, во многом очевидных, тезисов, которые могут помочь новичкам в Scrum

Немного о проекте и о командах.

Описанный проект — первый, на котором мы решили применить Scrum в полной мере.
До этого работали по итерациям, но без Stand-up митингов, Ретроспектив и Демок.

Работы над проектом ведут две команды.

Команда 1 создает систему документооборота, в которой будут готовиться данные для некого приложения, которое разрабатывает Команда 2.

Из-за этого в определенных итерациях мы пересекаемся и сильно зависим друг от друга

Итак.

1. В планированиидолжна участвовать вся команда

Из практики:
При планировании первой итерации по проекту не пригласил двух разработчиков (Вася и Петя) поскольку предварительно оговорили с Васей их объем работы устно.

В итоге в средине первой недели итерации стало очевидно, что часть работ не была учтена и не была зафиксирована на доске.

Результат:
неточная оценка работ и задержка в передаче данных смежникам. Как раз на этой итерации от нас сильно зависела смежная команда.

2. Контроль зависимостей между задачами внутри одной команды

Из практики:

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

Результат:

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

Что делать:

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

Также необходимо все выявленные зависимости разместить на доске для визуализации и контроля.
У нас это отдельная область на доске со стикерами типа «Вася должен Пете», «Петя должен Маше» и т.п.

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

3. Фиксирование договоренностей внутри команды

Из практики:

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

Участники команды устно договариваются что задача будет делаться на технологии N или активно утверждают, что эту задачу легко сделать на технологии N с одной стороны и также легко сделать на технологии J с другой стороны, но в итоге расходятся, не решив кто конкретно делает задачу.
Вообщем, поболтали и разошлись.
Возможно, это выглядит не серьезно, но у нас это случилось на одной из итераций.

Результат:

Задача была не выполнена. Когда подошел срок сдачи большой задачи — формат поля не устроил смежную команду и пришлось переделывать бОльше, чем если бы сразу сделали.

Что делать:

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

4. Взаимодействие со смежными командами по задачам с зависимостями

Из практики:

Команда 1 реализовала отдачу данных для Команды 2 и приступила к другим своим задачам. Через 3 дня Команда 2 обратилась к Команде 1 — данные не заливаются/данные не валидные и т.п.

Результат:

Команда 2 простаивает ожидая данных, которые по мнению Команды 1 уже отданы.
Этот простой потом еще аукнулся всем.

Что делать:

1. В Команде 2 определяется разработчик, который «принимает» данные
2. После завершения работы над задачей разработчик Команды 1 уведомляет разработчика Команды 2 — «готово, проверяй»
3. После Stand-up митинга, на котором задача с зависимостями ушла в тестирование, Scrum-мастер Команды 1 уведомляет об этом Scrum-мастера Команды 2
4. После того, как Команда 2 подтвердила, что данные получены, задача переносится в Готовые на доске.

5. Правильная оценка задачи или не бойтесь их переоценивать во время спринта.

Из практики:

Несколько дней на доске «в процессе» висит задача оцененная в несколько часов.

Причина — разработчик наткнулся на какой-то баг и не может в нем быстро разобраться

Мнение: если такие задачи будут часто висеть «в процессе», доска потеряет эффект «потока»

Что делать:

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

6. Обязанности должна брать на себя команда, а не только Scrum-мастер

Из практики:

В течении нескольких Stand-up митингов Scrum-мастер обязывался предоставить нужные данные смежникам, но в итоге по разным причинам этого не происходило.

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

Вместо вывода

Ту первую итерацию мы таки провалили.

После разобрали ситуацию на ретроспективе — тут главное не раздавать обязанности разработчикам, а подвести их к тому, чтоб они сами взяли обязанности на себя.
Следующую итерацию мы выполнили в срок с уверенным запасом.

А какие очевидные и не очень ситуации в вашей команде приводили к провалу итерации?

Автор: rezhisser

Источник ^[1]