Соображения о внедрении agile-культуры

Буквально неделю назад я попал на Slurm Agile, курс по Agile-трансформации, который вели Марина Алекс, работающая с Джеффом Сазерлендом (автор Scrum-гайда и Agile-манифеста) и Анатолий Иванов (директор по разработке в PropellerAds). По факту получилась смесь теоретических и практических знаний в нижних пропорциях.

В закладки

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

Прозрачность Agile-команд

Некоторое время назад один из наших клиентов в Progress Engine посетовал на то, что ему не хватает прозрачности. Несмотря на странную жалобу (коллеги регулярно общаются по рабочим вопросам) мы решили ввести у себя практику еженедельных отчётов для всех клиентов (что сделано, что планируем сделать на следующей неделе и с какими проблемами столкнулись). Интересно, что в одном из проектов, в котором владелец бизнеса не следил за разработкой, доверив её своему сотруднику, а позже, когда между ними возник конфликт, пришёл к нам с вопросом о том, что было сделано - мы в течении нескольких часов подготовили отчёт с детальным указанием работ и сроков.

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

Короткие итерации

Когда 8 лет назад я работал в одной достаточно крупной телеком-компании и у меня были длительные проекты - я не всегда понимал, что же за продукт пишут наши подрядчики. И когда спустя много месяцев они выкатывали релиз, я рвал на себе волосы насколько неудобно был сделан проект и сколько всего было в нём не учтено. С учётом того, что текущие реалии требуют всё более быстрых изменений и очень часто то, что было актуально несколько месяцев назад, уже потеряло своё значение - переход на короткие итерации становится всё актуальнее. Марина и Анатолий рекомендовали сократить итерации до 1 недели, что в принципе полностью совпадает с нашим текущим видением.

Внедрять Agile сложно и больно

Пожалуй соглашусь с этим, но частично, поскольку у себя мы частично уже заимствовали ряд инструментов Agile, такие как ежедневные daily-стэндапы, спринты и уже упомянутые еженедельные отчёты, а значит нам это будет не очень больно :) Но по озвученной на курсе статистике, в процессе внедрения Agile-культуры есть риск потерять до 30% сотрудников, не готовых к новым изменениям в компании. Такой риск есть и стоит быть к нему готовым.

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

Важность коммуникаций

Еще один важный момент - это коммуникации и обратная связь. При этом не должно быть встреч формата ППР, посидели, попи...ели (в смысле поговорили) и разошлись, а процесс должен быть контролируемым.

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

Ценность функционала - RICE-метрика и $$$-оценка

Прежде чем стартовать новую фичу стоит оценить её значимость. Есть много способов, но пожалуй самые популярные это RICE-метрика и $$$-оценка.

RICE метрика

Reach — охват людей, на которых повлияет новая функциональность в течение какого-то периода времени;

Impact — влияние новой функциональности на продукт;

Confidence — уверенность в оценке охвата, влияния и трудозатрат;

Effort — трудозатраты: количество «человеко-месяцев», недель или часов.

Чтобы получить оценку RICE, надо подставить значения этих факторов в формулу:

Reach * Impact * Confidence / Effort = RICE Score

$$$-оценка

$$$ - это оценка экономической привлекательности задачи в сравнении с её трудоёмкостью

Внедрение Agile методом Дом 2

Очень интересная рекомендация по внедрению Agile, которая, я думаю, может быть использована для внедрения любых новых практик в компании - это внедрение методом Дом 2. Как это работает - выбираете самую слабую или самую смелую команду, готовую к эксперименту и устраиваете небольшое шоу - вся компания наблюдает за тем, как в одной отдельно взятой команде происходит адаптация к новым веяниям компании. Самые предприимчивые в компании могут даже устроить тотализатор - кто из участников эксперимента сломается раньше :) (шучу).

В общем, если вам этот материал оказался полезным - значит я потратил своё и ваше время не зря :) А если вы хотите внедрить Agile у себя, то стоит послушать опыт ребят из Slurm или приходите к нам в Progress Engine - поделимся с вами своим личным опытом за чашкой кофе :)

Бонус - небольшое видео о важности burndown :)

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

Написать
{ "author_name": "Alexey Poimtsev", "author_type": "self", "tags": [], "comments": 0, "likes": 7, "favorites": 7, "is_advertisement": false, "subsite_label": "learn", "id": 111427, "is_wide": false, "is_ugc": true, "date": "Tue, 10 Mar 2020 17:16:45 +0300", "is_special": false }
0
Комментариев нет
Популярные
По порядку

Прямой эфир