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

В ALM реализован "пакетный" принцип управления проектом. Под "пакетом" понимается связанный набор задач, которые необходимо выполнить для достижения промежуточных целей проекта. Для оформления "пакета" работ используется Итерация. Другие названия Итерации - Спринт, Этап, Стадия и т.п.

Итерации могут быть вложенными (иерархическими), таким образом, обеспечивая произвольную детализацию планирования. Уровень итерации позволяет типизировать уровни декомпозиции плана работ, отличать один уровень планирования от другого, например, Стадии от Этапов.

Каждая итерация имеет плановые даты начала и окончания. Дочерние итерации влияют на плановую дату родительской итерации - растягивают ее.

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

Группу итераций можно объединить в релиз. Релиз - это крупная часть проекта, в рамках которой готовится новая версия ПО и т.п. Все релизы как правило выполняются одинаковым образом и определяют цикличность выпуска новой функциональности. Ход выполнения релиза можно распланировать при помощи итераций. Если целью проекта является выпуск одной единственной версии ПО, либо это проект внедрения, то релизы не нужны и отключаются в настройках методологии проекта.

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

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

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

Общая структура декомпозиции работ отображается в модуле "Дерево работ". Справа на дополнительной панели для релизов и итераций отображается детальная Гантт-диаграмма выполнения выбранного этапа проекта.

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

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

После создания календарного графика проекта, можно приступить к заполнению "пакетов" конкретными работами.

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

Альтернативный способ планирования задач - использование модуля "Оперативный план". В этом модуле задачи из "Бэклога" (то есть перечня неназначенных задач) распределяются по Итерациям ("пакетам" выполнения работ).

При формировании плана работ, основанного на документе, например, Техническом задании, задачи создаются непосредственно из документа:

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда набор требований оценен, то несложно определить - помещаются ли эти требования в очередной релиз или итерацию. У релиза и итерации есть длительность. С учетом скорости команды - объема работы, выполняемого за день - можно определить ёмкость релиза или итерации. Используйте эти индикаторы при планировании состава релиза или итерации:

Более трудоемким способом приоритизации является метод WSJF. Приоритет требования (истории) вычисляется на основе формулы, которая зависит от таких критериев как:

• Оценка трудоемкости - количество трудозатрат (или времени), необходимых для реализации требования;
• Ценность для пользователя - выгода, которую получает пользователь, в результате реализации требования;
• Критичность по срокам - насколько критично по срокам данное требование, чем выше оценка, тем раньше требование должно быть реализовано;
• Снижение рисков - насколько реализация данного требования устраняет или снижает пользовательские риски (потеря данных, невозможность выполнять работу, лишние трудозатраты, репутационные риски и т.п.).

Используйте соответствующие модули, например,

Система вычисляет Приоритет WSJF, по которому можно отсортировать строки. Сверху размещаются требования с наибольшей ценностью для клиента и менее трудозатратные. Единицы измерения коэффициентов соответствуют настройкам оценки трудоемкости в Методологии проекта.

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

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

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

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

В процессах "Поиск продукта" (Scrum) и "Развитие продукта" (Scrumban) при планировании спринтов дополнительно осуществляется декомпозиция историй на работы (задачи).

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

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