Бэклог

Планирование проекта основывается на объеме работ, который необходимо выполнить. В разработке ПО таким объемом работ является набор первичных (пользовательских) требований.

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

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

План проекта

Разработка ПО обладает особенностями, которые нивелируют преимущества традиционных сетевых диаграмм Гантта:

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

Поставку результата выгодно делать порциями (инкрементами). Время, в течение готорого реализуется очередной инкремент продукта, обычно называется релизом или итерацией. В Devprom ALM релизы отвечают за длительные интервалы времени (месяцы), итерации - за короткие (недели). Сделано это для того, чтобы можно было комбинировать релизы с итерациями. В этом случае итерации детализируют релизы.

Обычно итерации последовательны (идут друг за другом), а релизы могут быть параллельными: текущий и будущий, например. Для разных процессов можно использовать только итерации, только релизы или релизы и итерации совместно.

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

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

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

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

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

В дополнение к этому вы можете явно исключить релиз или итерацию из плана, выпадающих списков и т.п. Для этого установите признак "Завершено" на карточке релиза или итерации. Массовая операция для управления этим признаком доступна в модулях "Релизы" и "Итерации".

Дорожная карта (Roadmap)

Альтернативной формой представления плана работ является дорожная карта (Roadmap), которая показывает, когда будет разрабатываться или будет готова та или иная функциональность.

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

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

Оценка требований

Чтобы понять, сколько и каких требований можно поместить в релиз или итерацию, необходимо их оценивать. Методов оценки существует множество: эмпирические, количественные, точные и простые. В Devprom ALM используются простые методы оценки: в идеальных часах или Story Points (абстрактных единицах сложности). Выбор метода осуществляется в настройках методологии проекта.

Чаще всего команды используют одну из простых методик: оценку в идеальных часах или оценку сложности в абстрактных единицах (попугаях). Идеальным час назван потому, что в работе постоянно возникают утечки времени на помощь коллеге, чай, обсуждение и т.п. Так что в день у каждого обычно есть 5-6 идеальных часов, а не 8. Такая оценка годится, если над задачей будет работать один человек, используется предыдущий опыт, либо требования достаточно подробные. В других случаях такая оценка будет крайне неточной, поэтому используют альтернативный метод - оценку в абстрактных единицах, например, размерах или Story Points (сокращенно SP). Это абстрактные величины, характеризующие сложность задачи (пользовательской истории).

Самым простым вариантом оценки сложности являются размеры футболок: X, L, M, S. Такая оценка быстрая, грубая, но позволяет показать возможности команды и ранжировать задачи по их сложности, например, с целью приоритезации - сделаем сначала простые и важные, потом сложные и важные и т.д.

Более точную оценку позволяют получить Story Points. Поскольку сами по себе они абстрактные, то оценку ведут по шкале, отражающей возрастание сложности задач. Чтобы построить такую шкалу использовали исследования, в которых показано, что мы различаем сложное от еще более сложного, когда их оценка отличается примерно на 160% - 170%. Поэтому для оценки в SP используют шкалы последовательности Фибоначчи (1, 2, 3, 5, 8, ...) или степени двойки (1, 2, 4, 8, 16, ...). Какую из них выбрать?

Чем выше сложность задачи, тем выше неопределенность и больше погрешность, поэтому эффективно можно использовать несколько начальных элементов шкалы, например, до 40. Все истории, которые получили оценку больше этого значения лучше декомпозировать на более мелкие истории, выяснить больше деталей. Так вот, шкала "степень двойки" более грубая и значит более простая в использовании, но очевидно, менее точная. На "степени двойки" стоит остановиться, если команда небольшая, в итерации мало историй, уровень неопределенности в требованиях невысок. В других случаях лучше воспользоваться Фибоначчи и организовать планирование итераций в формате "Покер планирования".

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

Если процесс оценки занимает больше времени, либо для этого необходимо привлечь нескольких участников процесса разработки, то можно выделить специальную стадию ЖЦ требований, например, "Уточнение" или "Оценка". Участники процесса могут собраться вместе, обсудить требование и результирующую оценку сохранить в карточке требования или доработки. Если собраться вместе нельзя, то можно записать свои оценки в соответствующих задачах, декомпозирующих требование: