Доклад - Практика внедрения Scrum: трудности и пути их преодоления

Подождите немного. Документ загружается.

Практика внедрения 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 год

Обеспечивает хорошее и качественное распространение информации. Повышает

вовлеченность членов команды в процесс создания качественного ПО.

Во время совместных обсуждений с фломастером у доски рождаются лучшие идеи и

концепции, наиболее эффективно передается информация и know-how.

Самоорганизация внутри команды

Помогает «не убить» самомотивацию. Обеспечивает автоматическую подстройку под

обстоятельства. Подталкивает членов команды к кросс-функциональности. Разгружает

управляющее звено от принятия лишних решений.

Снежинка является достаточно ярким примером эффективной самоорганизации в природе

– попробуйте сконструировать такое вручную…

Жесткий time-boxing

Заключается в следующем:

 дата окончания итерации жестко фиксируется и не переносится

 объем работ тоже фиксируется на итерацию и должен соблюдаться

 время ежедневных Scrum-митингов жестко фиксируется в рамках итерации

Отход от этого – форс-мажор (бывает, но не должно быть чаще, чем раз в 4-5 итераций).

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

(с) Заказные ИнформСистемы, 2008 год

Принятие решения о переходе на Scrum

Итак, кто-то в компании заражается идеей внедрения Agile-методологии. И здесь

возникают проблемы:

• какую из Agile-методологий выбрать;

• как убедить руководство в том, что это действительно правильный путь;

• нужна пропаганда и разъяснение в массах трудящихся.

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

рассматривали только eXtreme Programming (XP), Scrum, Feature Driven Development

(FDD) и Open Unified Process (OpenUP). Что касается первых двух, то между ними и

выбирать особо не надо, так как сейчас стандартом де-факто является использование

Scrum, дополненного практиками из XP, касающимися чисто программирования (unit-

тесты, непрерывная интеграция и т.д.). Что же касается последних двух, то они показались

более сложными и тяжеловесными, т.е. потенциально более трудными во внедрении и

следовании им. Кроме того, мы нашли хорошего внешнего консультанта по Agile-

методологиям, который специализируется на внедрении именно Scrum. Так что решение

было по сути предрешено: уж если мы не сможем у себя внедрить Scrum, то вряд ли мы

вообще способны внедрить какую-то готовую стандартную методологию ведения

проектов (до этого у нас, как и у многих, были свои внутренние методологии, которые

зачастую отличались от проекта к проекту).

(с) Заказные ИнформСистемы, 2008 год

А вот убедить руководство оказалось не такой простой задачей. Сейчас это несколько

странно уже вспоминать, но основное беспокойство у руководящего состава компании

вызвала идея о самоорганизации внутри команды. Опасения были такие:

• активные будут брать себе всю самую интересную работу, а более скромные

довольствоваться тем, что осталось;

• ставит под удар индивидуальные планы развития;

• рушит организационную структуру внутри проектных групп;

• пропадет персональная ответственность за результаты труда;

• усложняет систему компенсации (как определить вклад отдельных членов группы в

общий результат).

Весь дальнейший опыт внедрения и применения Scrum показал, что все эти опасения

оказались совершенно напрасными: никаких проблем самоорганизация внутри команды не

принесла. Более того, она помогла выявить скрытых лидеров, которые стали своего рода

«моторами» проектных групп в новых условиях.

Так как же удалось преодолеть первоначальный скепсис? Здесь четкого рецепта нет. В

нашем случае помогли многочисленные обсуждения, изучение уже упомянутой книги

«Scrum and XP from the Trenches».

Что же касается пропаганды и разъяснений в массах трудящихся, то для этого был

проведен внутренний семинар, на котором рассказывалось про Agile вообще и Scrum в

частности. Интересно, что во время проводившихся позднее тренингов выяснилось, что

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

уделить значительно больше внимания «просветительской» работе.

Перевод первых команд на Scrum

Итак, коли вы решились пробовать Scrum, то перед вами почти неизбежно возникают

следующие задачи:

• выбор тренера/консультанта;

• выбор команды (или команд), на которой (ых) будет поставлен эксперимент;

• подбор параметров для команды (длина итерации, единица оценки трудоемкости,

начальное приближение для Focus factor-а, Scrum-мастер);

• как, собственно, внедрять.

Выбор тренера/консультанта

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

