Рубрика «планирование цикла разработки»

Предисловие переводчика: Недавно я рассказал о том, как реализовать процедуру планирования выпуска релизов по продуктам с помощью семейства продуктов Atlassian и дал ссылки на статьи как сделать тоже самое в Team Foundation Server и Redmine.

А что делать если компания не дозрела купить JIRA, TFS или Redmine, как обойтись только Excel-ем?

И эта статья о том как это сделать.

Гибкое планирование выпуска релизов 101 (на основе Excel) - 1

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

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

Это продолжение статьи «Управление потоком задач на разработку. История из жизни», ссылка на неё в конце этой статьи.

Контекст и задача

Компания самостоятельно разрабатывает программное обеспечение (Продукты) под нужды своих бизнес-подразделений (Заказчиков). Некоторые из продуктов поставлены заказчикам и компания занимается их доработкой-развитием.

Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.

Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.

Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.

Бизнес-логика

Планирование цикла разработки и выпуска релизов по продуктам - 1

Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js