Это продолжение статьи «Управление потоком задач на разработку. История из жизни», ссылка на неё в конце этой статьи.
Контекст и задача
Компания самостоятельно разрабатывает программное обеспечение (Продукты) под нужды своих бизнес-подразделений (Заказчиков). Некоторые из продуктов поставлены заказчикам и компания занимается их доработкой-развитием.
Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.
Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.
Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.
Бизнес-логика
Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).
Общая трудоемкость клиентских запросов на доработки превышает количество доступных ресурсов на их исполнение в производственном цикле. Чтобы понять какие запросы необходимо сделать в первую очередь, ежемесячно Менеджер по продукту обращается к Менеджерам по клиентам с просьбой приоритезировать список запросов по своим Заказчикам и указать какие из них они хотят получить в результате выполнения очередного цикла разработки (Sprint-а). Так появляется первая версия плана разработки на очередной цикл, состоящий из запросов, отмеченных Менеджерами по клиентам.
Каждый из продуктов также закреплен за одной из команд разработки. Менеджер по продукту запрашивает у Руководителя команды разработки доступные часы разработчиков на будущий цикл (Sprint Capacity).
Менеджер по продукту сравнивает трудоемкость первичного плана с доступной мощностью команд. Если пожелания Менеджеров по клиентам превышают доступные ресурсы, Менеджер по продукту просеивает задачи через сито критериев выгодности для Компании. На выходе вторая версия плана разработки с самыми выгодными для компании запросами с трудоемкостью реализации соответствующей мощности команд на цикл.
Запросы внутри плана группируются по продуктам (релизам) и выставляется очередность их реализации внутри релиза (повторная приоритезация). Это указывает командам какие запросы в какой последовательности реализовывать. Полученный план (Sprint Backlog) доводится до Менеджеров по клиентам и размещается на внутреннем портале.
Техническая реализация семейством продуктов Atlassian
JIRA Sotware
Выступает платформой для всего ИТ-решения. Обеспечивает реализацию бизнес-функции по ведению учёта запросов на разработку и доработку продуктов.
Используются стандартные возможности JIRA по добавлению пользовательских полей (custom fields) для хранения и последующей обработки информации по запросам.
Для планирования понадобится добавить следующие поля:
- Приоритет Заказчика
- Данные из Технико-Экономического Обоснования: Ожидаемая величина дохода-экономии
- Данные из ТЭО: Срок окупаемости
- Отметка о желании получить в результате следующего цикла разработки
- Информация о том в какой цикл разработки поставлен запрос
Которые нужно вывести на экранные формы запросов: создание, редактирование и просмотр. Это делается через панель администрирования «Экраны».
Пример экрана редактирования запроса с пользовательскими полями.
JExcel
Как следует из названия он представляет собой подобие Excel-я. Это плагин JIRA, который даёт возможности работы со списками-выборками, которых нет в базовом функционале.
В данном случае понадобятся две его возможности:
- Редактировать запросы в JIRA не заходя в них
На одной странице Менеджер по клиентам увидит все свои клиентские запросы, сможет указать им приоритет и какие из них хочет видеть в следующем релизе. - Суммирование в столбцах и выделенных ячеек
Менеджер по продукту увидит общую трудоемкость запросов на очередной спринт. Зная сколько у него есть ресурсов он раскидает запросы по циклам разработки, что войдет в ближайший, а что в следующий.
Рабочий инструмент в JExcel это workbook, создается он на основе Проектов JIRA или сохраненных фильтров. Фильтры написанные на Jira Query Language (JQL) пока не понимает. В каких то дополнительных настройках не нуждается.
Существует в двух видах: JExcel Lite – бесплатный, JExcel Pro – платный.
marketplace.atlassian.com/plugins/com.moresimp.jexcel/server/overview
moresimp.com/jexcel-lite
Tempo Planner
Это плагин JIRA которые даёт возможности для ведения ресурсов, детального планирования их работы и расчета доступности.
Этим плагином пользуется Руководитель команды разработки, на основании его данных он предоставляет Менеджерам по продукту информацию о доступности ресурсов на очередной цикл разработки.
Плагин платный.
marketplace.atlassian.com/plugins/com.tempoplugin.tempo-planner/cloud/overview
tempo.io/products/tempo-planner
Confluence
Это самостоятельный продукт — платформа, которая выступает экосистемой для построения внутреннего портала и базы знаний компании. В контексте планирования используется как Витрина для всех кому нужна актуальная информация о планах разработки на следующий цикл и что было в прошедших.
Так на странице в Confluence выглядит Sprint Backlog и план по выпуску релизов на месяц.
Используется стандартный макрос Jira Issue/Filter macro который выводит в Confluence сохраненные фильтры в JIRA. Это экран настройки отображения фильтра на странице.
Устроен так, что когда информация обновляется в JIRA она обновляется и в Confluence, поэтому страница с планом используется также для мониторинга текущего состояния выполнения плана.
Confluence как и JIRA является платным продуктом.
3 фундаментальные идеи для разработки процесса планирования
Идея Первая
Обычно ситуация выглядит так: Есть Продукт, Команда которая его делает, постоянно пополняющийся Список доработок продукта (Product Backlog). Пополняют его Менеджеры по проектам, Менеджеры по продажам/клиентам..., которым нужны доработки по их проектам / клиентам (User Story) в определенный срок. Менеджеры конкурируют между собой за ресурсы и это приводит к тому что:
- Вариант №1: Приоритеты в работе команды регулярно меняются. Менеджер идет к Руководству и пробивают себе повышение приоритета и выделение ресурсов команды на определенный срок, пока не появится более важный проект, заказ или более убедительный Менеджер.
- Вариант №2: Всем раздают по небольшому кусочку ресурса команды.
В результате Команда не завершив работы по одной истории, переключается на следующую. Выпуск нового релиза продукта регулярно откладывается, так как не одна из доработок не готова.
На рисунке показано, что у нас есть 3 клиентские истории, трудоемкость каждой 1 месяц, делает их одна команда разработки. Из-за постоянного переключения между историями возникают дополнительные затраты на переключение, поэтому все 3 истории сдаются в 4-м месяце.
Это рисунок говорит, что если истории приоритезировать и последовательно реализовать, то они будут реализованы быстрее чем в предыдущем способе организации работ. Зеленые квадраты сверху обозначают поступление выручки от клиентов за выполненные заказы.
Ресурсы конкретной команды лучше фокусировать чем распылять и пока первый заяц не будет пойман, за вторым не гнаться.
Идея Вторая
Чем дольше разрабатывается продукт тем выше вероятность что клиентские требования успеют «протухнуть» за этот срок, что приводит к их актуализации со стороны клиента, изменению технического задания, росту объема работы и приводит опять к удлинению срока разработки или к росту потребности в ресурсах, чтобы выдержать срок. Всё это время Клиент работает без нашего продукта, не получает от него выгоды, а конечная стоимость продукта для него увеличивается. Риск того, что Клиент останется не доволен нами и продуктом растёт.
Чтобы требования не «протухали» и Клиент был доволен, нужно выпускать продукт, за который клиент готов заплатить, как можно раньше. Для этого необходимо клиентские требования разбивать на самодостаточные блоки. Выпустив первый блок и принявшись за второй, мы даем клиенту возможности: накопить опыт использования продукта и выгоду от него, уточнить требования на третий блок и разместить заказ на новые требования, о которых Клиент не подумал до этого или не знал, что будут нужны.
Релиз с одной полезной функцией для Клиента через месяц лучше, чем релиз с десятком функций, но через полгода или год.
Идея Третья
Каждый релиз помимо затрат на разработку полезных функций имеет условно постоянные затраты на свой выпуск: это сборка релиза, разворачивание тестовой среды, регрессионное тестирование…
Представим что у нас 4 продукта и раньше мы выпускали новый релиз по каждому продукту 1 раз в полгода, наши затраты на выпуск релизов равны условным 4 единицам. Если мы решим релизить чаще, например, раз в месяц, руководствуясь Идеей №2, то наши затраты на выпуск релизов станут равны 24 условным единицам.
Из этого следует, что:
- Если раньше на выпуск одной полезной функции у нас приходилась 1 единица накладных расходов, то теперь на неё же будет приходится 6 единиц.
- Для того, чтобы обеспечить выпуск 20 дополнительных релизов, потребуются дополнительные ресурсы. Они у нас есть?
Для сокращения этих расходов необходимо внедрять инструменты DevOps.
Принимая решения о частоте выпуска релизов, необходимо посчитать сколько релизов в месяц мы можем физически выпускать сейчас и как изменится итоговая стоимость разработанной функции продукта.
Итог
Что ещё почитать по теме на Habrahabr
- Управление потоком задач на разработку. История из жизни
- О гибком планировании и управлении работами в TFS 11 Beta
- Джоэль Спольски: производственные запасы в разработке ПО
- Жизнь кирпичей. Почему расстановка приоритетов — ключевой элемент планирования
- Оперативное планирование в Redmine
- Жизнь управленца, кадр 4-1, Планирование — Разбор задач
Послесловие
Эта статья написана под презентацию на Meetup-е Московской Atlassian User Group, который состоится 1 марта 2017 года и пройдет в учебном классе компании Finam, начало в 19:00.
На него я вас и приглашаю.
Для тех кто быть не сможет, но содержание мероприятия интересно, будет вестись видеозапись, которая чуть позже появится на канале группы в Youtube. На нём сейчас можно посмотреть видеозаписи прошлых встреч.
На этих Meetup-ах мы делимся опытом использования продуктов компании Atlassian и плагинов к ним. Рассказываем для чего их используем, какие у них есть возможности, как их настраивать, обмениваемся контактами и отдыхаем в неформальной обстановке.
Увидимся на встрече и буду благодарен за содержательные комментарии к статье.
Автор: Locolind
