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

Мы начнем с быстрого знакомства с ним, затем разделим метод на три шага, каждый из которых рассмотрим в отдельной главе.

Scrum на уровне проекта . Этот подход применяется «по необходимости» (от лат. pro re nata (PRN), что означает «бери, когда нужно»). Например, когда кто-то нуждается в программном обеспечении за 30 дней или меньше. Глава 6 объясняет, как реализовать Scrum на уровне проекта с минимальными расходами и самыми быстрыми результатами.

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

Scrum на уровне организации. На этапе организации опыт и знания, полученные студией разработки, распространяются на всю компанию, ее общую производительность и гибкость. Глава 8 описывает этот шаг, а кроме того, рассказывает, как применять Scrum, чтобы внедрить его в организации. И как отделить разговоры о применении Scrum от реального его использования.

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

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

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

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

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

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

Когда планирование закончено, члены команды дают прогноз, какой объем работы они прогнозируют сделать к концу спринта. Это эмпиризм в действии: дать прогноз, посмотреть, что получилось в реальности, и принять решение на основании результата.

В силу необходимости двигаться дальше этот начальный этап должен быть протяженностью в один день.

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

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