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

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

Выводы

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

Организации хотят стать более гибкими, более творческими и более продуктивными, а также увеличить свою прибыль. Они хотят радовать своих клиентов и обгонять конкурентов. Многие организации решили использовать Scrum как одну из ключевых стратегий. Иногда его применяют только для самых важных задач, иногда организация создает новый IT-отдел параллельно с существующим, использующим каскадный процесс. Иногда вся организация трансформируется, чтобы стать более гибкой, конкурентоспособной. Вне зависимости от поставленной цели требуется изменение обычного подхода к делу. Как и в большинстве значительных изменений, неорганизованный подход независимо от его достоинств обречен на провал. Переход к 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-команда начинает создавать программное обеспечение, начиная с дня, непосредственно после дня планирования спринта. Инкремент функциональных возможностей программного обеспечения разрабатывается в течение первого спринта. Он может быть больше или меньше того, что прогнозировалось. Все члены Scrum-команды взаимодействует в течение спринта, проясняя задачи. Работа может быть переопределена, требования могут добавляться или удаляться по необходимости, если команда разработки определит, что время остается или оставшегося времени недостаточно.

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