Коэффициент концентрации — это фактор, который показывает, сколько времени в идеале должно было занять выполнение задачи и сколько получилось в итоге. Можно сказать, что это «фокус» команды на проекте.
Оценка задач в Story Points
Почти все, кто занимается разработкой программного обеспечения, знают, что такое Story Points (SP). Однако иногда мне приходится объяснять коллегам из других отделов или новичкам в команде, которые никогда не работали с таким подходом, почему мы используем SP и почему это практично для команды и эффективно для компании.
Цель этой заметки — объяснить, что такое SP, как использовать его для оценки задач и почему этот метод так широко используется.
Проблема
Оценка времени, необходимого для выполнения задачи, является очень простой, но очень рискованной задачей для команд разработчиков.
Неправильные оценки являются одной из первых причин срыва графика или даже проекта. Проблема в том, что компании рассматривают сметы как обязательства. Разработчики рассматривают оценки как предположения.
Для иллюстрации приведу пример вымышленного диалога из книги Роберта Мартина «Идеальный программист».
Майк (директор): Какова вероятность того, что вы сможете сделать это за три дня?
Питер (программист): Думаю, я смогу это сделать.
Вы можете дать мне номер?
Питер: Пятьдесят или шестьдесят процентов.
Майк: Значит, есть вероятность, что это займет у вас четыре дня?
Питер: Да. Возможно, потребуется даже пять или шесть, хотя я сомневаюсь в этом.
Майк: В какой степени вы сомневаетесь в этом?
Питер: О, нет. Я на девяносто пять процентов уверен, что работа будет выполнена менее чем за шесть дней.
Значит, их может быть семь?
Питер: Ну, если все пойдет не так…. Черт возьми, если ВСЕ пойдет не так, то может пройти десять или даже одиннадцать дней. Но шансы на то, что это произойдет, очень малы, не так ли?
Я думаю, что приведенный выше диалог звучит довольно знакомо для любого разработчика или менеджера проекта.
К сожалению, проблемы с оценками на этом не заканчиваются. Есть и другие подводные камни, которые следует учитывать:
Корреляция оценки и оценивающего
Выставленная оценка справедлива только в том случае, если автор оценки реализует проект. Наконец, время, затраченное на выполнение задачи опытным разработчиком и стажером, естественно, будет разным.
Идеальная оценка в неидеальном мире
Срочные встречи, рабочие электронные письма, мессенджеры и перегруженный менеджер задач вносят путаницу в и без того сложный процесс разработки, поэтому идеальные часы, представляемые в процессе оценки, малополезны для менеджера проекта, пытающегося создать диаграмму Ганта, которая быстро переполняется.
Далее мы рассмотрим подход SP к оценке задач и то, как он справляется со всеми сложностями, описанными выше.
Альтернативные решения
Конечно, подход
Исходя из этих трех оценок, ожидаемая продолжительность работ описывается следующей формулой:
А стандартное отклонение, которое фактически является мерой неопределенности проблемы, рассчитывается по следующей формуле:
Таким образом, проблема, обсуждаемая Питером и Майком, может быть оценена:
Как мы видим, этот метод заставляет оценщика рассматривать не только положительные, но и отрицательные сценарии, и даже использует элемент статистики. К сожалению, он не отвечает на все поставленные вопросы, а также сильно затрудняет процесс оценки.
Одним из наиболее важных аспектов методологии Scrum являются так называемые Story Points, которые очень тесно интегрированы в Scrum в сочетании с Planning Poker.
Самая распространенная проблема Scrum-команд заключается в том, что они не знают, как правильно оценить сложность и время, необходимое для выполнения задач. Из статьи Burndown Chart вы можете узнать, как создать график выгорания, если вы неправильно оцениваете работу, которую должна выполнить команда.
Для многих действительно трудно найти правильную шкалу оценок, и здесь необходим опыт или разумный подход. Чтобы максимально эффективно и быстро применить Story Points в жизни команды, необходимо взять задачи из предыдущих выполненных проектов и полностью их проанализировать. Этот анализ должен включать названия выполненных задач и их продолжительность. Следующий шаг прост: нужно отсортировать эти задачи в порядке возрастания, отсортированные по времени. Разделите их на группы с одинаковыми или похожими показателями и оцените их с помощью колоды Scrum Poker.
Если Scrum-команда способна оценивать свою работу, вести график скорости, следить за «диаграммой выгорания задач», то рано или поздно (или с самого начала) абсолютно все результаты будут записаны в Story Points.
Из графика скорости видно, например, что динамика команды растет в плане среднего burn-in за спринт, и среднее значение за последние две итерации составило 23-30 Story Points (в зависимости от выбранной системы подсчета). Из этой статистики владелец продукта может понять, на какие задачи ему/ей нужно потратить имеющиеся баллы, чтобы заполнить бэклог.
Дизайн покера
Story Points
Самым важным и интересным методом определения количества Story Points на задачу является планирование покера. Он гибкий и игривый и дает вам хорошее представление о том, что вы можете включить в бэклог продукта.
Скорость
Оценка точек повествования, а точнее, количества точек повествования, производится глобально с помощью Velocity. Скорость, которую развивает команда, используя формулу, рассчитывается по этой диаграмме.
Что же происходит на самом деле при Story Points?
Команда разработчиков
Команда разработчиков решает, сколько должностей должно быть создано в команде разработчиков.
Владелец продукта в блоге продукта сортирует задачи по важности и назначает релизы. Чтобы создать хороший бэклог продукта, необходимо правильно распределить задачи и релизы, что зависит от понимания сюжетных точек.
Скрам-спринт
Во время спринта все заявленные точки истории сгорают. На них рассчитываются различные диаграммы, которые можно использовать, например, в диаграмме выгорания. Успех спринта зависит от правильной оценки точек истории.
Система управления проектами Scrum
Одна из ошибок, которую вы можете допустить при оценке задач, — оценивать в одиночку и не спрашивать мнения членов команды. Может быть, у них есть свое мнение на этот счет?
Люди — это самый важный ресурс для оценки. Они могут видеть то, что вы не видите.
Просто выкрикивать оценки не очень эффективно, к тому же в команде могут возникнуть разногласия, и сессия может затянуться. Одним из вариантов групповой оценки является Planning Poker.
Вы можете провести оценку вручную, если подготовили специальные карточки.
Для производственного отдела существует два документа, в которых должны быть представлены задачи.
Задачи вводятся руководителями проектов, а время и рабочая нагрузка рассчитываются для каждого специалиста.
Документ № 1 — это еженедельная рабочая нагрузка. В этом документе руководитель проекта указывает, над какими проектами и сколько часов в неделю будет работать разработчик. В документе видно, насколько занят разработчик:
— Сильно загружен.
— Нормальная нагрузка.
Загруженность разработчика должна составлять до 30 часов в неделю.
Документ №2 — План на день. В этом документе руководитель проекта указывает название проекта и номер задания для разработчика.
Оценка в команде
Чем отличается оценка в команде от индивидуальной оценки?
Задачи в проекте не должны выполняться несколькими разработчиками одновременно.
Разработчики должны максимально следовать плану и сообщать менеджеру проекта, если в заданиях есть ошибки.
Как проводить оценку командой?
Standup — это ежедневная короткая сессия планирования в Scrum. Члены команды собираются в одно и то же время и в одном и том же месте и отвечают на три вопроса:
Scrum — это гибкая методология разработки программного обеспечения, которая помогает командам работать вместе.
Разработчикам
Ретроспектива — это групповой обзор последней фазы работы (спринта).
Цель ретроспективы — улучшить процесс разработки проекта и понять, что пошло не так.
Ретроспектива должна проходить в отдельной комнате, чтобы никто не мешал.
Положите доску, блокнот и тетрадь горизонтально.
Поговорите о том, что прошло хорошо, что прошло плохо, что помешало более быстрой работе, какие проблемы возникли и с чем пришлось столкнуться.
Менеджерам
- Поддерживать нормальный уровень коммуникации в команде
- Как можно быстрее узнавать о проблемах в проекте
- Что было сделано вчера?
- Что будет сделано сегодня?
- Какие есть проблемы?
Ретроспектива. WTF?
Формат ретроспективы:
