Думаю, эта статья должна помочь людям, которые впервые решили автоматизировать процесс трекания задач на базе Redmine в группе разработки программного обеспечения. В статье я расскажу о том, как этот процесс устроен у нас, какие новые поля для задачи мы завели и какие проблемы решают эти поля. Думаю, статья будет полезна широкому кругу лиц, на мой взгляд, настройка жизненного цикла задач эта работа под лозунгом «Очевидное — не очевидно».

Еще! Мы работаем в большой корпоративной среде, в основном, для внутренних клиентов (причем их несколько) и эта ситуация нашла отражение в нашем жизненном цикле.

Начнем.

Все начинается с того, что в один прекрасный момент появляется задача и после своего появления, задача логично должна упасть на автора. Почему?! Потому что у задачи всегда должен быть сотрудник, который отвечает за дальнейшее ее исполнение, тот, кто в данный момент тормозит задачу, тот на чей стороне «мячик», и он должен этот мячик «передать другому», сделать что-то вроде футбольного паса. Иногда этого человека быть не должно. Например, когда больше нет необходимости выполнять действия по задаче, когда она закрыта.

Какую информацию мы просим обязательно заполнить пользователя, создающего задачу?

Ну понятно, это тип задания, заголовок и описание, но еще:

• «Заказчик» – тот сотрудник который заинтересован в данной задаче и запросил ее исполнения. Он же будет впоследствии проверять результат работ, и оценивать исполнение.
• «Цель» – конечная цель, которую должна решить задача. До этого поля мы не сразу дошли. С одной стороны, зачем нужна цель, если есть подробное описание, в котором написано, что сделать?! Но если подумать, то цель это совсем другое. Описание задачи говорит о том, что нужно сделать, чтобы достигнуть цели и если цель не фиксировать, то в процессе выполнения задачи, цель может потеряться, и сделается не совсем то и не совсем так, как нужно.

Например, цель может быть такой:
«Реализовать возможность расчёта базовой части ЗП на основе произвольной математической формулы».

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

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

Куда может отправиться новая задача?

Чаще всего она отправляется в план, поскольку у нас часто возникают приоритетные задачи (ну вот такая вот клиент ориентированность и нежелание заказчиков думать о будущем).

Но бывает так, что задача не приоритетна и тогда она может отправиться в очередь (или Backlog, кому как больше нравится).

Если задача отправляется в план, то мы обязательно просим заполнить у нее следующие поля:

• «Оценка времени» – сколько, по мнению руководителя разработки, данная задача займет чистого времени работы программиста. Практически никогда нельзя точно определить это значение. Но нужно определять примерно. Потому что это время — на самом деле цена вопроса, т.е. это не время, это деньги, за которые заказчик покупает исполнение этой задачи у группы разработки.
• Дату начала и дату выполнения. Тут вроде все логично. Еще у нас, когда программист необоснованно просаживает задачку по срокам, то у него это влияет на ЗП.
• «Этап» – тот же план или версия или спринт, в который планируется выполнить задачу. У нас этапы совпадают с месяцами. По этапам и исполнителям мы контролируем ход выполнения работ.
• «На ком» – сотрудник ответственный за исполнение задания.

В момент постановки в план в поле задачи «Исполнитель» всегда копируется значение из поля «На ком». Задача рано или поздно уйдет с сотрудника ответственного за исполнение, но ответственность за исполнение уйти не должна, поэтому у каждой выполненной задачи всегда сохраняется исполнитель.

А если в очередь, то полей меньше:

• «Приоритет», что бы потом из очереди первыми вытягивать более приоритетные задачи.
• «Оценка времени», что бы можно было определиться, что влезет в будущий план, а что нет.

Ну и конечно, задача из очереди всегда может попасть в план, а может закрыться и получить статус «Закрыта». Статус «Закрыта» принципиально отличается от «Выполнена» тем, что по задаче не проводились работы.

Что исполнитель может сделать с задачей?

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

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

Конечно главная функция для исполнителя это возможность отправки задачи на проверку и одноимённая кнопка «На проверку». Кнопка отправляет задачу тестировщику, что должен заполнить программист:

• Поле «Как проверить» – удивительно простая и полезная вещь. Про это поле я впервые прочел в какой-то книжке по «Scrum». Программист, сдавая задачу на проверку, должен написать тестировщику и конечному заказчику, что нужно сделать, что бы воспользоваться новыми возможностями: какую ветку из репозитория взять, какие настройки сделать, куда пойти в интерфейсе и что потыкать. В результате, уходит масса ненужных вопросов у тестировщика, заказчика и руководителя группы.
• Поле «Что сделано». Программист не всегда делает то, что первоначально написано в описании к задаче. Иногда делает что-то дополнительно, иногда программисту дается свобода действий в исполнении. Через это поле программист сообщает руководителю, заказчику и тестировщику, что конкретно он сделал в результате выполнения. Помимо прочего, у нас внедрена денежная мотивация на основе оценок задач заказчиком и в этом поле программист может обратить дополнительное внимание заказчика на особенности выполнения задачи, которые могут привести к повышенной оценке.
• Поле «На ком» – тестировщик, который будет проверять задачу.
• Галочка «Я выложил задачу на тестовый сервер». Без заполнения этого поля нельзя отправить задачку на проверку. У тестировщика есть свой тестовый сервер для проверки задач, но прежде чем скидывать задачу на проверку программист должен выложить ее в рабочем состоянии на тестовый сервер. Прежде всего, для того что бы руководитель смог оценить качество исполнения задачи и ему не приходилось лишний раз просить выложить задачу на тестовый сервер или делать это самому.

После отправки задачи на проверку, ее статус логично изменяется на «На проверке». Теперь за дальнейшее исполнение задачи отвечает тестировщик.

Что тестировщик может сделать с задачей?

Ну, понятно: отправить задачку на доработку (кнопка «Вернуть обратно») или пропустить дальше на production-сервер (кнопка «Проверено»).

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

Для чего проверка руководителя нужна:

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

В любом случае, переход задачи из статуса «На проверки» в следующий статус «В эксплуатации» сопровождается заполнением кучки полей.

• «Оценка проверки» и «Пояснение к оценке проверке». Оценку может ставить тестеровщик или руководитель. Эта оценка позволяет влиять на ЗП программиста, в том числе.
• «Желаемая дата выкладки». Когда было бы здорово выложить задачку на production-сервер (за выкладку в нашей группе отвечает отдельный человек).
• «Требует оповещения». Требуется ли оповещать сотрудников о доступности нового функционала или чем-то еще. Если требуется, то тестеровщик обязан сделать это перед выкладкой.
• «Презентация». Когда задача будет презентована заказчикам (эта интересная процедура, но о ней в другой статье расскажу).

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

• Я проверила отсутствие рекурсивных и циклических SQL-запросов через RaсkMiniProfiler.
• Я проверила верстку на различных разрешениях браузера.
• Я проверила верстку и работоспособность в различных браузерах последних версий (Chrome, Firefox, Opera, Intenet Explorer).
• Я проверила работоспособность плагина на различных базах данных (MS SQL server, MariaDB, PostgreeSQL).
• Я проверила исполнение задания на соответствие фундаментальным правилам «Фундаментальные правила написания плагинов к «Redmine»».
• Я проанализировала необходимость оповещения сотрудников холдинга. Отметила необходимость оповещения в задаче.
• Я проанализировала необходимость обновления информации в инструкциях (в случае необходимости завела задачу).
• Задача выложена на тестовый сервер.
• Заведены задачи на написание автотестов.

Вот такая вот не простая процедура проверки.

Что может сделать с задачей администратор Redmine?

Он может выложить ее на рабочий сервер, тем самым переведя задачу из статуса «На проверки» в статус «В эксплуатации». Задача назначается на заказчика.

Что может сделать с задачей заказчик?

Заказчик может принять работу или не принять. Если не принял, то он отправляет задачу на перепроверку тестеровщику, написав комментарий. Если принял, то жмет кнопочку «Выполнено» и проставляет оценку выполнения и пояснение к оценке. Эти оценки влияют на ЗП исполнителя и руководителя.

В совокупности получается вот такая вот схема жизненного цикла задачи.

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

Конечно это не все, что у нас есть в жизненном цикле задач, но если бы я писал про все, то наверное маленькая книжечка получилась бы.

Буду рад, если вы поделитесь информацией о том, какой жизненный цикл используется у вас? Какие поля вы просите заполнить сотрудников когда трекаете задачу и почему?

Спасибо всем кто дочитал до конца.

Автор: tdvsdv

Источник