Эта статья помогает понять, как команды в Scrum и agile могут давать гарантии и сроки, сохраняя гибкость в планировании.
Она будет полезна всем, кто заинтересован в четких сроках реализации доработок: заказчикам, пользователям, владельцам продукта, другим командам и отделам. Для краткости назовем их стейкхолдерами. Стейкхолдеры опасаются, что при переходе к Scrum и agile команды перестанут брать на себя обязательства по реализации требований к определенному сроку. В этой статье мы разберемся, почему разработчикам так сложно называть сроки. И как после перехода в Scrum и agile сохранить уверенность, что команда сделает доработки к определенному сроку.
Статья будет полезна и разработчикам. Часто стейкхолдеры спрашивают сроки у разработчиков, оставляя за собой право на изменение требований. А разработчики еще даже не знают, как реализовать то, что хотят стейкхолдеры. В этой статье мы разберемся, почему сроки так важны для стейкхолдеров и как можно вести диалог о сроках, сохраняя при этом гибкость.
Обе стороны обнаружат в статье ценные рекомендации, которые помогут сгладить противоречия и наладить эффективное взаимодействие, сохранив ценности и принципы agile.
Статья делится на две части: теорию и практику. В теории осветим методы гибкого планирования в Scrum и agile с возможностью устанавливать сроки. Эта часть написана на основе статей и книг Майка Кона. В практике рассмотрим алгоритмы кратко- и долгосрочного планирования в соответствии с рекомендациями Майка Кона и моим опытом.
Пару слов о себе. Я старший скрам-мастер в Росбанке. Помогаю организовывать работу 2 скрам-мастеров и 9 команд, насчитывающих до 100 человек. Более 12 лет в IT, успел попробовать себя в шкуре разработчика, аналитика и руководителя проектов. Погрузился в мир agile и Scrum и не вынырнул. Проверяю свой опыт с помощью сертификаций: PMP, PSMII, A-CSM, PSPOI. На Хабр пришел делиться знаниями и практиками разработки ПО, в полезности которых убедился на своем опыте.
Теоретическая часть
Kudos to Mike Cohn
В первую очередь хочу выразить признательность Майку Кону. Именно его книги и статьи привели меня в agile и Scrum. Я помню себя руководителем проектов, который только-только сдал сертификацию PMP и думал: «Ну вот теперь-то все мои проекты будут укладываться в сроки и бюджет, а объем требований не будет увеличиваться!» Ситуация на моих проектах изменилась не сильно.
В то же время моя жена попала на проекты, где работали по Scrum. И каждый день рассказывала, насколько это круто. Как довольны были и стейкхолдеры, и разработчики. Я относился к этим рассказам с недоверием. Потому что о Scrum у меня тогда было представление: «Команды на себя никаких обязательств не берут». «Как же, — думал я, — теперь укладываться в сроки?». В этот момент жена подсунула мне книгу Майка Кона «Agile: оценка и планирование проектов». Прочитав ее, я понял, что мое представление ошибочно, и решил попробовать Scrum в своих командах. Выходит, благодарить мне надо не только Майка Кона, но и свою жену ????
Майк Кон является одним из основателей Agile Alliance и Scrum Alliance. В 2012 году занял первое место в рейтинге «The Top 20 Most Influential Agile People». Более 20 лет он занимается построением высокоэффективных команд с помощью agile и Scrum. Поэтому его мнению и рекомендациям действительно можно довериться. Рекомендую его блог.
Зачем нужно планирование?
Почему стейкхолдерам так важно знать сроки? Начнем с абстрактного примера. Представьте, вы устраиваетесь в компанию и вам говорят, что:
Компания не может назвать точные даты, когда будет выплачивать зарплату.
Компания не может сказать, когда вам выдадут рабочий компьютер и доступы.
Разумеется, такая компания будет менее привлекательна, чем те, где смогут дать четкие ответы. А чтобы это сделать, компания должна уметь планировать. Например, чтобы регулярно платить зарплату, компания составляет бюджет, где определяет, из каких доходов будет оплачиваться работа специалистов. Доходы определяются новыми фичами, которые будут реализованы в приложении, и зависят от сроков реализации этих фичей.
Планирование в организации используется для:
составления бюджета;
координации связанных активностей (обучения пользователей/службы поддержки, пресс-релизов, заказа/поставки необходимого оборудования);
определения наиболее привлекательных проектов для инвестиций.
Благодаря планированию, результаты команды становятся предсказуемыми. Это дает стейкхолдерам возможность эффективно реализовывать все вышеперечисленные пункты.
В agile и Scrum сообществах эту потребность стейкхолдеров прекрасно понимают. Поэтому Майк Кон посвятил планированию отдельную книгу «Agile: оценка и планирование проектов».
Почему планировать разработку ПО трудно?
Теперь посмотрим на планирование глазами разработчиков. Стейкхолдеры требуют назвать сроки готовности. С чем мы сталкиваемся, когда хотим составить план разработки ПО?
Основных проблем три:
Стейкхолдеры изначально не знают, чего они хотят. И по мере осознания своих желаний меняют свои требования.
Разработчики изначально не знают, как технически реализовать требования стейкхолдеров. Поэтому не могут дать оценку.
Внутри и вне компании постоянно происходят изменения. Которые изменяют приоритеты требований, добавляют новые или делают существующие требования неактуальными.
Раньше эти проблемы пытались решить путем каскадного (waterfall) подхода. В начале проекта собирали со стейкхолдеров все требования и фиксировали их. Далее на основании требований проектировали всю систему целиком и таким образом исключали все неопределенности реализации. После этого создавали детальный план реализации с точными датами поставки и бюджетом. Так делали в 70–90-е годы. Статистика оказалась неутешительна. Майк приводит в книге «Agile: оценка и планирование проектов» результаты трех исследований:
Почти 2/3 проектов значительно превышают бюджет (Lederere and Prasard, 1992).
Срок выполнения среднего проекта оказывается на 100% дольше запланированного (Johnson, 2002).
64% новых функций используются редко или вообще не используются (Standish, 2002).
Последнее исследование меня всегда расстраивает больше всего. Получается, что все эти превышения сроков и бюджетов были зря, поскольку больше половины функций пользователям оказываются просто не нужны.
Один из классических примеров - разработка операционной системы OS/2. Вот краткая хронология задержек релизов:
OS/2 1.0: Планировалась на 1986 год, вышла в 1987-м. Задержка произошла из-за проблем с разработкой и совместимостью.
OS/2 2.0: Должна была выйти в 1991-м, вышла в апреле 1992-го. IBM перестроила систему под 32-битные процессоры. Задержка была в основном связана с желанием IBM добавить больше функций и возможностей.
OS/2 Warp 4: Задержка из-за дополнительных функций. Вместо OS/2 Warp 3 для PowerPC в середине 90-х, IBM выпустила Warp 4 в сентябре 1996-го. Релиз Warp 4 ожидался раньше, но произошла задержка из-за включения дополнительных функций, таких как распознавание голоса.
OS/2 не смогла завоевать значительную долю рынка. IBM перестала обновлять и поддерживать OS/2 после декабря 2006 года.
Какой итог здесь можно подвести? В разработке ПО есть очень много неожиданностей, изменений, которые мы не можем предусмотреть или предсказать изначально. В начале проекта невозможно все зафиксировать, спроектировать и просчитать. Как же выйти из ситуации, когда стейкхолдерам нужны сроки, а их прогнозирование кажется невозможным?
Как проблема планирования решается в agile и Scrum?
Первый шаг в решении любой проблемы — это ее признание. Agile и Scrum признают невозможность устранения всей неопределенности до начала работ путем фиксирования требований, разработки детального плана и полного технического решения.
В agile предлагают разделять планирование на два уровня — краткосрочное и долгосрочное. Основное различие между двумя этими уровнями — степень уверенности в нашем прогнозе и объем усилий, который мы затрачиваем на планирование.
Краткосрочное планирование нацелено на то, чтобы создать максимальную степень уверенности у стейкхолдеров и у команды относительно результатов. Долгосрочное планирование изначально признается неточным. Слишком большой горизонт планирования, поэтому слишком много неизвестностей, которые мы не можем спрогнозировать и предусмотреть. Поэтому здесь применяется обратный подход: мы стараемся потратить минимум усилий и получить приемлемую точность. План должен быть гибким, чтобы его было легко пересматривать при необходимости.
В дальнейшем под краткосрочным планированием мы будем понимать планирование спринта в Scrum, потому что именно оно идеально подходит для наших целей.
Давайте рассмотрим каждое планирование подробнее.
Планирование спринта в Scrum
Вероятность выполнения плана спринта повышают следующим образом:
Сокращают горизонт планирования.
К концу спринта команда создает рабочий вариант ПО.
Стейкхолдеров просят воздержаться от добавления новых требований в течение спринта.
Команда прилагает дополнительные усилия при планировании, чтобы повысить вероятность реализации.
Оставляют за командой право определить объем элементов бэклога, по которым она готова взять на себя обязательства.
Давайте рассмотрим подробнее каждый пункт.
Сокращают горизонт планирования.
Чем меньше горизонт планирования, тем более точный прогноз мы можем дать, поскольку уменьшается число потенциальных неожиданностей. Согласно Scrum Guide, длительность спринта не должна превышать один месяц. Сейчас самой популярной длиной спринта является две недели. Так мы решаем третью проблему планирования: «Внутри и вовне компании постоянно происходят изменения». За две недели вряд ли могут произойти кардинальные изменения, а если и произойдут, то мы сможем их учесть в следующем спринте.
К концу спринта команда создает рабочий вариант ПО.
Проблема каскадного подхода к разработке ПО заключалась в том, что стейкхолдеры не ощущали прогресса. Команда вела бурную деятельность, писала и согласовывала много документов. Но работающее ПО можно было получить в лучшем случае через 6 месяцев, в худшем — через год или даже позже. В Scrum к концу каждого спринта стейкхолдеры получают новые работающие функции. Пусть размер новых доработок не такой большой, но это позволяет ощущать прогресс. Кроме того, стейкхолдеры получают гарантию, что у них останется работающее ПО, если они примут решение остановить разработку.
Это помогает решить и первую проблему планирования: «стейкхолдеры не знают, чего хотят». Именно в момент работы с новыми функциями стейкхолдеры понимают, что их устраивает, а что еще необходимо доработать. Поскольку спринты у нас короткие, то команда без проблем может учесть обратную связь стейкхолдеров при планировании на следующий спринт.
Стейкхолдеров просят воздержаться от добавления новых требований в течение спринта.
Сократив срок планирования до 2–4 недель, мы можем договориться со стейкхолдерами, что в течение спринта приоритеты и список элементов бэклога не меняются. Две-четыре недели вполне можно потерпеть, и скорректировать приоритеты или добавить новые элементы бэклога уже в рамках следующего спринта. У разработчиков появится уверенность, что в течение спринта список элементов бэклога изменяться не будет, и поэтому они смогут дать более точные прогнозы.
Бывает, изменения приоритетов или списка элементов бэклога настолько важны, что ждать 2–4 недели до следующего спринта просто невозможно. Например, если обнаружились критичные баги на продуктиве. Если такое происходит достаточно часто, то команда на планировании закладывает резерв, чтобы среагировать на эти изменения. Чем больше таких изменений в спринте, тем больший объем резерва команда оставляет на планировании и тем меньше элементов бэклога команда может взять в спринт.
Команда прилагает дополнительные усилия при планировании, чтобы повысить вероятность реализации.
Ниже я покажу, что в Scrum на планирование и контроль отводится значительное количество времени. Чтобы еще раз вас убедить в том, что от планирования в agile и Scrum никто не отказывался.
Согласно Scrum Guide, максимальная длительность встречи по планированию – до 8 часов для месячного спринта. Если спринт короче, то встречу по планированию можно пропорционально сократить. Например, для двухнедельного спринта длительность встречи по планированию может занимать до 4 часов. Это достаточно большая доля времени от всего спринта. Прибавьте еще 15 минут на дейли, где команда формирует план работ на день, оценивает свой прогресс и корректирует план. За двухнедельный спринт на дейли уходит 2,5 часа. Таким образом, на встречи тратится 6,5 из 80 рабочих часов двухнедельного спринта, то есть около 8% всего рабочего времени. Если оценить проект на год, то 8% — это примерно один месяц: 2,5 недели на составление плана работ и еще 1,5 недели на его актуализацию.
Почему же план в Scrum получается гораздо точнее, чем при каскадном подходе к разработке ПО? Ответ в первом пункте: мы планируем на гораздо меньший промежуток времени.
Далее в практической части статьи я расскажу, как эффективно потратить 4 часа планирования спринта, чтобы сформировать реалистичный план.
Оставляют за командой право определить объем элементов бэклога, по которым она готова взять на себя обязательства.
На планировании спринта владелец продукта предлагает команде взять в спринт, например, 10 пунктов бэклога. Команда может взять на себя обязательство сделать 7 из 10 этих пунктов. После этого владелец продукта ожидает, что команда к концу спринта сделает все 7 пунктов бэклога, которые пообещала. По такой схеме мы, с одной стороны, снижаем вероятность попадания в спринт элементов бэклога, которые команда, вероятно, не сделает, — если список элементов бэклога в спринте определяет владелец продукта. С другой стороны, мы даем ему уверенность в том, какой объем работ будет реализован.
Требование сделать за спринт все, что команда обязалась на планировании, было даже зафиксировано в первых версиях Scrum Guide. Но в последующих версиях формулировку смягчили: сейчас команда должна «дать прогноз», а не «принять обязательство». Условия поменяли по двум причинам. Во-первых, жесткое требование «сделать все, что пообещали» заставляло команду из-за страха ошибки брать меньше, чем она могла бы. Во-вторых, оригинальная формулировка позволяла продакт-оунерам и стейкхолдерам сильно давить на команды, когда они ошибались и брали слишком много.
Хоть условия и смягчились, важность реализации всего, что команда взяла в спринт, не уменьшилась. Потому что это помогает завоевать доверие стейкхолдеров. Мне нравится подход Майка Кона: идеальной является ситуация, когда в 8 из 10 последних спринтов команда сделала все, что пообещала. Это означает, что прогнозы команды по количеству элементов бэклога на планировании достаточно достоверны и при этом команда не осторожничает, берет в спринт по максимуму.
Долгосрочное планирование в agile
Часто стейкхолдерам нужен план более чем на один спринт вперед. Под долгосрочным планированием понимается планирование на 3–4 спринта, квартал и более. Важно не допускать чрезмерного увеличения горизонта планирования. Планировать больше чем на полгода вперед достаточно бессмысленно.
C расширением горизонта планирования растет и неопределенность, от которой уже не избавиться. Agile сосредотачивается на следующих вещах:
Потратить на долгосрочное планирование меньше усилий и получить приемлемую точность.
-
Разделить процесс планирования на два шага:
оценка фактической скорости команды;
оценка сложности элементов бэклога.
Сделать процесс долгосрочного планирования гибким, обеспечить возможность корректирования с наименьшим количеством усилий.
Дать оценки срока в виде диапазона.
Рассмотрим подробнее каждый пункт.
Потратить на долгосрочное планирование меньше усилий и получить приемлемую точность.
В книге «Agile: оценка и планирование проектов» Майка Кона находится график, иллюстрирующий связь между точностью прогноза и затраченными усилиями. Майк вывел ее, опираясь на собственный опыт и беседы с коллегами.
Изучая график, можно прийти к следующим выводам. Во-первых, точность прогноза никогда не достигнет 100%. Вне зависимости от усилий прогноз есть прогноз. Во-вторых, небольшое количество усилий в самом начале приводит к значительному повышению точности. Из графика следует, что первые 10% усилий приносят 50% точности. В-третьих, в какой-то момент дополнительные усилия будут приводить к снижению точности.
Мы помним, что при долгосрочном планировании мы не можем избавиться от неопределенности. Наш прогноз никогда не сможет учесть все неожиданности, с которыми мы можем столкнуться. Поэтому agile-команды предпочитают потратить небольшое количество усилий, получить прогноз приемлемой точности и иметь возможность легко этот план скорректировать.
Разделить процесс планирования на два шага.
При оценке сроков возникает естественное желание сразу назвать конкретную дату. Но если задуматься, процесс оценки сроков состоит из двух частей. Первая — оценка размера элемента бэклога. Вторая — оценка скорости, с которой мы этот элемент бэклога будем выполнять. Исходя из этих двух параметров, можно рассчитать сроки реализации элемента бэклога, разделив объем работы на скорость выполнения. Совмещая эти два шага, команды теряют в точности прогноза.
Кроме того, команды зачастую делают предположения относительно своей скорости выполнения, основываясь на чрезмерном оптимизме. Это приводит к неверным прогнозам сроков. Scrum базируется на эмпирическом подходе. Поэтому очень важно использовать фактическую скорость команды.
Сделать процесс долгосрочного планирования гибким, обеспечить возможность корректирования с наименьшим количеством усилий.
Разделение процесса планирования на два шага значительно упрощает корректировку плана. Если скорость команды по каким-то причинам изменилась, то нам достаточно рассчитать новую скорость команды. После этого разделить объем работ на новую скорость, и у нас готов новый срок. Так же легко пересчитывается срок в случае изменения объема работ.
Я до сих пор с ужасом вспоминаю план работ в MS Project по одному проекту. В плане было около 400 задач, связанных различными типами зависимостей. Я корректировал план работ в конце каждого месяца. Это занимало у меня 3–4 часа. Толку от этого было немного. Потому что каждый месяц обнаруживались новые неожиданности, которые не были предусмотрены в изначальном плане. И дата завершения постоянно сдвигалась. Когда я попробовал двухшаговый метод планирования, то ощутил, насколько он легче. А точность при этом пострадала несильно.
Дать оценки срока в виде диапазона.
С учётом предыдущих рассуждений стоит признать, что точность долгосрочного планирования невысока. Это необходимо отражать в прогнозах. Для этого оценки сроков представляются в виде диапазона. Диапазон определяется при расчете скорости команды. Например, скорость команды — от 5 до 10 сторипоинтов за спринт. Суммарный объем элементов бэклога, которые необходимо сделать — 50 сторипонтов. Разделив объем элементов бэклога на диапазон скорости, получим прогноз сроков: от 5 до 10 спринтов. Если длина спринта составляет две недели, то нам понадобится от 10 до 20 недель.
«Сергей! Ты обещал, что команда сможет составить план с четкими сроками!» Что делать, если у стейкхолдеров есть жесткий дедлайн? Например, есть дата начала выставки или презентации продукта, которую сдвинуть нельзя. В этом случае мы переносим диапазон в… набор элементов бэклога.
Поясню на примере. Представим, что компании хочет представить свой продукт на выставке 10 сентября. Из данных мы имеем: скорость команды колеблется от 10 до 15 сторипоинтов на спринт, а до установленного срока остается 7 спринтов. Мы можем вычислить, что команда способна реализовать от 70 до 105 сторипоинтов до дедлайна. Элементы в бэклоге упорядочены по убыванию важности. Таким образом, элементы бэклога наиболее высокого приоритета, суммарным объемом в 70 сторипоинтов, гарантированно будут выполнены. За ними следует элементы бэклога, реализация которых возможна, но не гарантирована — их совокупный объем составляет 35 сторипоинтов. Элементы бэклога с еще меньшим приоритетом, очевидно, не будут сделаны до 10 сентября ни при каких условиях.
В долгосрочном планировании от диапазона уйти не получится. Он будет выражен либо в сроках, либо в количестве элементов бэклога.
Это компромисс, на который стейкхолдерам приходится идти: четкие сроки на спринты, гибкий диапазон на долгосрочное планирование. Почему? Это надежнее. Никаких «сделаем все ровно через 4 месяца и 10 дней». Выполнение таких сроков никто не гарантирует. Просто все друг другу боятся в этом признаться.
Практическая часть
Алгоритм планирования спринта
Scrum Guide ограничивается общими рекомендациями для процесса планирования спринта. В начале команда должна выбрать цель спринта, потом определить количество элементов бэклога, по которым они готовы взять обязательство превратить их в инкремент к концу спринта. Параллельно с этим для каждого элемента бэклога команда должна составить план, как она будет превращать элемент бэклога в инкремент.
Scrum Guide не уточняет, каким образом команда понимает, что она сможет сделать 7, а не 10 элементов бэклога или как должен выглядеть план работ по элементу бэклога. Поэтому каждая команда может выбирать свой способ. Его можно придумать самостоятельно, либо воспользоваться опытом других команд.
Любой алгоритм планирования хорош, если он вас устраивает и позволяет достичь целей, которые зафиксированы в Scrum Guide для планирования. Алгоритм ниже — один из вариантов, который можно попробовать, чтобы повысить точность вашего планирования. По этому алгоритму составляют планы на спринт восемь команд Росбанка и пять команд в другом банке.
Алгоритм был разработан Майком Коном и называется Capacity-Driven Sprint Planning. В ходе работы мы его немного изменили, и у нас он выглядит вот так:
Определить capacity команды.
Посмотреть статистику за прошедший спринт, сделать выводы, определить общий лимит на команду.
Выбрать элемент из бэклога продукта.
Определить, можно ли его сделать за спринт. Для этого мы разбиваем элемент бэклога на подзадачи и оцениваем их.
Если осталась capacity, повторить шаги 3-4.
Проверить план на адекватность, сравнив запланированный объем часов с лимитом на команду и статистикой за предыдущие спринты.
Рассмотрим каждый шаг подробнее.
1. Определение capacity команды
Для определения capacity я готовлю вот такую таблицу в Excel. Основная цель этого шага — определить, сколько времени каждый член команды сможет выделить на работу в команде в следующем спринте.
Для этого участники команды рассказывают, пойдут ли они в следующем спринте в отпуск, планируют ли отгулы, обучение или другие мероприятия, которые сократят их время работы в команде.
На основе данных о количестве рабочих дней в спринте и данных об отпусках, отгулах и других отсутствиях в таблице рассчитывается диапазон доступного времени каждого участника команды и команды в целом. Оценка выполняется в идеальных часах.
Что такое идеальный час и зачем он нужен? Допустим, с утра член команды сказал, что сделает задачу за 8 часов. Исходя из этой оценки все делают вывод, что завтра к утру задача будет сделана. Полный энергии и уверенности, он начинает работать над задачей… и вдруг его зовут на несколько важных встреч, где без него не могут принять решение. Потом внезапно оказывается, что у него нет необходимых доступов, чтобы сделать доработку. Потом падает среда разработки и не получается выкатить доработку, чтобы протестировать ее. Потом приходит коллега из другой команды и просит нашего участника команды помочь решить одну проблему… К концу дня наш герой обнаруживает, что ему удалось поработать над задачей всего 4 из 8 часов рабочего дня. Так получилось, поскольку, прогнозируя 8 часов, участник команды имел в виду, что:
Он будет работать над одной задачей.
Его никто не будет отвлекать.
У него будут все необходимые доступы и инструменты.
Просить каждого разработчика закладывать в свои оценки все неожиданности, которые могут возникнуть, — пустая трата времени. Проще взять результаты статистических исследований (4–5,6 идеальных часов в день) и просить разработчиков давать оценки именно в идеальных часах.
Таким образом в таблице с capacity мы вычисляем диапазон минимального и максимального количества «идеальных часов» на спринт для каждого члена команды и команды в целом. Это помогает команде определить, когда им стоит остановиться при наборе элементов бэклога в спринт.
Для разработчиков все это объяснение можно сократить до следующего: «Скажите, сколько вам необходимо времени на выполнение задачи. Закладываться на неожиданности не надо».
2. Анализ статистики за прошедший спринт. Определение общего лимита на команду
На этом шаге мы смотрим результаты только что прошедшего и предыдущих спринтов. Для этого я готовлю таблицу, в которой на основании отчетов Jira рассчитывается, сколько идеальных часов в целом на команду мы брали в начале планирования, сколько пришлось добавить и сколько мы не успели сделать до окончания спринта.
Основная цель — чтобы количество удаленных из спринтов идеальных часов было равно нулю. Это будет означать, что команда сделала все, что взяла на планировании спринта и что было добавлено в спринт. Также хорошим показателем является стремление к нулю добавленных подзадач. Это означает, что в течение спринта команда не брала новых элементов бэклога в спринт и скоуп оставался неизменным. Если команда может быть уверена, что в течение спринта ей не прилетит новых, срочных элементов бэклога, то ей легче спланировать спринт. Если все-таки такое невозможно (например, надо оперативно исправлять критические баги с продуктива), то этот показатель может помочь определить резерв, который необходимо оставлять на планировании спринта.
После обсуждения я прошу команду определить в идеальных часах суммарный лимит всей команды, за который мы не будем выходь на планировании спринта.
3–4. Планирование работ по элементу бэклога и оценка подзадач в идеальных часах
Далее мы приступаем к планированию спринта. Для этого мы открываем раздел Backlog в Jira. Важно, чтобы к этому моменту продакт-оунер определился с приоритетностью элементов бэклога на следующий спринт. Очень хорошо, если он расположил элементы бэклога продукта по убыванию их приоритета.
Вначале, если у продакт-оунера есть понимание, он может озвучить предполагаемую цель спринта. Если понимания нет, к этому можно вернуться в конце планирования спринта. Далее команда берет самый важный по приоритету элемент бэклога, добавляет его в спринт и обсуждает, как он будет реализован. Уточняются детали по архитектуре, дизайну.
Когда способ реализации элемента бэклога становится понятен, команда создает подзадачи. Они описывают последовательность шагов, которые необходимо реализовать, чтобы элемент бэклога превратился в работающую фичу. К таким подзадачам могут относиться: уточнение бизнес- и системных требований, доработка макетов, написание кода, тест-кейсов, тестирование в различных средах. Каждая подзадача оценивается в идеальных часах.
В идеале подзадачи не должны назначаться на конкретных людей и к ним должен приступать первый освободившийся член команды. Но у нас пока этого не получалось, поэтому мы назначаем подзадачи на конкретных участников команды.
5. Можем ли взять еще один элемент бэклога в спринт?
После того как все подзадачи созданы и оценены, я задаю команде вопрос: готовы ли они взять еще один элемент бэклога в спринт и пообещать довести его до работающей фичи?
Чтобы дать ответ на этот вопрос, мы:
сравниваем лимит на планирование, который себе установили, с общей суммой идеальных часов по всем подзадачам на следующий спринт,
сравниваем данные из отчета Jira по накопленным идеальным часам для всех членов команды с диапазоном минимального и максимального количества идеальных часов из таблицы с capacity.
Далее команда принимает решение, готова ли она взять в спринт еще один элемент бэклога. Важно понимать, что общекомандный лимит, минимальная и максимальная граница для каждого участника команды жестко не закреплены. Это, скорее, ориентир, который помогает команде принять решение. То есть команда вполне может выйти за лимит, если считает, что способна довести дополнительные элементы бэклога до работающей фичи. Или команда может остановиться до лимита, если считает, что взяла уже достаточно. Оценив статистику по итогам спринта, можно будет обсудить с командой, насколько удачным оказался их выбор перейти за лимит или остановиться до него.
6. Проверка адекватности. Сравнение с предыдущими спринтами
В конце спринта можно еще раз попросить команду сравнить сумму идеальных часов по всем подзадачам на будущий спринт с установленным лимитом, а также посмотреть на статистику. Иногда это производит на команду отрезвляющее действие. Если они видят, что из спринта в спринт берут больше, чем реально могут сделать, то, возможно, скорректируют количество элементов бэклога, взятых в очередной спринт.
Всегда можно предложить следующий компромисс. Несколько элементов бэклога, уже разбитых на подзадачи и оцененных в идеальных часах, можно оставить в топе бэклога продукта. И если команда успеет сделать уже взятые элементы бэклога раньше, то может брать из топа бэклога продукта новые.
Я напомню, наша основная цель — создать ощущение уверенности. Лучше пообещать шесть элементов бэклога и сделать шесть, чем сделать шесть, пообещав при этом восемь.
Tips & Tricks
Критерии/метрики успешного планирования спринта
Исходя из принципов планирования спринта, описанных выше, на мой взгляд, основным критерием здесь является реализация всех пунктов бэклога, которые команда взяла на планировании. Оптимальное соотношение: в 8 из 10 последних спринтов команда сделала все элементы бэклога, которые взяла на планировании. Добиться этого помогают две метрики:
Объем элементов бэклога (в сторипоинтах, часах или чем-то еще), которые команда взяла в спринт, но не смогла сделать в течение спринта. Очень хорошо, когда эта метрика уменьшается.
Объем элементов бэклога (в сторипоинтах, часах или чем-то еще), которые команда не планировала в начале, но взяла по ходу спринта. Уменьшение этой метрики тоже хорошо. Чем меньше таких элементов бэклога, тем проще планировать спринт. Так при планировании нет необходимости думать о резерве на неожиданные элементы бэклога.
А как же задачи на анализ для следующих спринтов?
Часто возникает вопрос: а что делать с элементами бэклога, по которым проводится аналитика для подготовки к будущим спринтам? Стоит ли их включать в бэклог спринта или нет?
Если посмотреть в Scrum Guide, то ответ однозначен: нет, такие элементы мы включать в бэклог спринта не можем. Потому что все элементы бэклога, которые взяты в спринт, должны дойти до состояния Definition of Done, то есть до состояния «работающей фичи». Обычно, в Definition of Done входят пункты: код и тест-кейсы написаны, тестирование в различных средах проведено, доработка выведена в прод. Элементы бэклога, по которым завершен лишь анализ, очевидно, Definition of Done не удовлетворяют.
Что же делать? Вариантов два:
Не включать такие элементы бэклога в спринт. Оставлять их в топе бэклога продукта.
Если все-таки очень хочется, то можно добавить элементы бэклога в спринт и создать по ним одну подзадачу, «анализ», без оценки в идеальных часах. Тогда аналитики смогут на дейли рассказать, что они сделали по анализу, а отсутствие оценки в идеальных часах не будет влиять на оценку общего прогресса команды.
Следует помнить основную цель команды на спринт: превратить все элементы бэклога продукта, которые они взяли в спринт, в работающие фичи. Поэтому аналитик в первую очередь должен быть нацелен на помощь команде с элементами бэклога, которые должны превратиться в работающие фичи. Анализ задач на будущие спринты — второстепенная задача, к которой аналитик приступает, только если у команды нет вопросов и не требуется помощь по задачам из бэклога текущего спринта.
Насколько важна цель спринта?
Основная проблема с целью спринта в большинстве команд в том, что цель не включает в себя все элементы бэклога, которые команда берет в бэклог спринта.
Это происходит, потому что командам необходимо за спринт реализовать элементы бэклога для разных платформ: веб-приложения, мобильные приложения, внутренние системы и так далее. Кроме этого, часто в спринт приходится брать много багов и различных мелких доработок предыдущих фич по итогам обратной связи от пользователей с прода.
Обычно получается следующая ситуация. Команда берет в спринт 10–20 элементов бэклога. При этом цель спринта касается 3–4 элементов бэклога, которые являются самыми важными в спринте. В результате команда выполняет цель спринта, а вот все элементы бэклога, которые взяли в спринт, до состояния Definition of Done не доводит. Конечно, это лучше, чем ничего. Если новая команда не может за спринт сделать даже 3–4 самых важных элемента бэклога, фокус на цели спринта необходим. И это первое, чему должна научиться команда: планировать так, чтобы выполнять цель спринта.
После того как команда обучается достигать цель спринта, важность цели спринта снижается. Неважно, как она сформулирована, неважно, сколько элементов бэклога охватывает. Майк Кон, например, допускает в некоторых случаях невозможность формулирования цели спринта.
На первое место выходит следующий шаг развития команды: уметь спланировать спринт так, чтобы довести до Definition of Done все элементы бэклога, которые были взяты на планировании или в течение спринта.
Алгоритм долгосрочного планирования
Этот алгоритм используют шесть команд Росбанка для составления планов на квартал. У нас спринты по три недели, поэтому в квартале у нас от 4 до 5 спринтов. Вы можете выбирать горизонт планирования на свое усмотрение.
Алгоритм планирования следующий:
Анализ статистики за предыдущий период.
Определение диапазона скорости команды и диапазона сторипоинтов на следующий период.
Определение элементов бэклога, которые команда готова реализовать на следующий период.
Встреча по планированию у нас занимает не больше часа. Для этого до встречи необходимо выполнение трех условий:
Владелец продукта составил отсортированный список элементов бэклога для следующего квартала.
Команда уже оценила сложность элементов с помощью покер-планирования, используя сторипоинты.
Скрам-мастер подготовил таблицу с двумя листами: сравнение плана с результатами предыдущего квартала и лист с диапазоном скорости и объемом сторипоинтов на следующий квартал.
Невыполнение этих условий увеличивает длительность встречи. Наши команды научились быстро оценивать сложность элементов бэклога, укладываются в рекомендованные Майком 5-6 минут на один элемент. Поэтому второе условие мы иногда выполняем прямо на встрече, не превышая часовой лимит.
Очень хорошо, если в начале встречи владелец продукта объяснит команде, какой цели он хочет добиться к концу следующего квартала.
1. Анализ статистики за предыдущий период
Цель шага — понять, как мы можем повысить точность планирования. Для этого мы сопоставляем план и факт прошедшего квартала и думаем, что получилось хорошо, а что можно сделать лучше. Важно объяснить команде, что процесс направлен на обучение, а не на упреки. Используем подход «давайте проанализируем прошлые данные и подумаем, как повысить точность прогноза на следующий квартал».
При анализе статистики, мы фокусируемся на двух аспектах:
Количество элементов бэклога из предыдущего квартала, успешно достигших прода.
Соответствие реальной средней скорости команды прогнозу.
Как это помогает в планировании, можно увидеть на примере ситуаций в одной из наших команд. Заодно разберемся, из чего состоит лист с анализом результатов за прошлый квартал.
Рассмотрим лист с анализом результатов. В левой части отображаются фактические значения скорости команды за спринты. Чтобы легче ориентироваться, мы выводим даты начала и завершения спринтов и закрашиваем кварталы разными цветами.
В таблице «Определение диапазона скорости» отображается средняя скорость, которая была рассчитана на этапе планирования, и фактическая средняя скорость, которую команда показала в течение квартала. Планирование на 4 квартал происходило во время 62 спринта. Скорость за 62 спринт еще не была известна, поэтому мы рассчитывали скорость как среднее значение за последние 6 спринтов (больше данных у нас не было). Фактическая средняя скорость была рассчитана за последние 8 спринтов. В таблице «Определение диапазона сторипоинтов» можно сравнить планируемый и фактический объем сторипоинтов за квартал. О рекомендациях по расчету средней скорости и диапазонов мы с вами поговорим на следующем шаге.
В таблице «Список задач, которые берем на следующий квартал» можно посмотреть, какие из запланированных элементов бэклога были сделаны за квартал. А также сравнить, сколько из запланированных сторипонитов было реализовано.
Как мы воспользовались этими данными для анализа своих результатов? Команда запланировала на квартал сделать определенный список элементов бэклога. Объем составлял 236 SP. Из первоначального списка смогли сделать 111 SP. В то же время за квартал команда сделала 536 SP. Команда пришла к выводу, что приоритеты существенно изменились, и они взяли дополнительные элементы бэклога, которые появились в течение квартала. Стейкхолдеры были согласны с подходом, когда команда изначально брала меньше элементов бэклога, оставляя резерв для неожиданных ситуаций. Поэтому на следующий квартал решили планировать меньше элементов бэклога и оставлять больший резерв на пожары.
2. Определение диапазона скорости команды и диапазона сторипоинтов на следующий период.
Оценить диапазон скорости работы команды можно разными способами. Я не видел исследований, которые сравнивали бы эти способы между собой. Поэтому я полагаюсь на советы Майка и определяю диапазон скорости команды, используя коэффициенты. Этот процесс состоит из двух этапов:
Вычисляем среднюю скорость команды.
Умножаем среднюю скорость на коэффициенты, чтобы получить диапазон.
Майк рекомендует рассчитывать среднюю скорость команды на основе данных последних 8 спринтов. Если у нас нет данных за 8 спринтов, берем то, что имеется.
Коэффициенты, на которые следует умножить среднюю скорость для получения диапазона, можно найти в книге Майка Кона «Agile: оценка и планирование проектов»:
Наша следующая задача — вычислить диапазон сторипоинтов, которые команда сможет выполнить за квартал. Для этого определяем количество спринтов в следующем квартале и умножаем его на диапазон скорости команды.
3. Определение элементов бэклога, которые команда готова реализовать на следующий период
На листе выше представлен план еще одной команды на 3 квартал 2023 года. На встрече по планированию в таблице «Фактическая скорость» мы заполнили столбец «Отпуска». Это помогает повысить точность плана на квартал. Планирование проходило во время 74 спринта. Скорость по нему еще не известна. Средняя скорость за последние 8 спринтов составила 55,6 сторипонитов. В 3 квартале у нас будет 5 спринтов и в соответствии с этим рассчитан диапазон сторипоинтов.
После расчета диапазона сторипоинтов команда двигалась по приоритизированному бэклогу сверху вниз и по одному добавляла элементы бэклога в план на следующий квартал. Владелец продукта объяснял ценность элемента бэклога и условия удовлетворенности. Разработчики задавали уточняющие вопросы. Если команда еще не оценивала сложность элемента бэклога, они выполняли это на месте и двигались дальше.
После каждого элемента бэклога команда сравнивала накопленное количество SP с диапазоном сторипоинтов и решала, готовы ли они добавлять еще элементы в бэклог квартала. Элементы, которые расположены вверху бэклога и в сумме примерно равны минимальной границе диапазона сторипоинтов, отмечены как обязательные. За квартал команда реализует их с очень большой вероятностью. Оставшиеся элементы бэклога на следующий квартал отмечены как «возможные».
Tips&Tricks
Как проводить долгосрочное планирование, если у нас несколько команд?
Общую встречу по планированию для нескольких команд стоит проводить, если у них единый бэклог и владелец продукта. В таких случаях я готовлю общий файл со статистикой. Считаю общую скорость и общее количество сторипоинтов для всех команд.
Во время долгосрочного планирования нет смысла закреплять элементы бэклога за конкретными командами. Масштабируемые фреймворки (например, LeSS) настоятельно рекомендуют делать команды максимально универсальными, чтобы они могли сделать любой элемент из общего бэклога. Распределение элементов бэклога между командами откладывается до планирования спринта. Это дает дополнительную гибкость.
Почему для планирования спринта рекомендуется использовать часы, а для долгосрочного планирования — сторипоинты?
Разница между часами и сторипоинтами заключается в точности оценки и размере усилий. Сторипоинты являются неточной оценкой. Они позволяют быстро (за 5-6 минут) получить примерную общую оценку сложности элемента бэклога. Часы, наоборот, позволяют получить более точную оценку сложности элемента бэклога. Но для этого нам необходимо потратить больше усилий: обсудить подробнее техническую реализацию, составить план работ в виде списка подзадач, и каждую оценить в часах.
На этапе оценки в сторипоинтах команда еще не знает, действительно ли она будет реализовывать этот элемент бэклога. Через некоторое время он может стать неактуальным. Поэтому важно потратить небольшое количество времени и получить приемлемую точность. При планировании спринта команда и стейкхолдеры хотят иметь максимальную уверенность, что этот элемент бэклога к концу спринта будет выведен в прод. Поэтому команда прикладывает дополнительные усилия и здесь примерной общей оценки сложности в сторипоинтах уже недостаточно.
Как соотносятся между собой сторипоинты и часы?
Может возникнуть соблазн вычислить, сколько часов содержится в сторипоинте. Лучше этого не делать. Сторипоинты дают приблизительную оценку сложности элемента бэклога. Поэтому элементы бэклога с одинаковым количеством сторипоинтов могут получить разные оценки в часах во время планирования спринта. Это нормально, потому что, повторюсь, оценка в сторипоинтах — это примерная оценка сложности. Хорошую визуализацию приблизительности оценки в сторипоинтах Майк приводит в книге «Agile: оценка и планирование проектов»:
Использование скорости как метрики производительности команды
Я против того, чтобы оценивать производительность команды по количеству сторипоинтов или часов, которые команда сожгла за спринт. Потому что команда может легко эту метрику обойти. Раньше мы элемент бэклога оценивали в х часов/сторипонитов, а теперь будем оценивать в 2х. В результате «скорость» выросла в 2 раза, все молодцы, а производительность осталась прежней. Основное назначение сторипоинтов и часов — помочь командам повысить точность планирования.
Кроме того, не стоит сравнивать команды по скорости. Во-первых, по той же причине, что я описал выше. Во-вторых, команды могут оценивать одну и ту же задачу в разное количество сторипоинтов. Потому что в каждой команде может быть свое понимание размера задачи в один сторипоинт.
Результаты
Приведу статистику планирования спринтов одной из команд. Команда перешла на новый процесс планирования в начале февраля 2022 года. В первых трех спринтах средний объем взятых на спринт обязательств составлял 213 часов. Средний объем невыполненных элементов бэклога к концу этих спринтов был 113 часов. То есть 53% от изначально запланированной работы команда к концу спринта сделать не успевала. Год спустя, за три последних спринта средний объем взятых на спринт обязательств составляет 114 часов. Средний объем незавершенных элементов бэклога к концу спринта сократился до 13 часов. Таким образом, объем незавершенной работы к концу спринта у команды сократился с 53% до 11%. У команды появилась репутация, что они умеют сделать все, что пообещают.
Второй количественной оценкой, по которой можно судить о полезности изменений, является ICSS (Internal Customers Satisfaction Survey). Это уровень удовлетворенности внутренних клиентов качеством взаимодействия и сервисов. Два раза в год в банке проводится опрос, позволяющий командам оценить работу друг друга. До начала внедрения (октябрь 2021) нового подхода к планированию оценка наших команд составляла 8,3 балла. Последняя оценка (май 2023) показала результат в 9,7 балла. Безусловно, повышение удовлетворенности стейкхолдеров нашими командами произошло не только из-за изменения процесса планирования. Тем не менее я считаю, что в этом есть и определенный вклад нового процесса планирования.
Далее идут субъективные оценки. Во всех 8 командах, где внедрялось планирование на спринт, командам этот процесс понравился и они решили продолжать в нем работать. Ребята отмечают возросшую прозрачность и уверенность в способности назвать сроки и взять на себя обязательства. Процесс планирования на квартал с помощью сторипоинтов прижился в 6 командах из 7. Его полезность больше оценили владельцы продуктов. Потому что теперь план на квартал строится на основании фактической скорости и оценок сложности элементов бэклога со стороны команд, а не только на субъективных оценках.
Заключение
Надеюсь, статья помогла вам понять, как можно получить гарантии при планировании в Scrum и agile и в то же время сохранить гибкость ????
Напоследок еще несколько рекомендаций:
Изменения лучше внедрять в два этапа. Сначала планирование спринта. Когда оно приживется, приступать к долгосрочному планированию. Параллельное внедрение обоих процессов может оказаться для команд слишком сложным.
Лучше начинать с планирования спринта. Эффект от внедрения появляется быстрее, чем от долгосрочного планирования.
Если команд много, попробуйте изменить процесс планирования в одной-двух командах. Потом их можно будет использовать как Success Story для агитации других команд.
В гугл-таблицах я выложил шаблоны для планирования спринта и для долгосрочного планирования. Если есть вопросы — напишите мне в LinkedIn.
David_Osipov
Был продакт-оунером, все свои грабли прочитал в статье - спасибо :)