Очень хочу поговорить про Стори Поинты (далее SP), так как это наиболее изуродованная тема в практическом применении Agile при цифровых и культурных трансформациях.
Что только со SP не вытворяют: конвертируют их в часы/дни, привязывают к утилизации специалистов, оценивают в них всё подряд и переоценивают незавершенную работу. Это всё из-за банального непонимания.
Некомпетентность = первородный грех.
На каждом месте, где мне доводилось участвовать в трансформации, в самом начале я слышал фразу “Да, мы пробовали эти ваши стори поинты и они не работают, так что давайте оставим часы!”
И каждый раз, когда я слышу фразу: “Ваши Стори Поинты (Story Points/SP) не работают!”, я обычно отвечаю: “Мои Стори Поинты замечательно работают, а с вашими давайте разбираться.”
Совсем немного истории про SP
Придумал их Рон Джеффрис, один из трех основателей методологии Extreme programming (XP) и один из 17 подписантов Agile манифеста. Придумал он SP для удобства оценки работы разработчиками и для разработчиков, а не менеджерами и не для менеджеров.
И как оказалось, придумал он их совсем не так, как в итоге их начали использовать. Чтобы мои слова не были пустыми, вот ссылка на статью Рона, где он извиняется за то, что вообще их придумал, так как многие начали злоупотреблять и использовать их неправильно.
В общем, случилась классическая история, в которой набежали менеджеры, мало что поняли, но им понравилось, и они побежали внедрять это везде.
И да, я считаю, что это не SP неправильно используют, а придумал Рон не так, как надо использовать. [sarcazm]
Изобретатель SP знает, что большинство неправильно используют его изобретение. Но при этом сам же говорит: “Если вам так нравится - продолжайте использовать.”
На мой взгляд, это очень печально :(... но просто факт.
Представьте, что вместо привычных уже сейчас часов для обозначения времени мы бы начали использовать градус поворота земли, при условии, что мы знаем, что за неполных 24 часа земля делает оборот вокруг оси на 360 градусов.
Диалог в параллельной вселенной:
- Который час?
- 197 градусов вокруг оси
Ээээ… А это точно удобно?...
А ещё можно попробовать использовать, на сколько км повернулась земля вокруг своей оси относительно радиуса… О! Или ещё круче, какой угол, радиус и т.п. оборота совершила земля вокруг солнца… ну вы же понимаете, что это лютая дичь. Хотя и привыкнуть вполне можно. Коих примеров, кстати, достаточно много.
Приблизительно это сделали и продолжают сейчас делать с SP.
Давайте разбираться, что же на практике
По моему субъективному мнению, неправильное использование SP заключается в нескольких факторах:
- Кажущаяся простота использования
- Универсализация для всего
- Непонимание сути SP со стороны тех, кто их внедряет
Действительно, кажущаяся простота использования ряда Фибоначчи, а ещё лучше модифицированного и упрощенного ряда Фибоначчи, а ещё и при условии, что в большинстве случаев оценка задачи не переваливает за 13 SP, даёт ощущение легкости оценок. Одно дело, когда нужно посчитать все часы всех сотрудников и их трудозатраты, другое дело - суммировать небольшие значения оцененных в SP задачах.
И это ловушка номер 1, которая вводит большинство в заблуждение. Даже не смотря на то, что никто, никогда и нигде не упоминал о какой-либо взаимосвязи SP и часов, опытный Руководитель Проектов (далее РП) тут же производит расчет в голове, который кажется ему простым и удобным.
А проблема начинается там, где этому опытному РП приходится осознать, что SP не имеют никакого отношения к часам и людям, единственное для чего служит SP - это для комплексной командной оценки Пользовательских Историй. При этом я хочу особое внимание обратить на то, что в продуктовой разработке Пользовательские Истории - это не просто задачи, а задачи, решение которых приносит ценность конечному пользователю, т.е. потребителю продукта. К оцениваемым в SP задачам можно также добавить Технические Истории и Баги, реализация их, как правило, тоже имеет большое значение на последующее использование продукта (своё мнение о том, что стоит оценивать в SP, а что нет, как и почему, будет в отдельной статье).
И в таких условиях опытному РП приходится ломать голову, а как ему утилизировать время специалистов, которые напрямую не участвуют в работе над той самой пользовательской ценностью, куда запихнуть работу над презентацией, куда списать кучу времени на бесконечные встречи и как просчитать, сколько SP сделает проданная им команда.
Просто не надо пытаться считать это в SP!
SP - это командная оценка задачи, имеющей ценность для конечных потребителей и которую команда обязуется реализовать за итерацию. РП и/или Владелец Продукта (далее ВП), когда речь заходит о SP, всего лишь наблюдатели. Это, конечно, не значит, что не надо задавать вопросы в стиле “А чего это такая большая оценка истории?”, “А может подумаем над тем, чтобы декомпозировать эту огромную историю?”, “А не маловато ли взяли историй в Спринт?” и т.п. Но только КОМАНДА, которая будет реализовывать историю, вправе дать оценку истории и коммитмент на её реализацию. И если, по мнению команды, они оценивают историю в 13SP и при этом дают коммитмент на её реализацию в спринте, это право команды. Только в случае неудачи и уже на Ретроспективе можно и нужно разбираться, почему же команду постигла неудача, а главное - как извлечь урок, который предотвратит ошибку в следующей итерации.
А утилизацию считайте так же, как и раньше
Если в вашем производственном процессе необходим обязательный подсчет утилизации в часах, так и оставьте его в часах. С введением SP ваши специалисты все равно будут обязаны отработать по 40 часов в неделю, и если вам необходимы презентации, то и делаться они будут теми же сотрудниками, которые реализуют ценность для пользователей, в те самые неизменные 40 часов в неделю. Тут скорее важно, что с внедрением SP дополнительно можно увидеть, а сколько реальной ценности принесла команда, и, уже имея числовые значения, анализировать эти данные и вносить изменения в процессы.
Часто в командах я предлагаю использовать и SP, и часы, но обязательно с осознанием того, что именно и для чего конкретно нужно. Наряду с часами и SP также полезно использовать метрики, которые показывают, сколько прибыли принесла донесенная до потребителя ценность.
Главное всегда помнить, что потраченное время - это, скорее всего, константа, которая не изменяется, а SP - это командная оценка реализации полезной для потребителя фичи, ну и деньги, сколько фича принесла денег, при этом все эти метрики часто никак между собой не коррелируют. Так как нет никаких гарантий, что потратив 400 часов, при этом сделав историй на 125 SP, вы заработаете больше, чем потратив те же 400 часов и сделав историй на 90 или 180 SP. Это всё совершенно про разное.
Важно помнить, что каждая метрика ценна и существует исключительно для своей системы координат, преследуя конкретные цели. А практически любая попытка натянуть ненатягиваемое парализует систему и делает её неработоспособной.
На всё это бывают классические менеджерские возражения, типа:
- А как мне посчитать, сколько часов специалист потратил на работу?
- Вы же по договору ему платите за 40 часов в неделю, соответственно, специалист отработал на вас 40 часов за неделю по тем задачам, которые ему поставил руководитель. Так что хороший специалист будет тратить на работу столько часов, сколько прописано в договоре.
- Ну а как мне посчитать, сколько времени он потратил на конкретную задачу?
- Так вы же сами говорите “времени”, вот если вам надо, то и считайте часы, потраченные на конкретную задачу, оставьте в покое SP. Любая система контроля задач изначально заточена под часы.
- Ну а как конкретно мне всё спланировать и впоследствии отследить, учитывая, что команда делает оценку историй в SP?
- Надеюсь, что вы знакомы с таким понятием, как декомпозиция. Соответственно, декомпозируйте историю на отдельные подзадачи, которые будут отвечать отдельным технологиям и типам работ. Оцените дополнительно их в часах, после исполнения зафиксируйте фактический результат. Проанализируйте полученные данные и примите соответствующие меры при необходимости.
… как правило, такие дискуссии затягиваются на довольно объёмный список менеджерских вопросов-ответов на тему “А как мне максимально контролировать команду, используя всё таки SP”... НИКАК! Ещё раз: SP не для менеджеров, SP для команды! А если вы менеджер, который жаждет контроля, то вы скорее всего так себе лидер, и есть повод переосмыслить себя и свою работу.
Про метрики я обязательно запилю отдельный пост, потому как метрики важны. Но если вы используете метрики для контроля и наказания/поощрения, то у меня для вас будут плохие новости. Даже тем командам, которым я рекомендую использовать часы, я это делаю совершенно не для подсчета утилизации, а для совершенствования специалистов в своих оценках и нахождению дыр в экспертизе, которые необходимо закрывать.
А пока мы говорим с вами о правильности использования SP, возьмите этот список, распечатайте и повесьте на видном месте. Пусть каждый раз, когда так хочется пойти казалось бы простым путем, вас остановит здравый смысл и опыт коллективного разума.
Всегда помните, что SP:
- … - опасны и бесполезны, если использовать их неправильно.
- … - бесполезны, если привязывать и/или конвертировать их в часы или деньги.
- … - не заменяют часы и/или деньги.
- … - не про людей и не про их утилизацию.
- … - не про задачи, а про Истории.
- … - про ценность для потребителя.
- … - исключительно командная оценка.
- … - не соревновательная метрика для сравнения разных команд.
- … - упрощают работу команды с оценками, сокращают время планирования, обогащая дополнительными метриками.
- … - прекрасный инструмент, если уметь им пользоваться.
Пожалуйста! Прекратите делать плохо, делайте сразу хорошо :)) и сначала научитесь использовать инструменты правильно.
Продолжение следует!
P.S.
Если в вашей компании используется что-то из критикуемого мной, то это не обязательно должно гореть на костре святой инквизиции Agile, просто, возможно, вы используете какой-нибудь “<компанинейм>джайл” и/или работаете в компаниях, в названиях которых есть слова банк, нефть, газ, строй. В общем, не обращайте внимания, это не для вас, я просто вам завидую. Я точно это знаю, я в таких работал :)
P.P.S.
Сложность восприятия материала в этой статье 8 из 10.