Оценка задач. Planning Poker

Два подхода к оценке.

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

Сейчас мы меняем подход к оценки задач из product backlog. Изначально мы интерпретировали story point как некоторый идеальный человеко-день. В дальнейшем мы поняли, что данное представление не совсем корректно. На наш взгляд (и он совпадает с мнением agile-сообщества) story point - это единица измерения объема работ, но не их длительности. Отличная аналогия - выкапывание ямы. Можно оценить в днях, а можно в кубометрах.

В чем же разница?

Во-первых, многие отмечают сложность абсолютных оценок и простоту относительных. То есть человеку сложно сказать на глаз, что длина этой кровати 2,5 метра, а другой 1,98. Но в то же время, если перед глазами стоит двухметровая кровать, достаточно легко сказать, первая больше эталона, а вторая примерно такая же. Так и с задачами: иногда бывает сложно оценить задачу, но достаточно легко сказать, что задача xxx примерно такая же как и zzz. Или что задача aaa значимо сложнее bbb.

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

Список эталонных работ

Мы пока не дошли в полной мере до этого метода. Суть его проста: на планировании перед глазами держать список эталонных работ. Мы используем карты с числами Фибоначчи: 0, 0.5, 1, 2, 3, 5, 8... Задачи более 5 под запретом. Нам надо подготовить список для каждой оценки из верно оцененных задач прошлых спринтов. Таким образом, каждый участник при оценке может аргументировать свою оценку тем, что эта задача по сложности похожа на такую-то задачу из списка, поэтому я поставил эту оценку. Или, эта задача сложнее этой задачи. Если оценка падает между двух карт, то оцениваем в большую сторону.