Devprom ALM: Руководство пользователя

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

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

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

Шаблоны пожеланий и историй

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

Редактирование шаблонов и создание новых также доступно в настройках проекта: Настройки - Шаблоны и процессы - Шаблоны историй/пожеланий.

Шаблоны текстов

Также используйте шаблоны текстов, которые можно быстро подставить в описание первичного требования после символа # (решётка)

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы понять, сколько и каких требований можно поместить в релиз или итерацию, необходимо их оценивать. Вы можете оценивать трудоёмкость или сложность требований. Единицы измерения (часы, 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. Все истории, которые получили оценку больше этого значения лучше декомпозировать на более мелкие истории, выяснить больше деталей. Так вот, шкала "степень двойки" более грубая и значит более простая в использовании, но очевидно, менее точная. На "степени двойки" стоит остановиться, если команда небольшая, в итерации мало историй, уровень неопределенности в требованиях невысок. В других случаях лучше воспользоваться Фибоначчи и организовать планирование итераций в формате "Покер планирования".

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

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