Сторипоинт и с чем его есть

В разработке мы уже давно используем сторипоинты, как инструмент оценки задач. Большинство разработчиков ответит, что сторипоинт — это условная единица, позволяющая определить, насколько сложность той или иной задачи отличается от эталонной. Что в сторипоинтах измеряют емкость команды и используют их для понимания количества задач, которые можно будет решить в текущей итерации. И отдельно обратят внимание на то, что сторипоинт — условная единица, которую придумали, чтобы отвязаться от человеко-часов.

Какие вопросы мы слышим?

• Мне нужно зарезервировать время работы аналитика, чтобы он мог готовить фичи для будущего РІ
• Давайте выделим часть емкости команды для работы с техдолгом
• А когда команде устранять дефекты?
• Случился инцидент — когда мы его будем устранять?
• У нас тут планнинг, куда списывать время аутстафферам?

Тут вылезает избитое слово «однако». Все правильно, однако детали портят нам всю картину. Всплывают откуда-то задачи только на аналитиков, которые надо оценить. А чем оценивать? Сторипоинтами аналитиков? Появляются в бэклоге задачи техдолга, и их тоже надо оценивать — мы же сказали, что в сторипоинтах емкость команды измеряется, а техдолг эту емкость съедает. А еще дефекты и инциденты — их-то как оценивать и как время под них резервировать? А DSМы, планирования, разбор бэклогов? Это все тоже вносить в бэклог?

Списываем ёмкость команд

• Ставим задачи на функциональные роли
• Оцениваем задачи техдолга
• Выделяем время на работу с дефектами и инцидентами
• Резервируем время под подготовку к следующим итерациям
• Ломаем голову, как фиксировать активности фреймворка

Это показывает, что где-то за словами мы потеряли истинный смысл сторипоинта, и начали использовать его неправильно. Давайте прямо сейчас попробуем разобраться, где же именно это произошло и вернуть сторипоинту его истинное значение.

Понятие сторипоинта девальвировалось — он стал аналогом человеко-часа

Сторипоинт — мера ценности

Итак, еще раз: что такое сторипоинт?

• Как нам говорит интернет, сторипоинты — это единицы измерения для выражения оценки общих усилий, необходимых для полной реализации элемента невыполненной работы по продукту или любой другой части работы.
• Или еще один вариант: сторипоинт — это условная величина, позволяющая давать элементам бэклога относительные веса, используемая для оценки объёма работы над элементом бэклога продукта.

В чем проблема этих определений? В слове работа. Мы определяем сторипоинт, как единицу измерения работы. А работа в нашем понимании — это осуществление какой-либо деятельности. Я целый день таскал мешки, потратил кучу сил, устал — я работал. Я писал код целый день, устал — работал. Сидел на дейли, рассказывал, какую работу я выполнил вчера и какую собираюсь сделать сегодня — тоже работал. Время же потрачено. И вот тут происходит постепенная подмена смысла сторипоинта. Как-будто сторипоинт — это такой же человеко-час, только более удобный для команды. Участнику команды разработки нужно что-то сделать? Впишем это в бэклог и оценим в сторипоинтах.

А теперь вспомним школьную физику. Там ведь тоже было определение работы, механической работы. Что-то связанное с силой: приложил силу — совершил работу. И тут учителя давали хитрую задачку: Сизиф закатил камень на вершину, но он сорвался и скатился вниз. Совершил ли Сизиф работу?

Учебник физики говорит: нет! Потому что камень как лежал у подножия горы — так и лежит. Мы тоже говорим: нет, потому что нет результата — нет работы.

То, что Сизиф потратил много сил и устал не означает, что сделанное им имеет какую-то ценность.

Мы оцениваем не работу, как таковую, а ту ценность, которую мы доставляем клиенту выполнением этой работы.

Когда-то на заре внедрения Agile подходов в разработке говорили, что сторипоинты — это оценка ценности, которую команда поставляет клиенту. Определение слишком теоретическое и не практичное для повседневного использования, поэтому его и заменили на более понятную и обыденную единицу измерения работы, забыв при этом, что работа должна быть ценной. Предлагаю вернуть сторипоинту его прежний смысл и помнить о том, что оцениваем мы не просто работу, а ценность, которую мы доставляем клиенту.

Что лежит в бэклоге команды?

Итак сторипоинт — это единица измерения ценности, поставляемой командой клиенту, одновременно с этим единица измерения затрачиваемых командой усилий на поставку этой ценности, и при этом ещё и единица измерения элементов бэклога. Что же у нас должно лежать в бэклоге, чтобы мы могли мерить его такой меркой, как сторипоинт? Понятно, что не просто работа (помним про Сизифа).

