Отправляет 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
Автор
Денис

Статистика

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

500 ошибок применения Scrum: Поехали!


Коллеги, рад приветствовать вас в рассылке «100 ошибок внедрения Scrum»!

Я уже писал про то, как важно осознанно применять практики Scrum’а  и обещал продолжить. Продолжить решил в формате настоящей рассылки.

Сегодня мы рассмотрим две ошибки, которые обычно встречаются вместе, но бывают и исключения. Я хочу рассказать о

  • scrum-мастере внутри scrum-команды
  • и о растягивающихся спринтах

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

Чтобы понять чем же чревата ситуация, когда scrum-мастер одновременно является членом команды, для начала вспомним функции scrum-мастера:

  • Создает атмосферу доверия,
  • Участвует в митингах в качестве фасилитатора
  • Устраняет препятствия
  • Делает проблемы и открытые вопросы видимыми
  • Отвечает за соблюдение практик и процесса в команде

(http://citforum.ru/SE/project/scrum/)

А теперь представьте, что scrum мастер такойже разработчик, как и все остальные участники команды, у него теже мысли и проблемы, что и у команды: кодить в начале проекта не хочется, daily scrum только отвлекает от работы и бесполезен, если что-то не доделано к концу спринта, оттягивает завершение спринта, пока не доделает и т.д.

Одним словом, такой scrum-мастер погружается в кодирование, и забывает о более значимых задачах, которые на него возложены, даже если он знает про них, где-то в глубине сосзния.

Отсюда в общем и вытекает вторая ошибка: «резиновые» спринты. Согласитесь, никому не хочется бросать дело на середине, а особенно когда конец уже кажется близким. Еще ситуация может усугубляться тем, что кроме этого в течении спринта ничего не успел больше сделать. Тогда хочется во чтобы то нистало закончить до окончания спринта, что выливается в засиживания до поздна, недосыпаия и откладывание завершения спринта, если сам scrum-мастер поддался этому соблазну.

Решения

Scrum-мастер внутри команды

Исправления этих ошибок могут быть разные. Во-первых нужно себе как scrum-мастеру сделать постоянные напоминалки, типа «Ты – scrum-мастер, следи за процессом», «Алёооо! Daily Scrum – успех проекта зависит от тебя, соблюдай практики!» и т.д. Для кого что подействует…

Второй вариант, более эффективный, вывести scrum-мастера из scrum-команды. Но здесь тоже могут быть подводные камни. Scrum-мастеринг обычно не занимает 100% времени даже для самой плохой команды, поэтому, вероятно, scrum-мастер будет занят на каком-то еще проекте и может возникнуть вопрос приоритетов: он опять же может уйти с головой в другой проект и забывать о части своих обязанностей как scrum-мастера.

Пожалуй, самый правильный выбор, если scrum-мастером будет руководитель проекта. Во-первых он как никто другой заинтересован в успехе проекта, а во-вторых обычно менеджеры имеют больше опыта заниматься параллельно несколькими активностями без «провисания» какой либо одной.

Если Вы всё-таки стали scrum-мастером, и вы не являетесь ПМом этого проекта (Вы либо член команды, либо вообще вне проекта), то можно порекомендовать выделить какое-то время в день, которое вы будете полностью посвящать scrum-мастерингу, забывая все остальные роли и проблемы, с ними связанные.

«Резиновые» спринты

Что же делать, если вы не уложились в спринт? Есть ли какие-то максимально дозволенные сроки растягивания спринта? На эти вопросы встретить ответ можно гораздо чаще.

Как бы мало вы ни сделали в течение спринта завершать его нужно всегда в срок. В этом сила Scrum’а, иначе можете не рассчитывать на profit от применения методологии.

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

Естественно, о просрочке нужно сообщать владельцу продукта (product owner) причем не в конце спринта, а как только вы поймёте, что не успеваете, он будет вам только благодарен, ибо сможет скорректировать свои планы, зависящие от проекта.

И ещё один важный момент: всё, что не успели сделать, включается в следующий спринт. Естественно, что времени на добавление нового функционала остается меньше времени. Владелец продукта, может при этом выбросить или отложить некоторый функционал, недоделанный в завершённом спринте.

На сегодня всё! В следующий раз поговорим про ошибки при проведении daily scrum:

  • Отсутствие daily scrum как таковых
  • Формальные daily scrum
  • Привычка давать «втык» за лень или просрочку
  • Превращение daily scrum в многочасовое заседание

 

C наилучшими пожеланиями, 
Денис
В избранное