Отправляет email-рассылки с помощью сервиса Sendsay

100 ошибок применения Scrum

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Советы миллионеров - как стать богатым и знаменитым!?" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Май 2011   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Денис

Статистика

35 подписчиков
0 за неделю
←   Все выпуски   →

100 ошибок применения Scrum: Болезнь члена команды или Scrum-мастера


Всем доброго времени суток!

Прошу прощения, за столь продолжительный перерыв: совпала пора конференций и аврал на проекте.

Как и обещал сегодня об ошибках, которые можно допустить, если кто-то из команды или scrum-мастер (SM) заболел, и как избежать этих ошибок.

Начнем с наиболее вероятного случая - заболел член scrum-команды.

Обычно сотрудник заболевает по средине спринта :). В первую очередь, конечно, нужно оповестить владельца продукта (PO). Конечно, разрешать ему менять sprint backlog крайне нежелательно, но если вы видите, что это целесообразно, то можно.

После этого нужно сразу перепланировать спринт с учётом того, что в команде стало на одно бойца меньше. Этим планом поделиться с PO.

Если у вас длинные спринты, то можно предположить, что сотрудник выздоровеет до конца спринта (через неделю или через 2 - имеет смысл вести статистику, сколько обычно длиться болезнь у каждого из сотрудников :) ).

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

Соответственно, если сотрудник неожиданно выздоровел во время спринта, тут свои нюансы. Если он болел недолго, т.е. не требуется много времени для вхождения в проект, стоит сразу опять перепланировать спринт, хотя бы внутри (без оповещения PO). Можно и с PO, всё зависит от того как у вас оплачиваются итерации и насколько доверительные отношения с PO. Если перепланирует без участия PO и вы закончите задачи спринта раньше, то поступите так же как в случае не сработавших рисков: возьмете верхнюю задачу из бэклога продукта или из того стека задач, которые вы с PO отобрали как запасные на спринт.

Это всё имеет смысл конечно, если сотрудник выздоровел задолго до конца спринта, иначе его можно просто использовать для подстраховки. Тоже самое относится к случаю, если сотрудник болел достаточно долго и ему нужно время для вхождения в проект. Аналогично ведём себя в ситуации с новым сотрудником на проекте.

Про болезнь сотрудников, вроде всё. Теперь про то, что же делать, если заболел ОН – скрам-мастер. В хорошей scrum-команде по большому счёту скрам-мастер и не нужен, кроме случаев отражения внешних помех. Если команда сама опытна в скраме, самоорганизуема, мотивирована, она не заметят пропажу SM, если конечно, он не был сам членом команды.

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

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

PS: 4 июня выступаю на DevConf с докладом «Как не разочароваться в Scrum». Там буду рассказывать как про уже описанные в рассылке ошибки, так и про другие:

  • Планирование рисков в Scrum
  • 100500 ошибок Planning Poker
  • Вредные шаблоны поведения scrum-мастера

Удачи,
Денис
В избранное