Управление разработкой в DIRECTUM

Задача

При разработке программного обеспечения результат очень сильно зависит от того, как организован сам процесс. Ошибки, совершенные на ранних этапах, могут привести к серьезным последствиям, начиная от превышения сроков и трудозатрат, заканчивая полным отказом клиента от решения из-за несоответствия заявленным требованиям.

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

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

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

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

• Исходные требования для проектирования.
• Детальное описание реализации, по которому осуществляется разработка.
• Список созданных или измененных компонент в процессе разработки.
• Список пожеланий или дефектов, выявленных на этапе тестирования.

Сборка и хранение пакетов разработки. При выполнении больших доработок очень много времени может быть потрачено на подготовку пакета, не редкость – ситуации, когда в пакет забывают включить все необходимые изменения, что приводит к возникновению различных ошибок.

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

Принимая все эти факторы во внимание, было принято решение разработать собственный инструмент, который полностью покрывает все вышеперечисленные требования, при этом остается простым в использовании и учитывает специфику системы.

Описание и возможности решения

В решении выделено 2 функциональных модуля, направленных на автоматизацию задач процесса разработки ПО.

1. Управление процессом разработки

Модуль предоставляет удобное и единое рабочее пространство для планирования задач, отслеживания текущего состояния и фиксации результатов работ.

Ключевыми справочниками модуля являются:

• Рабочие проекты.
• Спринты.
• Рабочие элементы.

Основная работа происходит в справочнике Рабочие проекты. Карточка записи справочника представляет собой SCRUM-доску с этапами (статусами) и распределенными по ним рабочими элементами, о которых речь пойдет чуть дальше.

Для каждого проекта доступна гибкая возможность настройки:

• Порядок расположения статусов на доске, и начального статуса, в котором будут создаваться все рабочие элементы.
• Цвет заголовка для каждого статуса. Задается с помощью палитры цветов.
• Доступность редактирования рабочих элементов, находящихся в определенном статусе. Возможные значения: «Все участники», «Исполнитель и координатор», «Координатор».
• Необходимость указания исполнителя и при переводе рабочих элементов в определенный статус. Возможные значения: «Обязателен», «Необязателен» и «Не требуется».
• Необходимость уведомления координатора.
• Доступные переходы из статуса. При помощи данной настройки можно выстроить процесс работы с элементами.

Помимо ручной настройки каждого статуса доступно создание жизненного цикла проекта из готовых шаблонов, которые при необходимости можно изменить под конкретные нужды.

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

При работе со спринтами на доске доступно переключение между списками рабочих элементов:

• «Все». Отображаются все рабочие элементы по текущему проекту.
• «Спринт1…Спринт n». Отображаются только рабочие элементы по конкретному спринту.
• «Нераспределенные». Отображаются только рабочие элементы по текущему проекту, которые не связаны ни с одним из спринтов.

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

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

• Заголовок.
• Номер.
• Текущий исполнитель (фото из карточки работника).
• Приоритет.
• Плановые трудозатраты.
• Плановая дата исполнения.

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

Карточка рабочего элемента содержит:

• Основные реквизиты рабочего элемента;
• WYSIWYG редактор, поддерживающий все стандартные возможности для оформления подробного структурированного описания со скриншотами и таблицами.
• Область тегов;
• Список компонент прикладной разработки DIRECTUM, созданных/измененных разработчиками в рамках работы над рабочим элементом. Данный список используется при рецензировании кода, а также при автоматической сборке пакетов разработки по выполненным рабочим элементам, о которой речь пойдет в следующем разделе;
• Историю работы, содержащую информацию обо всех статусах/исполнителях, а также фактических трудозатратах.
• Область переписки, для обсуждений и фиксирования информации в ходе работы: вопросов по разработке, найденных багов при тестировании разработки, комментарии рецензента и т. д.

Изменение статуса рабочего элемента и назначение исполнителя может осуществляться 3-мя способами:

