Попытка выяснить, как лучше оценивать. Часть 1.
Оригинальная статья Альбины Поповой: When story points misfire.
Иллюстрации Альбины Поповой.
Статья переведена с английского Еленой Максимовой.
Доступна вторая часть статьи: Зачем мы оцениваем и можно ли обойтись без этого?.
Я начала работать в XING около 2,5 лет назад с тремя командами. Все они долгое время использовали Scrum. Казалось, что гибкие ценности и принципы - уже часть их ДНК. Работал хорошо налаженный процесс двухнедельных спринтов с еженедельными сессиями уточнения беклога продукта. Все команды выполняли непрерывную поставку. Это означало, что каждую пользовательскую историю можно было легко развернуть на основном сервере, выполнив одну задачу в Jenkins. Казалось, старт будет легким.
Но, вскоре после моего приезда, одна из команд не смогла выкатить новую функцию продукта вовремя. Изначально работа над функционалом была оценена в 3 спринта (1,5 месяца), но даже 4 месяца спустя мы все еще не могли ее закончить.
В конце концов, прошло целых 6 месяцев с момента начала разработки до момента, когда функция была доступна для 100% пользователей XING.
После окончания работы мы получили убедительную просьбу научиться оценивать более точно от высшего руководства. Если бы они сначала знали, что этот функционал окажется настолько дорогостоящей, они, возможно, не инвестировали бы в нее в первую очередь.
В то время процедура планирования состояла из следующих шагов:
Определить приблизительный набор эпиков, потенциальных идей на следующих полгода или больше.
Прояснить эпики вместе с Владельцем Продукта
Оценить эпики с помощью метода T-Shirt sizes
Постепенно разбить эпики на пользовательские истории
Оценить пользовательские истории в Story Points.
Справедливости ради отмечу, что в целом этот подход к планированию работал хорошо. До поры, до времени.
Взяв на заметку просьбу об улучшении оценивания, я стала уделять больше внимания тому, как именно мы это делали.
В ряде случаев, во время встреч по уточнению беклога продукта разговоры, вызванные оценкой историй в Story Points, уходили в неожиданном направлении.
Анти-шаблон № 1 - одинаковая оценка, различное понимание
Владелец продукта представил историю. Несколько человек дало одинаковую оценку в Story Points. Обсуждения за этим не последовало. У нас есть договоренность, что, когда оценка в Story Points одинакова у всех членов команды, мы не обсуждаем ее дальше. Только позже мы выяснили, что люди совершенно по-разному поняли, о чем эта история и что нужно для ее реализации.
Анти-шаблон № 2: "Тупо" торги
Та же встреча уточнения беклога, после краткой презентации пользовательской истории Владельцем Продукта, команда приходит к разным оценкам в Story Points.
Происходит короткий пинг-понг:- Это 8.- Неа, это 5! Это не прям так сложно- Ну ладно. Я соглашусь с 5. Идем дальше.
Произошел обмен мнениями, но, кажется, он не принес какой-либо пользы.
Анти-шаблон № 3: Поверхностная оценка рисков
Это 5. -Неа, это 8. Код, который мы собираемся менять, "с душком", и я хотел бы подстраховаться. -Ну, хорошо, сошлись на 8!
Здесь, по крайней мере, есть некоторая оценка рисков, и похоже, что мы движемся в правильном направлении. Но если посмотреть внимательнее - принесла ли она пользу? Особенно, если за ней не последовало "почему у нас есть код "с душком" и "как убедиться, что он не появится снова"?
Анти-шаблон № 4: Еще раз - что такое сложность?
Это 5.
Это 8! Это кажется простым, но требует много усилий и ручной работы.
Подожди. Мы измеряем сложность. Это ведь не так сложно, как наша шаблонная история для "8".
Ладно, но опять таки - что такое сложность?
Раз за разом я видела недоуменные лица, когда мы оценивали несложные долгоиграющие задачи. Утверждение, что мы оцениваем сложность, а не время, и что такая оценка будет строится на основании средних показателей, в случае простых долгоиграющих задач было недостаточно убедительно и до конечных адресатов не доходило.
Анти-шаблон № 5: Переоценка частично завершенных историй
Хорошо, значит “Функционал А" почти готов, из 13 Story Points осталось всего около 2.
"Функционал B" тоже на полпути, давайте включим 3 Story Points из него в общую оценку для планирования спринта.
Подобные ситуации иногда случались во время планирования спринта. Даже после того, как все согласились считать историю целиком, когда она растягивается на несколько спринтов. Если размышлять вслух, сколько еще историй нужно перенести в следующий спринт, как правило, происходит такая переоценка.
Анти-шаблон № 6: Преобразование Story Points во время
Всякий раз, когда появлялся новый разработчик, и кто-то из команды вводил его в курс дел, я слышала примерно следующий диалог:- Как вы оцениваете? Что такое 5, например?- Ну, 5 Story Points - это приблизительно неделя работы, 8 - около двух недель. 1 - что-то вроде смены 1 строчки кода... Ты скоро привыкнешь.
Независимо от сложности дискуссий и наличия «шаблонных» историй для каждого количества Story Points, люди будут преобразовывать оценку в Story Points во время. Потому что так "Story points" легче понять, запомнить и объяснить кому-то.
Анти-шаблон № 7: «Мне нужна оценка»
Часто в ситуациях, когда торги длятся некоторое время, Владелец Продукта нередко подталкивает их к завершению и сама дает оценку истории в Story Points. Фраза «ребята, мне нужна оценка» действительно отражает ее потребности. Процесс устроен так, что пользовательская история, не имеющая оценки, не может попасть в спринт. Во время обсуждений, посвященных обзору беклога, нам нужно было прийти к общему пониманию ценности истории пользователя и его технической реализации. Тем не менее, неявное сообщение, которое получали члены команды, было: оценка - вот что действительно важно. И это не вина Владельца Продукта или кого-то еще, мы сами построили этот процесс так, чтобы оценка в Story Points стала необходимым условием для реализации любой идеи. Если Владелец Продукта хотел, чтобы что-то попало в беклог продукта, это нужно было оценить.
В сухом остатке
Любая практика или любой инструмент могут быть использоваться неправильно. Мне было интересно, действительно ли во всех случаях, описанных выше, мы просто неправильно использовали оценку в Story Points как инструмент.
Должна ли я была строже относиться к процессу оценки в Story Points и Planning Poker'y? Могли ли мы избежать некоторых анти-шаблонов, если бы мы подробно обсуждали каждую пользовательскую историю? Нужно ли мне было напоминать всем, что мы оцениваем сложность, а не время, на каждой встрече?
И самое важное: если рассматривать оценку в Story Points как инструмент для работы, что именно я хотела реализовать с его помощью?
«Работа» или мои ожидания относительно оценки в Story Points были такими:
сделать производительность команды предсказуемой, то есть помочь определить объем работы в следующем спринте, помочь согласовать важные этапы работы и прояснить ожидания с заинтересованными сторонами.
создать среду для беседы о пользовательской истории, которая привела бы к установлению общего понимания того, что мы пытаемся построить, между Владельцем Продукта и командой, и также внутри самой команды.
После пристального наблюдения за процессом оценки в течение нескольких месяцев у меня возникли сомнения в том, что оценка в Story Points была лучшим триггером для начала беседы о том, что мы хотим построить. У меня было ощущение, что определенные вопросы могут стать лучшей отправной точкой.
Например, вместо того, чтобы предложить: «Давайте оценим» после представления пользовательской истории, просто задайте 2 вопроса:
Вопрос 1 - Может ли кто-нибудь из команды объяснить своими словами, какова ценность пользовательской истории?
Вопрос 2 - Каков технический подтекст?
Мне легко удалось найти другой/лучший инструмент для «запуска ценной беседы».Второй и последней задачей, которую должно было решить использование Story Points, была необходимость сделать результат работы команды предсказуемым. Витающие в воздухе идеи из дискурса по #noestimates подсказывали - если бы мы убрали оценку в Story Points, то все равно в итоге сохранили бы тот же уровень предсказуемости. Таким образом, оценка в Story Points больше не была нужна.
Как только я поняла, каковы были мои ожидания в отношении процесса оценки, я захотела увидеть, насколько эти ожидания совпадали с ожиданиями команд, с которыми я работала. Чтобы понять это, я провела встречу во время нашего загородного выезда по теме “Почему мы оцениваем и можем ли мы обойтись без этого?”
Результаты той открытой дискуссии будут размещены в отдельной статье “Почему мы оцениваем и можем ли мы обойтись без этого. Попытка стать предсказуемым. Часть 2”.
Остальная часть истории - как мы провели эксперимент по удалению Story Points и какие результаты получили, будут рассмотрены в статье “Внедрение #noestimates”. Реальный пример от идеи до развертывания в трех командах. Часть 3”.
Доступна вторая часть статьи: Зачем мы оцениваем и можно ли обойтись без этого?
Comments