Как перевести команды разработчиков на единый шаблон проекта

Когда все команды True Engineering перешли на единый трекер на базе Azure DevOps (TFS), это позволило нам создать единый свод правил для ведения проектов. Рассказываем, как проектный офис разработал логику, по которой сейчас работают наши разработчики.

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

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

Целью было сделать так, чтобы в итоге каждый проект можно было «прочитать» в трекере и однозначно понять его состояние. Причём сделать это может как человек (настраивать сквозные метрики по всем проектам, понимать, где всё хорошо, а где хуже), так и машина (сервис формирования Release Notes «понимает», какие задачи с какими статусами и тегами включать в рассылку). И конечно, все вновь запускаемые проекты нужно сразу создавать в тех же правилах.

Этой цели мы сейчас и добились. Когда менеджер отправляет заявку администраторам, чтобы ему завели новый проект, ему не нужно объяснять, что там должно быть: какие настройки и типы задач, к каким системам подключить. Всё необходимое есть в проекте с самого начала, можно сразу заводить спринты, заполнять задачи, готовить план разработки.

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

Дальше про то, по какой логике работает шаблон и какие настройки в него встроены по умолчанию.

1. Виды задач и их иерархия. Первое, о чём договорились наши команды – это единое представление о декомпозиции продукта.

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

Здесь важным критерием является конечность эпика во времени, то есть достижимость конкретной цели. Хороший пример эпика — «Автоматизация тестирования на проекте».

Под ними – Feature, эти элементы разрабатываются за 1-3 спринта). Одна Feature – один бизнес-сценарий. Например, оформление командировок.

Ещё одним уровнем ниже – PBI (Product Backlog Item, единица поставки), они представляют собой отдельный кейс в рамках сценария. Подготовка заявки на командировку, согласование поступающих заявок, загрузка чеков для авансового отчёта – это PBI. Они разделяются на Task-и, атомарные единицы работы, которая назначается на исполнителя и не занимает больше 8 часов.

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

2. Механика конвейера разработки. Это огромная часть работы любого PM – они контролируют, в каком состоянии находится каждая разрабатываемая фича, отслеживают, чтобы в нужный момент команда могла отправить код на тест, и так далее.

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

Проектный офис изучил практику наших команд и сформировал единый набор статусов, по которым проходит релиз. Схему сделали максимально подробной, чтобы никакой команде не понадобилось добавить какие-то свои шаги.

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

3. Поддержка планирования ресурсов и времени. Мы внедрили во всех командах три метрики для контроля трудозатрат:

- Первоначальная оценка времени на разработку

- Реально зарепорченное время

- Остаток времени

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

Единый набор метрик. Про нашу проектную аналитику мы подробно рассказывали в статье про дашборды TFS. Наш шаблон сразу включает в себя всё, что нужно менеджеру, чтобы быстро оценить состояние проекта, в том числе, и когда он подключается к уже работающей команде.

Плагин TFS Aggregator. Этот инструмент подключается к проекту и позволяет автоматические контролировать движение статусов Task-ов и по этим данным отслеживать состояние их родительских PBI. В результате мы можем написать единые правила для трекера заказчика и отправлять ему оповещения о статусах релизов, комментариев к задачам и т.д. Эта функция используется для автоматического сбора Release Notes, уведомления заказчикам о поставках фич, как мы рассказывали в материале про Release Notes.

Интеграция с OLAP-кубом. Эта функциональность отвечает за анализ трудозатрат, статусов задач, контроль Time-to-Market, прочих проектных показателей. Раньше мы использовали куб для контроля показателей внутри проектов. Когда у нас появилась единая система координат, стало возможным делать сквозную аналитику по всем командам сразу – мы знаем, что во всех проектах действуют одни и те же измерения с одними и теми же смыслами.

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

Календарь. Этот модуль помогает отслеживать, кто в команде собирается в отпуск, кого в тот или иной период привлекают к работе в параллельной команде и проч.

Наша первоочередная цель – это интеграция с порталом фича-флагов. Этот инструмент постепенно берут на вооружение всё больше наши команд, и мы хотим, чтобы состояние фич было видно в TFS.

Параллельно мы думаем над расширением перечня метрик над шаблонами. Мы хотим создать сквозные метрики, чтобы вывести эту аналитику за пределы каждого отдельного проекта. Тогда мы сможем выделять сильные стороны разных команд и определять узкие места, улучшим обмен лучшим опытом и ускорим накопление интеллекта.

Ещё одна задача – это организация ретроспективы спринтов. По нашей задумке, система должна уметь трактовать и интерпретировать результаты спринта: что планировали в начале спринта, что получили в конце, как шли работы в процессе и если были трудности, то где. Тогда в рамках ретроспективы команда будет заниматься не субъективным анализом своих результатов, а оценивать их по объективным данным.

Ещё по теме — Как мы построили систему управления проектами на базе Azure DevOps.