Наша команда в одном из последних проектов столкнулась со сложностями по планированию временных затрат. В числе прочего попробовали методику покера планирования, об этом опыте и хочу рассказать.
Оценить сложность задачи и утвердить сроки ее исполнения бывает непросто даже опытному проджект-менеджеру, особенно учитывая скорость развития технологий коммуникаций и принятия решений. Провести дополнительные обсуждения легко, если команда насчитывает несколько человек, собранных в одном месте. Если же участников дискуссии уже больше и/или часть команды работает удаленно, то оценка временных затрат может сильно затянуться.
Для оценки решения задачи можно использовать:
- Метод экспертной оценки.
- Метод PERT (Program Evaluation and Review Technique) – или по-другому метод «трех точек».
- Метод аналогии.
- Метод COCOMO (Constructive Cost Model) – или параметрическая оценка.
Но цель этой статьи не сравнительный анализ, а знакомство с одной конкретной методикой – покер планирования (англ. – Planning Poker).
В чем суть метода
Принцип впервые описал Джеймс Греннинг в 2002 году и позднее популяризировал Майк Коном в книге «Agile Estimating and Planning». Он используется в методологии Scrum и позволяет руководителю проектов оценить сложность задач и определить, сколько времени потребуется на их выполнение.
Суть метода заключается в том, что он реализуется в формате игры и участие принимает вся команда. Важно понимать, что ключевая цель оценки сложности не состоит в том, чтобы точно сказать, когда задача будет готова, а убедиться, что все участники одинаково понимают задачу. Инструментом может быть как простая колода карт, так и специальная. Также существуют различные приложения и онлайн-сервисы, которые подойдут распределенным/удаленным командам.
Как проходит «игра»
В начале игры каждому участнику команды раздается колода карт – это и есть шкала, по которой будут оцениваться задачи. В качестве параметра оценки может быть выбрана сложность задачи либо время ее исполнение.
Далее ведущий озвучивает задачу и каждый сотрудник выбирает наиболее подходящую по его мнению карту. После того как все ставки сделаны – ведущий их принимает и проводит анализ. Если все оценили задачу примерно одинаково – высчитывается среднее значение и можно переходить к следующей.
В случае, если есть значительный разрыв между оценками игроков – запускается обсуждение. Важный момент заключается в том, что обсуждение должно происходить только после того, как все дали свою оценку. Это позволит избежать эффекта привязки к чьему-либо мнению.
Если один член команды дает оценку в один день, а другой в три дня, то наверняка у них кардинально отличается подход к решению – им необходимо будет объяснить свое видение. Именно в этом и заключается идея метода – рассмотреть задачу со всех сторон и прийти к общему знаменателю, к единому мнению относительно каждой задачи.
Различия в оценках возникают по ряду причин:
- опыт сотрудников;
- квалифицированность и компетентность в определенных вопросах;
- владение информацией, которой нет у другого.
Если озвученный срок отличается более чем на рабочий день, то задача должна выполняться в паре, притом тот, кто оценил в меньшую сторону, руководит тем, кто оценил в большую.
Приятное следствие в том, что покер планирования способствует коммуникации в команде и повышает уровень взаимопонимания между участниками. Каждый имеет возможность высказать свое мнение и обосновать свою оценку, что помогает улучшить качество командной работы.
В результате – более эффективное планирование и достижение поставленных целей.
Полезные советы, как улучшить процесс планирования
- Нужно стремиться, чтобы сложность задачи не превышала один день. Планирование лучше всего проводить так, чтобы у команды всегда был запас задач на один-два дня, но не больше. Так все участники будут хорошо помнить все детали обсуждения каждой конкретной задачи.
- Если задача провисела в очереди на исполнение более четырех дней, ее нужно снова вынести на обсуждение, чтобы команда вспомнила, что и как нужно сделать по ней.
- Если задача выполняется на два дня дольше, чем планировалось, ее нужно вынести заново на планирование и обсудить с командой и заказчиком все сложности и проблемы с которыми столкнулись в ходе выполнения, чтобы в следующий раз при оценке учесть их.
Как внедрить метод: инструкция
1. Подготовьтесь
Проведите информационную встречу для объяснения основных принципов и целей этой практики. Подготовьте колоду карт, которая будет использоваться для оценки сложности задач или выберите онлайн-сервис.
2. Проведите первую встречу
Определите время для проведения покера планирования. Далее это может быть регулярная встреча, например, раз в неделю. Выберите небольшую задачу, которую команда может оценить в качестве пробного варианта. Раздайте каждому участнику колоду карт.
Далее каждый участник выбирает карту с оценкой, которая по его мнению соответствует сложности задачи. Убедитесь, что все держат карты скрытыми до определения всех оценок.
Если оценки различаются, проведите обсуждение, чтобы понять причины расхождений и прийти к единому мнению. Это может быть объяснение задачи, уточнение требований или обсуждение возможных сложностей.
Повторите процесс оценки и обсуждения для всех задач, которые требуют планирования на текущей или ближайшей итерации.
3. Систематический обзор
Проведите обзор результатов первой встречи, чтобы оценить эффективность процесса и выявить возможные улучшения. Убедитесь, что участники понимают, какие задачи следует оценивать, и что оценки соответствуют реальной сложности задач.
4. Регулярные встречи
Установите регулярное расписание по покеру планирования, чтобы включить эту практику в еженедельные или двухнедельные циклы работы команды. Поощряйте обратную связь от участников команды и вносите изменения в процесс, чтобы сделать его более эффективным и удобным.
5. Мониторинг и адаптация
Регулярно отслеживайте прогресс выполнения задач и учитывайте результаты оценок при планировании будущих итераций. Не останавливайтесь на достигнутом. Продолжайте собирать обратную связь и адаптировать процесс в соответствии с изменениями в команде или условиями проекта.
С пошаговым подходом к внедрению покера планирования команда сможет успешно интегрировать эту практику в свою повседневную работу и достичь большей прозрачности и эффективности в планировании и управлении задачами.
Три сервиса, которые помогут применить методику
- Planningpoker.com
- Planningpoker.ru
- PlanITpoker.com
Заключение
Преимущества покера планирования очевидны. Однако, чтобы достичь максимальной пользы от этой методики, необходимо обеспечить эффективное взаимодействие и коммуникацию в команде. Важно поддерживать постоянное обучение и развитие участников, чтобы улучшать процесс планирования и совершенствовать результаты.
Читайте также:
Кстати зря смеетесь. Есть постановщик задачи - бог среди разработчиков. На уровне нормочасов он действительно может оцифровать в часах, сколько может занимать написать код и скомпилировать под MVP практически для любого ТЗ. Потом ведь тайминг проекта это не время разработки. Отладка, тестирование + стандартный % запаса на "сложности" ))
Я ничуть не смеюсь, не обращайте внимания на некоторые вольности моего текста. Вы справедливо пишете о типичной практике. Да, прикинул нормочасы, добавил запас... И потом начинается чехарда работы по выходным и вечерами. ))) А тот заболел, а этот уволился, а там заказчик уточнил ТЗ, а меня не спросили, потому что я был в отпуске, а новый программист оказался отнюдь не сеньором...
Разве не так? Завтра закачик просит показать? "Бросаем всё, компилируем хотя бы работающую версию, тестирование пропускаем, отладку перенесём на опытную эксплуатацию".
Именно поэтому и и пишу о перераспределении запасов времени. По своему опыту и по расчёту нормочасов наметил примерные сроки, добавил на "усушку, утруску", ефрейторский зазор, а потом лови сэкономленные часы у разрабочиков, тестировщиков, всякого рода бэков и фронтов - никому не болтай об этом, а просто учитывай. И чуть-чуть дави на свою команду, ласково так, но постоянно. :)))))
Вы на правильном пути. Это работает.
Напоминает некоторые идеи Critical Chain Project Management (CCPM) Голдратта. В частности, активное формирование и использование резервов (буферов) ресурсов менеджером проекта по мере необходимости и для расшивки уже известных узких мест. Ваши примеры авралов и причин их возникновения очень к месту.
Но нужно разделять базовую версию плана, использованную, например, при подготовке контракта, и текущие версии плана, меняющиеся по мере продвижения к цели.
Понятно, что ни о каких задачах длиной в один день и менее речь не идет. Это вырожденный случай - если представить, сколько времени будет бессмысленно потрачено на упражнения для коллективного обсуждения, например, 1000 задач, выполняемых в соответствии с целями проекта и планом.
Scrum, кстати, в этом не виноват. Его базовая концепция - инкрементальное исполнение маленькими порциями за счет минимизации продолжительности задач и постоянного получение обратной связи по уже доступным результатам. Естественно, там, где такое возможно. И Scrum не настаивает на однодневной продолжительности. Спринт может быть и месяц.
Почему нет, любой каприз. Но попробуйте так построить дом или мост. Или разработать и внедрить действительно сложную систему.
Вспомним, что в этой жизни за план проекта отвечает менеджер проекта, а не коллектив. И для повышения точности оценок работ используются любые инструменты, которые ему доступны. Как и для подготовки плана. Жаль, что волшебной палочки не сушествует - только практика.
У программистов? Может я чего не понимаю, но планировать можно только то, о чём есть представление, какие-то данные. Даже опыт нужно переводить в данные по трудоёмкости, предполагаемой продолжительности отдельных работ. Нужен ещё состав работ и последовательность. Вот Корчанов точно вычленил суть подобного рода "методик". А я бы добавил ещё короче - танцы с бубнами.
Думаю, что тут нет противоречий. Никак иначе дать оценку длительности работ нельзя. Есть мнение исполнителя, которому предстоит эту работу выполнять, обычно есть и другие источники.
В случае совершенно новой задачи, когда у исполнителей нет соответствующего опыта и/или квалификации, работа менеджера проекта становится сложнее, а точность оценок падает. Но есть методы борьбы и с такими проблемами. Уверен, что Вы их знаете.
Евгений, Вы как всегда заноза в моей ... За это и уважаю Ваше мнение. По моему мнению, даже если совершенно новая задача мы планируем то, что знаем. Это так просто. Невозможно планировать то, что не знаешь. Возьмите любую задачу и мы уже можем планировать этапы решения, выбирать методы и т.д. Появятся детали, тогда корректируем или расширяем планы.
Работа менеджера сложнее становится не от сложности задачи, сложная или простая задача, у него работы достаточно, а от необходимости выдавать результат под давлением или вопреки. Точность оценок всегда зависит не от сложности, а от недостатка информации. Даже сложные проекты при условии детальной проработки позволяют составлять реальные планы.
Если я правильно понял вопрос, то отвечу так.
Спланировать работу программиста (программистом) не самая сложная задача. Как правило, во-первых, задача делится на некоторые более мелкие шаги. Во-вторых, программисту известен стек, в котором он работает, наработаны приёмы использования АПИ, функций, библиотек, имеется репозитарий и т.д. Хотя есть и шутка: "Если программист называет сроки, увеличивай в два раза и повышай порядок" ))))
Конечно, если программист работал в джаве скрипт, а ему ставят задачу на рнр, в котором у него нет опыта, то это следует учитывать.
И Евгений хорошо это понимает:
В совершенно новой задаче будет разбираться архитектор, менеджер проекта, опираясь на точку зрения программиста.
Увы, жизнь намного богаче вариантами.
Каждый проект уникален. Новые задачи появляются каждый день. И планируем мы то, что нужно (или мы думаем, что нужно) для получения результата. Что-то мы знаем, с чем-то раньше не сталкивались. Это нормально. Сделаем проект - узнаем, а дальше снова будет что-то новое.
По Вашему мнению, кто должен делать то, что нужно в проекте, но лично для нас эта тема новая?
Это и есть планирование. Сначала предварительные и грубые оценки снизу или сверху, затем они уточняются.
Как делаются оценки - известно, варианты всегда есть. Но в проекте важен только результат. И сложные проекты потому и называются сложными, что степень неопределённости там обычно намного выше. Менеджер проекта не зря получает свою зарплату.
И все вместе они могут смотреть на аналогичные проекты, которые делали другие. И уточнять все недостающие для начала работы детали всюду, где только они есть. Например, в собственной песочнице.
Почему "увы"? Наоборот, хорошо.
Как для руководителя проектов наверно тема не новая.