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

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

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

В таких условиях у разработчика есть два пути: продолжать терпеть или брать инициативу в свои руки.

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

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

Вот несколько формальных признаков, свидетельствующих о том, что с процессом разработки в вашей команде что-то не то:

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

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

Если же пункты сверху вызывают у вас недоумение, а идея внедрения скрама пришла вам в результате:

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

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

В совершенстве изучите теорию Scrum'a. Это архиважно. Я рекомендую книгу Хенрика Книберга "Scrum и XP: заметки с передовой": это очень известная Scrum-методичка которая пошагово разжевывает все моменты процесса. После её прочтения вы поймете, почему стендапы должны проводиться непременно стоя и в одно и то же время, почему нельзя забивать на демо, почему нужно оценивать задачи именно Planning Poker'ом, а не в открытую. Появится понимание как это всё связано.
Если у вас всё ещё остаются вопросы о целесообразности тех или иных практик Scrum'a — прочитайте книжку ещё раз. Если вопросы по-прежнему остаются — возможно вам не стоит браться за внедрение Scrum'a.

Найдите себе соратников среди разработчиков. Расскажите за обедом какие плюсы они получат после внедрения этого процесса. Не забудьте сказать и про обязательства, накладываемые скрамом на разработчиков.
Большинство людей готовы поддерживать благие начинания. Может найтись кто-то, кто скажет что против изменений — это нормально. Но если вы единственный в команде, кто считает что текущий процесс некомфортен для разработчиков — возможно вам не стоит браться за внедрение Scrum'a в этой команде.

Найдите соратников среди руководства. Чем более высокому руководителю вы об этом расскажите, тем выше шансы на успех.
Начните с руководителя вашего подразделения. Двигайтесь выше. В небольших компаниях(до 50 человек) я предпочитаю идти вплоть до директора. Сделайте получасовую презентацию с описанием текущего процесса и его проблем. Опишите как скрам их решает.
Большинство менеджеров должно воспринять вашу инициативу нейтрально. Но хотя бы один руководитель должен встать на вашу сторону и пообещать поддержку. Запомните этого человека, он вам о-о-очень пригодится в будущем.
Если вам не удалось привлечь на свою сторону ни одного руководителя — вам точно не стоит браться за внедрение Scrum'a в этой компании.

Явно озвучьте руководству, что скрам-мастеринг требует вашего времени и, соответственно, ваша эффективность как технаря снизится процентов на 30%. Если предыдущий шаг пройден успешно, то это воспримут адекватно. И не спешите на этом этапе просить прибавку к зарплате, вы ещё ничего не сделали, за что вам стоит платить больше.

Посмотрите ещё раз на проделанную работу. Вот на все эти разговоры, споры и выступления. Если это вам показалась сложным и это не то, чем вы хотели бы заниматься в ближайшие 6-9 месяцев — вам не стоит браться за внедрение Scrum. Потому что внедрение Scrum — это работа с людьми. Она будет отнимать у вас прилично времени и душевных сил. Первое время вам точно придется совмещать её с вашей основной, технической, деятельностью.

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

Совместно с руководством выберите проект, на котором вы сформируете Scrum-команду. Идеальная команда — 4-6 кроссфункциональных разработчика. Так почти никогда не бывает, разработчики имеют свою специализацию и не хотят заниматься тестированием. Поэтому 3-4 некроссфункциональных разработчика и 1-2 тестировщика — тоже очень хорошая команда. Вы должны быть одним из этих ребят. А ещё вы теперь скрам-мастер.
Ни в коем случае не соглашайтесь на внедрение Scrum'а сразу во всей компании или в команде, в которую вы не входите — потеряете контроль.

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

Профессиональные скрам-мастера приходят в команду с целым портфелем сервисов и плагинов, позволяющих отслеживать скрам-активность в online-трекерах. Это не ваша специализация, поэтому не заморачивайтесь на сложном инструментарии.
Напротив, используйте аналоговые инструменты: оффлайновую доску с рукописными стикерами, листки ретроспективы приколотые к ней же, burndown нарисованный маркером на соседней доске. На этапе становления скрама такие вещи даже более наглядны, чем их онлайн аналоги.

Дальнейшие шаги — это формирование бэклога, первое планирование, стендапы, демо, ретро… Здесь нет каких-то особенностей для скрам-мастера технаря, действуйте по книжке.

Но на одном я хочу остановиться подробнее: скрам-мастер — это менеджер. Теперь у вас есть определенные рычаги влияния на команду и даже на человека, который является product owner'ом в вашей команде. И вы должны(!) пользоваться этими рычагами.
Объясню на примерах.

В начале производительность команды может упасть, это нормально когда меняется процесс разработки.
Но уже через 2-3 спринта вы и другие разработчики почувствуете плюсы скрама: задачи не влетают хаотичным образом, появилась двухнедельная определенность, вся команда погружена в решение общих задач, тестирование происходит сразу после разработки.
У product owner'а появится понимание чем занята разработка и некоторая уверенность что большинство запланированных задач будет выполнено к концу спринта. Не забывайте подсвечивать это на ретро: технари склонны сгущать краски и озвучивать только проблемы.

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

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

Важный момент: на этом этапе, когда уже видны результаты внедрения скрама, поговорите с руководством о доплате за скрам-мастеринг. Попросить +15% к своему окладу — нормально. Объясните, что эта активность требует сил и нервов и на одном энтузиазме долго не протянуть. И это действительно так! Я видел немало скрам-мастеров технарей, чистый энтузиазм которых сменялся обидой за неоплачиваемый тяжелый труд. В итоге компания теряла и скрам-мастера и разработчика.

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

Через какое-то время вы услышите от членов команды, что скрам не так-то уж и хорош. Что, дескать, приходится укладываться в спринты и ходить на стендапы, что мы слишком много времени тратим на разговоры. Особенно этим грешат молодые разработчики, присоединившиеся уже после внедрения скрама и не видевшие как было раньше.
Это нормально. Просто заготовьте немного картинок с описанием как было раньше и показывайте их время от времени недовольным. Иногда к таким разговорам привлекайте product owner'а, потому что он как старший товарищ у походного костра: его рассказы о былых временах воспринимаются командой очень живо.

Вообще, менеджеры недовольны скрамом в самом начале внедрения, когда впервые сталкиваются с запретом на внесение новых задач в текущий спринт. Но уже после первого демо понимают, что преимущества процесса перевешивают это ограничение. Через несколько месяцев менеджер станет главным ценителем скрама.
Повторюсь, технари из команды частенько раздувают негатив, а менеджеры видят картинку более реалистично. Поэтому, если вы чувствуете что критиканы вас заклевали — выпейте кофе с вашим product owner'ом, он обязательно поддержит, а поддержка в такие моменты очень важна.

Но критика бывает и конструктивной. Идеально настроить скрам с нуля невозможно, поэтому постоянно прислушивайтесь к советам и примеряйте их на ваш процесс. Каждое предлагаемое изменение встречайте двумя вопросами: «Какую проблему это решит?» и «Какие проблемы это породит?»

Критично ли сдвинуть время стендапа с 10 утра на 18 вечера? Или сделать время стендапа плавающим? Что если отменить демо? Или придумать новый тип встречи?

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

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

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