Покер планирования

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Разработка программного обеспечения
Процесс разработки ПО
Шаги процесса

Анализ • Проектирование • Программирование • Документирование • Тестирование

Модели

Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model

Методологии

Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD

Сопутствующие дисциплины

Конфигурационное управление • Управление проектами • Управление требованиями

Покер планирования (англ. Planning Poker, а также англ. Scrum poker) — техника оценки, основанная на достижении договорённости, главным образом используемая для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения. Это разновидность метода Wideband Delphi.

Она обычно используется в гибкой методологии разработки, в частности, в методологии экстремального программирования.

Метод впервые был описан Джеймсом Греннингом (James Grenning)[1] в 2002 году и позднее популяризован Майком Коном (Mike Cohn) в книге «Agile Estimating and Planning»[2].

Описание процесса оценки[править | править вики-текст]

Подготовка[править | править вики-текст]

Для проведения покера планирования необходимо подготовить список обсуждаемых функций и несколько колод пронумерованных карт. Список функций либо пользовательские истории описывают разрабатываемое программное обеспечение. Карты в колодах должны быть пронумерованы. Обычно колода содержит карты, содержащие числа Фибоначчи, включая ноль: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; другие разновидности колод могут использовать аналогичные последовательности.

Колода карт для покера планирования

Аргумент в пользу использования последовательности Фибоначчи — отражение типичной неопределённости при обсуждении самых важных и больших пунктов.

Одна из имеющихся в продаже колод содержит следующую последовательность: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 и иногда знак вопроса («?»), означающий неуверенность, и чашку кофе, означающую требование перерыва. Некоторыми организациями используются обычные игровые карты, включающие туз, 2, 3, 5, 8 и короля. Король буквально означает: «Данный пункт слишком большой или его слишком сложно оценить». Выбрасывание короля завершает обсуждение пункта в текущем круге (англ. sprint).

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

Процедура проведения[править | править вики-текст]

Каждому участнику обсуждения выдаётся по одной колоде карт. Все колоды идентичны друг другу.

Обсуждение проводится следующим образом.

  • Ведущий (англ. Moderator), не участвующий в обсуждении, ведёт собрание.
  • Менеджер проекта (англ. Product Manager) представляет краткие обзоры каждого из пунктов. Команда может задавать вопросы и вести обсуждение предложений и рисков. Итог обсуждения записывается менеджером проекта.
  • Участники выбирают по одной карте и кладут их рубашкой вверх, показывая таким образом, что выбор сделан. Числовые достоинства карт могут использоваться по-разному: они могут означать количество дней, наиболее подходящие дни или относительные единицы сложности (англ. story points). Во время обсуждения достоинствам не должны приписываться новые значения в зависимости от размера функций с целью избегания эффекта привязки.
  • Каждый участник называет свою карту и переворачивает её.
  • Участникам с высокими и низкими оценками даётся возможность высказаться и обосновать свою оценку.
  • Процесс обсуждения продолжается до тех пор, пока не будет достигнут консенсус. Голос участника, который, скорее всего, будет владеть разработкой, имеет больший вес в «голосовании на основе консенсуса».
  • Таймер используется для обеспечения структурированности обсуждения; ведущий или менеджер проекта может в любое время перезапустить таймер, по истечении времени все обсуждения должны быть прекращены, затем начинается новый круг покера.

Выступления участников повторяются вновь и вновь. Карты пронумерованы так, что чем больше число, тем больше неопределённость. Так, если разработчик желает выбрать 6, но он не до конца уверен, он выберет 5, либо может предусмотрительно выбрать 8.

Достоинства метода[править | править вики-текст]

Покер планирования — это средство оценки проектов по разработке программного обеспечения. Эта техника минимизирует эффект привязки путём опроса каждого из участников команды таким образом, что никто не знает чужого решения до одновременного оглашения выбора каждого из участников.

Исследование[3] K. Молёккен-Эствольда (норв. K. Moløkken-Østvold) и Н. Хаугена (норв. N.C. Haugen) показало, что оценки, полученные с помощью покера планирования, были менее оптимистичными и более точными, чем оценки, полученные с помощью простого сложения отдельных оценок аналогичных задач.

Избегание эффекта привязки[править | править вики-текст]

Эффект привязки возникает, когда команда открыто обсуждает оценки. Команда обычно имеет в своём составе как сдержанных, так и импульсивных участников, могут быть участники, у которых есть определённые планы; разработчики, вероятно, захотят как можно больше времени заниматься работой над проектом, а владелец продукта или заказчик, вероятно, захочет, чтобы работа была закончена как можно скорее.

Оценка становится подверженной эффекту привязки, когда владелец продукта говорит нечто подобное: «Я думаю, это несложная работа, вряд ли это займёт больше пары недель». Либо когда разработчик говорит: «Думаю, нам нужно лучше стараться; решение проблем с бэк-эндом, которые у нас были, могло затянуться на месяцы». Если начинающий обсуждение говорит: «Думаю, это займёт 50 дней», — он сразу устанавливает рамки мышления остальных участников; возникает эффект привязки, то есть число 50 подсознательно будет отправной точкой для всех участников.

Те, кто хотел назвать число 100, захотят уменьшить свою оценку, а те, кто задумал число 10, захотят увеличить её. Это становится серьёзной проблемой, если число 50 произносится влиятельным участником в то время, когда остальная команда преимущественно останавливает свой выбор на бо́льших или меньших значениях. Из-за эффекта привязки у остальных участников они могут — сознательно или нет — не проявить своего первоначального единомыслия; на самом деле, они могут так и не понять, что они думали об одном и том же. Это может быть опасным и приводить к оценкам, на которые повлияли планы или личные мнения людей, не сфокусированных на качественном выполнении задачи.

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

Если у влиятельного участника есть хорошие аргументы для спора, все остальные будут видеть смысл и прислушиваться, но, по крайней мере, остальные участники не будут подвержены эффекту привязки; вместо этого они должны будут исходить только из разумных соображений.

Средства для распределённых команд[править | править вики-текст]

Когда команда географически рассредоточена, можно использовать некоторые инструменты, чтобы получить преимущества метода покера планирования.

Примечания[править | править вики-текст]

  1. James Grenning. Planning Poker. Renaissance Software Consulting (April 2002). Проверено 31 августа 2008. Архивировано из первоисточника 20 августа 2012.
  2. Mike Cohn. Agile Estimating and Planning. Mountain Goat Software (November 2005). Проверено 1 февраля 2008. Архивировано из первоисточника 20 августа 2012.
  3. Moløkken-Østvold, K. Haugen, N.C. [http://ieeexplore.ieee.org/xpl/freeabs_all.jsp? arnumber=4159687 Combining Estimates with Planning Poker—An Empirical Study]. IEEE (13 April 2007). Проверено 1 февраля 2008.
  • Mike Cohn Agile Estimating and Planning. — 1 edition. — Prentice Hall PTR, 2005. — ISBN 978-0131479418

Ссылки[править | править вики-текст]