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

В конце спринта Scrum-мастер встречается с разработчиками для проведения обзора спринта. Эта встреча не должна продолжаться более четырех часов. Scrum-команда и ключевые заинтересованные стороны собираются и дают оценку результатам предыдущего спринта и прироста функционала. Обзор включает следующее: что было сделано, каков объем реализованных задач, насколько эффективна разработка и насколько полезен ее результат. Инкремент должен быть законченным фрагментом пригодного к применению программного обеспечения. Пункты бэклога продукта, которые выполнены не полностью, остаются в списке как «все еще требующие выполнения». Новые требования часто возникают в течение обзора спринта. Также часто появляются новые возможности и трудности. Иногда достаточно просто увидеть инкремент, чтобы зародились новые идеи.

Результаты обзора спринта могут включать один или несколько из следующих пунктов:

• начало использования разработанного функционала;

• решение, что делать в течение следующего спринта, и подготовка к нему;

• решение остановить работу.

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

Проведение ретроспективы спринта

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

Ретроспектива спринта – естественный разрыв между спринтами, когда команда садится и обсуждает события предыдущего спринта, а также ищет пути улучшения своей работы и способов, которыми эта работа ведется.

Обсуждение может включать следующие вопросы:

• хорошо или плохо работают члены команды вместе и почему;

• больше или меньше работы, чем предполагалось, делает команда и почему;

• обладает ли команда всеми необходимыми навыками и обеспечением, требующимся для выполнения работы;

• понимают ли разработчики требования и почему;

• способна ли команда закончить спринт в соответствии с требованиями, и если нет, то почему;

• что можно добавить или выбросить из следующего инкремента функционала;

• что команда думает об использовании подхода Scrum.

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

Продолжение спринта

Scrum-команда продолжает повторять шаги, описанные ранее, пока цели не будут достигнуты, возможности максимально использованы, возврат инвестиций достигнут или пока не столкнутся с непреодолимым препятствием (рис. 5.1).

Рис. 5.1. Scrum в действии

Выводы

Scrum прост. Мы рассмотрели его и знаем его составные части. Мы знаем, как двигаться от планов к реализации. Теперь мы посмотрим, как заставить Scrum работать в вашей организации.

6. Scrum на уровне проекта

Использовать Scrum можно, когда это необходимо, например когда у вас есть безотлагательная возможность или очень важный проект. Эта глава поможет понять, как начать это делать немедленно, без суеты и затрат. Вы научитесь получать ценность каждые 30 дней.

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

Снизу вверх и невидимый Scrum

В течение предыдущих 20 лет многие Scrum-проекты проходили внизу организации, скрытые от взгляда. Команда, работающая над проектом, пробовала применить Scrum и создавала впечатляющие результаты. Затем другая команда пробовала его, и скоро команды внутри организации начинали разрабатывать программное обеспечение быстрее и чаще. Довольно скоро Scrum-проекты стали проявляться повсюду в организации. Мы называем такой Scrum PRN.

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

Преимущества и открытия