Статья о практическом опыте внедрения Scrum в компании CustIS. Презентация - http://www.slideshare.net/biBIGine/scrum-2029850

1. Практика внедрения Scrum:
трудности и пути их преодоления
Бибичев Андрей (andrew@custis.ru)
15 апреля 2008 года
Введение
Данный доклад основан на реальном опыте внедрения методологии Scrum в компании
«Заказные ИнформСистемы», занимающейся заказной разработкой ПО корпоративного
(enterprise) уровня. Решение о переходе на Scrum начало созревать летом прошлого (2007-
ого) года, в сентябре того же года Scrum внедрили в первых трех командах. Сейчас по
этой методологии работает 5 проектных групп (каждая – от 5 до 12 человек, включая
разработчиков, аналитиков, инженеров-тестировщиков). И пока еще живы воспоминания
о тех сложностях, с которыми пришлось столкнуться при внедрении и уже во время
использования Scrum, хочется ими поделиться.
Все трудности можно разделить по стадиям, на которых они возникали:
• принятие решения о переходе на Scrum;
• перевод первых команд на Scrum;
• использование Scrum (около полугода);
• перевод последующих команд на Scrum.
Именно в таком порядке о них и поговорим.
Но прежде, всё же, пара слов о самой методологии.
Три кита Scrum
Краткое описание методологии Scrum можно найти в Wikipedia и на сайте agilerussia.ru:
• http://en.wikipedia.org/wiki/Scrum_(development)
• http://agilerussia.ru/index.php?option=com_content&task=view&id=16&Itemid=29
Весьма увлекательное и подробное описание практического опыта совместного
использования Scrum и XP приведено в книге «Scrum and XP from the Trenches», которая
послужила для нас своего рода отправной точкой, если не сказать «библией Scrum».
Именно благодаря этому труду мы заразились идеей Scrum. Электронная версия данной
книги доступна для свободного скачивания:
• http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Здесь же хочется кратко остановиться только на трех ключевых моментах, которые
делают методологию Scrum столь успешной (по нашему мнению):
Эффективные коммуникации
Достигается за счет обязательного активного участия всех членов команды в сессии
планирования, демонстрации, ретроспективе, а также ежедневных Scrum-митингах.
(с) Заказные ИнформСистемы, 2008 год 1

2. Обеспечивает хорошее и качественное распространение информации. Повышает
вовлеченность членов команды в процесс создания качественного ПО.
Во время совместных обсуждений с фломастером у доски рождаются лучшие идеи и
концепции, наиболее эффективно передается информация и know-how.
Самоорганизация внутри команды
Помогает «не убить» самомотивацию. Обеспечивает автоматическую подстройку под
обстоятельства. Подталкивает членов команды к кросс-функциональности. Разгружает
управляющее звено от принятия лишних решений.
Снежинка является достаточно ярким примером эффективной самоорганизации в природе
– попробуйте сконструировать такое вручную…
Жесткий time-boxing
Заключается в следующем:
 дата окончания итерации жестко фиксируется и не переносится
 объем работ тоже фиксируется на итерацию и должен соблюдаться
 время ежедневных Scrum-митингов жестко фиксируется в рамках итерации
Отход от этого – форс-мажор (бывает, но не должно быть чаще, чем раз в 4-5 итераций).
Обеспечивает предсказуемый, управляемый и абсолютно прозрачный ход проекта.
(с) Заказные ИнформСистемы, 2008 год 2

