Одновременное ведение agile- и waterfall-проектов

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

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

Работал в стартапе. Один продукт, одна небольшая команда, нет жестких ограничений по срокам. Использовали Scrum и Kanban в чистом виде, если можно так выразиться. Записывали задачи в Trello и перетаскивали по 4 доскам: идеи, надо сделать, в работе, готово. Для обсуждения хода работы созванивались каждый день, а раз в неделю планировали задачи на следующий спринт. Все как у людей.

Немного сменив курс развития, я отправился за новым опытом в веб-студию. Там в первую очередь удивился гибкости работы с клиентами, а, если без сарказма, отсутствию какой-либо системы.

Чтобы показать общую картину, приведу сильно упрощенный пример.

Заказчик А: мне нужно разработать лендинг для проведения мероприятия такого-то числа.

Менеджер проектов (МП): окей, сделаем к такой-то дате.

Заказчик Б: срочно внесите следующие изменения на сайт.

МП: хорошо, добавим как можно скорее.

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

Записи в системе условно выглядят так:

Подход к ведению вполне логичный, но возникают следующие проблемы:

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

Дизайнер сообщает о преждевременном завершении верстки (да, так тоже бывает). Спрашивает: что делать дальше? МП ставит задачу из четвертого проекта, первую по списку. В конце дня понимает, что четвертая задача из первого проекта была важнее.

Задачи в разных проектах. Держать их в голове или искать в каталогах никому не хочется. Проще, когда закончил, спросить: что делать дальше?

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

Попросили поменять ссылку на сайте. О, это просто, сегодня сделаем. Потом менеджер вспоминает, что на другом сайте есть супер критичные баги. В итоге изменение ссылки, по мнению заказчика, команда растянула на неделю.

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

Для создания системы в первую очередь необходимо было привести данные к единому формату. Преобразуя массу переданных в моё распоряжение сущностей удалось прийти к следующей концепции:

Думаю, по картинке все понятно, но есть небольшие нюансы связанные с реализацией в Jira. Разберем каждую сущность на примерах.

С понятием проект (project) все однозначно как в умах сообщества, так и компании Atlassian. Это последовательность действий направленных на получение результата за ограниченное время. Например: разработать сайт, поддерживать приложение на всем времени жизни, сделать рекламную компанию.

Эпики (release)— обособленные большие куски проекта: личный кабинет, корзина, каталог товаров. Вот тут уже начинаются разногласия. В Jira есть сущность — epic, но все же я использовал release.

Дело в том, что для реализации правильной структуры, необходимо иметь 3 уровня вложенности, у Jira на момент написания статьи их 2+1 (история и задача располагаются на одном уровне). +1 — это sub-task, его не беру в расчет, так как он несет функцию скорее дополнения чем вложенности из-за отсутствия гибкости и сильной привязки к родителю.

Вместо release можно было бы использовать component или sprint, но для моих целей они смотрелись менее удачно. По той же причине для записи историй использован epic.

История (epic) в данной структуре — это задача бизнеса (желание заказчика). Задача (task)— понятные действия для решения задач бизнеса.

Также сущностям были добавлены некоторые счетчики и поля. Самое важное из них — шкала оценки сложности задачи от 1 до 10 в условных единицах (story point).

Данные есть, после нужно решить, в каком виде и как их выводить. Я создал общий проект для команды и написал JQL-запрос для подтягивания в него задач из всех наших проектов (запрос легко сгенерировать в разделе issues). Добавил в него Kanban доски и статусы соответствующие нашему техпроцессу: Backlog → To do → Doing → Review → Testing → Matching → Done.

Получилась такая картина:

Теперь все задачи проходят по единому циклу производства, который достаточно универсален (дизайн можно не тестировать, а сразу перенести в согласование). В случае непрохождения какого-либо этапа, к задаче дописывается комментарий и она отправляется обратно в To Do. Каждая задача имеет видимые связи с проектом, историей клиента (epic) и эпиком (release).

Используя тот же JQL запрос с плагином BigGantt (или любым другим) для Jira задачи можно просмотреть в виде диаграммы Ганта. Изменить время выполнения, сроки, прописать зависимости, посмотреть нагрузку на исполнителей. Свернуть задачи в истории, истории в эпики, т.е. визуализировать roadmap или подробный план работ.

Из методологий используется Lean (определена последовательность действий при этом остается возможность параллельного выполнения задач), Kanban (задачи идут от специалиста к специалисту, легко выявляется “узкое место”). Из Scrum взял ежедневные встречи для поддержания понимания, кто что делает. На них же оценивали сложность новых задач в story points. Хотел, но не мог использовать спринты, т.к. заказчик иногда менял приоритет задач, а регулировать объем работ после начала спринта уже нельзя.

После встречи задачи приоритезируются в бэклоге, назначается исполнитель и переносится в To do. Разработчик создает ветку в BitBucket, задача автоматически перепрыгивает в Doing. По завершению “девелопер” переносит в Review, исполнитель переключается на другого разработчика. Ели все ок, “ревьюер” делает merge и код оказывается на тестовом сервере. Jira отправляет задачу тестировщику. После проверки, QA переводит ее на менеджера. Тот показывает заказчику. Заказчик доволен — код отправляется на боевой сервер под пристальный присмотр ежедневных автотестов.

За такую автоматизацию спасибо нашим devops — инженерам. Я только настроил изменение статусов и исполнителей по событиям из git. Делается это в настройках бизнес-процессов, если вы работаете в рамках экосистемы Atlasian. А при использовании GitLab, Bitrix, Redmine придется повозиться.

Посмотрим, чего удалось добиться:

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

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

Задачи в одном проекте. Каждый член команды видит, как они перемещаются по Kanban доске, общий ход работ. Что уже сделали и что предстоит.

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

Добавляя новую задачу в любой проект, ее видно в общем бэклоге. Приоритет относительно остальных задач выставляется ей по единой метрике.

Некоторые процессы удалось сократить или автоматизировать, но гораздо больше осталось в планах:

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

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

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