Как Автоматически Создать Отчет О Выпуске

Сегодня мы расскажем, как автоматизировать создание заметок о выпуске на основе импорта данных из систем отслеживания TFS, Redmine и JIRA и из системы управления проектами Microsoft Project Server.



Статья будет интересна в первую очередь менеджерам ИТ-проектов.

В чем проблема?

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

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

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

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

Вот тут и возникли проблемы.

Проблема 1: Ошибки.

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

Сбор огромного отчета по ним занял много времени, а сделать все отчеты проверенными на 100% помешал человеческий фактор.

Проблема 2. Непоследовательность в дизайне.

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

Что мы получили после автоматизации?

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

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

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

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

В нем вся информация разделена по категориям и к каждому элементу прикреплена ссылка, ведущая на соответствующую страницу трекера.

Вот как выглядят готовые выпущенные примечания к выпуску:

В Ворде такой документ занял бы 11 страниц.

А создание его в приложении заняло всего около 2 минут. Но главное не в экономии времени, а в том, что мы уверены в точности данных.

Управленческие бонусы

1. Исправлены ошибки в отчетах о релизах.

   Теперь клиент оперативно получает 100% проверенные примечания к выпуску.

2. Мы стандартизировали форматирование отчетов о релизах.

   Теперь наши примечания к выпуску выглядят как красиво оформленные html-файлы в фирменном стиле.

3. Улучшено качество управления проектами в трекерах.

   Чтобы релиз-ноты могли быть составлены одним нажатием волшебной кнопки, руководитель проекта должен поддерживать в трекере идеальный порядок.

   Приятный бонус при этом – автоматическое заполнение отчета.

   Конечно, мы затеяли автоматизацию не для экономии 1 часа рабочего времени.

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

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

   Некоторым клиентам наш html-файл с отчетом показался настолько удобным, что они попросили сделать аналогичный шаблон, в котором можно было бы редактировать отчет, чтобы отправить полный отчет или его части с комментариями новым получателям.

Автоматизация шаг за шагом

Теоретически для автоматизации подготовки релизноутов можно было использовать плагины для трекеров, в которых мы работаем (TFS, Redmine и JIRA).

А вот плагины для TFS и Redmine оказались неудобными.

А для сборки единого отчета сразу с двух-трех трекеров вообще не было готового решения.

Поэтому нам пришлось создавать свои собственные.

Шаг 1. Навели порядок в трекерах: ввели единые стандарты для проектных менеджеров, по которым они ведут проекты.

Для интеграции трекеров необходимо было провести работу по внедрению единых стандартов для всех трекеров.

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

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

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

Шаг 2. Хранилище собранных данных на основе данных трекеров и MS Project Server.

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

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

Подробнее об этом мы уже написали .

Для сбора данных мы использовали Службы интеграции SQL Server (SSIS) .

Данные из трех систем отслеживания (TFS, Redmine, JIRA) и Microsoft Project собираются в единое хранилище данных.

Сначала загружаем данные из Microsoft Project.



