Команда, с которой я работаю как Scrum-мастер, далека от разработки игр, тем более азартных. И тем не менее, каждые две недели мы собираемся для партии в покер… Planning  Poker.

Когда на конференции AgileBaseCamp я спрашивал: “Кто из присутствующих работает по Scrum?”, то почти все подняли руки. И в тоже время, на вопрос: “Кто НЕ знаком с правилами Planning Poker?”, я опять увидел лес рук. Возможно, об этом следует рассказать. Во всяком случае, расскажу зачем МЫ играем в него.

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

Парадокс с программистами заключается в том, что если их спросить, как сложно сделать то или иное требование, то в ответ можно услышать: “десять часов”. Продолжительность во времени еще не означает сложность. Бывают случаи, когда нужно изменить сотню файлов по всему проекту, а бывает нужно изменить одну строчку, только вот еще бы найти где 🙂 И никакие сложные математические теории не помогут. Значит, нужно упрощать!

Еще с давних времен, человек мог отличить большое яблоко от маленького. Или отличить льва от носорога и зайца. В этом и состоит суть оценки сравнением. Мы берем следующий элемент из бэклога и сравниваем с теми, что уже оценены или хотя бы с предыдущим опытом. Это больше чем то? Возвращаясь к примеру с животными, на вопрос “а какого размера жираф”, почти любой скажет – между львом и  носорогом. Т.е. для нового элемента мы находим место между другими, уже оцененными.

Хочу обратить внимание, что мы не сравниваем с эталоном. Однажды услышал от кого-то фразу: «Мы перестали играть в Planning Poker, потому что уже забыли ту маленькую историю пользователя, которой мы дали оценку 1 и потом с ней сравнивали остальные». Тут явно что-то не так :-).

Как я уже говорил, мы сравниваем элементы бэклога между собой. Если у вас новый проект и новая команда – это, пожалуй, самый сложный случай. Тогда приходится искать какую-то отправную точку – некое маленькое требование, о котором вся команда может сказать: “Оно маленькое”. Если же команда уже работает не первый спринт или даже не первый проект, то проще всего сравнивать с предыдущими историями или проектами. Кстати, зачастую вспоминается, что не такой уж страшной оказалась воооон та «большая» история в позапрошлом спринте.

Итак, надеюсь, что уже смог вас убедить – “сравнивать” хорошо, а “оценивать” плохо. Поэтому когда мы говорим об Agile-оценках, мы говорим скорее об интегральном понятии “сложности” и делаем это сравнением. Еще пару слов про то, какие цифры присваивать. Можно использовать числа подряд: 1,2,3,4. Но, как показывается народная мудрость, начинаются мелочные споры, о том, что это 2 или 3, и опять в ход идут “метрические линейки” типа рабочих часов, минут, дней. Поэтому уже давно многие Agile-практики рекомендуют пользоваться последовательностью Фибоначчи (0,1,2,3,5,8,13…). Ее выгода в том, что она начинает резко расти вверх. Ведь если требование действительно сложное, то детали уже не так важны – слона лучше всего есть по частям, главное понять, что это слон 😉

Ну и самое интересное, причем здесь покер? Это удобный инструмент, чтобы присвоить оценки используя опыт всей команды. Правила Planning Poker просты:

• Каждому участнику дается набор карт с цифрами
• Заказчик/Владелец Продукта читает историю, и команда кратко уточняет ее
• Каждый участник выбирает свою оценку и кладет карту рубашкой вверх
• Все одновременно открывают карты
• Если есть разница (большая), то обсуждается «Почему?»
• Делаем еще один раунд оценки, пока все не сойдутся на одном числе

Вот таким простым способом, вся команда может быстро и без лишних усилий оценить работы, которые  будет делать, возможно, даже не в ближайших спринтах и даже не в ближайшем релизе. Владельцу Продукта важно знать “цену”, и он ее получит. О том, что он будет с ней делать, я расскажу отдельно.

Сразу хочу ответить на вопрос, который мне задают почти на каждом тренинге. В покере должны участвовать те люди, которые будут делать эти требования. И если для нового проекта собирается новая команда, то у них будут свои определения сложности. Опять же, если Владелец Продукта не принимает участия в работе по реализации требований, то он не может играть – он скорее “крупье”.

P.S.

Хочу сказать, что Майк Кон, автор книги “Agile Estimation and Planning”, является владельцем торговой марки Planning Poker ® и, соответственно, той колоды, которую многие из нас привыкли использовать. Думаю, что сделав это, он оказал большую услугу всему Agile-сообществу.  Он бесплатно раздает права на использование торговой марки и печать собственных колод. Единственное, что нужно сделать –  только написать ему и подписать формальный договор. А ведь какой-нибудь другой “делец” мог бы на этом деньги зарабатывать :-).