Зачем мы играем в покер на работе

Команда, с которой я работаю как 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-сообществу.  Он бесплатно раздает права на использование торговой марки и печать собственных колод. Единственное, что нужно сделать —  только написать ему и подписать формальный договор. А ведь какой-нибудь другой “делец” мог бы на этом деньги зарабатывать :-).

Вы можете оставить комментарий, или отправить trackback с Вашего собственного сайта.
  • http://tim.com.ua/ Тимофей Евграшин

    Уже не однократно слышал от команд, что они просто используют размеры футболок для оценки размера каждого элемента бэклога. Т.е. S,M,L,X,XL,XXL

    Этого тоже более чем достаточно, если у вас нет критической необходимости в числовых оценках. Если команда работает «в потоке», то тут важнее оценить сможем ли мы проглотить требование за спринт или нет. Особенно если команда пришла к «Канбану».

  • http://tim.com.ua/ Тимофей Евграшин

    Уже не однократно слышал от команд, что они просто используют размеры футболок для оценки размера каждого элемента бэклога. Т.е. S,M,L,X,XL,XXL

    Этого тоже более чем достаточно, если у вас нет критической необходимости в числовых оценках. Если команда работает «в потоке», то тут важнее оценить сможем ли мы проглотить требование за спринт или нет. Особенно если команда пришла к «Канбану».

  • Pingback: Еще один способ быстрой оценки Бэклога или как оценивать играючи | The Improved Methods