Софт за 30 дней. Как Scrum делает невозможное возможным

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

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

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

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

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

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

1.7. Выводы

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

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

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

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

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

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

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

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

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

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

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

Благодарности

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

Об авторах