Сегодняшний пост будет не про 1С, а про регистрацию и проработку задач. Как я писал в прошлый раз, мы используем систему RedMine http://www.redmine.org/. Сразу хочется сказать, что описанная ниже система жизненно необходима для команды разработки численностью больше 5-6 человек. Для одного-двух разработчиков можно, наверное, использовать и более простые способы (задачи Outlook, Excel-таблицу, листок бумаги )))). Но, честно, я бы даже для пары человек предпочел запустить автоматизированную систему, сделать это не сложно, а для грамотного управления незаменимо.
Внешний вид задачи в системе RedMine выглядит следующим образом:
И сегодня я хочу описать поля, которые мы используем в работе. Ниже представлены основные атрибуты, которые используются для работы над задачей как со стороны бизнеса, так и со стороны ИТ:
- Тип задачи (Трекер): может принимать следующие значения (пункт (1) на картинке):
- HD (ошибка) – ошибка работы в системе, которая требует оперативного устранения. В зависимости от приоритета, на решение задачи отводится определенное время (в соответствии с SLA).
- CR (новая функциональность) – название говорит само за себя.
- FS (поддержка) – обычно задачи не требующие изменения кода (помочь пользователю в ответе на вопрос, сделать разовую выгрузку и т.д.)
- DE (изменение данных) – изменение данных в системе с помощью обработок.
- IR (внутренние запросы ИТ) – задачи по оптимизации работы, оптимизации процессов и т.д.
- Тема: название запроса, кратко и информативно отражает суть проблемы.
- Описание: развернутое описание возникшей проблемы и/или ожидаемой функциональности.
- Статус: отражает текущее состояние задачи. Статус может принимать следующие значения:
- Новая – начальный статус для всех задач.
- Не согласована – задача не подтверждена соответствующим Владельцем Бизнес Процесса.
- Согласована, нет анализа – задача согласована Владельцем Бизнес Процесса, но не выполнена оценка трудоемкости реализации на стороне ИТ.
- Готова к работе – предварительный анализ задачи завершён, произведена оценка трудоемкости.
- В работе – разработчик начал работу над задачей.
- Решена – разработчик завершил разработку и тестирование на стороне ИТ. Подготовлен тестовый план и отправлен бизнесу на тестирование.
- Протестирована – тестирование со стороны бизнеса успешно завершено.
- Закрыта – задача исполнена и перенесена в рабочую среду.
- Отменена – задача отменена.
- Отложена – задача отложена.
- Приоритет: может принимать четыре указанных ниже значения. Вводить большее число приоритетов с моей точки зрения нецелесообразно.
- Низкий
- Средний
- Высокий
- Критический
- Назначена: ответственный разработчик за выполнение задачи, заполняется в момент планирования задачи.
- Инициатор задачи: постановщика задачи.
- DeadLine: дату, к которой данная задача должна быть решена. Заполняется постановщиком и фактически является его пожеланием по дате выполнения запроса.
- Дата выполнения: планируемая дата передачи задачи на тестирование. Заполняется в момент планирования задачи.
- Оценка времени: планируемая трудоемкость задачи в часах.
- Затраченное время: сколько времени в часах было потрачено на реализацию задачи.
Так же мы используем атрибуты задачи, которые предназначены только для внутренних процессов ДИТ, а именно:
- Приоритет работ – текстовое поле, которое добавляет еще одно измерения для разбивки задач. Используется для долгосрочного планирования задач (распределения задач поддержки на несколько месяцев вперед), для выделения подпроектов, проектов. По факту одного поля достаточно, чтобы в нем гибко закодировать возможность разнообразного анализа задач по измерениям в отчетности.
- % участия – предназначен для установки % времени, которое разработчик будет тратить в день на задачу. Заимствован из MS Project и предназначен для оперативного планирования рабочего времени. По умолчанию считает равным 80%, так же используется значение 50%, реже 25%.
- Review Date, Review Responsible, Review Comments – используются для контроля незакрытых задач, делают более гибкой систему мониторинга подвисших задач.
- Delpoy Status, Deploy Comments – предназначены для работы с протестированными задачами в рамках процедуры переноса в рабочую среду. ПолеDeploy Statusсодержит следующие значения:
- Отправлено на выкладывание – выставляется в момент успешного тестирования задачи разработчиком.
- Готово к выкладыванию – задача не заблокирована другими задачами и оформлена в соответствии с процедурой.
- Внесено в конфигурацию раб. среды – изменения внесены в конфигурацию рабочей 1С (для внешних обработок выполнен Merge в ветку рабочей среды).
- Перенесено в рабочую среду – понятно без комментариев ))).
- Заблокирована – используется для отображения задач, изменения по которым заблокированы не протестированными задачами.
Вся приведенная выше структура затем переносится в специальную базу данных на SQL Server – так как для быстрого формирования отчетности требуется определенная структура таблиц. Данный процесс останется вне рамок данной серии статей, так как он относится только к грамотному проектированию баз данных и умению писать запросы на T-SQL. Результатом же являются приведенные ниже отчеты, которые отражают большинство сторон процесса разработки:
- ProjectCapacityReport (распределение часов по разработчикам по дням): http://borisfrolov.com/2012/10/14/every-dayevery-week-planning-task-capacity-report/
- Aging Report (подвисшие задачи): http://borisfrolov.com/2012/10/21/aging-report/
- BugReport (отчеты по ошибкам): http://borisfrolov.com/2012/12/18/how-we-track-bugs-in-tfs-common-reports/
- SLAReport (отчет о выполнении уровня сервиса) – опишу в будущем.
В следующем посте будет описан блок по переносу хранилища в единую базу отчетов и связь всех изменений в хранилище с задачами.