3. Принятие решения о переходе на Scrum
Итак, кто-то в компании заражается идеей внедрения Agile-методологии. И здесь
возникают проблемы:
• какую из Agile-методологий выбрать;
• как убедить руководство в том, что это действительно правильный путь;
• нужна пропаганда и разъяснение в массах трудящихся.
Что касается первой проблемы, то здесь было относительно несложно. Внимательно мы
рассматривали только eXtreme Programming (XP), Scrum, Feature Driven Development
(FDD) и Open Unified Process (OpenUP). Что касается первых двух, то между ними и
выбирать особо не надо, так как сейчас стандартом де-факто является использование
Scrum, дополненного практиками из XP, касающимися чисто программирования (unit-
тесты, непрерывная интеграция и т.д.). Что же касается последних двух, то они показались
более сложными и тяжеловесными, т.е. потенциально более трудными во внедрении и
следовании им. Кроме того, мы нашли хорошего внешнего консультанта по Agile-
методологиям, который специализируется на внедрении именно Scrum. Так что решение
было по сути предрешено: уж если мы не сможем у себя внедрить Scrum, то вряд ли мы
вообще способны внедрить какую-то готовую стандартную методологию ведения
проектов (до этого у нас, как и у многих, были свои внутренние методологии, которые
зачастую отличались от проекта к проекту).
(с) Заказные ИнформСистемы, 2008 год 3

4. А вот убедить руководство оказалось не такой простой задачей. Сейчас это несколько
странно уже вспоминать, но основное беспокойство у руководящего состава компании
вызвала идея о самоорганизации внутри команды. Опасения были такие:
• активные будут брать себе всю самую интересную работу, а более скромные
довольствоваться тем, что осталось;
• ставит под удар индивидуальные планы развития;
• рушит организационную структуру внутри проектных групп;
• пропадет персональная ответственность за результаты труда;
• усложняет систему компенсации (как определить вклад отдельных членов группы в
общий результат).
Весь дальнейший опыт внедрения и применения Scrum показал, что все эти опасения
оказались совершенно напрасными: никаких проблем самоорганизация внутри команды не
принесла. Более того, она помогла выявить скрытых лидеров, которые стали своего рода
«моторами» проектных групп в новых условиях.
Так как же удалось преодолеть первоначальный скепсис? Здесь четкого рецепта нет. В
нашем случае помогли многочисленные обсуждения, изучение уже упомянутой книги
«Scrum and XP from the Trenches».
Что же касается пропаганды и разъяснений в массах трудящихся, то для этого был
проведен внутренний семинар, на котором рассказывалось про Agile вообще и Scrum в
частности. Интересно, что во время проводившихся позднее тренингов выяснилось, что
качество усвоения этого семинара было не особо высоким, так что, возможно, следовало
уделить значительно больше внимания «просветительской» работе.
Перевод первых команд на Scrum
Итак, коли вы решились пробовать Scrum, то перед вами почти неизбежно возникают
следующие задачи:
• выбор тренера/консультанта;
• выбор команды (или команд), на которой (ых) будет поставлен эксперимент;
• подбор параметров для команды (длина итерации, единица оценки трудоемкости,
начальное приближение для Focus factor-а, Scrum-мастер);
• как, собственно, внедрять.
Выбор тренера/консультанта
Тренера мы искали/выбирали пару месяцев. Так долго не потому, что выбор большой, а
потому, что не верилось, что этого самого выбора почти нет. Зато в своем выборе мы не
разочаровались! Так что если кому нужен Agile-тренер/консультант, можем
порекомендовать .
Выбор команды (команд)
Это тонкий вопрос. В качестве «пионера» не стоит использовать слабую команду: процесс
у них не будет ярким; они, скорее всего, не станут примером для подражания; слабые
команды очень не любят изменения (для них это реальный стресс). Но и команду, у
которой всё хорошо (скорее, которая сама так считает), тоже лучше не трогать на первом
этапе, так как и в такой ситуации воли к переменам внутри команды, вероятно, будет
недостаточно. Идеально подходит сильная команда, у которой накопились какие-то
проблемы и трудности, так что большинство членов команды искренне чувствуют, что
(с) Заказные ИнформСистемы, 2008 год 4

