Цифровая трансформация: гибкие методологии и оценка задач для Agile-управления

Оценка необходима для ответов на три ключевых вопроса:

• Сколько будет стоить сделать эту работу? Это самый важный вопрос. От ответа на него зависит, стоит ли вообще её делать, а если стоит, то когда. В продуктовой разработке есть множество подходов приоритизации задач между собой и все они, так или иначе, основываются на том, как много ценности может принести реализация каждой из работ. А если в компании применяется проектный подход к бюджетированию, то денег на реализацию той или иной работы может не хватить
• Когда будет сделана эта работа? Данный вопрос чаще всего держат в голове представители заказчика, когда просят оценить работу. Решение о том, что она будет сделана, в этот момент, обычно уже принято. Осталось понять когда же клиенты смогут воспользоваться новой функциональностью. Так же, этот вопрос важен для тех, кто управляет релизами и других заинтересованных сторон, чтобы спланировать свои работы. Например, не достаточно просто разработать новый продукт, надо доставить его до клиентов, запустить маркетинговую кампанию и подготовить юридическое сопровождение продукта
• Какая работа будет выполнена к конкретной дате? Данный вопрос, фактически, является вариацией предыдущего. В ряде контекстов не так важно, чтобы была готова конкретная работа, как понимать какая именно работа будет выполнена к определенной дате. Например, если компания готовится презентовать новые возможности на конференции, то большому количеству заинтересованных сторон нужно проделать много работы вокруг того скоупа новой функциональности, которые будут готовы к открытию конференции

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

Рассмотрим четыре основных подхода к оценке трудоёмкости задач, которые применяются Agile-командами.

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

Абсолютная оценка измеряется непосредственно в человеко-часах или человеко-днях.

В случае с прямой оценкой, разработчик должен произвести реализацию предложенной работы в голове. Это, безусловно, быстрее, чем сделать её в реальной жизни. Тем не менее, для того, чтобы оценка была точной, ему нужно максимально подробно знать детали работы и выбрать способ ее реализации уже на данном этапе. Такой подход к оценке достаточно трудоёмкий сам по себе. А главное, полученная оценка является специфичной для разработчика, который оценивал задачу. Ну и, очевидно, часто никто и не пытается превратить «на реализацию потребуется 4 часа» в "будет готово к 15 мая". Как часто вы встречались с ситуацией «я сделаю эту работу за два часа, в течение недели»?

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

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

Или рассмотреть другие подходы.

Относительная оценка базируется на сравнении задач друг с другом. Рассмотрим самые популярные подходы к относительным оценкам

• Story Points (стори поинты) – единицы оценки сложности задач относительно друг друга. Так, команда рассматривает трудоемкость, сложность и риски задачи. А потом присваивает стори поинты задачам, сравнивая её с оцененными ранее.
• Метод футболок (T-Shirt Size) – задачи оцениваются по аналогии с размерами одежды (S, M, L, XL).

Оценка в стори поинтах быстрее и дешевле абсолютной оценки. Хотя для нее и надо провести первичную оценку бэклога. Как это сделать можно прочтитать в статье Быстрая сборка бэклога. Чтобы уменьшить неопределенности при возрастании рисков, трудоемкости или сложности работы оцениваются с использованием ряда фибоначчи (1, 2, 3, 5, 8, 13, 21, 34, 55, 89…) или модернизированного ряда фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100…). Чтобы понять, зачем это сделано достаточно провести пару мысленных эксперимента. Попробуйте представть, что вы взяли в одну руку килограммовую гантель, а во вторую двухкилограммовую. Уверен, понять какая из них тяжелее и что разница примерно вдвое не составит труда. А теперь представьте, что у вас в одной руке 50 килограмм, а во второй 51. Почувствуете ли вы разницу?

Еще дальше по этому пути пошел метод футболок. Вариативность еще меньше, скорость еще выше.

Этот подход использует статистические данные и метрики, чтобы прогнозировать сроки выполнения задач и наиболее известен благодаря Канбан Методу.

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

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

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

Подход #NoEstimates предлагает радикальную альтернативу: не оценивать задачи вовсе. Вместо этого команда фокусируется на постоянной поставке небольших, ценностных фрагментов работы и использует исторические данные для прогнозирования сроков. Идея в том, чтобы устранить «лишнюю» работу по оценке и сосредоточиться на максимальном ускорении цикла обратной связи. Такой подход особенно эффективен для команд с высоким уровнем зрелости и в условиях высокой неопределенности.

Определите имеющиеся цели и ограничения.

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

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