Читать «Софт за 30 дней. Как Scrum делает невозможное возможным» онлайн - страница 107

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

Возможности инструментальной архитектуры

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

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

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