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

Разработка требований по принципу PRN. Многие небольшие Scrum-проекты добились успеха с помощью неформальных механизмов формирования требований, таких как прямое обсуждение между владельцем продукта и командой разработки. Но, по мере того как сложность и критичность проекта растут, требуется более глубокое и полное описание требований и их версий. К примеру, становится важной документация интерфейсов, которая влияет на несколько команд. Изменения в интерфейсах или новые функции, которые выходят за пределы одной команды, могут иметь значительное влияние на весь проект.

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

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

Планирование релиза. Философия Scrum фокусируется на «магии воспользоваться возможностями в ближайшей перспективе», в отличие от «черной магии по точному предсказанию именно того, что будет доставлено через 6–12 спринтов». Эта философия – прорыв в мышлении на уровне команды, потому что это позволяет Scrum-командам фокусироваться на текущей работе в ближайшие 30 дней и таким образом производить работающее программное обеспечение более надежно. Но, по мере того как количество команд растет, применение дополнительного анализа и точности к спринтам за пределами непосредственного горизонта помогает избежать архитектур, которые требуют в дельнейшем существенного рефакторинга, который хотя и весьма поощряется в гибком методе разработки, но становится менее практичным по мере увеличения масштаба приложений и количества существующих внедрений. Дополнительное планирование релиза, который предоставляет нам архитектурный путь, часто бывает оправданным. Таким образом, искусство планирования спринта может включать функции планирования «что будет через несколько спринтов» и «что если планирование…», которые помогают командам идти на компромиссы в бэклогах и обсуждать разумное видение и дорожную карту продукта со спонсорами.

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

Развитие инфраструктуры в спринтах. В Scrum внедрение этого уровня инфраструктуры не разовое событие, подготовленное «заранее» командой внедрения.

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

Рис. А3.4. Добавление инфраструктурных элементов в спринт

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

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

Обычно организации, специализирующиеся на разработке программного обеспечения, после внедрения Scrum получают следующие преимущества:

• уменьшение времени цикла разработки;

• больше ценности для конечных пользователей;

• более высокое качество;

• меньше производственных рисков;

• большая удовлетворенность пользователей;

• улучшение морального духа компании.

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

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

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

Эта книга не стала бы такой, какая она есть, без превосходного редактирования Арлетт Бэлью, общих указаний Ричарда Наррамора и лазерного фокуса Кэри Армстронг.