Покер-планирование — это всего лишь маленький трюк, который позволяет несколько точнее предсказывать сроки выполнения задач. Может быть в книжках это описывается подробно и может быть мы применяли эту штуку не в полной мере правильно, но в том виде, в котором я её опишу, нам сильно помогло.
Начнём с проблемы — мы всегда НЕ попадали в установленные сроки. Конечно же не успевали, а не в другую сторону. Причём это происходило несмотря на то, что задачи и сроки обсуждали тут же, при всех, и часто даже сам исполнитель назначал срок на свою задачу. Имею в виду не большие, длинные задачи, а задачи в рамках спринта. Т.е. то, что запланировано к выполнению на спринт — не выполнялось. При этом сложность изначально привязывали ко времени, 10 стори пойнтов — 1 день, минимальное значение сложности — 5 стори пойнтов — 0,5 дня. (На всякий случай, Story Point — условная единица сложности) Хотелось также постепенно перейти от оценки во времени к оценке именно сложности, чтобы можно было измерять рост или падение эффективности команды, т.е. сколько единиц сложности мы успеваем сделать за период, растёт ли это значение или падает. С привязкой ко времени такое не сделаешь.
2 задачи:
- Точнее предсказывать сроки (это всем нравится)
- Оценивать эффективность команды
Что мы сделали:
- Распечатали карточки с цифрами оценки сложности — что-то из ряда простых чисел (7, 13, 17, etc) — это магия, смысл которой в том, чтобы уйти от сроков к сложности. Потому что если распечатываешь карточки 10, 20, 30 и т.д. все автоматически продолжают думать о них, как о днях, по-любому.
- Подробно обсуждали каждую задачу, после чего «раскрывались» — каждый показывал карточку со своей оценкой сложности.
- Если карточки у всех одинаковые — едем дальше. Если обнаруживалось, что люди показали разные карточки, тогда БИТВА — люди с минимальной и максимальной оценками должны обосновать свою оценку. Обычно после небольшого заруба они находят консенсус и в итоге все сходятся на одной оценке. Битв до последней капли крови не наблюдалось. Такая штука позволяет выявить некоторые неочевидности в задачах. Т.е. если чувак кажет цифру заведомо больше или меньше остальных — он чё-то знает. После того, как он приводит свои аргументы, все либо соглашаются с ним, либо объясняют ему, почему он не прав.
По паре первых спринтов (периодов планирования) мы замерили, сколько стори пойнтов в новой системе мы в принципе можем делать. Удивительно, но факт, что спустя пару месяцев мы стали попадать в эту оценку. Т.е. при планировании мы брали столько стори пойнов, сколько обычно можем взять, к концу оказывалось, что, во-первых, мы всё сделали, а во-вторых, лишнего времени особо не осталось. Причём у меня не складывалось ощущения, что мы что-то подгоняем, т.е. ты такой сидишь и тянешь время, потому что у тебя на задачу вообще-то 2 дня, а ты уже сделал, можно и отдохнуть. Или наоборот, упарываешься, чтобы успеть в назначенный срок. Когда не думаешь в привязке ко времени, то просто делаешь, как можешь, не упарываясь, и особо не тормозя.
Список типовых задач:
Забыл упомянуть довольно важную вещь. Для того, чтобы начать оценивать сложность, нужно завести список типовых задач, на которые можно было бы ориентироваться и проставить для них сложность. Например, из инженерского, один чертёж простой детали — 3 sp, чертёж узла — 7 sp, типовой статический расчёт — 11 sp, типовой динамический расчёт — 17 sp и т.п. Список можно пополнять, но не нужно в него пихать всё подряд, это должны быть типовые часто возникающие задачи.
Зачем?
- Это позволит понять, от чего плясать при оценке сложности для нетиповых задач.
- Не возникнет ситуации, что вот, мы все научились ляпать чертежи за полминуты и стали вместо 3 выставлять им 1 sp. И наши сторипойнты за спринт не меняются. Тогда это то же самое, что оценивать время. Сложность типовой задачи остаётся неизменной, это наши навыки растут. По этому можно оценить рост скиллов команды — раньше мы делали в спринт 10 чертежей стоимостью 3 sp, а теперь делаем 30. Т.е. наша производительность за спринт возросла с 30 до 90.
Сроки:
Скрам - это гибкая методология, она не позволит распланировать всё на год вперёд. Зато вы всегда будете понимать, сколько объёма сможете сделать за 2 недели и начальству, зная ваш ресурс на эти 2 недели, легче будет решить, что вам дать в разработку в первую очередь и чего от вас спустя эти две недели можно получить. Долгосрочно это тоже позволит делать некоторые прикидки, но менее точно. Зато не просто с потолка, как обычно.
Разбиение:
Нужно установить какой-то максимум сложности для задач. У нас это было, вроде, 23. Потому что чем сложнее задача, тем точность её оценки ниже. Система не работает, если у вас на спринт 2 задачи по 100500 sp каждая. Нужно разбивать такие задачи на более мелкие. Мы, имея в голове всё таки время (изначально мы плясали от времени при назначении sp типовым задачам, это потом оценки могут плясать уже от этих типовых задач, а не от времени), делали так, что не пускали в спринт задачу с ожидаемым временем выполения больше 2-х дней. Если больше — разбиваем. Иначе ничего не понятно и концов не найти.
Результат по пунктам:
- Мы стали попадать в сроки — сказали, что за 2 недели сделаем вот это, и сделали.
- Со временем можно будет понять, насколько растёт эффективность команды. Пока такого не было видно, просто попадали в стабильное число.
- Как следствие — довольное нашей предсказуемостью начальство.