Вот так выглядит скрипт загрузки проекта с информацией о заказчике и руководителе проекта.

   

 SELECT proj.PROJ_NAME AS ProjectName
       ,proj.PROJ_UID as ProjectUID
       ,CT.Customer      
       ,PCC.CostCenter 
       ,PP.ProjectAccount
       ,pr_owner.RES_NAME AS ProjectOwner
       ,pr_owner.RES_UID as OwnerResourceNameUID
       ,CASE WHEN PPS.ProjectStatus IS NULL THEN 'Undefined' ELSE PPS.ProjectStatus END AS ProjectStatus
 FROM (SELECT PROJ_UID
                ,PROJ_NAME
                ,WRES_UID
     FROM pub.MSP_PROJECTS
     UNION SELECT 'E38038FA-F8CA-47D1-BFD4-6B45B8462972' AS Expr1
                 ,'Administrative' AS Expr2, NULL AS Expr3) AS proj                          
     LEFT OUTER JOIN pub.MSP_RESOURCES AS pr_owner ON pr_owner.RES_UID = proj.WRES_UID
     LEFT OUTER JOIN
             (SELECT     pspPrjCFV.PROJ_UID
                 ,psLV.LT_VALUE_TEXT AS Customer
                     FROM ProjectWebApp_PSWA.pub.MSP_PROJ_CUSTOM_FIELD_VALUES AS pspPrjCFV
                     INNER JOIN ProjectWebApp_PSWA.pub.MSP_CUSTOM_FIELDS AS pspCF ON pspCF.MD_PROP_UID = pspPrjCFV.MD_PROP_UID
                     LEFT JOIN ProjectWebApp_PSWA.pub.MSP_LOOKUP_TABLE_VALUES AS psLV ON psLV.LT_STRUCT_UID = pspPrjCFV.CODE_VALUE
                     WHERE (pspCF.MD_PROP_NAME = 'Customer')
             ) AS CT ON CT.PROJ_UID = proj.PROJ_UID
     LEFT OUTER JOIN
             (SELECT pspPrjCFV.PROJ_UID, psLV.LT_VALUE_TEXT AS CostCenter
                     FROM pub.MSP_PROJ_CUSTOM_FIELD_VALUES AS pspPrjCFV
                     INNER JOIN pub.MSP_CUSTOM_FIELDS AS pspCF ON pspPrjCFV.MD_PROP_UID = pspCF.MD_PROP_UID
                     LEFT OUTER JOIN     pub.MSP_LOOKUP_TABLE_VALUES AS psLV ON psLV.LT_STRUCT_UID = pspPrjCFV.CODE_VALUE
                     WHERE (pspCF.MD_PROP_NAME = 'Cost_Center')
             ) AS PCC ON PCC.PROJ_UID = proj.PROJ_UID
     LEFT OUTER JOIN
             (SELECT pspPrjCFV.PROJ_UID, pspPrjCFV.TEXT_VALUE AS ProjectAccount
                     FROM pub.MSP_PROJ_CUSTOM_FIELD_VALUES AS pspPrjCFV
                     INNER JOIN pub.MSP_CUSTOM_FIELDS AS pspCF
                     ON pspPrjCFV.MD_PROP_UID = pspCF.MD_PROP_UID
                     WHERE (pspCF.MD_PROP_NAME = 'Project Account')
             ) AS PP ON PP.PROJ_UID = proj.PROJ_UID
             LEFT OUTER JOIN
                     (SELECT pspPrjCFV.PROJ_UID, psLV.LT_VALUE_TEXT AS ProjectStatus
                 FROM pub.MSP_PROJ_CUSTOM_FIELD_VALUES AS pspPrjCFV
                         INNER JOIN  pub.MSP_CUSTOM_FIELDS AS pspCF ON pspPrjCFV.MD_PROP_UID = pspCF.MD_PROP_UID
                         LEFT OUTER JOIN pub.MSP_LOOKUP_TABLE_VALUES AS psLV
                         ON psLV.LT_STRUCT_UID = pspPrjCFV.CODE_VALUE
                 WHERE (pspCF.MD_PROP_NAME = 'Project Status')
                     ) AS PPS ON PPS.PROJ_UID = proj.PROJ_UID

   

И мы начинаем собирать данные из систем отслеживания.

Данные собираются по-разному для каждой системы.

Как уже писалось в Эта статья , для Redmine и TFS мы написали представления, которые возвращают нам все необходимые данные.

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

Но это другая история.

После загрузки данных с трекеров нужно заполнить «пробелы» в таблицах проектов и сотрудников.

Эти пробелы возникают из-за того, что не все проекты и сотрудники включены в Microsoft Project в силу каких-то обстоятельств (либо не успели их создать, либо так сложилось исторически).

Недостающие данные сразу видны в отчете из OLAP-куба, они помечаются в отдельном столбце как Mismatch, и их можно сразу обработать и привести в порядок.

Далее осталось собрать все воедино.

Собираем список задач.

И заполняем таблицу фактов (кто, где и сколько времени провел).

После этого мы создали Job, который выполняет пакет SSIS каждые 3 минуты.

И в итоге наше Хранилище Данных готово.

Тогда с ним можно будет сделать кучу полезных вещей.

Например, собрать из него OLAP-куб для построения отчетов, или взять данные для Release Notes, или использовать его для построения графика отпусков (да-да, об этом мы вам еще скоро расскажем).

Шаг 3. Создали красивые заметки о выпуске нашей мечты.

Шаг 4. Создали веб-приложение, которое на основе данных Хранилища данных создает единый html-документ с отчетом для заказчика.

Шаг 5. Проект не останавливается.

И мы думаем о том, какие трудозатраты и бизнес-процессы еще можно оптимизировать.

Теги: #примечания к выпуску #Redmine #tfs #Jira #сервер Microsoft Project #sql #olap #отчеты #бизнес-аналитика #управление проектами #коммуникации с клиентами #управление разработкой #управление проектами

• Почему Найм Агентства Цифрового Маркетинга Является Экономически Эффективной Мерой, Которую Вы Можете Предпринять

  19 Oct, 24

• Не Становитесь Жертвой Мошенничества С Оплатой Опросов

  19 Oct, 24

• Американская Онлайн-Платформа Для Дизайна И Обустройства Дома Houzz Запускается В России

  19 Oct, 24

• Шелкопряд Поможет Обеспечить Информационную Безопасность

  19 Oct, 24

• Новые Мониторы Lg Ultrawide

  19 Oct, 24

• Jtag Только Для Красоты Или Он Для Чего Нужен?

  19 Oct, 24

• Онлайн-Покер Становится Социальным

  19 Oct, 24

• Деревянные Игрушки, Часть Четвертая - 1990 Г.

  19 Oct, 24

• Миллион Долларов За Идею

  19 Oct, 24

• Автотесты — Дело Хозяйское

  19 Oct, 24