5. нужны перемены. Именно по такому пути мы и пошли, и хочется отметить, что сейчас это
одна из самых ярких команд, хотя остался ряд проблем и еще есть, куда расти.
Естественно, какой бы выбор не был сделан, он должен быть согласован с
руководителями проектов и лидерами команды. Как правило, непосредственно перед
началом внедрения Scrum проводится несколько консультаций руководителей и лидеров с
Agile-тренером.
Сколько команд? Для начала лучше совсем немного, так как на начальном этапе
приходится достаточно активно помогать командам осваивать ключевые практики Scrum
(как планировать, как проводить Scrum-митинги и ретроспективу, обязательно
присутствовать на демонстрации). Мы начали с одной командой, а через несколько недель
прибавилось еще две. Потом была достаточно долгая пауза – учились, привыкали,
набивали шишки.
Подбор параметров для команды
Оставьте команде максимум свобод в выборе личного стиля: где и как вести Product
Backlog, кто Scrum-мастер, какова длина итерации, в каких единицах проводить оценку
трудоемкости. Но на начальном этапе важно помочь команде советом и консультацией,
чтобы подобрать хорошее начальное приближение для этих параметров.
Большинство команд у нас начинали со следующих значений параметров:
• длина итерации – 2 календарных недели (10 рабочих дней);
• единица оценки трудоемкости – идеальные человеко-часы (или человеко-дни для
крупных задач);
• способ оценки трудоемкости – Planning Poker;
• Focus-factor (коэффициент для пересчета из рабочих часов в идеальные) – 0.5;
• Scrum-мастер – самовыдвиженец (член команды, сам вызвавшийся быть Scrum-
мастером);
• время начала Scrum-митинга – в 12:00 или 15:00;
• ведение Product Backlog-а в Excel-файле (с проносом в систему ведения дел для
всех задач текущей итерации).
Со временем поменялись, по сути, только Focus-factor и время проведения Scrum-
митингов. Сейчас все пять команд используют двухнедельные итерации, а Focus-factor
разнится от 0.4 до 0.65.
(с) Заказные ИнформСистемы, 2008 год 5

6. Что же касается выбора Product Owner-а, то это прерогатива менеджмента. У нас в
большинстве случаев им стал руководитель проекта.
Как внедрять
Главное – быстро:
• через несколько дней после консультаций с руководителями и лидерами команды
проводится общий тренинг для всей команды, на котором объясняются базовые
принципы Agile и Scrum, проводятся деловые игры для освоения базовых практик;
• на следующий день после тренинга начинается первая итерация (точнее,
«нулевая», т.е. пробная): в присутствии тренера команда обсуждает задачи на
итерацию, дает им оценку трудоемкости, формирует объем работ на итерацию;
• несколько раз за этот спринт (итерацию) на Scrum-митингах присутствует тренер и
помогает команде поправить ключевые ошибки;
• первые демонстрацию и ретроспективу также помогает провести тренер, причем на
демонстрации он выступает, скорее, в роли наблюдателя, а вот на ретроспективе –
в роли ее ведущего, демонстрируя Scrum-мастеру стиль и приемы;
• приглашать на первую же демонстрацию представителей заказчика или нет –
решается по обстоятельствам (мы приглашали только в одном случае из пяти).
Дальше тренер помогает всё меньше и меньше, но важно, чтобы у Scrum-мастера всегда
была возможность проконсультироваться с ним по животрепещущим вопросам (по
телефону, электронной почте, ICQ и т.д.).
Опыт работы по методологии Scrum
Вот здесь и начинается самое интересное!
Одна команда, несколько проектов/модулей
При переводе первой же команды на Scrum мы столкнулись с вопросом: как быть, если
одна команда ведет разработку нескольких проектов/модулей? Априори нам почему-то
казалось, что нельзя в один спринт (итерацию) «замешивать» задачи, относящиеся к
разным проектам. Нам подсказали, что это надуманное ограничение и совершенно
свободно можно выполнять задачи, относящиеся к разным проектам/модулям, в рамках
(с) Заказные ИнформСистемы, 2008 год 6