Мы же не просто так придумали пользовательские истории — мы сказали, что это способ понять потребности клиента через описание того, что он хочет получить, т. е. через результат работы. Получается, в бэклоге мы должны фиксировать не саму работу, а ее результат, который имеет ценность для клиента. «А как же энейблеры?» — спросите вы.

Да, те результаты, которые ждут от нас наши клиенты, слишком большие, чтобы быть вписанными в бэклог целиком — слишком долго придется ждать результатов и невозможно будет отслеживать прогресс. Поэтому мы делим их на части. Но при этом мы выдвигаем требование, чтобы эта часть также несла ценность — пусть не для конечного заказчика, но для самой команды разработки. Не «провести аналитическую проработку взаимодействия с сервисом N по API», а «подготовить прототип модуля получения данных из API сервиса N».

И в этом случае в бэклоге мы фиксируем результат работ, а не саму работу. При этом мы говорим, что результат работы Agile-команды достигается усилиями всей команды целиком. Не отдельных ее участников, а всей команды целиком. Не аналитик изучает API внешнего сервиса, чтобы передать его разработчику, который в свою очередь спихнет написанный код тестировщику, а вся команда целиком делает прототип адаптера взаимодействия с внешним сервисом. Не аналитик изучает алгоритм верификации ИНН, чтобы передать его описание разработчику, который спихнет написанный код тестировщику, а вся команда целиком реализует модуль проверки валидности ИНН.

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

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

Методика оценки элементов бэклога

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

Далее рассмотрим такую ситуацию: для того, чтобы доставить ценность — допустим, обеспечить привязку capabilities из бэклога solution train к проектам, утвержденным на страткомитете, — нам нужно не только добавить поле «Стратегический проект» на форму редактирования capability, но и заполнить его значениями — названиями стратпроектов. А названия эти в количестве 50 штук есть только в виде скриншота доски Miro.

Будет ли оценка этой задачи равна оценки задачи классификации дефектов по средам обнаружения, где в выпадающем списке имеется лишь три значения? Технически-то они абсолютно идентичны — и в том, и в другом случае надо вставить поле — выпадающий список.

Нет, мы учитываем, что в первом случае мы потратим много времени на то, чтобы просто перенести значения с доски Miro в поле ввода.

Таким образом, вторым учитываемым фактором является объем требуемой работы.

И еще одна ситуация: требуется реализация получения данных через REST API. Но в одном случае разработчики вменяемые: есть документация, она соответствует реализации, есть тестовый стенд для проверки, он идентичен промышленному и т. д. Во втором случае документация устарела, гарантии, что тест соответствует промышленному стенду нет.

Риск, что наше решение не заработает, во втором случае сильно выше. Следовательно, мы должны учитывать, что затраты времени на устранение проблем во втором случае будут больше, и оценку мы должны дать выше.

То-есть, третьим фактором у нас является риск, в том числе и риск неправильно понятых или неверно сформулированных требований.

Получаем, что наша оценка есть функция от трех переменных:

На первый взгляд выглядит, что это тот же человеко-час и есть. Но мы должны помнить, что оценка дается элементу бэклога. Который, в свою очередь, несет ценность для клиента и может быть реализован командой целиком. То-есть, сторипоинт, в отличие от человеко-часа, показывает, какой объем усилий команда целиком должна затратить для того, чтобы поставить ожидаемую ценность. Таким образом получается, что корректность и правильность использования оценки в сторипоинтах напрямую зависит от правильности формирования бэклога.

Как это все увязывается с ежедневной работой

Наконец-то мы добрались до простого участника команды, какого-нибудь разработчика Вагиза. Давайте посмотрим на его рабочий день. Понятно, что он работал над реализацией элементов бэклога, он же ради этого работает в команде. Отметим то время, которое он потратил на истории и энейблеры, зеленым. Также с утра он был на DSM и какое-то время на это тоже ушло. Отметим его голубым.

Можно ли будет спланировать следующий спринт, если элементы бэклога команды не будут проработаны? Нет, конечно. Если мы не поймем, что мы хотим сделать, как будет выглядеть результат, есть ли подводные камни в реализации, мы не сможем дать адекватную оценку, и тем самым обманем ожидания заинтересованных лиц. В скраме для этого существует специальная активность, называемая PBR. Эту активность мы должны регулярно проводить в течение текущего спринта. Мы, так сказать, даем наше время в долг будущему спринту. Сегодня у Вагиза был PBR, и это время пусть будет желтым.