потому, что не верилось, что этого самого выбора почти нет. Зато в своем выборе мы не

разочаровались! Так что если кому нужен Agile-тренер/консультант, можем

порекомендовать .

Выбор команды (команд)

Это тонкий вопрос. В качестве «пионера» не стоит использовать слабую команду: процесс

у них не будет ярким; они, скорее всего, не станут примером для подражания; слабые

команды очень не любят изменения (для них это реальный стресс). Но и команду, у

которой всё хорошо (скорее, которая сама так считает), тоже лучше не трогать на первом

этапе, так как и в такой ситуации воли к переменам внутри команды, вероятно, будет

недостаточно. Идеально подходит сильная команда, у которой накопились какие-то

проблемы и трудности, так что большинство членов команды искренне чувствуют, что

(с) Заказные ИнформСистемы, 2008 год

нужны перемены. Именно по такому пути мы и пошли, и хочется отметить, что сейчас это

одна из самых ярких команд, хотя остался ряд проблем и еще есть, куда расти.

Естественно, какой бы выбор не был сделан, он должен быть согласован с

руководителями проектов и лидерами команды. Как правило, непосредственно перед

началом внедрения 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 год

Что же касается выбора Product Owner-а, то это прерогатива менеджмента. У нас в

большинстве случаев им стал руководитель проекта.

Как внедрять

Главное – быстро:

• через несколько дней после консультаций с руководителями и лидерами команды

проводится общий тренинг для всей команды, на котором объясняются базовые

принципы Agile и Scrum, проводятся деловые игры для освоения базовых практик;

• на следующий день после тренинга начинается первая итерация (точнее,

«нулевая», т.е. пробная): в присутствии тренера команда обсуждает задачи на

итерацию, дает им оценку трудоемкости, формирует объем работ на итерацию;

• несколько раз за этот спринт (итерацию) на Scrum-митингах присутствует тренер и

помогает команде поправить ключевые ошибки;

• первые демонстрацию и ретроспективу также помогает провести тренер, причем на

демонстрации он выступает, скорее, в роли наблюдателя, а вот на ретроспективе –

в роли ее ведущего, демонстрируя Scrum-мастеру стиль и приемы;

• приглашать на первую же демонстрацию представителей заказчика или нет –

решается по обстоятельствам (мы приглашали только в одном случае из пяти).

Дальше тренер помогает всё меньше и меньше, но важно, чтобы у Scrum-мастера всегда

была возможность проконсультироваться с ним по животрепещущим вопросам (по

телефону, электронной почте, ICQ и т.д.).

Опыт работы по методологии Scrum

Вот здесь и начинается самое интересное!

Одна команда, несколько проектов/модулей

При переводе первой же команды на Scrum мы столкнулись с вопросом: как быть, если

одна команда ведет разработку нескольких проектов/модулей? Априори нам почему-то

казалось, что нельзя в один спринт (итерацию) «замешивать» задачи, относящиеся к

разным проектам. Нам подсказали, что это надуманное ограничение и совершенно

свободно можно выполнять задачи, относящиеся к разным проектам/модулям, в рамках

(с) Заказные ИнформСистемы, 2008 год

одного спринта, главное – чтобы Product Owner был один. И это действительно неплохо

работает.

Однако дальнейшее развитие событий показало, что есть серьезные трудности с

достижением кросс-функциональности в таких командах:

• до перехода на Scrum отдельные члены команды специализировались на отдельных

проектах/модулях, так что слабо разбираются (а зачастую и вообще не

разбираются) в другой части;

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

берут именно ее, и очень немногие пытаются расширить свой кругозор, взяв

задачу, относящуюся к слабо знакомой области.

Как с этим можно пытаться справиться:

• по договоренности с Product Owner-ом несколько спринтов по возможности

сделать узко специализированными (целый спринт должен быть посвящен

преимущественно одному проекту/модулю) – тогда всем членам команды просто

неизбежно придется поработать над данным проектом/модулем;

• несколько первых итераций активно использовать парную работу: тот, кто хорошо

разбирается в соответствующей части функциональности, садится в пару с тем, кто

плохо разбирается в этой части функциональности, и они вместе делают задачу.

Практика показывает, что это весьма и весьма эффективный способ передачи

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

в паре, но в подобных ситуациях, на наш взгляд, это одно из наиболее

