Во-первых, эта статья о личном опыте, эволюции и понимании Scrum. Во-вторых, она о том, как правильно применять Scrum-артефакты и ритуалы, а также о том, с чего начать и как обеспечить ценность, чтобы Scrum не был просто набором ритуалов. И еще эта статья о том, как адаптировать Scrum к реалиям жизни, и почему это не «серебряная пуля».
Краткий экскурс в теорию Scrum
Для начала коротко о фреймворке Scrum. Здесь я бы рекомендовал ознакомиться со Scrum-гайдом https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Russian.pdf. Если вы никогда его не читали, самое время это сделать. Это довольно короткий, но очень важный, основополагающий документ, который определяет основные элементы и ритуалы в Scrum. Он был создан давно, но при этом периодически обновляется.
Вообще первые идеи итеративной разработки возникли еще в 1986 году. В 1990 году Джефф Сазерленд и Кен Швабер формализовали Scrum, а в 1995 представили его на конференции в Калифорнии как революционный метод управления сложными проектами. В 2001 году он вошел в Agile-манифест и стал ключевым Agile-фреймворком.
Расскажу о базовых вещах. Во-первых, все начинается с того, что мы хотим создать продукт или развивать уже существующий. Что говорит нам фреймворк Scrum? «Вам нужна Scrum Team – кросс-функциональная самоорганизующаяся команда».
В этой команде нужен Scrum-мастер – любой участник команды, который берет на себя функцию человека, помогающего команде работать по Scrum-процессам. Также нужен Product Owner – человек, который определяет вектор развития продукта, приоритеты и задачи, на которых нужно сфокусироваться.
Далее нам нужен продуктовый бэклог – набор фичей и пользовательских историй, которые приближают продукт к достижению целей и делают его лучше.
После этого команда собирается на планирование спринта. Здесь возникает понятие «спринт» – это итерация, в течение которой команда создает инкремент продукта, то есть работающий результат, приносящий пользу стейкхолдерам и пользователям. Интервалы могут быть разными: неделя, две недели – как договоритесь. По итогам планирования формируется спринт с его бэклогом.
Далее, когда спринт сформирован, команда ежедневно встречается на Daily Scrum – это дейлики, митинги, стендапы. Команда продвигается вперед в решении задач, разбирается с блокерами, синхронизируется в понимании прогресса и движения к цели.
В конце проводится спринт-ревью: команда демонстрирует готовый инкремент продукта стейкхолдерам и продукт-оунеру и получает обратную связь. После этого проходит ретроспектива спринта, где команда выявляет проблемы в процессах и договаривается, как будет улучшаться дальше и что будет делать, чтобы работать еще эффективнее.
Первое знакомство со Scrum
Теперь немного про мое первое знакомство со Scrum. Это было примерно в 2012 году. Все началось с того, что сеть принесла мне какую-то статью на Habr или другом тематическом ресурсе. Я почитал, изучил скрам-гайд и понял, что Scrum – это про гибкость и адаптивность, про фокус на ценности для клиента, прозрачность и командную работу, проверку гипотез и культуру непрерывных улучшений.
Звучит классно, отличные идеи. Но что с этим делать и как внедрять это в реальную жизнь, было не очень понятно. Я пошел к коллегам, заряженный этой идеей, начал рассказывать про Scrum и предложил попробовать у себя.
Но тот момент я работал в госкомпании, где задачи приходят через служебные записки с формулировкой «выполнить до такого-то числа». Какая гибкость? Какая адаптивность? Просто бери и делай в назначенный срок. В итоге, пообщавшись, мы отложили эту идею в долгий ящик. Я тоже отложил ее на будущее, а через какое-то время перешел работать в другую, более современную компанию.
Вторая попытка: рост компании и вертолет из палок
В новой компании в какой-то момент началась стадия роста: стали наращивать IT, выделили отдельное юрлицо – IT-компанию. И задумались о том, что нужно становиться стильными, модными, молодежными и запускать у себя новые практики.
На тот момент я был руководителем отдела разработки, и мне нужно было перестраивать работу команд под новый фреймворк.
Мы начали планировать спринты, как нам казалось. Встречались с бизнесом, смотрели на бэклог, выбирали, что будем делать, договаривались: «Через две недели мы сделаем вот это».
Но столкнулись с тем, что нам все равно приносили новые задачи. Приходили и говорили: «Надо, извини, вот прямо очень срочно». В итоге получалось так, что выполнялось где-то 50–60% задач, а остальные перетекали из спринта в спринт и закрывались только спустя несколько итераций.
У нас не было метрик, не было ретроспектив. Какие-то элементы Scrum мы внедрили, но назвать это Scrum было сложно. В итоге ни команда, ни бизнес не почувствовали существенной пользы от внедрения – мало что поменялось.
Это напоминало строительство вертолета из палок: на вертолет похоже, но не летает.
Третий этап: Agile-трансформация и осознанные практики
Спустя некоторое время я перешел в другую компанию, где как раз шла Agile-трансформация. Я вышел туда руководителем сначала одной команды, потом мне доверили три команды. Моей задачей было внедрить Scrum-практики в реальную работу.
На тот момент там не было никаких методологий. Была одна: бери задачу, делай и бери следующую. Можно сказать, что было что-то вроде Kanban – постоянная смена приоритетов, хаотичная работа.
Постепенно, пообщавшись с людьми, участвовавшими в Agile-трансформации, разобравшись, как правильно выстраивать работу и последовательно внедрять Scrum, я начал понимать, что именно помогает командам применять Scrum и получать от него реальную пользу. Со временем работа стала более прозрачной и прогнозируемой.
Какие выводы я сделал:
-
Нужно фиксировать цели спринта. Если цели нет, то «у самурая нет цели, есть только путь», но здесь это не работает – цель должна быть.
-
Также важно проводить Product Backlog Refinement – регулярный пересмотр и уточнение бэклога. И проводить демо для бизнеса, иначе вы не получите обратную связь и не поймете, насколько хорошо справляетесь с задачами.
-
Проводить ретроспективы – это must-have, потому что без них не будет улучшений.
-
И, конечно, нужны метрики для планирования и оценки эффективности.
Не все было идеально, но многое удалось внедрить. В результате появилась прогнозируемость, мы начали достигать целей, фиксировать их и получать нужный результат. И для бизнеса, и для команды это стало ощутимо.
Проблема метеоритов и решение с выделенной полосой
Конечно, не все так радужно. В какой-то момент мы столкнулись с проблемой: не всегда попадаем в цели, не всегда выполняем запланированное. Если раньше это было 50–60%, то здесь метрики выросли до примерно 80%.
В чем проблема? В «метеоритах» – задачах, которые ломают спринт. Прибегает бизнес и говорит: «Мне срочно, прямо сейчас». Нужно, например, сдать налоговую отчетность. Какой Scrum? О чем речь? Бери и делай. Планы ломаются, метрики рушатся.
Решение оказалось довольно простым. Мы поняли, что нужна выделенная полоса – отдельный поток для срочных задач, который позволяет быстро их обрабатывать. Но важное условие: туда должны попадать только действительно критичные задачи. Нельзя использовать эту полосу для продуктовых задач, которые просто хотят ускорить.
В итоге предсказуемость сохраняется, и при этом появляется возможность реагировать на форс-мажоры. С одной стороны, команда достигает целей, с другой – может быстро решать срочные проблемы.
Так произошла моя трансформация от деревянного вертолета к настоящему. Теперь я могу предложить план того, как можно внедрять Scrum у себя.
Пошаговый план внедрения Scrum
Первый шаг. Сформируйте кросс-функциональную команду. Важно, чтобы все компетенции были покрыты и команда могла быть достаточно автономной.
Определите Product Owner и Scrum Master – без этого некому будет помогать работать по фреймворку и направлять команду в нужное русло.
И, конечно, всей команде нужно изучить основы Agile и Scrum.
Второй шаг. Создайте и приоритизируйте бэклог. Без нормального, проработанного бэклога двигаться дальше невозможно. Важно его оценить – пусть не весь, он может быть большим, но хотя бы верхняя часть бэклога должна быть оценена.
Третий шаг. Запустите первый спринт и начните итеративную работу. Проведите планирование, определите, сколько задач вы можете взять из бэклога. Не пытайтесь брать слишком много, не переоценивайте свои возможности – это может демотивировать команду.
Проводите ежедневные встречи – Daily Scrum. Важно понимать, что это не отчет руководителю, а синхронизация команды в том, как она движется к цели. Если возникают блокеры, их нужно решать, а не игнорировать.
Обязательно проводите ревью и ретроспективы – это обратная связь, рефлексия и возможность улучшаться.
Четвертый шаг. Когда вы прошли несколько итераций, начинайте собирать метрики – о них я скажу чуть ниже. Адаптируйте процессы, как, например, в примере с выделенной полосой, и постепенно добавляйте практики, которые помогают работать эффективнее: автотесты, Definition of Done (чек-листы готовности задач).
Ключевые метрики для оценки эффективности
Как говорил Питер Друкер: «То, что нельзя измерить, нельзя улучшить». Возможно, Питер Друкер этого и не говорил, но сама мысль очень точная.
Какие метрики стоит собирать? Отмечу несколько наиболее важных.
Scope Drop – базовая метрика. Она показывает, сколько задач вы не завершили за спринт. Можно считать процент завершенных задач, но незавершенные дают более честную картину – показывают, сколько вы не успели.
Velocity Chart – график, который отражает реальную производительность команды. Он показывает, сколько задач команда действительно выполняет за спринт (в часах или story points).
Burndown Chart – это ориентир того, как должна «сгорать» работа. Есть идеальная линия и есть фактическая, ступенчатая. Если фактическая выше – вы отстаете, если на уровне или ниже – все идет по плану.
Velocity Chart также позволяет видеть, как команда коммитится на объем задач и сколько реально выполняет. Это помогает выбирать подходящий уровень нагрузки для следующих спринтов и планировать более точно.
Кумулятивная диаграмма потока показывает накопление задач в разных статусах с течением времени. С ее помощью можно увидеть узкие места – например, где задачи застревают, в тестировании или на согласовании.
И, наконец, канбан-доска. Это не метрика и не график, но это важнейший инструмент. Она наглядно показывает прогресс команды. Ее удобно использовать на ежедневных встречах, чтобы видеть, где возникают заторы и на что нужно обратить внимание.
Почему Scrum – не серебряная пуля
Казалось бы, фреймворк классный – почему бы всем его не применять? Я для себя сделал следующий вывод: многое упирается в зрелость команд и компаний.
Есть понятие зрелости команд, например модель Такмана. Есть Agile Fluency Model – модель зрелости Agile-команд. Я не буду подробно на этом останавливаться, но важно понимать: если вы находитесь на этапе Forming и пытаетесь сразу внедрить Scrum, вы только ухудшите ситуацию.
Второй момент – зрелость компаний. Есть спиральная динамика – модель зрелости компаний, групп и личной зрелости: от бежевого до бирюзового уровня. Я не буду разбирать каждый уровень, но приведу несколько примеров.
Бежевый уровень – это уровень выживания. Компания или команда занята тем, чтобы просто удержаться на плаву. В таких условиях говорить о внедрении Scrum бессмысленно – сначала нужно решить базовые проблемы.
Красный уровень – это про иерархию и власть. Scrum внедрить можно, но он будет использоваться скорее как инструмент отчетности: соблюдаются ритуалы формально, чтобы показать, что все под контролем.
Оранжевый уровень – свобода и успех. Здесь Scrum уже ложится гораздо лучше, потому что компания ориентирована на результат, конкуренцию и развитие. Scrum становится инструментом для вывода передовых решений на рынок.
Желтый уровень – гибкость, адаптивность и децентрализация. Тут Scrum подходит особенно хорошо, потому что сам фреймворк как раз про гибкость, адаптивность и самоорганизующиеся команды. В Scrum Guide прямо сказано, что Scrum Team – это самоорганизующаяся команда.
Выводы:
-
Scrum лучше всего приживается в оранжевых, зеленых и желтых компаниях.
-
В синих и красных потребуется трансформация культуры – внедрение будет сложным.
-
В фиолетовых и бежевых это почти нереализуемо без смены парадигмы, поэтому лучше даже не пытаться.
Итоговые рекомендации для успешного внедрения
-
Изучите Scrum. Не стоит идти наощупь – есть Scrum Guide, есть теория Agile, в ней нужно разобраться.
-
Учитывайте контекст. Важно понимать, где вы это внедряете. Не везде это взлетает – у меня был опыт, когда стало ясно, что внедрение просто не полетит.
-
Найдите единомышленников. В одиночку такие изменения не внедряются – нужны люди, которые разделяют подход и готовы двигаться вместе с вами.
-
Донесите ценность до команды и бизнеса. Не все сразу понимают, зачем это нужно. Если объяснить, в чем ценность Scrum и Agile, вовлеченность становится гораздо выше.
-
Начните с малого, постепенно улучшаясь. Не пытайтесь внедрить все сразу. Вводите базовые практики, смотрите, как они работают, и постепенно развивайте процесс.
-
Адаптируйте Scrum под себя. Никто не запрещает это делать. Ванильный Scrum почти не встречается – в реальности его всегда подстраивают под контекст.
-
Собирайте и анализируйте метрики. Если вы не понимаете, что происходит с результативностью команды, вы не сможете принимать обоснованные решения. Но важно помнить, что метрики – это не цель, а инструмент. Они помогают оценить ситуацию, но за ними всегда нужно видеть реальную картину и разбираться в причинах.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.