Решение Rational для совместного управления жизненным циклом (Collaborative Lifecycle Management - CLM) представляет собой набор гладко интегрированных приложений, которые работают как единая платформа управления всем жизненным циклом проектов разработки ПО. CLM помещает в хранилище данных для целей отчетности информацию о приложении, которое группа создает в ходе своих проектов, и его жизненном цикле. Эта статья знакомит читателя с новыми возможностями и отчетами, которые собирают данные из разных приложений, проектов и даже из разных планов, позволяя настроить панели мониторинга, демонстрирующие состояние всего портфеля проектов.
JRS предоставляет новый набор готовых отчетов в виде гаджетов OpenSocial для панелей мониторинга. Эти отчеты относятся к совместному управлению жизненным циклом приложений по нескольким проектам с использованием данных из взаимосвязанных артефактов по управлению изменениями и конфигурацией приложений (Change and Configuration Management - CCM), управлению их качеством (QM) и управлению требованиями к приложениям (RM). Приложение JRS, которое отображает эти отчеты, легко развернуть отдельно или в рамках готового решения Rational для сервера приложений Collaborative Lifecycle Management (CLM). Приложение JRS обеспечивает интеграцию с панелями мониторинга Collaborative Lifecycle Management посредством общего каталога виджетов. После установки CLM пользователи получают каталог виджетов, содержащий 21 отчет. Эта статья знакомит читателя с некоторыми из этих новых отчетов и сценариями их использования.
Начало работы с галереей панели мониторинга
После установки и настройки Jazz Reporting Services и его интеграции с серверами CLM пользователи немедленно получают доступ к новому набору отчетов для своих панелей мониторинга. Чтобы открыть галерею, нажмите кнопку Add Widget и выберите новый каталог Jazz Reporting Services. Просмотрите галерею отчетов. Эскизы рядом с каждым отчетом указывают на несколько видов графических отчетов, включая таблицы. Щелкните на имени отчета, чтобы увидеть его подробное описание, как показано на рисунке 1.
Рисунок 1. Галерея отчетов JRS на панели мониторинга CLM
Добавив отчет на панель мониторинга, вы получите запрос для уточнения параметров, которые ограничивают область охвата отчета теми проектами и этапами разработки, которые вас интересуют и к которым у вас есть доступ. Выбранные фильтры сохраняются вместе панелью мониторинга, и их можно отредактировать в любое время, нажав кнопку Filter или Edit.
В следующих разделах приведены несколько примеров отчетов для различных сценариев использования. Данные, приведенные в этих примерах, относятся к упрощенной умозрительной демонстрации и не являются отражением полноценного использования в реальных условиях.
Просмотр хода проектов с помощью межпроектных отчетов
Те, кто уже работал с отчетами CLM, знают, что все отчеты, предоставляемые CLM, ограничены областью одного проекта. Даже те отчеты, которые обеспечивают прослеживаемость между жизненными циклами проектов CLM, начинаются с выбора области одного проекта управления качеством, изменениями конфигурацией или требованиями, из которой потом прослеживаются области связанных проектов. Отчеты JRS обычно охватывают несколько проектов; они позволяют сравнивать данные по разным проектам, группам или планам.
Тех, кто реализует программу из нескольких проектов или выпусков, охватывающую несколько приложений или компонентов, которые разрабатываются несколькими группами одновременно, заинтересуют общие обзорные отчеты о состоянии этих выпусков. Эти отчеты можно наполнить более подробной информацией, чтобы сравнить конкретные аспекты параллельных выпусков. Например, может потребоваться сравнение того, как каждая группа набирает баллы историй в текущей итерации или как она выполняет устранение дефектов. Отчет о состоянии выпуска, показанный на рисунке 2, содержит краткий обзор хода проекта.
Рисунок 2. Отчет о состоянии выпуска, в котором сравниваются баллы историй для разных компонентов приложения
В примере, приведенном на рисунке 2, данные по текущей итерации разработки четырех приложений, которые разрабатываются в рамках одной и той же программы и выпускаются вместе как единый комплекс приложений, развернуты до уровня выпуска. Этот отчет посвящен подсчету полного числа историй в текущих итерациях разработки. При наведении курсора на диаграмму на панели мониторинга отображается точное число, соответствующее каждому столбику.
На рисунке 3 показан второй отчет с использованием точно такого же запроса к данным, но с более детальным представлением результатов этого запроса в виде таблицы. Этот отчет также подсчитывает число открытых и закрытых историй, но разбивает эти данные по группам разработчиков. В нем также добавлено количество дефектов, исправленных каждой группой, и показано, сколько осталось открытых дефектов. Это представление позволяет увидеть количество дефектов, влияющих на выполнение обычных историй.
Рисунок 3. Таблица состояний выпусков с добавлением числа дефектов и разбивкой по группам
Чтобы еще больше углубиться в ход разработки этих выпусков приложений, воспользуемся другим отчетом с еще более подробной разбивкой. Отчет Iteration Health, представленный на рисунке 4, помимо учета выполненной работы, показывает даты каждой итерации и оставшееся число дней разработки.
Рисунок 4. Отчет Iteration Health с разбивкой хода итераций
Отчет Team Velocity, представленный на рисунке 5, - еще один детализированный отчет, в котором рассматривается одна группа разработчиков одного выпуска приложения. В нем прослеживаются тенденции накопления баллов выполненных историй по в каждой итерации. На рисунке 5 видно, что группа, работающая над приложением Mobile Banking 1.6, уже завершила работу над историями в 36 баллов, и до этапа Sprint 1 ей осталось 8 баллов. Столбик Sprint 2 указывает на то, что на следующую итерацию, Sprint 2, уже запланировано 37 баллов. Он даже показывает размер незавершенной работы по продукту.
Рисунок 5. Отчет Team Velocity показывает процесс выполнения баллов истории от одной итерации до другой
Отслеживание объема работы в итерации и creep-функции
Помимо отслеживания хода запланированной работы группами разработчиков, JRS предоставляет отчеты для отслеживания объема работ по итерации. Выражаясь в терминах метода scrum, если группа разработчиков ценит стабильность своих незавершенных спринтов, то она должна следить за элементами, которые добавляются или удаляются во время итерации. JRS предоставляет для этого два отчета.
На рисунке 6 показан отчет Scope Added, в котором перечислены элементы, добавленные в текущую итерацию выбранного периода разработки области проекта после начала итерации. Так как в таком списке не обязательно показывать элементы всех типов (например, можно исключить недавно обнаруженные препятствия или дефекты), то для указания типов, которые нужно отслеживать, можно использовать фильтр Work Item Type. В примере отчетов показаны три элемента истории, добавленные к текущей итерации спринта 2 (1.6). Для каждого элемента указан размер, дата создания и из какой итерации он добавлен: вновь созданной истории, истории, перенесенной из другой итерации, или из незавершенных работ.
Рисунок 6. Отчет Scope Added отслеживает элементы, добавленные в ходе итерации
Отчет Scope Removed дает противоположную информацию, используя те же фильтры. Он показывает, какие типы элементов были удалены из текущей итерации за выбранный период разработки области проекта. Как показано на рисунке 7, в нем указаны итерации (например, следующая итерация или незавершенная работа по продукту), в которые были перемещены элементы.
Рисунок 7. Отчет Scope Removed показывает элементы, удаленные из текущей итерации
Поиск зависимостей и блокировок
Члены и руководители составной группы, которая разрабатывает сложные приложения, состоящие из взаимозависимых компонентов или интегрированных приложений, должны сразу же видеть, когда проблемы одной из групп блокируют работу других. В приложении CCM CLM можно создавать блоки взаимоотношений между элементами работы, такими как дефекты. Затем каждая группа может использовать отчет Team Dependencies, показанный на рисунке 8, чтобы доказать, что в данный момент она заблокирована другой группой.
Рисунок 8. Отчет Team Dependencies, показывающий дефекты другой группы
Отчет Team Dependencies показывает только те элементы работы, которые связаны отношениями блокирования, когда взаимосвязанные элементы относятся к двум разным группам. Отчет фильтруется путем выбора области группы. Область группы соответствует группе, к которой относятся заблокированные элементы, указанные в отчете в порядке степени их серьезности. Кроме того, для каждого из этих заблокированных элементов работы показаны блокирующие элементы и соответствующие им группы.
К заблокированным элементам относятся элементы работы, но это могут быть и дефекты, обнаруженные при выполнении тестов управления качеством, блокирующие завершение теста. В отличие от отчета Team Dependencies, который показывает, как группа разработчиков блокируется дефектами, относящимися к другим группам, в отчете Blocking Work Items, представленном на рисунке 9, перечислены все элементы работ выбранной группы, которые блокируют выполнение работ другими группами (включая группу тестирования). Этот отчет показывает элементы работы текущей группы, которые удовлетворяют одному из следующих условий:
- серьезность дефекта - блокирующий;
- дефект связан с записью выполнения блокирующего теста в QM.
Рисунок 9. Отчет Blocking Work Items показывает заблокированные элементы группы
Оценка влияния дефектов
В предыдущем разделе описаны отчеты JRS, отражающие блокирующие дефекты, которые непосредственно влияют на способность группы выполнять работы. Чтобы получить представление об общей картине дефектов и о том, как они влияют на соблюдение требований для данной итерации, или чтобы увидеть, как дефекты влияют на выполнении регрессивных тестов в этой итерации, выберите один из следующих отчетов. Каждый из этих отчетов можно вывести на панель мониторинга в виде списка или линейчатой диаграммы.
- дефекты в порядке приоритета для выбранной группы и текущей итерации;
- дефекты по выбранным требованиям, как показано на рисунке 10;
- дефекты по тестовым примерам из плана тестирования.
На рисунке 10 показаны только те требования, для которых были обнаружены дефекты. Дефект учитывается для требования из RM, если он прослеживается до истории пользователя в CCM, которая относится к текущему выпуску, и эта история пользователя протестирована в QM. Отчет также показывает, как много дефектов, обнаруженных при тестировании определенных требований, остаются открытыми и какие из них уже закрыты. Этот отчет поможет оценить риски, связанные с выполнением этого конкретного требования.
Рисунок 10. Диаграмма и список дефектов по требованиям
Отчеты, перечисленные выше, предоставляют аналогичную информацию. В отчете Defects Per Test Case можно выбрать один или несколько планов тестирования и просмотреть статистику по тем же дефектам, которые включены в отчет по требованиям, по отношению к тестовым примерам этого плана. Отчеты Defects by Priority отображают диаграмму и список дефектов, открытых в настоящее время для выбранной области группы, запланированных на текущую итерацию, и сгруппированных по приоритету.
Отслеживание требований
Следующая группа отчетов относится к отслеживаемости требований в целом.
Отчет Story Traceability, приведенный на рисунке 11, дает группам разработчиков полный обзор прослеживаемости покрытия CLM. Для пользовательских историй CCM, запланированных на определенную итерацию, отчет включает ссылки трассировки на требования по развитию истории в RM, ссылки на тестовые примеры для историй в QM и количество открытых на данный момент дефектов, обнаруженных при выполнении этих тестовых примеров. Отчет можно использовать для выявления пробелов в трассировке, таких как пропущенные тестовые примеры. Он также может служить средством навигации при открытии и просмотре связанных элементов путем непосредственного нажатия на активные ссылки в отчете.
Рисунок 11. Отчет Story Traceability показывает прослеживаемость от историй до требований, тестов и дефектов
Отчет Story Traceability, показанный на рисунке 11, указывает число дефектов, связанных с тестированием пользовательских историй CCM в QM. Более подробное представление об успешных и неудачных прогонах тестов дает отчет Test Execution per Requirement, изображенный на рисунке 12.
Рисунок 12. Отчет Test Execution per Requirement показывает успешные и неудачные прогоны тестов
Для этого отчета нужно выбрать проект требований, план тестирования и итерацию тестирования. Для каждого требования, связанного с пользовательской историей и тестовым примером, отчет показывает количество выполненных тестов и степень их успеха. Этот отчет дает краткий обзор зрелости определенных реализованных требований. Его можно использовать для определения того, по каким требованиям имеются проблемы, которые нужно решить, а какие готовы к тому, чтобы ответственные за выпуск продукта и внешние заказчики могли попробовать текущую интегрированную сборку.
Заключение
Эта статья знакомит читателя с набором готовых отчетов, прилагаемых к Jazz Reporting Service в составе CLM 5.0. В их число входят типовые сценарии: отчеты о состоянии проектов и управлении объемом работ, анализе зависимостей между группами, влиянии дефектов на работу групп и отслеживаемости. Смотрите видеодемонстрацию и разбор этих отчетов на сайте YouTube.
Имеются также дополнительные отчеты JRS, не рассматриваемые в этой статье. Они предоставляют дополнительную информацию о состоянии (например, открытые истории для группы в текущей итерации) и охватывают другие области CLM (такие как мероприятия по внесению изменений или успешность сборки). Я рекомендую установить приложение, попробовать его и дать свой отзыв или предложить дополнительные отчеты.