To Scrum or not to Scrum?

Сейчас во всем мире популяризируется Agile и, в частности Scrum, как наилучшая методология для разработки ПО.

Всегда ли Scrum так хорош, а его применение оправдано? Всегда ли он применим в чистом виде?

Недавно я беседовала с СЕО нашей компании, и он пытался понять, чем же Scrum лучше, чем старый добрый waterfall. Он задал мне правомерный вопрос: «Я правильно понимаю, что затраты на скрам больше, чем на вотерфолл? Новые роли, куча митингов…». И, действительно, это так. Ежедневные stand-up митинги, планирование, ретроспективы, репетиции ДЕМО, сами ДЕМО. Несомненно, есть много плюсов у этого фреймворка и, зачастую, плюсы перекрывают эти затраты.

Мне интересно, во многих ли российских компаниях применяется Scrum в чистом виде? Пока я не встречала такого примера, всегда есть некая адаптация. И, думаю, это правильно. Всегда нужно исходить из нужд проекта, от какой-то задачи, а не внедрять методологию ради методологии (хотя, и такое иногда случается, когда, например, заказчик требует этого и не хочет слышать разумных доводов, но и тут возможны варианты).

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

1. Product Owner и Product backlog

По учебнику, Product Backlog должен быть, им должен заниматься специально выделенный на это Product Owner. Действительно заниматься, т.е. отслеживать, чтобы были правильно расставлены приоритеты, чтобы верхние User Story были оценены, каждая не больше, чем в спринт. Чтобы каждая User Story, действительно, включала в себя все этапы waterfall: анализ, имплементация, тестирование, документирование…

Как показывает мой опыт (правда, работала я в одной компании, но в разных проектах), часто Product Backlog состоит из названия фич, расставленных по приоритетам. Иногда нет и этого. Иногда формируется несколько бэклогов, приоритеты между которыми непонятны. Product Owner, зачастую, никак не занимается бэклогом. Сам не уверен в приоритетах. Не утруждает себя описанием User Story. Пытается делегировать эту ответственность в команду, но это не всегда хорошо работает, т.к. только у PO есть бизнес-видение, он является интерфейсом к заказчику и должен транслировать его ожидания. Команда может этих ожиданий не знать и не понимать (как часто бывало в моей команде, т.к. прямого контакта с заказчиком у них не было).

2. Все этапы разработки в рамках User story

У нас элементы бэклога, как правило, это огромные фичи. Поэтому, в любом случае, присутствуют элементы waterfall в процессе: выделяется 1 или несколько спринтов на анализ и предварительные оценки, на написание технической документации с деталями реализации. А в конце разработки всегда будет этап интеграционного тестирования, т.к., как бы мы ни раздробили фичу, нам надо убедиться, что весь функционал работает полностью. К тому же, часто бывает, что фича делается несколькими распределенными командами. Получается, что по скраму мы делаем только имплементацию.

3. Burndown

Цель у Burndown прекрасная — как можно раньше выявить проблемы, отставания от плана. Но! Всегда ли мы можем себе позволить рисовать правду? В некоторых проектах нам нужно было сделать так, чтобы Burndown сходилась в 0 каждый спринт, иначе заказчик отказывался платить. Мы и рады бы были это делать по-честному, но требования заказчика постоянно менялись (это можно понять и соответствует одному из основных принципов аджайла: «гибкость важнее следованию плана»), мы постоянно меняли backlog спринта и искали потерянное время (где что уже списали, где надо досписать). В итоге, вся эта работа с Burndown превратилась в формальность и подгон к идеальному значению.

В одном проекте столкнулась с тем, что команда сама подделывает Burndown. На ДЕМО они отчитались заказчику, все у них хорошо сошлось, все сделали. Попрощались с заказчиком, и они говорят: «фух, а теперь пойдем доделывать!». Оказывается, им страшно было показать заказчику правду, что часть user story они не доделали, и они показали идеальную картинку, а потом несколько дней доделывали.

4. Самоорганизующиеся команды и скрам мастер

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

5. Кросс-функциональные команды

Тут тоже всегда возникает много споров. С одной стороны, кросс-функциональные команды — это круто, они могут взять любую фичу из бэклога, в них есть все компетенции, чтобы сделать ее от начала и до конца. С другой стороны, в больших проектах, с кучей экспертиз, это звучит как утопия. И, когда размазывается экспертиза по командам, теряется глубина этой экспертизы. Как решение, можно создавать Module Guardians, ответственных за определенные модули людей, которые всегда секьюрят качество изменений в этих модулях. И создавать СоРы (Community of Practice) по этим модулям, где специалисты в этой области будут собираться, делиться опытом и развивать свою экспертизу. Решать этот вопрос лучше исходя из нужд проекта. В некоторых проектах это было строгое требование  заказчика, и мы делали кросс-функциональные команды и Module Guardians. В каких-то проектах эффективнее было оставить команды по экспертизам и делить фичу между ними. Или в процессе разработки фич подучивать новые области и привлекать команду-эксперта на ревью.

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

  • Прозрачность — это очень важно для заказчика, видеть процесс разработки, видеть, куда уходит время, с какими проблемами сталкиваются разработчики, смотреть на Burndown и предсказывать, когда фича или релиз будут сделаны.
  • Эмпиризм — обучение на опыте, решения принимаются на основании того, что является известным.
  • Инспекция и адаптация — каждый спринт дает информацию для анализа: что было сделано не достаточно хорошо, как мы можем это улучшить это в следующем спринте? Ошибки — это возможности для улучшения.

Мне кажется, что в чистом виде скрам может быть применим, например, в веб разработке (как это сделано в Spotify). Где каждый элемент может быть заимплементирован отдельно, где достаточно высокая скорость интеграции фичи в продукт, где протестировать можно каждый элемент отдельно. А в дремучих аутсорсинговых проектах, не продуктовых, где большую часть разработки заказчик оставляет на своей стороне, получается только аналог скрама.

© Ирина Захарьина
Share