- PVSM.RU - https://www.pvsm.ru -
Это продолжение статьи «Управление потоком задач на разработку. История из жизни», ссылка на неё в конце этой статьи.
Компания самостоятельно разрабатывает программное обеспечение (Продукты) под нужды своих бизнес-подразделений (Заказчиков). Некоторые из продуктов поставлены заказчикам и компания занимается их доработкой-развитием.
Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.
Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.
Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.
Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).
Общая трудоемкость клиентских запросов на доработки превышает количество доступных ресурсов на их исполнение в производственном цикле. Чтобы понять какие запросы необходимо сделать в первую очередь, ежемесячно Менеджер по продукту обращается к Менеджерам по клиентам с просьбой приоритезировать список запросов по своим Заказчикам и указать какие из них они хотят получить в результате выполнения очередного цикла разработки (Sprint-а). Так появляется первая версия плана разработки на очередной цикл, состоящий из запросов, отмеченных Менеджерами по клиентам.
Каждый из продуктов также закреплен за одной из команд разработки. Менеджер по продукту запрашивает у Руководителя команды разработки доступные часы разработчиков на будущий цикл (Sprint Capacity).
Менеджер по продукту сравнивает трудоемкость первичного плана с доступной мощностью команд. Если пожелания Менеджеров по клиентам превышают доступные ресурсы, Менеджер по продукту просеивает задачи через сито критериев выгодности для Компании. На выходе вторая версия плана разработки с самыми выгодными для компании запросами с трудоемкостью реализации соответствующей мощности команд на цикл.
Запросы внутри плана группируются по продуктам (релизам) и выставляется очередность их реализации внутри релиза (повторная приоритезация). Это указывает командам какие запросы в какой последовательности реализовывать. Полученный план (Sprint Backlog) доводится до Менеджеров по клиентам и размещается на внутреннем портале.
Выступает платформой для всего ИТ-решения. Обеспечивает реализацию бизнес-функции по ведению учёта запросов на разработку и доработку продуктов.
Используются стандартные возможности JIRA по добавлению пользовательских полей (custom fields) для хранения и последующей обработки информации по запросам.
Для планирования понадобится добавить следующие поля:
Которые нужно вывести на экранные формы запросов: создание, редактирование и просмотр. Это делается через панель администрирования «Экраны».
Пример экрана редактирования запроса с пользовательскими полями.
Как следует из названия он представляет собой подобие Excel-я. Это плагин JIRA, который даёт возможности работы со списками-выборками, которых нет в базовом функционале.
В данном случае понадобятся две его возможности:
Рабочий инструмент в JExcel это workbook, создается он на основе Проектов JIRA или сохраненных фильтров. Фильтры написанные на Jira Query Language (JQL) пока не понимает. В каких то дополнительных настройках не нуждается.
Существует в двух видах: JExcel Lite – бесплатный, JExcel Pro – платный.
marketplace.atlassian.com/plugins/com.moresimp.jexcel/server/overview [1]
moresimp.com/jexcel-lite [2]
Это плагин JIRA которые даёт возможности для ведения ресурсов, детального планирования их работы и расчета доступности.
Этим плагином пользуется Руководитель команды разработки, на основании его данных он предоставляет Менеджерам по продукту информацию о доступности ресурсов на очередной цикл разработки.
Плагин платный.
marketplace.atlassian.com/plugins/com.tempoplugin.tempo-planner/cloud/overview [3]
tempo.io/products/tempo-planner [4]
Это самостоятельный продукт — платформа, которая выступает экосистемой для построения внутреннего портала и базы знаний компании. В контексте планирования используется как Витрина для всех кому нужна актуальная информация о планах разработки на следующий цикл и что было в прошедших.
Так на странице в Confluence выглядит Sprint Backlog и план по выпуску релизов на месяц.
Используется стандартный макрос Jira Issue/Filter macro который выводит в Confluence сохраненные фильтры в JIRA. Это экран настройки отображения фильтра на странице.
Устроен так, что когда информация обновляется в JIRA она обновляется и в Confluence, поэтому страница с планом используется также для мониторинга текущего состояния выполнения плана.
Confluence как и JIRA является платным продуктом.
Обычно ситуация выглядит так: Есть Продукт, Команда которая его делает, постоянно пополняющийся Список доработок продукта (Product Backlog). Пополняют его Менеджеры по проектам, Менеджеры по продажам/клиентам..., которым нужны доработки по их проектам / клиентам (User Story) в определенный срок. Менеджеры конкурируют между собой за ресурсы и это приводит к тому что:
В результате Команда не завершив работы по одной истории, переключается на следующую. Выпуск нового релиза продукта регулярно откладывается, так как не одна из доработок не готова.
На рисунке показано, что у нас есть 3 клиентские истории, трудоемкость каждой 1 месяц, делает их одна команда разработки. Из-за постоянного переключения между историями возникают дополнительные затраты на переключение, поэтому все 3 истории сдаются в 4-м месяце.
Это рисунок говорит, что если истории приоритезировать и последовательно реализовать, то они будут реализованы быстрее чем в предыдущем способе организации работ. Зеленые квадраты сверху обозначают поступление выручки от клиентов за выполненные заказы.
Ресурсы конкретной команды лучше фокусировать чем распылять и пока первый заяц не будет пойман, за вторым не гнаться.
Чем дольше разрабатывается продукт тем выше вероятность что клиентские требования успеют «протухнуть» за этот срок, что приводит к их актуализации со стороны клиента, изменению технического задания, росту объема работы и приводит опять к удлинению срока разработки или к росту потребности в ресурсах, чтобы выдержать срок. Всё это время Клиент работает без нашего продукта, не получает от него выгоды, а конечная стоимость продукта для него увеличивается. Риск того, что Клиент останется не доволен нами и продуктом растёт.
Чтобы требования не «протухали» и Клиент был доволен, нужно выпускать продукт, за который клиент готов заплатить, как можно раньше. Для этого необходимо клиентские требования разбивать на самодостаточные блоки. Выпустив первый блок и принявшись за второй, мы даем клиенту возможности: накопить опыт использования продукта и выгоду от него, уточнить требования на третий блок и разместить заказ на новые требования, о которых Клиент не подумал до этого или не знал, что будут нужны.
Релиз с одной полезной функцией для Клиента через месяц лучше, чем релиз с десятком функций, но через полгода или год.
Каждый релиз помимо затрат на разработку полезных функций имеет условно постоянные затраты на свой выпуск: это сборка релиза, разворачивание тестовой среды, регрессионное тестирование…
Представим что у нас 4 продукта и раньше мы выпускали новый релиз по каждому продукту 1 раз в полгода, наши затраты на выпуск релизов равны условным 4 единицам. Если мы решим релизить чаще, например, раз в месяц, руководствуясь Идеей №2, то наши затраты на выпуск релизов станут равны 24 условным единицам.
Из этого следует, что:
Для сокращения этих расходов необходимо внедрять инструменты DevOps.
Принимая решения о частоте выпуска релизов, необходимо посчитать сколько релизов в месяц мы можем физически выпускать сейчас и как изменится итоговая стоимость разработанной функции продукта.
Эта статья написана под презентацию на Meetup-е Московской Atlassian User Group [11], который состоится 1 марта 2017 года и пройдет в учебном классе компании Finam, начало в 19:00.
На него я вас и приглашаю [12].
Для тех кто быть не сможет, но содержание мероприятия интересно, будет вестись видеозапись, которая чуть позже появится на канале группы в Youtube [13]. На нём сейчас можно посмотреть видеозаписи прошлых встреч.
На этих Meetup-ах мы делимся опытом использования продуктов компании Atlassian и плагинов к ним. Рассказываем для чего их используем, какие у них есть возможности, как их настраивать, обмениваемся контактами и отдыхаем в неформальной обстановке.
Увидимся на встрече и буду благодарен за содержательные комментарии к статье.
Автор: Locolind
Источник [14]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/246273
Ссылки в тексте:
[1] marketplace.atlassian.com/plugins/com.moresimp.jexcel/server/overview: https://marketplace.atlassian.com/plugins/com.moresimp.jexcel/server/overview
[2] moresimp.com/jexcel-lite: http://moresimp.com/jexcel-lite/
[3] marketplace.atlassian.com/plugins/com.tempoplugin.tempo-planner/cloud/overview: https://marketplace.atlassian.com/plugins/com.tempoplugin.tempo-planner/cloud/overview
[4] tempo.io/products/tempo-planner: http://tempo.io/products/tempo-planner/
[5] Управление потоком задач на разработку. История из жизни : http://habrahabr.ru/post/314448/
[6] О гибком планировании и управлении работами в TFS 11 Beta : http://habrahabr.ru/post/143268/
[7] Джоэль Спольски: производственные запасы в разработке ПО : http://habrahabr.ru/post/147501/
[8] Жизнь кирпичей. Почему расстановка приоритетов — ключевой элемент планирования: http://habrahabr.ru/post/119358/
[9] Оперативное планирование в Redmine : http://habrahabr.ru/post/245065/
[10] Жизнь управленца, кадр 4-1, Планирование — Разбор задач: http://habrahabr.ru/post/193014/
[11] Московской Atlassian User Group: https://www.facebook.com/groups/1692084817674894/
[12] На него я вас и приглашаю: https://www.meetup.com/Moscow-Atlassian-User-Group/events/237727456/
[13] на канале группы в Youtube: https://www.youtube.com/channel/UC7v2CVnBomHLw8wiuOzWF9g/about
[14] Источник: https://habrahabr.ru/post/321598/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.