Оценка бэклога "в попугаях" (story-point)

2020.10.26 (ред. 2021.12.27)

Чаще всего оценка "в попугаях" встречается как некая веха на пути внедрения Scrum-фреймворка. В разработке сложных (complex) продуктов очень сложно заранее предсказать, сколько времени займет решение той или иной задачи. Поэтому вместо традиционных методов оценки трудозатрат по времени в продуктовой разработке лучше применить попугаи - относительные функциональные единицы. Помимо собственно оценки решаются следующие задачи:

Что плохого в часах?

Каждый человек спокойно может прикинуть вилку по времени, за которое он сделает ту или иную работу. Более того, людям из разных отделов очень трудно находить общий язык между собой. Поэтому при попытке собрать всех на совещание по оценке бэклога, всегда появляются недовольные возражения "Не понимаю, зачем терять время? Почему нельзя просто собрать со всех оценки и сложить их?".

Если мы просто сложим трудозатраты по всем функциям, то это все ещё не включает в себя трудозатраты на интеграцию результатов работы отдельных функций в общий результат для заказчика. А между тем, большинство причин выхода за рамки бюджета и срока кроется именно в интеграции. Закон Паретто тут выглядит следующим образом: первые 80% работы занимают 20% времени, оставшиеся 20% работы занимают 80% времени.

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

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

Более того, измеряя работу в часах, вы отбираете у команды возможность увидеть своё ускорение. Правильное применение Scrum приводит к значительному повышению скорости команды за первые 4-8 спринтов. Бывает и в 4 раза, и в 10 раз. Это происходит за счет системной работы по устранению препятствий - команда самостоятельно ищет и убирает их внутри себя, а Scrum Master работает по уборке препятствий вовне (в организации).

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

Когда мы просим человека взять на себя обязательство, то он будет закладывать в него подстраховку. А это прямые потери заказчика. И не надейтесь, что работа будет закончена раньше. По закону Паркинсона работа занимает все отведенное на нее время. Вытекающее из этого системное давление всегда снижает качество работы и демотивирует коллектив в моменте. В долгосрочной перспективе, давление является распространенной причиной текучки кадров. И в первую очередь уходят лучшие сотрудники, потому что у них всегда есть альтернативы. И никакими зарплатами эту проблему не решить. В итоге вы рискуете остаться с коллективом из непрофессионалов, которые работают просто потому, что у них нет выбора.

Относительные оценки

Итак, мы выяснили, что абсолютные оценки по времени - не самое лучшее решение. На самом деле люди не умеют эффективно оценивать трудозатраты по времени. Однако, мы хорошо умеем сравнивать один размер с другим, то есть делать относительную оценку. Например, видеть разницу между футболками размеров S, M и L. Или между собаками: такса, будьдог, лабрадор, дог. Такой подход позволяет решить проблему проектов, которые никак не хотят укладываться в рамки бюджета и времени.

Самый примитивный вопрос для оценки звучит примерно так: "Эта задача - такса или дог?". Члены команды смотрят все элементы бэклога и определяют их размер "в собаках". Чтобы было ещё проще, можно присвоить каждой породе собаки число. Таким образом такса станет единицей, дог - тринадцать, лабрадор - пять, бульдог - три.

Можно применить этот подход к списку дел для проведения свадьбы. Найти зал для приема гостей? Надо будет собрать информацию по ценам, посмотреть все варианты помещений. Этот пункт потребует некоторых усилий, поэтому наречем его лабрадором - т.е. пять. Жених и невеста? Тут просто нам обоим нужно прийти. Этот пункт будет таксой - единица. Приглашения? Нужно составить список жениха, список невесты, получить список от одних и других родителей, выбрать бумагу и конверты, заказать печать приглашений, подписать их от руки. Этот тяжелый пункт тянет на дога - тринадцать. Может быть даже на двух догов, почти слона. Есть смысл разбить его на два поменьше: список людей и открытки. Каждый будет по бульдогу - по три. В отдельный элемент выделим подписи жениха и невесты на этих открытках. Назовем овчаркой - пять. И так далее. Это и есть относительная оценка - сравнение задач друг с другом.

