Гибкие и не очень модели управления разработкой ПО. Как реализовать и комбинировать в Redmine

В нашей компании, занимающейся разработкой софта по полному циклу (от сбора требований до внедрения и техподдержки), принят курс на максимальную оптимизацию ресурсов. Существуют проектные команды, отделы и службы, а сами сотрудники динамично «шарятся» между различными подразделениями. Выстраивание процесса управления ресурсами в такой обстановке, а тем более его автоматизация — нетривиальная задача.

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

Как известно, сейчас существует несколько подходов к управлению проектами: гибкие, жесткие, чаще всего их комбинация. Мы поставили перед собой задачу предоставить такой инструмент контроля жизненного цикла задачи в трекере, который, с одной стороны, позволит учесть технические аспекты производства ПО, с другой — не будет навязывать команде или группе сотрудников метод работы, с третьей — позволит единообразно организовать внутренний процесс выполнения задач (унифицированные состояния-статусы, одинаковые метрики и т.д.).

Рассмотрим жизненный цикл задачи на внедрение новой функциональности (такие стадии имеются в нашей компании):



В жизни, к сожалению, задача часто возвращается на предыдущие этапы не один раз — обратные стрелки не стал рисовать, чтобы не загромождать схему. Обычно процесс выполнения такой задачи организуется в редмайне «в лоб», аналогично схеме на картинке — создается задача (талон), далее он передается от исполнителя к исполнителю со сменой статусов. Такая схема больше подходит каскадной модели управления, когда постоянная команда выполняет заранее разработанный план, либо задачи организованно передаются от подразделения к подразделению (например, от разработчиков к тестировщикам). Но для agile подхода, либо при работе выделенных служб такая схема не очень удобна. Итак, достоинства описанной схемы (назовем ее «одна задача — один талон»):

• Единая сущность, которую легко создавать, искать, «понять»;
• Вся история и комментарии в одном месте.

Недостатки схемы «одна задача — один талон»:

• Трудно выполнить оценку трудоемкости и планового времени выполнения по типам деятельности (приходится вводить много дополнительных полей, из-за невозможности оценить по времени хотя бы одну стадию плывет оценка всей задачи в целом);
• Чтобы было понятно, на какой именно стадии выполнения задача находится сейчас, приходится вводить кучу дополнительных статусов вроде «Готова к разработке», «На тестировании» и т.д. Это усложняет схему и применение метрик;
• Невозможно распараллелить действия (например, документирование и тестирование), поскольку задача в данный момент времени может быть назначена только на одного исполнителя;
• Исполнителю, принявшего задачу на последних стадиях (документирование или тестирование), трудно разобраться в текущем статусе, приходится прописывать постановку задачи в комментариях, что неверно методологически;
• При использовании спринтов неудобно планировать длинные задачи в одном талоне, поскольку они обычно выполняются в течение нескольких итераций.

Талон, работа в котором выполняется по схеме «одна задача — один талон», выглядит примерно так (для случая, когда все работы выполняет один работяга Вася Пупкин):



Схема переходов для задачи «одна задача — один талон» (трекер, не мудрствуя лукаво, назван «Задача») упрощенно выглядит так (не считая дополнительных статусов вроде «Обратная связь», «На согласовании» и т.д.):

Новая -> Готова к бизнес-анализу -> Бизнес-анализ -> Готова к системному анализу -> Системный анализ -> Готова к разработке -> Разработка -> Готова к тестированию -> Тестирование -> Готова к документированию -> Документирование -> Готова к внедрению -> Внедрение -> Выполнена -> Закрыта.

Для решения проблем схемы «одна задача — один талон» была разработана схема с созданием отдельных талонов (подзадач) на каждую атомарную деятельность, выполняемую одним исполнителем. Общая постановка в этом случае формируется в родительской задаче (трекер «Общая задача»), а атомарные задачи — как подзадачи. Т.е. функциональная детализация заменена на детализацию жизненного цикла. Назовем такую схему «одна подзадача — один талон».

Талоны по такой схеме выглядят так:



Вынос типа деятельности в название трекера позволяет применить единую схему переходов:

Новая -> В очереди -> В работе -> Выполнена -> Закрыта.

Схема простая, понятная как менеджеру, так и исполнителю, позволяет применять унифицированные метрики и agile-инструменты (например, виртуальные доски со стикерами).

Достоинства схемы «одна подзадача — один талон»:

• Возможность формирования индивидуальной задачи для конкретного исполнителя — снижается риск недопонимания;
• Возможность распараллеливания подзадач — ведь у каждой свой талон и свой исполнитель;
• Можно проставлять точные оценки времени и плановую дату завершения именно для этой подзадачи в независимости от остальных;
• Однообразие и простота схемы переходов;

Отдельно скажу про следующее достоинство: при работе с внутренними службами, а также с аутсорсерами передавать им единый талон по задаче не совсем корректно как с технической, так и с политической точки зрения. Так, если вы отдали на аутсорсинг тестирование, то знать этим ребятам про то, как у вас проходит, например, документирование, совсем необязательно. Аналогично с внутренними службами — у нас, например, сформированы кросспроектные команды по роду деятельности: технические писатели, группа развития продукта. Они не знают особенности реализации того или иного проекта, поэтому им неинтересно разбираться в предыстории, а нужна четко сформированная задача.

Но есть у такой схемы и недостатки:

• Необходимо создавать много талонов в редмайн (5-10 на каждую задачу), навигация по которым в дальнейшем может быть проблематична;
• Если исполнителю необходимо узнать предысторию выполнения задачи, ему необходимо будет искать ее в других талонах;
• Управлять жизненным циклом такой задачи сложнее, поскольку менеджеру придется отслеживать и синхронизировать состояния разных талонов.

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

Такой талон выглядит следующим образом:



Что же с практикой? Одно из подразделений нашей компании перешло на работу по описанной концепции примерно 3 месяца назад. на текущий момент создано 395 талонов, из них:

1. По концепции «одна задача-один талон» 248;
2. По концепции «одна подзадача-один талон» 147;

Несмотря на то, что пока с большим отрывом лидирует концепция «одна задача-один талон», цифры показывают, что востребованы оба предложенных инструмента, что не может не радовать.

Есть еще интересные идеи и реализации на тему оперативного планирования в Redmine, вот тут.