Вход для клиентов
Вход для клиентов
Регистрация
Нас рекомендуют
А.А. Третьяков
АО "Тройка-Д Банк"
Сидоров Т.В.
ген. директор ООО "ДСС Медиа Групп"
С.И. Воробьёв
АО "ВОКБАНК"
Талаш А.А.
Генеральный директор группы компаний РосКо, к.э.н.
Егоров Виталий
директор ООО "ПАЛИТ-РА" it-palitra.ru
Ахметов И.Р.
директор akhmadi-invest.com
Подтыкан Я.А.
директор GM-Lab., проект yavshoke.net
Комарцова Мария
редактор ИА "Бел.Ру"
Бузенкова Мария
директор Domnatamani.ru
Дроздов Вадим
директор importkama.ru
Сергей Вачиков
ООО еКузбассРу
Смирнов Константин, директор
ООО «ФАРМ-ЭКСПРЕСС1»
Занис А.Л.
ген. директор ООО "Веб-Сторс"
Наталия Захаренко
ген. директор ООО "МЦС"
Подробнее
Наши клиенты
Подробнее

Применение гибких методов разработки ПО: Покер планирования

Опыт многих проектов говорил разработчикам о том, что большинство заказчиков проекта часто модифицируют требования и условия его поставки на рынок. Очевидно, что сразу в начале работ выработать нужный план необходимого функционала и постоянно его придерживаться в разрабатываемой системе сложно, а чаще всего невозможно. И как быть в случае, если готовый проект не удовлетворит желаниям заказчика? Следовательно, использовать негибкую модель будет просто неэффективно. Но как, в отличие от первой модели, узнать, сколько времени займет разработка? Существует несколько методов, применяемых на практике: Метод Дельфи, PERT, и Покер планирование. На нём и остановимся.

Проведение Покер планирования. Чаще всего этот метод используется в большом стеке методологий scrum при проведении спринта. Спринт - это определенный промежуток времени (чаще всего 1-3 недели), в течение которого команде разработки необходимо реализовать определенный функционал проекта. Как команда узнать, какое количество задач необходимо взять на спринт и как оценить время их разработки? Использовать методологию Покер планирования. Его суть заключается в том, чтобы командными усилиями прийти к осознанному пониманию того, сколько времени займет та или иная задача.

Каждому участнику выдается колода карт, обычно содержащая в себе такие элементы:

- цифры 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100

- символы "?" и символ кружки кофе

Цифры на картах могут обозначать часы, дни, или “Story Point” - единицы оценки сложности задач. При оценке последнего необходимо выбрать самую простую выполнимую задачу и посчитать ее за эталон, по которому следует оценивать все последующие.

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

Если оценки одинаковы, значит, задача понятна, и с ней согласна команда. Если же нет, то либо задача оказалась не ясна, либо какие-то особенности задачи известны одному из членов команды. В таком случае тот, чья оценка расходится с существующей, объясняет, как он понимает данную задачу, и почему он поставил именно её. Затем участники команды проводят новый кон. Когда оценки совпадут (при этом не обязательно, чтобы было строгое совпадение, разброс в одну-две карты будет некритичным), команда принимает эту задачу на реализацию в текущий спринт. Иногда для ускорения процесса ведущий может использовать таймер; кроме того, это помогает структурировать рассуждение. По истечении таймера обсуждения прекращаются, и начинается новый кон покера.

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

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

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

Если владелец продукта говорит что-то подобное: "Я не думаю, что это сложная работа, возможно, займет недели две", или разработчик говорит "Считаю, на это уйдет 20 дней" - они сразу устанавливают и ограничивают рамки мышления остальных участников. При этом возникает эффект привязки - подсознательно "две недели" и "20 дней" станут отправными точками для мыслей других участников. Те люди, которые хотели назвать оценки ниже или выше уже сказанной, будут подсознательно стремиться к уже названному числу. При этом не гарантируется, что они покажут свое начальное единомыслие; могут так и не осознать, что размышляли об одном и том же. Это не всегда благоприятно, и может привести к оценкам, основанных на мнениях людей, которые не заинтересованы в предложении качественного решения задачи.

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

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

Пример использования. Для проекта "Книжный магазин" при планировании первого спринта была поставлена цель создания базовой системы заказа книг. Были выбраны следующие пользовательские истории:

Как покупатель, я хочу искать книги по разным параметрам, чтобы быстрее перейти к оформлению заказа.

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

В качестве оценки сложности было решено использовать часы работы. После непродолжительного обсуждения первой пользовательской истории было принято считать ее "точкой отсчета" для всех остальных историй. В первом коне получились такие цифры: 2, 2, 3, 5. Один из участников с цифрой 2 и участник с 5 объяснили, почему они поставили именно такие цифры; после этого был проведен второй кон. Итогами второго кона оказались: 3,2,3,3. Задача была понятна всем членам команды и в дальнейшем взята одним из них на разработку.

Комментарии
Отправить
Свяжитесь с нами

Чтобы получить консультацию наших экспертов, свяжитесь с нами удобным для вас способом, заполнив форм справа, позвонив по телефону:

(495) 999-02-56

или отправив нам письмо на адрес:

kopiraiting.com@gmail.com

Не забудьте рассказать о вашей компании, цели проекта, имеющихся наработках и оставить свои контактные данные.

Отправить