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

У знакомого вводные следующие:

• Команда около 30 человек.

• Майлстоун начался примерно в начале декабря. Следующий релиз в прод — в июне. Т.е. майлстоун длиной в полгода.

• Изначально бизнес поставил перед командой несколько целей. Они превратились, как и положено, в эпики. И эти эпики как-то оценили. Довольно неплохо оценили, на мой взгляд.

• Эпики декомпозируются естесственным образом. То что называется по методу набегающей волны — чем ближе к делу, тем лучше декомпозиция.

• Декомпозиция неплохая — большинство тикетов не больше 1-2 спринтов длиной.

• Скоуп довольно динамично меняется и пересогласуется. Т.е. много изменений походу майлстоуна. Ну, это тоже нормально.

Хочется: чтобы весь запланированый скоуп был закончен в срок.

Майлстоуном я здесь буду называть мини-проект внутри общего потока работ по разработке продукта. Т.е. установленные цели, которые нужно завершить в определённый срок.

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

В общем, приличный Agile-проект. Но даже при всё при этом, планировать не получается и в майлстоуны не укладываются.

Для начала я предложил ему почитать две очень полезные ссылки:

• User Story Mapping — для того, чтобы лучше понимать про декомпозицию работы и её планирование по спринтам и релизам.

• Управление проектом по методу FFF — чтобы понимать, что это нормально, когда срок и бюджет фиксированные, а скоуп меняется.

Конечно, по-хорошему, если бы комитменты были очень жёсткие, и если бы это был старт проекта, то надо было бы начинать с Гантта. Но здесь уже прошло 5 спринтов (кстати, спринты, как обычно, по 2 недели). Поэтому, Гантт уже как-то поздновато, по ощущениям, рисовать — уже можно применить другие интересные инструменты.

Дальше я предложил настроить Reliable Scrum — усовершенствованный Burndown chart, который показывает вероятность уложиться в срок. На YouTube есть запись, где мы с Максимом Дорофеевым и Джорджем Ивановым подробно обсудили эту тему. Максим изначально и познакомил меня с этим инструментом где-то примерно в 2014 году. Вот здесь можно взять шаблон.

Reliable Scrum, на самом деле, мало отношения имеет к Scrum. Просто так его назвал Wolfram Muller, который придумал использовать матстат в Burndown chart. Главное, что нужно, чтобы им пользоваться это:

1. Чтобы был более-менее равномерный поток работы. Т.е. работа делалась бы более-менее стабильной командой из недели в неделю. Но даже если это не так, то можно использовать поправочные коэффициенты.

2. Чтобы задач в проекте было хотя бы 20 штук. Лучше — больше, конечно. Но попробовать использовать можно и с 20 штук.

3. Чтобы майлстоун был больше месяца длиной. А лучше — месяца три или больше.

4. Чтобы задачи были оценены в единицах, которые напрямую мапятся на время.

Если у вас это есть, то можете попробовать Reliable Scrum!

Зачем нужен Reliable Scrum?

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

Reliable Scrum — по-сути, очень простой инструмент. Он берёт на вход статистику по добавлению и закрытию задач. И показывает за какое время команда, имея такую скорость, справится с оставшимся скоупом.

Плюсы следующие.

1. Такую статистику довольно сложно подделать. Когда строишь Гант, роадмапы и т.д. — очень легко манипулировать оценкой и убедить себя, или позволить другим убедить себя, что оценка и скоуп меньше чем кажется.

Прогноз по срокам даётся максимально реалистичный. Когда планируются Ганты и роадмапы, там сложно учесть то, что скоуп будет неизбежно меняться и добавляться. Даже если у вас водопад этого невозможно избежать. В Reliable Scrum это вшито изначально!

2. Reliable Scrum, однажды настроив, довольно легко дальше поддерживать. От команды требуется только оценивать новые задачи в скоупе. Но, при определённых условиях, можно вообще отказаться от оценок. Т.е. РМ практически без участия команды может строить прогнозы по окончания майлстоуна. Это удобно — не надо команду отвлекать от их любимых дел.

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

Почему нужно, чтобы задач в проекте было больше 20 штук?

R-scrum работает на основе статистики. Поэтому, чем больше статистики, тем лучше. Но существует распространённый миф, что статистики нужно много. На самом деле нет!

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

Что такое модель? Это примерно как в нейронках — ты тренируешь модель, а потом она может входы превращать в соответствующие выходы. Поэтому, если вы хотите точный прогноз по дальнейшему скоупу, то нужно нормально натренировать модель.

Т.е. чем статистика, на которой тренируем модель, будет ближе к тому как дальше будет идти проект, тем лучше, конечно.

