Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban

Исследования подтверждают эту мысль, так что не позволяйте команде разрастись до двузначного числа.

Ключевые Скрам-события

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

Пять Скрам-событий:

• спринт – общий цикл для остальных событий;

• планирование спринта – происходит в самом начале работы;

• ежедневная летучка (дейли Скрам) – происходит каждый день (без исключений);

• обзор итогов – проводится в конце спринта;

• ретроспектива – подводит итоги.

Спринт

Спринт – жестко фиксированный по времени, от одной до четырех недель, временной период (time-box) для всех остальных Скрам-событий. Обычно команды выбирают длину спринта в две недели, но идеальной продолжительности нет – во всех вариантах будут присутствовать и плюсы, и минусы. Если есть сомнения, лучше начать с одно- или двухнедельного спринта и посмотреть, как пойдут дела.

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

Блистательный совет для сохранения времени

В «Руководстве по Скраму» не упоминаются пользовательские истории – у владельца продукта могут быть и другие способы объяснить свои идеи. Пользовательские истории в основном просто самый популярный метод.

Не распыляйтесь, тратя время на другие варианты, – идите по проторенному пути.

Планирование спринта

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

Главной характеристикой планирования является то, что основное управление отдано команде, а Скрам-мастер только помогает. Раньше руководитель проекта просто говорил команде, что должно быть сделано и когда, в то время как планирование в Agile позволяет команде решать, что должно быть снято из списка приоритетных задач, что позволяет специалистам планировать реальные сроки выполнения.

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

Также во время планирования нужно убедиться в том, что каждая задача в журнале требований должна быть проверена на понимание перед включением в спринт. Очень важно, чтобы бизнес отметил этот момент до того, как работа начнется, – любые недопонимания нужно устранять; именно для этого тут и присутствует Владелец продукта. Старайтесь не начинать спринт с сомнительных обещаний.

И как только пользовательские истории, которые войдут в спринт, согласованы – для команды и Скрам-мастера заканчивается время обсуждений и раздумий и начинается работа.

Блистательный пример

Команда разработки решает, какой объем работы войдет в спринт, но Владелец продукта и Скрам-мастер тоже принимают в этом участие.

• Начните с четкой цели спринта. Всем должно быть ясно, в чем эта цель заключается и как может быть измерена.

• Выберите пользовательскую историю с наивысшим приоритетом. Проверьте критерии успеха – всем они должны быть понятны.

• Спросите у команды, может ли эта история быть воплощена в течение этого спринта. Если ответ «да» и на этот счет ни у кого нет серьезных сомнений, тогда история включается в этот спринт.

• Если ответ «нет», разберитесь в причинах. Например, если история слишком большая, ее следует разбить на подзадачи. Если ответ все еще «нет», продолжайте обсуждение.