эффективных решений;

• если команда большая (больше 8-ми человек) и проектов/модулей у нее «сильно

больше одного», то разумно попытаться разделить эту команду на две.

Здесь надо отметить, что несмотря на все эти приемы, в части команд у нас до сих пор

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

отдельных проектах/модулях/компонентах. Конечно, эта специализация постепенно

ослабевает, появляются «полиглоты», но до той самой идеальной кросс-

функциональности нам еще идти и идти…

Taskboard

Далее заметили интересный нюанс: сделанная на этапе планирования спринта оценка

трудоемкости зачастую мешает при работе над задачей:

• “у меня есть еще N часов, согласно сделанной трудоемкости, так что я могу их

потратить на дальнейшую шлифовку и полировку написанного кода”;

• “ой, у меня уже не осталось времени на решение этой задачи, так что вскрывшиеся

сложности и нюансы я так и оставлю без внимания”.

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

как крайне редко мы обладаем полными сведениями о задаче на этапе планирования.

Феномен эффективности планирования заключается в усреднении: по людям (кто-то

(с) Заказные ИнформСистемы, 2008 год

работает более эффективно, кто-то менее) и по задачам (какие-то задачи оказываются

недооцененными, а какие-то – переоцененными). Так что не следует выполнять

сравнительный анализ план-факт по отдельным задачам, это имеет смысл делать только

по общим планам и фактам на целый спринт (итерацию). Осознав такую проблему, мы

стали писать оценку трудоемкости на оборотной стороне бумажек, вывешиваемых на

Taskboard, и перестали проносить ее в электронную систему ведения дел.

Оказалось не всё так просто и с самим обустройством Taskboard-ов: липкие стикеры

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

 Возможных решений здесь два (мы используем оба):

• накупить побольше магнитиков и прижимать стикеры ими;

• использовать пробковые доски, к которым «пришпиливать» стикеры.

Scrum-митинги

Дальше, естественно, заметили более серьезные проблемы. Почти у всех команд были (а у

некоторых и до сих пор остаются) те или иные трудности с проведением Scrum-митингов:

• на Scrum-митинге присутствуют не все члены команды (опоздания);

• Scrum-митинг превращается в отчет членов команды перед Scrum-мастером;

• Scrum-митинг затягивается и переходит в обсуждения.

Что касается опозданий, то это у нас в первую очередь связано с гибким графиком, по

которому работают сотрудники компании. Формально рамки у этой гибкости есть и

достаточно четкие, но фактически график многих сотрудников настолько гибок, что

выходит за эти самые рамки. И здесь следует отметить следующий факт: хотя и

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

команды могли на нем присутствовать. Так что сейчас в трех командах из пяти Scrum-

митинги проходят в 15:00, что совсем не утро… В других двух – в районе 12, что уже как-

то больше напоминает утро (особенно по меркам нашей компании ). Т.е. время митинга

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

Здесь еще хочется сделать предостережение: очень опасно, если компания начнет

навязывать для команд какие-либо штрафные санкции за опоздание на Scrum-митинг –

для нашего менталитета нет ничего хуже подобной принудиловки. Пускай каждая

команда самостоятельно (на ретроспективах) решает как «штрафовать» за опоздание и

стоит ли это вообще делать. Вначале у нас были всякие идеи о pizza-фонде, и даже очках,

в которых измеряется карма, но в итоге ни одна из команд не использует подобные

практики, т.к. они скорее демотивируют, нежели стимулируют.

Следующей трудностью, как указано выше, оказалось превращение Scrum-митингов в

отчет Scrum-мастеру. Причин тут сразу две:

• Scrum-мастер очень строго спрашивает: “что делал вчера?”

(с) Заказные ИнформСистемы, 2008 год

• Сотрудник моментально распознает в этом менеджерские нотки, по привычке

подсознательно решает, что перед ним новый (еще один) менеджер, и начинает

давать формальный отчет Scrum-мастеру.

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

помогают следующие приемы:

• разъяснительная работа со Scrum-мастером (чтобы вопросы его задавались с

нейтральными интонациями и без напора, чтобы во время рассказа члена команды

Scrum-мастер не смотрел ему в глаза или даже уходил за спину говорящего);

• разъяснительная работа с командой (что Scrum-митинг – это для всех, что

менеджеров на Scrum-митингах нет, а если и есть, то они обязаны молчать и т.д.).