Возможно ли создавать ПО без дефектов? Философский вопрос, на который хотелось бы ответить «да», но в реальности мы видим, что дефекты все-таки в наших программных продуктах присутствуют. Следует помнить, что устранение дефектов подчас важнее, чем создание новой функциональности, поскольку дефект — это отсутствие у пользователя возможности получить то, что мы ему уже гарантировали, а новая функциональность — это только лишь еще наши обещания. Поэтому время на устранение дефектов мы тоже должны выделять. Так же, как и время на ликвидацию технического долга. Метафорично можно сказать, что вы возвращаем долги за прошлые спринты. Это время у нас будет помечено красным.

Итак, весь день Вагиза расписан с утра до вечера. Из этого рабочего дня только зеленый интервал времени был потрачен непосредственно на создание ценности — реализацию элементов бэклога спринта. Понятно, что заказчику и владельцу продукта хотелось бы, чтобы этот интервал времени был равен 8 часам. Но зададимся вопросом: будет ли работоспособен такой процесс? Нет, потому что мы не сможем ни синхронизировать работу команды, ни планировать её, ни поддерживать работоспособность и возможность развития нашего продукта. Любой процесс имеет определенные накладные расходы, и эти расходы являются составной частью стоимости продукта.

Разумеется, загрузка Вагиза в разные дни спринта будет отличаться. В начале и в конце спринта мы больше времени потратим на активности фреймворка, в какой-то день больше времени уйдет на дефекты. Но в целом эти четыре составляющие: работа над элементами бэклога, проработка элементов для бэклога следующей итерации, работа с дефектами и техдолгом и общекомандные активности, предписываемые фреймворком (планирование, ретро, DSM и проч.), — всегда будут присутствовать.

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

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

Что включает в себя сторипоинт

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

Мы видим, что за спринт команда реализовала три пользовательские истории. В свое время мы выбрали одну небольшую историю в качестве эталонной, определив усилия, необходимые для ее реализации в один сторипоинт. Относительно этой истории мы определили усилия, необходимые для реализации этих трех историй в 8, 4 и 5 сторипоинтов соответственно.

Значит velocity нашей команды (не придираемся сейчас к правильности подсчета velocity) составляет 17 сторипоинтов. Иными словами, команда за спринт может поставить ценности на 17 сторипоинтов. Или же взять обязательство реализовать историй, суммарный объем усилий на реализацию которых не будет превышать 17 сторипоинтов.

Давайте еще раз зададим себе следующие вопросы:

• Сколько историй команда может взять в спринт? На 17 сторипоинтов.
• Возможно ли поставить ценность на 17 сторипоинтов, реализуя только элементы бэклога и не выполняя вспомогательные активности, такие как DSM, PBR, планирования, ретроспективы, устранение дефектов, работа с техдолгом? Нет.
• Означает ли это, что поставка ценности на 17 сторипоинтов включает в себя усилия, необходимые для выполнения основных и вспомогательных активностей? Да.

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

Посмотрим еще раз на рисунок, где показано общее распределение времени команды на реализацию трех элементов бэклога. Давайте мысленно объединим все прямоугольники одного цвета, получим пять больших прямоугольников и разделим их на 17 ровных частей. Понятно почему на 17? Потому что velocity нашей команды мы определили в 17 сторипоинтов. Получим мы примерно следующее.

Сторипоинт содержит в себе усилия, связанные с непосредственной реализацией элемента бэклога, с устранением дефектов и техдолга, с подготовкой к следующей итерации разработки и с активностями фреймворка.

Еще раз обратим внимание на то, что сторипоинт содержит в себе усилия, связанные с непосредственной реализацией элемента бэклога, с устранением дефектов и техдолга, с подготовкой к следующей итерации разработки и с активностями фреймворка.

Исходя из всего вышеперечисленного мы должны сделать следующий вывод:

В бэклоге команды не может существовать элементов:

• Не являющихся описанием ценности, получаемой заказчиком или командой по окончании итерации разработки
• Являющихся задачами на отдельных сотрудников, исполняющих отдельные функциональные роли
• Являющихся инструментом резервирования времени

Чтобы правильно оценивать свой бэклог постарайтесь помнить о следующих принципах:

• Для достижения ценности команда работает вместе, как единая сущность
• Бэклог содержит только описание результата, который ждет заказчик, другая команда или сама команда
• Оцениваем ценность, но учитываем объем усилий, помня, что в этот объем входят все усилия, предпринимаемые командой в течение спринта

Владимир Николаев, руководитель дирекции развития производственных процессов