Фибоначчи для оценки бэклога

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

Медики знают: чтобы пациент отметил улучшение в состоянии своего здоровья, это улучшение должно превышать 2/3 от разницы между "болею" и "здоров". Сознание плохо замечает плавные изменения в каком-либо процессе. Гораздо лучше мы осознаем прыжки, резкие переходы из одного состояния в другое.

Более того, чем более сложная задача подвергается оценке, тем выше риск ее "распухания" в процессе работ. Увеличение разброса между числами в ряде Фибоначчи обнажает этот риск, намекая на абсурдность попытки взять в работу слишком большую задачу.

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

Кто должен оценивать?

Пока команда занята оценкой, работа стоит на месте. Однако нам нужны оценки, без них мы не можем управлять рисками. Может быть отдадим эту функцию в проектный офис (PMO)? Они будут оценивать проекты, а отчеты предоставят сначала заказчику на утверждение, а потом - команде разработки. Вполне разумно, да?

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

Метод Delphi для снижения эффекта привязки

Эффект привязки (binding) - это когда мнение одного члена команды принимается другими без критического осмысления. Предложенное решение может оказаться далеко не самым лучшим, не говоря уже о рисках пропустить какие-то ключевые факторы. Почему возникает привязка? Каждый человек склонен ошибаться, впадать в иллюзию, обманывать и, наконец, наши чувства и интеллект несовершенны:

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

Чтобы получить на основании независимых оценок общее мнение с достаточной степенью точности и достоверности, можно воспользоваться методом "Delphi" (RAND 1962). Авторы этого метода в 1950х годах проводили опросы в группе экспертов: четыре экономиста, специалист по анализу физической уязвимости, системный аналитик и инженер-электротехник. Им предложили оценить, сколько атомных бомб понадобится русским, чтобы помешать американцам производить их собственные. Чтобы социальное положение и статус одних экспертов не оказывал давления на других, ни один из экспертов не знал, кем были остальные. Потом индивидуальные оценки изучались, обобщались и обрабатывались организационной группой других ученых, и уже в обезличенном виде их снова скармливали анонимной экспертной группе.

Итак, при первом опросе для получения 50%-гарантии уничтожения американской военной промышленности было необходимо 50 - 5000 боеголовок. Второй опрос показал разброс от 89 до 800 боеголовок. С каждой итерацией разброс мнений сужался, пока эксперимент не остановили на диапазоне 167 - 360. Таким образом удалось отсеять невероятно широкий спектр оценок — от десяти тысяч процентов до двухсот.

Покер-планирование

Однако, мы не можем позволить себе тратить время неделями на оценку - нам нужно сделать это за несколько часов. Для этого есть довольно быстрый и точный способ сбора оценок - покер-планирование. Каждому участнику дается колода карт с числами Фибоначчи — 1, 3, 5, 8, 13 и т.д. Каждая задача выкладывается на стол. Затем каждый участник оценивает, выбирает соответствующую карту и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6.6) и переходит к следующей задаче.

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

Например, вы красите стены в доме, и вам нужно оценить, сколько времени уйдет на покраску гостиной, кухни и двух спален.

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

Проблемы с попугаями

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

Например, если у вас функциональная (аналитики, тестировщики, программисты, или др.) или компонентная (бэкэнд, фронтэнд, ios, или др.) команда, то метод просто не будет работать, потому что продукт/инкремент не является результатом работы такой команды, соответственно измерять его "попугаями" не получится.

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

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

Когда соответствующие препятствия сняты, в команде возникает запрос на инструменты для командной работы. Только в этот момент (не раньше!) и нужно заносить попугаев. В целом когда происходит внедрение Scrum-фреймворка, крайне важно соблюсти правильный порядок действий, чтобы не случился Scrum-But.

Ссылки

Scrum. Революционный метод управления проектами | Сазерленд Джефф.