Рассмотрим устройство скелета. В начале итерации команда разработки анализирует, что она должна сделать. Затем выбирает требования, которые сможет к концу итерации превратить в инкремент готовой к поставке[6] функциональности. В ходе итерации команда прилагает для этого все усилия, а любые заинтересованные лица не отвлекают команду до конца итерации. По завершении итерации команда разработки демонстрирует созданный за итерацию инкремент продукта, чтобы заинтересованные лица могли произвести его инспекцию и соответствующие адаптации в проекте могли быть произведены своевременно.

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

Реализовать этот скелет итеративно-инкрементального процесса в скраме позволяют три роли. В следующих разделах я дам краткий обзор этих ролей, а затем опишу процесс скрама и его артефакты. Приложение A содержит список событий и правил, а Приложение Б – определения терминов скрама. Более подробную информацию о скраме можно найти в Приложении В «Ресурсы», а также в книге «Гибкое управление разработкой ПО по скраму» (Agile Software Development with Scrum).

В скраме есть только три роли: владелец продукта, команда разработки и скрам-мастер. Вся ответственность в части управления проектом разделена между этими ролями. Владелец продукта отвечает за представление интересов всех лиц, заинтересованных в проекте, в создаваемой программной системе. Чтобы добиться и затем получать регулярное финансирование проекта, владелец продукта описывает первоначальные общие требования проекта, определяет цели по возврату инвестиций (ROI) и поддерживает план релизов в актуальном состоянии. Список требований называется бэклогом продукта. Владелец продукта несет ответственность за поставку заинтересованным лицам максимальной ценности: гарантирует, что наиболее ценная функциональность будет реализована в первую очередь. Это достигается за счет регулярного пересмотра порядка задач в бэклоге так, чтобы в следующую итерацию были взяты самые ценные требования.

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

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

Люди, выполняющие эти роли, должны быть преданы проекту. Остальные тоже могут быть заинтересованы в проекте, но они «не на крючке». Скрам четко различает эти две группы и гарантирует, что те, кто несет ответственность за проект, имеют полномочия делать все необходимое для его успеха, а те, кто не несет такой ответственности, не могут вмешиваться в работу первых. В этой книге я называю эти группы людей «цыплятами» и «поросятами» соответственно. Названия пришли из старого анекдота. Цыпленок и поросенок идут по дороге. Цыпленок говорит поросенку: «Хочешь открыть вместе со мной ресторан?» Поросенок поразмыслил и отвечает: «Да, пожалуй. Как ты хотел бы назвать его?» «Яичница с беконом!» – отвечает цыпленок. Поросенок останавливается и, вздохнув, отвечает: «Знаешь, я передумал. Я не хочу открывать такой ресторан с тобой, потому что мне придется отдать себя проекту целиком, а тебе – лишь поучаствовать!»

Это важное различие, поэтому скрам так настойчив в требовании полной прозрачности: всегда должно быть понятно, кто на крючке, а кто просто назойливый советчик. Кто несет ответственность за возврат инвестиций, а кто имеет долю в ROI, но не отвечает за него. Кому придется превратить новую технологию в функциональность, а кто – лишь беспокойный «адвокат дьявола». Скрам проводит явную черту между цыплятами и поросятами, чтобы положить конец неразберихе, и тем самым повышает производительность и создает продуктивный импульс.

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

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