«Размер имеет значение, но только относительное». Именно такими словами можно начать описание техники Покер планирования (Planning Poker, Scrum Poker), используемый в гибкой методологии Scrum. Что же в данном случае значит слово «относительное»? Давайте предположим, что у вас есть список задач, который вы уже выстроили по приоритетности дел, но теперь вам необходимо оценить сколько потребуется усилий, а значит денег и времени на выполнение этих дел.
Такие аспекты как сложность задачи можно обсуждать часами, но что если изначально сравнивать эти задачи друг с другом? Как это происходит? Очень просто и ежедневно. Приходя в магазин вы видите разницу между футболками S, M, L, XL. Или же, гуляя с собакой, вы понимаете что ваш шпиц меньше пуделя, а тот меньше овчарки. Конечно, свои дела вы не будете оценивать в собаках или других зверях (хотя некоторые IT-компании так и поступают), вы будете оценивать задачи в цифрах.
Уверены, что многие из вас слышали о “последовательности Фибоначчи” и уже знакомы с магией этого числа. Эта последовательность заложена и в формировании раковины наутилуса, и в ветвях дерева, и в извилинах человеческого мозга. 0, 1, 1, 3, 5, 8, 13, 21, 34, сумма следующего равна сумме двух предыдущих…Последовательность Фибоначчи позволяет нам избежать точной оценки, свое мнение мы формируем ориентируюсь на весь ряд чисел.
Но теперь возникает вопрос, что же делать с этими числами, и как играть с ними в “покер”. Идея очень проста и строится на 7 базовых действиях:
- Каждый участник команды получает колоду карт с числами 1, 3, 5, 8,13 и так далее.
- Каждая задача, которая должна быть оценена, выкладывается на стол или оглашается вслух.
- Затем каждый участник лично оценивает задачу и кладёт на стол “закрытую” карту со своим числом.
- После того, как все карты сыграли, карты переворачиваются.
- Если расхождение не более, чем на две карты (например, 5, 8, 8, 13), то берется среднее арифметическое, округленное в большую сторону (здесь будет 8), и команда переходит к следующей задаче.
- Если расхождение больше чем в три карты, тогда участники с самой большой и маленькой картой объясняют свою точку зрения, и после этого команда переигрывает “раунд”. Такие ситуации часто происходят, когда команда имеет скиллы разного уровня или направленности, например, кто-то больше специалист по back-end, или кто-то ещё не пользовался выбранными технологиями front-end, поэтому такие люди могут оценить задачу слишком “большой”, или, наоборот, из-за своей некомпетентности, они могут не понимать всю сложность поставленной перед командой задачи. Именно в этот момент командное обсуждение и пригодится.
После того, как все задачи были «сыграны», у вас появляется список со всеми задачами и их оценками, именно основываясь на них, вы сможете спланировать, сколько суммарных «очков» (Poker points) вы сможете закрыть за спринт. Предположим, команда только начинает проект, берёт за начальную «ставку» 21 поинт за неделю. Если в течение недели команда набрала чуть меньше очков по выполненным задачам (например, 18), то на следующую неделю команде всё равно стоит запланировать 21 поинт, чтобы команда всегда была мотивирована нарабатывать «скорость» работы. Если же команда совсем не справилась с поставленной задачей, то стоит снизить планку, но если команда закрыла все поставленные задачи, то «ставку» стоит поднимать для развития команды и качества доставляемого продукта.
Но чем же всё-таки удобен подобный «покер»? Во-первых, это просто, во-вторых, нет эффекта «стадности» в принятии решений, в-третьих, дискуссия не превращается в хаос, ведь задачи обсуждаются поочерёдно, что держит обсуждение в рамках одной задачи. Более того, задачу оценивает именно сама команда, которая эту задачу и будет выполнять, поэтому их оценка максимально близка к действительности. Ну и конечно же, Poker Planning — это игра (пусть даже на серьезном проекте), и каждый игрок сможет лишний раз отрепетировать свой «Poker face», который может очень пригодиться в работе с некоторыми «особенными» заказчиками.
