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

2020.10.26 (ред. 2021.12.27)

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

В чем проблема индивидуальной оценки в часах?

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

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

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

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

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

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

Итак, мы выяснили, что абсолютные оценки по времени - не самое лучшее решение. На самом деле люди не умеют эффективно оценивать трудозатраты по времени. Однако, мы хорошо умеем сравнивать один размер с другим, то есть делать относительную оценку. Например, видеть разницу между футболками размеров 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. Революционный метод управления проектами | Сазерленд Джефф.