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

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

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

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

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