7. одного спринта, главное – чтобы Product Owner был один. И это действительно неплохо
работает.
Однако дальнейшее развитие событий показало, что есть серьезные трудности с
достижением кросс-функциональности в таких командах:
• до перехода на Scrum отдельные члены команды специализировались на отдельных
проектах/модулях, так что слабо разбираются (а зачастую и вообще не
разбираются) в другой части;
• поэтому когда в спринте оказывается задача по их профилю специализации, они
берут именно ее, и очень немногие пытаются расширить свой кругозор, взяв
задачу, относящуюся к слабо знакомой области.
Как с этим можно пытаться справиться:
• по договоренности с Product Owner-ом несколько спринтов по возможности
сделать узко специализированными (целый спринт должен быть посвящен
преимущественно одному проекту/модулю) – тогда всем членам команды просто
неизбежно придется поработать над данным проектом/модулем;
• несколько первых итераций активно использовать парную работу: тот, кто хорошо
разбирается в соответствующей части функциональности, садится в пару с тем, кто
плохо разбирается в этой части функциональности, и они вместе делают задачу.
Практика показывает, что это весьма и весьма эффективный способ передачи
знаний и навыков. В отличие от XP, мы у себя не проповедуем постоянную работу
в паре, но в подобных ситуациях, на наш взгляд, это одно из наиболее
эффективных решений;
• если команда большая (больше 8-ми человек) и проектов/модулей у нее «сильно
больше одного», то разумно попытаться разделить эту команду на две.
Здесь надо отметить, что несмотря на все эти приемы, в части команд у нас до сих пор
остаются проблемы с достаточно сильной специализацией отдельных членов команды на
отдельных проектах/модулях/компонентах. Конечно, эта специализация постепенно
ослабевает, появляются «полиглоты», но до той самой идеальной кросс-
функциональности нам еще идти и идти…
Taskboard
Далее заметили интересный нюанс: сделанная на этапе планирования спринта оценка
трудоемкости зачастую мешает при работе над задачей:
• “у меня есть еще N часов, согласно сделанной трудоемкости, так что я могу их
потратить на дальнейшую шлифовку и полировку написанного кода”;
• “ой, у меня уже не осталось времени на решение этой задачи, так что вскрывшиеся
сложности и нюансы я так и оставлю без внимания”.
Здесь важно помнить, что оценка неизбежно условна и имеет большую погрешность, так
как крайне редко мы обладаем полными сведениями о задаче на этапе планирования.
Феномен эффективности планирования заключается в усреднении: по людям (кто-то
(с) Заказные ИнформСистемы, 2008 год 7

8. работает более эффективно, кто-то менее) и по задачам (какие-то задачи оказываются
недооцененными, а какие-то – переоцененными). Так что не следует выполнять
сравнительный анализ план-факт по отдельным задачам, это имеет смысл делать только
по общим планам и фактам на целый спринт (итерацию). Осознав такую проблему, мы
стали писать оценку трудоемкости на оборотной стороне бумажек, вывешиваемых на
Taskboard, и перестали проносить ее в электронную систему ведения дел.
Оказалось не всё так просто и с самим обустройством Taskboard-ов: липкие стикеры
плохо держатся на металлических досках. Вот если бы это было единственной проблемой!
 Возможных решений здесь два (мы используем оба):
• накупить побольше магнитиков и прижимать стикеры ими;
• использовать пробковые доски, к которым «пришпиливать» стикеры.
Scrum-митинги
Дальше, естественно, заметили более серьезные проблемы. Почти у всех команд были (а у
некоторых и до сих пор остаются) те или иные трудности с проведением Scrum-митингов:
• на Scrum-митинге присутствуют не все члены команды (опоздания);
• Scrum-митинг превращается в отчет членов команды перед Scrum-мастером;
• Scrum-митинг затягивается и переходит в обсуждения.
Что касается опозданий, то это у нас в первую очередь связано с гибким графиком, по
которому работают сотрудники компании. Формально рамки у этой гибкости есть и
достаточно четкие, но фактически график многих сотрудников настолько гибок, что
выходит за эти самые рамки. И здесь следует отметить следующий факт: хотя и
рекомендуется проводить Scrum-митинг утром, но значительно важнее, чтобы все члены
команды могли на нем присутствовать. Так что сейчас в трех командах из пяти Scrum-
митинги проходят в 15:00, что совсем не утро… В других двух – в районе 12, что уже как-
то больше напоминает утро (особенно по меркам нашей компании ). Т.е. время митинга
нужно выбирать так: самое раннее из гарантировано подходящего всем членам команды.
Здесь еще хочется сделать предостережение: очень опасно, если компания начнет
навязывать для команд какие-либо штрафные санкции за опоздание на Scrum-митинг –
для нашего менталитета нет ничего хуже подобной принудиловки. Пускай каждая
команда самостоятельно (на ретроспективах) решает как «штрафовать» за опоздание и
стоит ли это вообще делать. Вначале у нас были всякие идеи о pizza-фонде, и даже очках,
в которых измеряется карма, но в итоге ни одна из команд не использует подобные
практики, т.к. они скорее демотивируют, нежели стимулируют.
Следующей трудностью, как указано выше, оказалось превращение Scrum-митингов в
отчет Scrum-мастеру. Причин тут сразу две:
• Scrum-мастер очень строго спрашивает: “что делал вчера?”
(с) Заказные ИнформСистемы, 2008 год 8

