Что такое Story Points?

Story Point  условная величина, позволяющая оценивать задачи из бэклога. Оценка одних задач относительно других.

Бэклог — это упорядоченный набор задач по проекту.

Как использовать?

Важно понимать:

Справедливо оценить задачу может только тот, кто будет ее выполнять.

1-й вариант: 

Выбирается небольшая задача из бэклога, которую команда точно может оценить. Задача берется за условную единицу (Story Point) и остальные задачи оцениваются в этой задаче.

Story Point служит для предварительной оценки проекта.

Пример:

Берем небольшую задачу, например, форма обратной связи.

Мы знаем точное время на эту задачу — 2 часа. Это один Story Point.

Далее все задачи оцениваем в Story Points. 1 SP = 2 часа.

2-й вариант:

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

Факторы, влияющие на оценку усилий:

• Объем требуемой работы;
• Техническую сложность задачи;
• Возможные риски и неопределенность в требованиях.

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

Относительность оценки

Задачи оцениваются относительно друг друга, таким образом возникает универсальная шкала оценки, не зависящая от опыта оценивающего. Даже если у задачи сменится ответственный — ее оценка остается неизменной, достаточно оценивать новые задачи относительно этой шкалы.

Замена часов на абстрактные баллы

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

Оценка в команде

Чем отличается оценка в команде от индивидуальной оценки?

Одна из ошибок, которые можно допустить при оценке задач — оценить самостоятельно и не спросить мнения членов команды. Может быть, у них есть свое мнение по этому поводу?

Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите вы.

Как проводить оценку командой? 

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

Можете провести оценку вручную, если подготовили специальные карточки.

Разработчикам

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

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

Документ №1 — недельный рывок, в этом документе менеджер проекта указывает, какими проектами и сколько часов будет заниматься разработчик на неделе. В документе можно посмотреть на сколько загружен разработчик:

   — сильно загружен.      

   — нормально загружен.

Загрузка разработчика в неделю должна доходить до 30 часов.

Документ №2 — план на день. В этом документе менеджер проекта указывает, наименование проекта и номер задачи, для разработчика.

Работу по одному проекту не должны вестись сразу несколькими разработчиками.

Пример заполнения:

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

Менеджерам

Нужно две вещи:

• Поддерживать нормальный уровень коммуникации в команде
• Как можно быстрее узнавать о проблемах в проекте

Стендап — ежедневная короткая планерка в Scrum. Члены команды собираются в одно и то же время, в одном и том же месте и отвечают на три вопроса:

• Что было сделано вчера?
• Что будет сделано сегодня?
• Какие есть проблемы?

Scrum — это  гибкая методология разработки ПО, помогающая командам вести совместную работу.

Ретроспектива. WTF?

Ретроспектива — это командный пересмотр последнего этапа работы (спринта).

Цель ретроспективы — улучшить процесс разработки проекта, понять, что пошло не так.

Формат ретроспективы:

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

Размещаем доску, блокнот, тетрадь горизонтально. 

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

Продолжительность от 30 минут до часа.

В “+” записываем, что было хорошо, какие позитивные моменты может сказать команда по прошедшему спринту.

В “-” — что было плохо.

Желательно заранее попросить команду обдумать, какие были “+” и “-”.

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

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

Диаграмма сгорания

Для чего нужна?

Диаграмма сгорания показывает, сколько задач осталось до завершения спринта на временной шкале (и сколько уже сделано). По вертикали — количество задач, по горизонтали — время. Цель команды: «сжечь» все задачи до того, как приблизится дедлайн.

Velocity = Focus Factor х Оценка новых задач.

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

Focus Factor — коэффициент, который показывает, сколько задача должна была занять в идеале, а сколько вышло в итоге. Можно сказать, что это «концентрация» команды над проектом.

Диаграмма производительности

Для чего нужна? 

Предназначена для выяснения, насколько выполненное количество задач в спринте соотносится с плановым. Более «глобальная» метрика позволяет оценить, насколько команда справляется с планом в каждом спринте и сделать прогноз на будущее. На горизонтальной оси — время, на вертикальной — количество задач в спринте. Рядом по два столбца: первый — фактически выполненные задачи, второй — план на спринт.

Важно: для того, чтобы оперировать показателем Velocity нужно, чтобы продолжительность спринта и число человек в команде не менялось (как и состав команды).