Книга: Софт за 30 дней. Как Scrum делает невозможное возможным
Назад: Раздел II. Как создать программное обеспечение за 30 дней
Дальше: 6. Scrum на уровне проекта

5. Знакомство со Scrum

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

 

Таблица 5.1. Основы Scrum

 

Разрабатывать программное обеспечение будет Scrum-команда, состоящая из того, кто хочет получить программное обеспечение (владелец продукта), менеджера (Scrum-мастер), а также разработчиков. Чтобы избежать путаницы, может быть только один владелец продукта, который решает, что будет разработано в каждой итерации, или спринте – в терминологии Scrum, – и оценивает результаты приращения функционала в конце каждого спринта. Scrum-мастер управляет проектом согласно правилам Scrum. Некоторые Scrum-мастера прошли обучение, другие имеют значительный, проверенный опыт в успешном его использовании. Главное – знание, как управлять Scrum-командой и проектом.
Создание Scrum-команды и планирование спринта
Первая задача Scrum-мастера – поиск разработчиков и создание команды разработки. Люди в этой команде должны иметь необходимую квалификацию по превращению потребностей и требований владельца продукта (бэклог продукта) в рабочие инкременты программного обеспечения после каждого спринта.
Все члены Scrum-команды собираются для знакомства, обсуждения предстоящей работы и создания условий для совместной работы. Scrum-команда должна знать видение продукта (необходимый и желаемый результат), какие результаты будут означать успех или неудачу и какие есть ограничения. Команда рассматривает только самые важные требования и выбирает максимальное количество тех, что имеют хорошие шансы быть реализованными в предстоящем спринте. (Разработчики должны иметь опыт по разделению больших требований на маленькие осуществимые фрагменты, которые они смогут завершить в спринте.)
Scrum-команда оценивает усилия по разработке требований в законченные функциональные возможности программного обеспечения. Так как они будут выполнять работу, они и должны делать прогнозы. Точность этих прогнозов зависит от того, как долго они работали вместе, как они понимают применяемые в проекте технологии и насколько хорошо они понимают бизнес или сферу, в которой им предстоит работать.
Когда планирование закончено, члены команды дают прогноз, какой объем работы они прогнозируют сделать к концу спринта. Это эмпиризм в действии: дать прогноз, посмотреть, что получилось в реальности, и принять решение на основании результата.
В силу необходимости двигаться дальше этот начальный этап должен быть протяженностью в один день.
Участники Scrum-команды работают вместе, пока все имеют четкое понимание проблемы и подхода к ее решению, пока все знают, что должно быть разработано в предстоящем спринте. Вещи, которые не были очевидными, станут проясняться, как только команда начнет создавать программное обеспечение.
Спринт за ценностью
Теперь Scrum-команда начинает создавать программное обеспечение, начиная с дня, непосредственно после дня планирования спринта. Инкремент функциональных возможностей программного обеспечения разрабатывается в течение первого спринта. Он может быть больше или меньше того, что прогнозировалось. Все члены Scrum-команды взаимодействует в течение спринта, проясняя задачи. Работа может быть переопределена, требования могут добавляться или удаляться по необходимости, если команда разработки определит, что время остается или оставшегося времени недостаточно.
Каждый день в течение спринта разработчики проводят 15-минутные совещания, называемые Scrum-митингами, чтобы спланировать предстоящую работу, все время стремясь достигнуть того, что было договорено. Чтобы максимизировать продуктивность разработчиков, задачи спринта должны быть согласованы как разработчиками, так и владельцем продукта. Они соглашаются, что создадут столько требуемого функционала, сколько возможно, и могут быть переориентированы перед каждым новым спринтом. Владелец продукта соглашается, что требования, над которыми работает команда, не будут меняться в течение спринта. Все, что не было запланировано (включая, например, участие разработчиков во встречах с потребителями), может подождать до следующего спринта. Производительность разработчиков повышается, когда их не прерывают. Применение более коротких спринтов обычно обеспечивает внесение более частых изменений – об этом мы поговорим в следующей главе.
Проведение обзора спринта
В конце спринта Scrum-мастер встречается с разработчиками для проведения обзора спринта. Эта встреча не должна продолжаться более четырех часов. Scrum-команда и ключевые заинтересованные стороны собираются и дают оценку результатам предыдущего спринта и прироста функционала. Обзор включает следующее: что было сделано, каков объем реализованных задач, насколько эффективна разработка и насколько полезен ее результат. Инкремент должен быть законченным фрагментом пригодного к применению программного обеспечения. Пункты бэклога продукта, которые выполнены не полностью, остаются в списке как «все еще требующие выполнения». Новые требования часто возникают в течение обзора спринта. Также часто появляются новые возможности и трудности. Иногда достаточно просто увидеть инкремент, чтобы зародились новые идеи.
Результаты обзора спринта могут включать один или несколько из следующих пунктов:

 

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

 

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

 

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

 

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

 

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

 

Выводы
Scrum прост. Мы рассмотрели его и знаем его составные части. Мы знаем, как двигаться от планов к реализации. Теперь мы посмотрим, как заставить Scrum работать в вашей организации.
Назад: Раздел II. Как создать программное обеспечение за 30 дней
Дальше: 6. Scrum на уровне проекта