Кроме того, практика показывает, что со временем это и само во многом исправляется:

команда привыкает к Scrum-митингам и роль Scrum-мастера становится менее значимой

(как правило, и вопросы уже не нужно задавать – за несколько раз все их выучивают

наизусть и можно использовать просто передаваемый из рук в руки карандашик или

ручку, чтобы понимать, чья очередь говорить).

Ну и наконец: Scrum-митинг затягивается и переходит в обсуждения. Это наблюдается

тоже достаточно часто. Как здесь быть: в такой ситуации многое зависит от навыков

Scrum-мастера (нужно уметь оборвать развертывающееся обсуждение, взять его «на

карандаш» и отложить до «после Scrum-митинга»). Некоторые команды у нас используют

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

Ретроспектива

Ретроспективу либо вообще пропускают (как правило, это команды, только перешедшие

на Scrum), либо со временем она вырождается в формальность (а это характерно для

команд, несколько месяцев практикующих Scrum). И это весьма обидный факт, так как

ретроспектива важна – это не только точка подстройки процесса, но и возможность

каждому высказаться, повлиять на развитие команды, снять какие-то напряженности и

недомолвки.

С первым проявлением (ретроспективу пропускают) легко бороться просвещением и

помощью:

(с) Заказные ИнформСистемы, 2008 год

• еще раз поговорить со всей командой о ретроспективе: что это, зачем она нужна, в

чем польза и незаменимость;

• несколько раз пригласить опытного Scrum-мастера из другой команды или

внешнего тренера в качестве ведущего ретроспективы;

• а потом еще несколько последующих ретроспектив – в качестве наблюдателя.

Что же касается второго (перспектива вырождается в формальность), то здесь главное

сильно не переживать: в конце концов ретроспектива – это не самоцель, и если всё идет

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

4-5 итераций даже в полностью налаженной и привычной работе случаются проблемы и

сбои, так что в такие спринты ретроспектива неизбежно возрождается в полной красе.

Кроме того, внешние обстоятельства и состав команды тоже со временем меняются, так

что и здесь на выручку приходит ретроспектива.

Есть способы, как «освежить» ретроспективу и в достаточно стабильных условиях:

• менять ведущих (ничего страшного, а даже очень интересно, когда ретроспективу

ведет не Scrum-мастер, а кто-то другой из вашей команды или даже кто-то

приглашенный из другой команды);

• обсуждать более широкий круг вопросов (прочитанные книги по IT, посещенные

конференции и т.п.).

Еще хорошим подспорьем может послужить книга «Agile Retrospective: Making Good

Teams Great». В ней приведены целые наборы приемов и методов для проведения каждого

из этапов ретроспективы, так что из них можно компоновать свой собственный

(неповторимый) сценарий.

Демонстрация

С демонстрацией связаны следующие сложности:

1. зачастую тяжело обеспечить присутствие заказчика на демонстрации;

2. демонстрация затягивается из-за технических проблем (заранее не подготовлено

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

для этого не хватает и т.д.);

3. во время демонстрации по отдельным задачам выясняется, что сделано не то или

не в полном объеме.

Что касается присутствия (точнее, отсутствия ) заказчика, то это, как правило,

объективные обстоятельства, под которые проще подстроиться, чем преодолевать их.

Подстроиться проще всего следующим образом: хотя бы раз в пару итераций устраивать

повторные «выездные» демонстрации, т.е. на территории заказчика и в удобное для

заказчика время. На этих демонстрациях не присутствует вся команда, а всего один-два

человека от команды. На этих демонстрациях не показываются внутренние и

вспомогательные работы. Но, несмотря на это, такие демонстрации крайне важны, и

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

Это не только обеспечит команду столь необходимым в Agile-разработке feedback-ом, но

и будет наглядно демонстрировать заказчику ход, темп и качество работ.

Технических и организационных проблем на демонстрации в идеале быть не должно, так

как это время всей команды, да еще и пришедших заинтересованных лиц (stakeholder-ов),

т.е. не только время, но и лицо команды. Совет банальный: к демонстрации надо

готовиться, надо четко выделять время в конце итерации на подготовку к демо, надо

иметь готовое функционирующее тестовое окружение, подходящее под нужды и цели

(с) Заказные ИнформСистемы, 2008 год