Есть множество готовых проверенных временем фреймворков для организации рабочего процесса, в которых хорошо описаны методы и принципы. Если собираем машину, используем Kanban, готовим пирог — Lean, разрабатываем сайт на заказ — PMBoK. Важно учитывать, что каждый проект уникален и нуждается в адаптации подходов, но в целом для вашего случая скорее всего уже есть достаточно полезных решений. Выстраивая процессы для себя, взял всего понемногу.
Работал в стартапе. Один продукт, одна небольшая команда, нет жестких ограничений по срокам. Использовали Scrum и Kanban в чистом виде, если можно так выразиться. Записывали задачи в Trello и перетаскивали по 4 доскам: идеи, надо сделать, в работе, готово. Для обсуждения хода работы созванивались каждый день, а раз в неделю планировали задачи на следующий спринт. Все как у людей.
Немного сменив курс развития, я отправился за новым опытом в веб-студию. Там в первую очередь удивился гибкости работы с клиентами, а, если без сарказма, отсутствию какой-либо системы.
Чтобы показать общую картину, приведу сильно упрощенный пример.
Заказчик А: мне нужно разработать лендинг для проведения мероприятия такого-то числа.
Менеджер проектов (МП): окей, сделаем к такой-то дате.
Заказчик Б: срочно внесите следующие изменения на сайт.
МП: хорошо, добавим как можно скорее.
Дальше МП согласовывает смету для заказчика А, записывает задачи в трекер, создавая отдельные проекты и несвязанные доски. Рассказывает команде, что, кому нужно сделать. Разработчики начинают пилить, а по завершению менеджер показывает клиентам результат.
Записи в системе условно выглядят так:
Подход к ведению вполне логичный, но возникают следующие проблемы:
Возможно, в данном примере с правками и лендингом не выглядит страшно, так как все это легко держать в голове, но на практике могло быть по 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), все расчеты было бы возможно проводить без участия человека.
Было
Работал в стартапе. Один продукт, одна небольшая команда, нет жестких ограничений по срокам. Использовали 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 задачи, а у кого-то их нет.
- При планировании времени завершения не учитываются задачи из других проектов.
Добавляя новую задачу в любой проект, ее видно в общем бэклоге. Приоритет относительно остальных задач выставляется ей по единой метрике.
Планы
Некоторые процессы удалось сократить или автоматизировать, но гораздо больше осталось в планах:
Генерация смет по проектам time&material
Выполняя каждую задачу сотрудник отмечает в ней время. Зная ставки в час каждого человека, его должность, поправочный коэффициент (на сколько умножить для учета издержек компании) можно генерировать таблицу со списком работ и стоимостями.
Автоматические взаиморасчеты между менеджерами
Если у меня есть задачи, но на ее выполнение не хватает ресурсов, прошу у другого менеджера исполнителя. Когда подходит время отчетов, вношу как расходы потраченные деньга-часы сотрудника в свой план и как доходы в план другого менеджера.
Каждый месяц приходилось поднимать все работы, сверяться с менеджерами, перемножать и вычитать без какого-либо креатива. Если бы все сотрудники перешли на единый формат данных (способ ведения проектов в Jira), все расчеты было бы возможно проводить без участия человека.
s1im
Предлагаю для начала разобраться что такое «Ajile» в заголовке поста.
Arepo
Запланируют исправление на следующий спринт
silantevdenis Автор
Дописал в заголовок. Имелось в виду то, что использованная методология берет некоторые популярные методы, но не соблюдает все принципы. Видимо, не раскрыл это в статье.