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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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