9. • Сотрудник моментально распознает в этом менеджерские нотки, по привычке
подсознательно решает, что перед ним новый (еще один) менеджер, и начинает
давать формальный отчет Scrum-мастеру.
Это очень неприятные тенденции, которые мы наблюдали сразу в двух командах. Здесь
помогают следующие приемы:
• разъяснительная работа со Scrum-мастером (чтобы вопросы его задавались с
нейтральными интонациями и без напора, чтобы во время рассказа члена команды
Scrum-мастер не смотрел ему в глаза или даже уходил за спину говорящего);
• разъяснительная работа с командой (что Scrum-митинг – это для всех, что
менеджеров на Scrum-митингах нет, а если и есть, то они обязаны молчать и т.д.).
Кроме того, практика показывает, что со временем это и само во многом исправляется:
команда привыкает к Scrum-митингам и роль Scrum-мастера становится менее значимой
(как правило, и вопросы уже не нужно задавать – за несколько раз все их выучивают
наизусть и можно использовать просто передаваемый из рук в руки карандашик или
ручку, чтобы понимать, чья очередь говорить).
Ну и наконец: Scrum-митинг затягивается и переходит в обсуждения. Это наблюдается
тоже достаточно часто. Как здесь быть: в такой ситуации многое зависит от навыков
Scrum-мастера (нужно уметь оборвать развертывающееся обсуждение, взять его «на
карандаш» и отложить до «после Scrum-митинга»). Некоторые команды у нас используют
песочные часы, чтобы лимитировать время, отводимое для рассказа одного участника.
Ретроспектива
Ретроспективу либо вообще пропускают (как правило, это команды, только перешедшие
на Scrum), либо со временем она вырождается в формальность (а это характерно для
команд, несколько месяцев практикующих Scrum). И это весьма обидный факт, так как
ретроспектива важна – это не только точка подстройки процесса, но и возможность
каждому высказаться, повлиять на развитие команды, снять какие-то напряженности и
недомолвки.
С первым проявлением (ретроспективу пропускают) легко бороться просвещением и
помощью:
(с) Заказные ИнформСистемы, 2008 год 9

