В сфере разработки программного обеспечения команды сталкиваются с высокой неопределенностью. В Спринтах, несмотря на лучшие стремления команды, все может пойти не так, оценки “плывут”, а результаты часто непредсказуемы. Давайте разбираться почему так происходит, и как улучшить ситуацию с помощью Скрам-паттернов.
Разработчики непрофессионалы или…?
Когда я работал программистом, то был фрустрирован тем, что постоянно не попадал в оценки. Не покидало ощущение, что я ненадежный работник и на меня нельзя положиться. С такими же проблемами сталкивались мои коллеги.
“Злые” проблемы
Инновационная работа отличается от серийного производства. У рабочего на заводе есть конкретные стандарты качества и приемки продукции. Подшипник готов, когда он соответствует разработанной спецификации. Каждая новая фича в Бэклоге Продукта представляет собой новую проблему и по своему уникальна, а технологии и окружение постоянно меняются. Разработчик начинает лучше понимать проблему, когда появляется первоначальное решение.
Хорст Риттель и Мелвин Уэббер определили «злую» проблему как проблему, которая может быть четко определена только путем ее решения или решения ее части. Этот парадокс подразумевает, по сути, что вы должны «решить» проблему один раз, чтобы четко определить ее, а затем решить ее снова, чтобы создать работающее решение. (Стив Макконнелл)
Высокая вариабельность
Часто даже небольшие изменения порождают цепь “сюрпризов”. Требования, люди и технологии постоянно меняются. К примеру, код оказывается чрезмерно запутанным или в конце Спринта появляется конфликт в коде с разработчиком из другой команды. Как результат, работа занимает больше времени.
Работа растягивается во времени
Работникам умственного труда часто стремятся найти идеальные решения. Разработчики не останавливаются на удовлетворительном решении, которое закрывает проблему по минимуму. Они продолжают “вылизывать” код, излишне усложняя его и обобщая для всех кейсов, надеясь, что это понадобится в дальнейшем. В книге “Managing the Design Factory” Дон Рейнертсен иллюстрирует различие между завершением работы в теории и на практике. В теории команда завершает все фичи в Спринт. На практике же работа занимает больше времени. Проекты по разработке программного обеспечения почти никогда не завершаются досрочно. Как минимум, в срок, а чаще всего с опозданием.
Скрам-паттерны могут помочь
Скрам-паттерны — коллекция известных практик и подходов, которые помогали Скрам-командам во многих организациях по всему. Они меняют структуру работы и организации, перестраивая коммуникации. Скорее всего, они помогут и вам.
- Паттерн Stable Teams помогает командам стать более предсказуемыми для стейкхолдеров и снижает вариабельность, потому что команда сохраняет свой состав на протяжении многих лет. Исследования показывают, что на пик продуктивности команды выходят через 2-3 года.
- Фиче-команды являются кросс-компонентными, кросс-функциональными и колоцированными. Эта структура обеспечивает высокую скорость, отсутствие зависимостей и максимальную автономность. Работа не блокируется и выполняется внутри команды. Применяйте паттерны Collocated Team, Сross-functional Team, Autonomous Team, Small Teams.
- Паттерн Yesterday Weather помогает командам стабилизировать свою скорость и брать в Спринт ровно тот объем работ, который она может выполнить.
- Активность Product Backlog Refinement (PBR) является надежным базисом, который помогает командам снижать вариабельность и количество неприятных “сюрпризов” в Спринте. Подготавливайте Бэклог Продукта так, чтобы его верхушка состояла из одинаковых по размеру элементов Бэклога Продукта. Как эффективно проводить PBR можно почитать в статьях “Эффективный PBR часть I” и “Прокачайте PBR при помощи Example Mapping”.
- Помогите команде работать в трех оптимальных режимах коллаборации: Swarming, Mob-programming, Pairing. Когда команда работает только над одним элементом Бэклога Продукта, то это дает минимальный Lead Time, создает эффект группового потока и снижает неопределенность. В этом случае команда работает в настоящем стиле Скрам из регби, вместе перенося мяч (фичу) на продуктив. Про моббинг читайте статью “Как убить очереди и ускорить команду при помощи моббинга”. Изучите Скрам-паттерн Swarming: One Piece Continuous Flow.
- Команды, которые держат кодовую базу и окружение в хорошем состоянии и чистоте, не тратят время на то, чтобы разгребать завалы. Они становятся более предсказуемыми. В бережливом производстве известен подход 5S, а его аналог в Скраме — паттерн Good Housekeeping. Еще уместно вспомнить принципы KISS и YAGNI, с помощью которых мы оставляем код чистым, чтобы эффективнее решать завтрашние проблемы.
- Скрам-паттерн Teams That Finish Early Accelerate Faster описывает довольно распространенную ситуацию, когда с каждым Спринтом команда берет все большие обязательства и хронически не завершает работу, не выполняя Цель Спринта. Это мешает команде бороться с техническим долгом и совершенствоваться. Решение — брать меньше работы, чтобы вернуть команде уверенность в собственных силах и перезапустить процесс непрерывного совершенствования.
- Если команда страдает от большого количества прерываний, то используйте Скрам-паттерн Illеgitimus Non Interruptus. Команда договаривается с Владельцем Продукта и стейкхолдерами о фиксированном эмпирическом буфере, куда попадают незапланированные задачи. При переполнении буфера Спринт прерывается.
Главные мысли статьи
- Скрам-команды вынужденно работаю с высокой степенью неопределенности и вариабельности, сталкиваясь со “злыми” задачами.
- На практике инновационная работа никогда не завершаются раньше. Как минимум, в срок, а чаще всего с опозданием.
- Есть много Скрам-паттернов, которые помогают командам стать более предсказуемыми.
