В качестве такс-трекера и баг-трекера мы используем Redmine. В этой статье я хочу рассказать о внедренной концепции работы с задачами в редмайне.
Как известно, сейчас существует несколько подходов к управлению проектами: гибкие, жесткие, чаще всего их комбинация. Мы поставили перед собой задачу предоставить такой инструмент контроля жизненного цикла задачи в трекере, который, с одной стороны, позволит учесть технические аспекты производства ПО, с другой — не будет навязывать команде или группе сотрудников метод работы, с третьей — позволит единообразно организовать внутренний процесс выполнения задач (унифицированные состояния-статусы, одинаковые метрики и т.д.).
Рассмотрим жизненный цикл задачи на внедрение новой функциональности (такие стадии имеются в нашей компании):
В жизни, к сожалению, задача часто возвращается на предыдущие этапы не один раз — обратные стрелки не стал рисовать, чтобы не загромождать схему. Обычно процесс выполнения такой задачи организуется в редмайне «в лоб», аналогично схеме на картинке — создается задача (талон), далее он передается от исполнителя к исполнителю со сменой статусов. Такая схема больше подходит каскадной модели управления, когда постоянная команда выполняет заранее разработанный план, либо задачи организованно передаются от подразделения к подразделению (например, от разработчиков к тестировщикам). Но для agile подхода, либо при работе выделенных служб такая схема не очень удобна. Итак, достоинства описанной схемы (назовем ее «одна задача — один талон»):
- Единая сущность, которую легко создавать, искать, «понять»;
- Вся история и комментарии в одном месте.
Недостатки схемы «одна задача — один талон»:
- Трудно выполнить оценку трудоемкости и планового времени выполнения по типам деятельности (приходится вводить много дополнительных полей, из-за невозможности оценить по времени хотя бы одну стадию плывет оценка всей задачи в целом);
- Чтобы было понятно, на какой именно стадии выполнения задача находится сейчас, приходится вводить кучу дополнительных статусов вроде «Готова к разработке», «На тестировании» и т.д. Это усложняет схему и применение метрик;
- Невозможно распараллелить действия (например, документирование и тестирование), поскольку задача в данный момент времени может быть назначена только на одного исполнителя;
- Исполнителю, принявшего задачу на последних стадиях (документирование или тестирование), трудно разобраться в текущем статусе, приходится прописывать постановку задачи в комментариях, что неверно методологически;
- При использовании спринтов неудобно планировать длинные задачи в одном талоне, поскольку они обычно выполняются в течение нескольких итераций.
Талон, работа в котором выполняется по схеме «одна задача — один талон», выглядит примерно так (для случая, когда все работы выполняет один работяга Вася Пупкин):
Схема переходов для задачи «одна задача — один талон» (трекер, не мудрствуя лукаво, назван «Задача») упрощенно выглядит так (не считая дополнительных статусов вроде «Обратная связь», «На согласовании» и т.д.):
Новая -> Готова к бизнес-анализу -> Бизнес-анализ -> Готова к системному анализу -> Системный анализ -> Готова к разработке -> Разработка -> Готова к тестированию -> Тестирование -> Готова к документированию -> Документирование -> Готова к внедрению -> Внедрение -> Выполнена -> Закрыта.
Для решения проблем схемы «одна задача — один талон» была разработана схема с созданием отдельных талонов (подзадач) на каждую атомарную деятельность, выполняемую одним исполнителем. Общая постановка в этом случае формируется в родительской задаче (трекер «Общая задача»), а атомарные задачи — как подзадачи. Т.е. функциональная детализация заменена на детализацию жизненного цикла. Назовем такую схему «одна подзадача — один талон».
Талоны по такой схеме выглядят так:
Вынос типа деятельности в название трекера позволяет применить единую схему переходов:
Новая -> В очереди -> В работе -> Выполнена -> Закрыта.
Схема простая, понятная как менеджеру, так и исполнителю, позволяет применять унифицированные метрики и agile-инструменты (например, виртуальные доски со стикерами).
Достоинства схемы «одна подзадача — один талон»:
- Возможность формирования индивидуальной задачи для конкретного исполнителя — снижается риск недопонимания;
- Возможность распараллеливания подзадач — ведь у каждой свой талон и свой исполнитель;
- Можно проставлять точные оценки времени и плановую дату завершения именно для этой подзадачи в независимости от остальных;
- Однообразие и простота схемы переходов;
Отдельно скажу про следующее достоинство: при работе с внутренними службами, а также с аутсорсерами передавать им единый талон по задаче не совсем корректно как с технической, так и с политической точки зрения. Так, если вы отдали на аутсорсинг тестирование, то знать этим ребятам про то, как у вас проходит, например, документирование, совсем необязательно. Аналогично с внутренними службами — у нас, например, сформированы кросспроектные команды по роду деятельности: технические писатели, группа развития продукта. Они не знают особенности реализации того или иного проекта, поэтому им неинтересно разбираться в предыстории, а нужна четко сформированная задача.
Но есть у такой схемы и недостатки:
- Необходимо создавать много талонов в редмайн (5-10 на каждую задачу), навигация по которым в дальнейшем может быть проблематична;
- Если исполнителю необходимо узнать предысторию выполнения задачи, ему необходимо будет искать ее в других талонах;
- Управлять жизненным циклом такой задачи сложнее, поскольку менеджеру придется отслеживать и синхронизировать состояния разных талонов.
К сожалению, в теории все выглядит намного красивее, чем в жизни. Начав работать по двум предложенным схемам, мы быстро поняли, что они не могут существовать отдельно друг от друга, необходимо их комбинировать. Например, в случае, когда команде, работающей по концепции «одна задача-один талон» необходимо передать какую-то подзадачу на аутсорс или во внутреннюю службу. Решение нашлось достаточно просто — в талоне типа «Задача» предложено было при необходимости добавлять подзадачи по схеме «одна подзадача-один талон», который могли выполняться параллельно и не мешали последовательному выполнению остальных подзадач.
Такой талон выглядит следующим образом:
Что же с практикой? Одно из подразделений нашей компании перешло на работу по описанной концепции примерно 3 месяца назад. на текущий момент создано 395 талонов, из них:
- По концепции «одна задача-один талон» 248;
- По концепции «одна подзадача-один талон» 147;
Несмотря на то, что пока с большим отрывом лидирует концепция «одна задача-один талон», цифры показывают, что востребованы оба предложенных инструмента, что не может не радовать.
Есть еще интересные идеи и реализации на тему оперативного планирования в Redmine, вот тут.
Комментарии (10)
kentastik
27.07.2015 21:12А что у вас было до Редмайна? Просто такое ощущение, что ничего…
NeoUser Автор
02.08.2015 12:37Мы достаточно давно использовали Рэдмайн, но не было единой концепции его применения. Т.е. были трекеры типа «Ошибка», «Улучшение», «Консультация» и схемами перехода типа «из любого состояния в любое». С одной стороны, это удобно, поскольку ни руководитель, ни исполнитель никогда не ощущали никаких ограничений в своей работе. С другой стороны, это не позволяло выстроить процесс, когда, например, задача перед началом разработки обязательно должна была пройти через системного аналитика, либо перед закрытием обязательно пройти через тестирование.
Данная схема в первой версии также не имеет совсем жестких ограничений, однако тут есть хотя бы общая идея, которую я описал.
Gamegen
28.07.2015 10:25А Redmine Backlogs не пробовали?
NeoUser Автор
02.08.2015 12:39Спасибо за ссылку. Нет, не пробовали, в ближайшее время посмотрю.
У нас в компании не используют Scrum в чистом виде. Да и я сам не ярый его сторонник, но некоторые возможности, думаю, будут полезны
xzDeveloper
31.07.2015 10:51А я раньше думал, что одна задача не должна превышать по объему работ одного рабочего дня исполнителя задачи…
А тут в одной задаче целый мини-проект.NeoUser Автор
02.08.2015 12:49А откуда взялось ограничение на один день? Я, например, не вижу проблем, если сложная задача на 200 часов разработки будет выполняться в одном талоне. Тут важную роль, на мой взгляд, играет квалификация исполнителя: если это junior, то ему надо давать максимально детализированные и декомпозированные задачи. А опытному сотруднику можно дать и задачу в общем виде, чтобы он решал ее целостно, думал на 2 шага вперед. Консолидация всех комментариев, данных о коммитах (при настроенной интеграции с VCS) в дальнейшем позволит значительно эффективнее восстановить историю работы с задачей.
Но при этом вторая предложенная мной схема позволяет декомпозировать единую задачу разработки на подзадачи типа «Разработка», длительность каждой из которых будет менее 8 часов, если так построен Ваш рабочий процесс.
А тут в одной задаче целый мини-проект.
Действительно, задача типа «Общая задача» может рассматриваться как мини-проект. Опять же, не вижу ничего страшного. если редмайн будет инструментом не только для разработчиков. но и для менеджеров :-) Как минимум, исполнителям это никак не помешает выполнять свои задачи.
Kettariecz
Мне кажется, или итоговая схема комбинирует и минусы двух предыдущих:
1. К задаче надо добавлять много доп полей (кто-то откажется создавать к ней подзадачи и ему надо будет указывать трудозатраты);
2. Каждому следующему разработчику вероятно придется искать историю задачи — если он получил только подзадачу. Или не придется, если ему передали основную задачу.
и т.д. В чем плюсы тогда? Просто в возможности работать так, как удобно на каждый конкретный тикет?
Мы работаем по второй схеме, но не с подзадачами, а со связями между задачами и объединением задач в проекты/версии.
И наконец самый больной вопрос, как вы планируете задачи? Все задачи, которые планируется взять в работу (не зависимо от того, когда работы реально начнутся) вводятся в систему сразу или менеджер/ответственный за проект вводит задачи по мере начала работ с ними? Как исполнитель узнает, что через некоторое время ему придется активно поработать?
NeoUser Автор
Извиняюсь за задержку с ответом — этой мой первый пост, ожидал подтверждения прохождения модерации на почту, а тут оказывается все уже пройдено :-)
По первым двум пунктам, к сожалению, согласен :-(
Плюсы — в универсальности. Предполагается (и в принципе ожидания оправдались), что каждый проект или отдел сможет выстроить удобную для себя схему, применяя предложенный инструмент. И при этом не нужно будет выдумывать совсем индивидуальные схемы для каждого.
Вы имеете в виду, что не используете типы деятельности как трекеры? Или все же используете?
Задачи обычно вводятся сразу, по мере поступления информации. Они образуют бэклог (висят неназначенные в статусе «Новая»). Я считаю, что задачи должны поступать в трекер, как только становится о них известно. поскольку это позволяет оценивать и планировать объем работ.
Мы как раз стараемся исполнителя отгородить от этого. У нас фиксированные рабочий день по 8 часов, и исполнителю всегда будет работа. к чему ему знать размер бэклога? По предложенной схеме исполнитель получает задачи в статусах «В очереди» либо «Готова к <вид деятельности>». Я сторонник коротких недельных спринтов (мы их называем оперативными планами), т.е. каждому исполнителю составляется очередь задач на неделю (набираем суммарную трудоемкость в 32 часа с буфером). Подробнее о том, как реализуем работу с этими оперативными планами, напишу в ближайшее время и выложу сюда ссылку.
Kettariecz
Используем. Суть та же, только названия другие — диагностика, постановка, разработка… А статусы мы используем только чтобы отразить реальное состояние задачи — в работе, в ожидании и т.д. Чтобы показать, что разработка выполняется на базе постановки, а постановка — по итогам какой-то диагностики, — мы используем связи «предыдущая-следующая», «связана с» и «блокирует» между соответствующими задачами.
С бэклогом полностью согласен, но не вижу необходимости скрывать от сотрудника его будущие задачи. Хотя планированием занимаются только руководители. Я как понимаю, у вас не много проектов открыто одновременно и бэклог один?
NeoUser Автор
Нет, проектов как раз много, и на каждом свой бэк-лог, причем достаточно большой (несколько десятков задач).
Вы могли бы сделать скриншот типового талона в Вашем рэдмайне, чтобы понять схему использования?