10. • еще раз поговорить со всей командой о ретроспективе: что это, зачем она нужна, в
чем польза и незаменимость;
• несколько раз пригласить опытного Scrum-мастера из другой команды или
внешнего тренера в качестве ведущего ретроспективы;
• а потом еще несколько последующих ретроспектив – в качестве наблюдателя.
Что же касается второго (перспектива вырождается в формальность), то здесь главное
сильно не переживать: в конце концов ретроспектива – это не самоцель, и если всё идет
гладко, то и действительно особо нечего улучшать в процессе. Опыт показывает, что раз в
4-5 итераций даже в полностью налаженной и привычной работе случаются проблемы и
сбои, так что в такие спринты ретроспектива неизбежно возрождается в полной красе.
Кроме того, внешние обстоятельства и состав команды тоже со временем меняются, так
что и здесь на выручку приходит ретроспектива.
Есть способы, как «освежить» ретроспективу и в достаточно стабильных условиях:
• менять ведущих (ничего страшного, а даже очень интересно, когда ретроспективу
ведет не Scrum-мастер, а кто-то другой из вашей команды или даже кто-то
приглашенный из другой команды);
• обсуждать более широкий круг вопросов (прочитанные книги по IT, посещенные
конференции и т.п.).
Еще хорошим подспорьем может послужить книга «Agile Retrospective: Making Good
Teams Great». В ней приведены целые наборы приемов и методов для проведения каждого
из этапов ретроспективы, так что из них можно компоновать свой собственный
(неповторимый) сценарий.
Демонстрация
С демонстрацией связаны следующие сложности:
1. зачастую тяжело обеспечить присутствие заказчика на демонстрации;
2. демонстрация затягивается из-за технических проблем (заранее не подготовлено
тестовое окружение, не удается выполнить тестовый сценарий, так как чего-нибудь
для этого не хватает и т.д.);
3. во время демонстрации по отдельным задачам выясняется, что сделано не то или
не в полном объеме.
Что касается присутствия (точнее, отсутствия ) заказчика, то это, как правило,
объективные обстоятельства, под которые проще подстроиться, чем преодолевать их.
Подстроиться проще всего следующим образом: хотя бы раз в пару итераций устраивать
повторные «выездные» демонстрации, т.е. на территории заказчика и в удобное для
заказчика время. На этих демонстрациях не присутствует вся команда, а всего один-два
человека от команды. На этих демонстрациях не показываются внутренние и
вспомогательные работы. Но, несмотря на это, такие демонстрации крайне важны, и
нужно всячески стремиться к тому, чтобы они проводились с завидной регулярностью.
Это не только обеспечит команду столь необходимым в Agile-разработке feedback-ом, но
и будет наглядно демонстрировать заказчику ход, темп и качество работ.
Технических и организационных проблем на демонстрации в идеале быть не должно, так
как это время всей команды, да еще и пришедших заинтересованных лиц (stakeholder-ов),
т.е. не только время, но и лицо команды. Совет банальный: к демонстрации надо
готовиться, надо четко выделять время в конце итерации на подготовку к демо, надо
иметь готовое функционирующее тестовое окружение, подходящее под нужды и цели
(с) Заказные ИнформСистемы, 2008 год 10

11. итерации и т.д. Для обсуждения подобных проблем и задач есть ретроспектива. Команда
сама должна решить, что ей нужно предпринять, чтобы демонстрации были максимально
четкими и проходили гладко.
Ну и наконец, ситуация «делали-делали, а недоделали или вообще не то сделали». Чтобы
этого не было, обязательно следует придерживаться следующих правил:
• в Product Backlog-е для каждой задачи (item-а) должно быть краткое, но
содержательное описание «Как демонстрировать»;
• во время спринта каждый реализованный пункт Product Backlog-а в обязательном
порядке должен проходить фазу верификации (тестирования), на которой нужно не
забыть сопоставить то, что получилось, с тем, что описано в «Как
демонстрировать».
Правда и этого бывает недостаточно. Очень часто во время планирования по задаче
выясняются нюансы, дополнительные детали, формируется картина как это должно быть
сделано. Оценка трудоемкости дается именно исходя из этого, а когда дело доходит до
реализации, часть этого понимания и знания, как правило, уже забывается. Чтобы
справиться с этим, часть команд у нас рисует «vision» задачи во время планирования: на
листе A4, от руки, очень кратко и тезисно (просто, чтобы сработал ассоциативный ряд).
Этот «vision» просматривается перед тем, как непосредственно приступить к работе над
задачей (чтобы освежить в памяти результаты обсуждения этой задачи во время
планирования), а также используется на этапе QA, т.е. проверки.
Time-boxing
Во многом, эта ахиллесова пята всех Agile-методологий: трудно объяснить менеджменту
преимущества гибких методологий, если даже краткосрочные планы не выполняются.
При этом важно, чтобы команда сама искренне стремилась к максимально четкому
соблюдению жесткого time-boxing-а, так как Agile работу «из-под палки» не предполагает.
Части команд это присуще как-то само по себе, с такими командами в этом плане проблем
почти нет. Но есть и другая часть – проблемная.
Так что же делать, если у команды не хватает (само)мотивации на соблюдение жесткого
time-boxing-а, т.е. команда не борется за выполнение взятых на себя обязательств в
полном объеме?
Есть мнение, что такая ситуация, как правило, возникает в командах, в которых нет
сильного яркого лидера, т.е. своего рода «мотора». Но это достаточно тонкий и скользкий
вопрос. И даже если допустить, что это действительно всецело так, то всё равно такого
лидера найти ой как не просто, его адаптация к команде (и команды к нему) в любом
случае займет немало времени, а проблему соблюдения планов нужно решать здесь и
сейчас.
И здесь на выручку может придти следующий нехитрый совет: чем выше и активней
интерес к проекту «со стороны» (т.е. извне команды), тем выше (само)мотивация внутри
команды. Таким образом, очень важно, чтобы проектом интересовались, причем делали
это активно, открыто и доброжелательно:
• присутствие представителя заказчика на сессии планирования поможет точнее и
качественнее сформировать объем (scope) работ на итерацию;
• здорово, когда хотя бы на нескольких Scrum-митингах за итерацию присутствуют
Product Owner, руководитель проекта, может даже представитель HR-отдела –
команда чувствует, что ходом работ интересуются, т.е. многим вокруг важно, что и
(с) Заказные ИнформСистемы, 2008 год 11