Здесь не надо впадать в крайности. R-scrum нужно довольно мало данных для тренировки модели — от 10 выполненных задач. Но, конечно, чем ближе эти задачи будут выполнены к модельным условиям, тем лучше. Или чем больше период мы возьмём, за который будут выполнены задачи — тем ближе, вероятно, они будут к модельным.

Но не надо ни в коем случае бояться и заранее придумывать себе причины, по которым R-scrum у вас не заработает! Многолетний опыт показал мне, что гораздо лучше построить какой угодно плохой прогноз, а потом «пошатать» разные параметры модели и данные на входе, чтобы его уточнить. Чем не построить никакой прогноз. Большой плюс R-Scrum в том, что можно быстро поменять входные параметры и моментально получить прогноз.

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

Часто говорят, что «я не хочу подгонять прогноз под ответ». На мой взгляд это не правильно. Здесь дело не в том, что подгоняешь под ответ. Здесь ты занимаешься ОТЛАДКОЙ. И в процессе этой отладки ты:

1. Понимаешь, когда ты на вход даешь заведомо ложные параметры. Т.о. ты понимаешь, где ты начал обманывать модель и себя, а где нет.

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

3. Тебе не нужен один самый правильный прогноз. Тебе нужно много прогнозов для разных сценариев развития майлстоуна. R-scrum позволяет тебе мгновенно тестировать эти сценарии и понимать, что будет в том или ином случае.

Можно ли применять в случае канбана, где нет спринтов?

Как это применимо в случае чистого канбана, когда нет итераций как таковых?

Reliable Scrum — это просто статистическая машинка. Ты ей на вход даешь данные о производительности команды и объёме оставшегося скоупа. На выход получаешь прогноз — сколько нужно итераций, чтобы закончить этот скоуп.

В простейшем случае (а начинать всегда лучше с простого) — можно просто разделить количество оставшихся задач на среднее количество задач, которое команда делает в неделю. И ты уже получишь прогноз окончания майлстоуна. Который будет гораздо точнее, чем «мы не знаем когда, но, уже кажется, что никогда». Или, наоборот, обещания сделать полугодовой майлстоун за два месяца.

Причём, я не оговорился выше — можно даже делить количество задач, а не сумму их оценок.

Я видел проекты, где команда уже была настолько измучена нереальными сроками, что либо вообще отказывалась давать оценки. Либо давали их такими завышеными, что толку от них было мало. В такой ситуации надёжнее было работать с количеством задач, хоть оно даёт и больший разброс вероятностного распределения. Но плюс R-scrum в том, что вы получаете сразу оба прогноза — в штуках и в поинтах (см. шаблон). Так что дальше уже сами можете выбрать, что, по ощущениям, ближе к реальности.

Возвращаясь к теме с канбаном. Если представить r-scrum как такую статистическую машину, то легче ответить на такой вопрос. Что нужно этой машине? Чтобы производительность команды была как можно стабильнее и похожа на будущую производительность (до конца майлстоуна). Вот и всё!

И если сравнивать канбан со скрамом, то Kanban обеспечивает даже более стабильный поток сделанных задач (там это так и называется — Flow), чем Scrum. В Scrum, как его представляют обычно, команда искусственно старается запихать задачу в размер спринта. В результате это кончается тем, что либо команда сдаётся и «прощает» себе задачи, которые не уложились в спринт. Либо, начинает брать на спринт меньше задач, чем на самом деле могла бы, занимаясь оставшееся время рефакторингом и тестированием.

А ещё я видел очень забавный вариант, когда нет фиксированного размера спринта. Команда выбирает какую-то большую фичу и оценивает её. Потом говорит, что это и будет наш спринт, и добивает оставшийся объём этого срока мелкими задачами, которые точно в него уложатся. Это было настолько необычно, что даже мне понравилось — у каждого спринта своя цель, как и положено =) Но для r-scrum это не подходит. Потому что тогда количество работы будет сильно меняться от спринта к спринту.

Но даже в такой ситуации вам ничего не мешает просто не привязываться к размеру спринтов. Пусть, например, в r-scrum временные интервалы у вас будут 2 недели. А формально, спринты — какие угодно. Так тоже можно. Главное — чтобы команда выдавала как можно стабильнее количество работы за интервал.

Соответственно, в канбане, где один из основных принципов, как раз — стабилизация флоу задач, ещё лучше делать r-scrum. Потому что тогда количество сделанной каждый интервал работы будет стабильным. И прогноз будет иметь меньший разброс.

P.S. По закону больших чисел вся разница в продуктивности команды между разными интервалами быстро (кажется, со скоростью квадратного корня?) нивелируется. Так что если у вас в прошлом больше 10 интервалов (по опыту), то можно уже почти не обращать внимания на эту разницу.

Гораздо важнее, понять, что у вас с добавленной работой. Но об этом в другой раз. В этой статье больше хотелось обсудить условия для применения Reliable Scrum.

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