- PVSM.RU - https://www.pvsm.ru -
Думаю, эта статья должна помочь людям, которые впервые решили автоматизировать процесс трекания задач на базе Redmine в группе разработки программного обеспечения. В статье я расскажу о том, как этот процесс устроен у нас, какие новые поля для задачи мы завели и какие проблемы решают эти поля. Думаю, статья будет полезна широкому кругу лиц, на мой взгляд, настройка жизненного цикла задач эта работа под лозунгом «Очевидное — не очевидно».
Еще! Мы работаем в большой корпоративной среде, в основном, для внутренних клиентов (причем их несколько) и эта ситуация нашла отражение в нашем жизненном цикле.
Начнем.
Все начинается с того, что в один прекрасный момент появляется задача и после своего появления, задача логично должна упасть на автора. Почему?! Потому что у задачи всегда должен быть сотрудник, который отвечает за дальнейшее ее исполнение, тот, кто в данный момент тормозит задачу, тот на чей стороне «мячик», и он должен этот мячик «передать другому», сделать что-то вроде футбольного паса. Иногда этого человека быть не должно. Например, когда больше нет необходимости выполнять действия по задаче, когда она закрыта.
Ну понятно, это тип задания, заголовок и описание, но еще:
Например, цель может быть такой:
«Реализовать возможность расчёта базовой части ЗП на основе произвольной математической формулы».
А в описании будут более детальные ключевые шаги и требования для достижения цели. Например, «подключение библиотеки MathML, возможность связывания формулы с расчетным периодом» и т.д.
В общем случае, описание вообще может зависеть от квалификации исполнителя и в некоторых случаях может быть всего в пару строк (если у вас хорошая коммуникация с исполнителем, вы сработались и хорошо друг друга понимаете).
Чаще всего она отправляется в план, поскольку у нас часто возникают приоритетные задачи (ну вот такая вот клиент ориентированность и нежелание заказчиков думать о будущем).
Но бывает так, что задача не приоритетна и тогда она может отправиться в очередь (или Backlog, кому как больше нравится).
Если задача отправляется в план, то мы обязательно просим заполнить у нее следующие поля:
В момент постановки в план в поле задачи «Исполнитель» всегда копируется значение из поля «На ком». Задача рано или поздно уйдет с сотрудника ответственного за исполнение, но ответственность за исполнение уйти не должна, поэтому у каждой выполненной задачи всегда сохраняется исполнитель.
А если в очередь, то полей меньше:
Ну и конечно, задача из очереди всегда может попасть в план, а может закрыться и получить статус «Закрыта». Статус «Закрыта» принципиально отличается от «Выполнена» тем, что по задаче не проводились работы.
Две спорные, но имеющие право на жизнь функции: «приступить» и «приостановить», которые соответственно меняют статус задачи из «Назначено» в «В работе» и наоборот. В малых группах эта функция не особо прижилась, а в некоторых больших прижилась. Если программистов много и они помечают задачи, которые исполняют в текущий момент, то можно строить срез по тем задачам, которые в текущий момент в работе у исполнителей (своего рода «Work in Progress»).
Почти в любом статусе сотрудник, на котором в текущий момент задача может запросить информацию у автора, руководителя, заказчика и т.д. Конечно, исполнитель не исключение.
Конечно главная функция для исполнителя это возможность отправки задачи на проверку и одноимённая кнопка «На проверку». Кнопка отправляет задачу тестировщику, что должен заполнить программист:
После отправки задачи на проверку, ее статус логично изменяется на «На проверке». Теперь за дальнейшее исполнение задачи отвечает тестировщик.
Ну, понятно: отправить задачку на доработку (кнопка «Вернуть обратно») или пропустить дальше на production-сервер (кнопка «Проверено»).
Еще он может изменить проверяющего (и одноименная кнопка), и в нашей группе административно закреплено, что задачи должны проходить вторую проверку через руководителя (в других группах нет).
Для чего проверка руководителя нужна:
В любом случае, переход задачи из статуса «На проверки» в следующий статус «В эксплуатации» сопровождается заполнением кучки полей.
Еще есть куча галочек для проверки перед отправкой задачи в рабочую среду. Перечислю их, вдруг кому-то будет полезно:
Вот такая вот не простая процедура проверки.
Он может выложить ее на рабочий сервер, тем самым переведя задачу из статуса «На проверки» в статус «В эксплуатации». Задача назначается на заказчика.
Заказчик может принять работу или не принять. Если не принял, то он отправляет задачу на перепроверку тестеровщику, написав комментарий. Если принял, то жмет кнопочку «Выполнено» и проставляет оценку выполнения и пояснение к оценке. Эти оценки влияют на ЗП исполнителя и руководителя.
В совокупности получается вот такая вот схема жизненного цикла задачи.
На ней переходов между статусами гораздо больше, чем описано в статье. В большинстве своем это привилегированные переходы для руководителя, когда ему административно нужно перевести задачу в следующее состояние не дожидаясь тестеровщика или программиста.
Конечно это не все, что у нас есть в жизненном цикле задач, но если бы я писал про все, то наверное маленькая книжечка получилась бы.
Буду рад, если вы поделитесь информацией о том, какой жизненный цикл используется у вас? Какие поля вы просите заполнить сотрудников когда трекаете задачу и почему?
Спасибо всем кто дочитал до конца.
Автор: tdvsdv
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/plugins/63277
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/227507/
Нажмите здесь для печати.