12. как они делают (только помните, что эти «гости» не должны вмешиваться в ход
Scrum-митинга, а могут только молча наблюдать);
• крайне важно, чтобы на демонстрации были сторонние зрители, а иначе всё это
рискует выродиться в скучный показ для самих себя. Если удается обеспечить
присутствие представителей заказчика, то вообще здорово! Но даже и без этого
можно хорошо оживить демонстрацию, позвав коллег-экпертов из других команд,
главного архитектора, представителей руководящего звена.
Кстати, интересно отметить еще следующий момент, связанный с выполнением полного
объема работ: если команда полностью успевает сделать все запланированные задачи, то в
последние день-два возникает «простой» отдельных сотрудников (кто-то дожимает
оставшиеся задачи, а другим вроде как получается нечего делать). Это не очень здорово,
поэтому рекомендуется иметь на итерацию пару «бонусных» задачек, к которым можно
приступать, если остальные задачи уже все сделаны или вот-вот будут доделаны. Также
можно планировать с небольшим перебором объема работ (например, за счет небольшого
завышения Focus-factor-а) и считать, что если команда немного не успела, то это
абсолютно нормально.
Еще опытный факт: даже у самой хорошей и мотивированной команды примерно раз в 4-5
итераций случаются проблемы с выполнением полного объема работ. Как правило, это
связано с одним (или сразу несколькими) факторами:
• большое количество незапланированных срочных работ (либо всплеск поддержки,
либо какие-то особые обстоятельства у заказчика);
• серьезная недооценка целого ряда задач (новый вид работ, не учли серьезные
нюансы, освоение нового инструментария);
• технические трудности (серьезные баги в базовых библиотеках, падение сервера и
т.п.);
• эпидемия гриппа.
Трагедии из этого делать не надо. Это нормально. Главное, чтобы это не случалось
слишком часто.
Nokia-тест
В процессе работы по методологии Scrum, благодаря ретроспективам и гибкости,
заложенной в сам процесс, команда может достаточно далеко уйти от канонического
понимания Scrum-а. И здесь возникают неизбежные вопросы:
• каковы рамки адаптации процесса?
• каковы критерии, что это всё еще Scrum?
У нас уже возникали такие споры. И пока мы не нашли лучше ответа, нежели интервью с
одним из прародителей Scrum-а – Jeff-ом Sutherland-ом, которое он дал в 2006 году на
конференции QCon London 2006:
• http://www.infoq.com/interviews/jeff-sutherland-scrum-rules
Согласно этому интервью в компании Nokia, активно практикующей Scrum, применяют
следующий «тест»:
1. У вас итеративный процесс разработки?
(Are you doing iterative development?)
2. У вас итерации фиксированы, т.е. начинаются в назначенное время и
заканчиваются в фиксированное время?
(с) Заказные ИнформСистемы, 2008 год 12