1. Drag & Drop рабочего элемента на доске проекта (для изменения исполнителя без изменения статуса необходимо кликнуть на портрет текущего исполнителя).
2. Действием на ленте в карточке рабочего элемента.
3. Выполнением задания в рамках типового маршрута. Задача запускается автоматически при создании каждого рабочего элемента.

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

 

При работе с рабочими элементами на доске доступны инструменты:

1. Поиск по рабочим элементам, содержащих слова/слово/части слова (не менее 3 символов). Поиск выполняется по следующим реквизитам:

• Заголовок.
• Номер.
• Тэги.
• Текстовое описание.

2. Фильтрация рабочих элементов в рамках выбранного разреза:

• По исполнителю.
• По приоритету.
• По типу.
• По плановой дате завершения.

3. Сортировка рабочих элементов по реквизитам:

• Приоритет.
• Номер.
• Дата регистрации.

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

 

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

Диаграмма содержит два графика:

1. Идеальный (плановый) график. Точки для графика рассчитываются автоматически на основе суммарных трудозатрат рабочих элементов, запланированных на спринт, и общей длительности спринта, с учетом выходных и праздничных дней. Полученное значение является плановой дневной загрузкой, при которой команда сможет завершить все запланированные задачи в срок.
2. Фактический график. Точки графика рассчитываются на основе суммарных фактических трудозатрат команды в каждый из дней.

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

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

2. Автоматизация сборки и хранения пакетов

Модуль призван облегчить жизнь разработчикам при сборке пакетов с прикладной разработкой DIRECTUM и предоставить доступ ко всем собранным пакетам разработки компании.

Включает в себя следующие справочники:

• Прикладная разработка DIRECTUM.
• Релизы разработки DIRECTUM.
• Версии разработки DIRECTUM.
• Пакеты разработки DIRECTUM.
• Базы данных.

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

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

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

Вся работа по настройке состава пакетов разработки и их формированию осуществляется в справочнике Версии разработки DIRECTUM.

Наполнение осуществляется путем выбора существующих компонент и добавления их в табличные разделы на одноименных закладках записи справочника Версии разработки DIRECTUM:

• Табличный раздел «Записи справочников».
• Табличный раздел «Типовые маршруты».
• Табличный раздел «Мастера действий».
• Табличный раздел «Разработка».
• Табличный раздел «Варианты запуска».
• Табличный раздел «Веб-доступ».
• Табличный раздел «Документы».
• Табличный раздел «Прочие файлы».

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

Для быстрого заполнения можно использовать:

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

В качестве инструкции по установке и настройке может выступать документ DIRECTUM или локальный документ.

Решение позволяет также формировать и XML файл с метаданными пакета разработки, который используется в «плагине» автоматического импорта разработки (https://club.directum.ru/award/150127). Внутри метаданных содержится информация по имеющимся зависимостям между пакетами разработки, что полностью исключает возможность случайно перезаписать разработку при установке пакетов в неправильной последовательности.

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

В карточке для редактирования доступен реквизит Тип пакета, который заполняется вручную, следуя следующей логике:

• «Alpha» и «Beta» для пакетов, устанавливаемых во внутреннем тестовом контуре.
• «RC» - для пакетов, передаваемых для тестирования в тестовый контур клиента.
• «RTM» - для пакетов, передаваемых для установки в рабочий контур клиента.

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

Результаты применения решения

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

Планы развития

• Адаптация решения для работы в веб-доступе DIRECTUM.
• Добавление возможности выстраивать связи между рабочими элементами с отрисовкой всего дерева.
• Интеграция в справочник Пакеты разработки DIRECTUM вызова «плагина» автоматического импорта пакета разработки в выбранную базу DIRECTUM.

Будем рады увидеть в комментариях идеи и мысли о том, какие еще задачи из процесса разработки ПО могут быть реализованы в рамках данного технического решения.