13. (Do you have fixed iterations? Do you have an iteration that starts at a specified time
and ends at a fixed time?)
3. Длина итерации не превышает 6 недель?
(And that iteration has got to be less than 6 weeks)
4. В конце итерации вы имеете работающее ПО?
(Well, at the end of the iteration, do you have working software?)
5. Вам нужна детальная спецификация для того, чтобы начать итерацию?
(Do you have to have a specification in complete detail before you can start the
iteration?)
6. Важно иметь работающее ПО в конце итерации: вы проводите тестирование во
время процесса разработки?
(It's important for working software at the end to have testing as part of the
increment: Do you have testing in the middle of the development?)
Если ответы на все вопросы кроме 5-ого – ДА, то команда применяет итеративный
процесс разработки в полном смысле этого слова. Но это еще не обязательно Scrum.
Касательно Scrum есть четыре дополнительных вопроса:
7. У вас есть Product Owner, т.е. есть кто-то, кто представляет заказчика и работает
вместе с вами?
(Do you have a product owner? Do you have someone that represents the customer
who is working with you?)
8. Если у вас есть Product Owner, ведет ли он Product Backlog, т.е. список «фич»,
которые нужно запрограммировать? Приоритезирован ли этот список по важности
для заказчика? Есть ли оценка трудоемкости по каждому пункту?
(If you have a product owner, do they have a product backlog, a list of features to be
developed? Is that backlog prioritized by business value, and is it estimated how long
it is going to take to build those pieces?)
9. Строите ли вы график сгорания работ (burndown chart) во время итерации, чтобы
видеть, сколько работы осталось, и успеваете ли вы к концу итерации?
(When the team is doing the development, do you have a burndown chart that shows
how much work is remaining in the iteration as you are moving forward, so you can
track your progress? And from that, can you tell the velocity of the team, how fast is
the team moving?)
10. Во время итерации команда работает по принципу самоорганизации, т.е.
менеджеры не вмешиваются в работу команды по ходу итерации?
(Nokia has a rule that you can't have a project manager interfering with the team in
the middle of an iteration because that stops the self organization and it guarantees
you are going to have a suboptimal path to a solution.)
Если и на эти четыре вопроса у вас ответ ДА, то согласно Jeff Sutherland-у и его Nokia-
тесту – у вас Scrum!
Перевод последующих команд на Scrum
Здесь наблюдается следующий феномен: целый ряд команд, где еще не внедрен Scrum,
сами активно жаждут перехода на него, но есть и команды, достаточно прохладно
относящиеся к идее перехода на Scrum. И здесь, как оказалось, важно вовремя помочь
первой группе команд (провести для них тренинг и активно консультировать во время
первых итераций), так как в противном случае они пытаются перейти на Scrum
(с) Заказные ИнформСистемы, 2008 год 13

14. самостоятельно, что и сложнее для них, и рождает своеобразный диалект Scrum-а (по
началу понимания не хватает).
Что же касается остальных команд, то тут главное не спешить и слишком не давить: очень
опасно, когда переход на Scrum навязан чисто сверху. Опыт показывает, что со временем
количество скептиков уменьшается – народ неизбежно замечает, как повышается уровень
проектной жизни и интерес к работе в соседних командах, перешедших на Scrum.
Заключение
В заключение хочется отметить, что когда всё это начиналось, было очень много скепсиса
на всех уровнях, но он оказался неоправдан (по большей части). Те сложности и
трудности, которые гипотетически виделись перед началом реального внедрения Scrum, в
жизни не встретились (за весьма редким исключением), а столкнуться пришлось с совсем
иным.
Так что лучше не критиковать Scrum, исходя из исключительно умозрительных
построений, а взять и попробовать его использовать!
(с) Заказные ИнформСистемы, 2008 год 14