Когда я начал разрабатывать программное обеспечение, сотрудничество с заказчиками и их вовлечение не были проблемой. В 1960-х годах компьютеры были намного менее мощными, пользователей было меньше, приложения были проще, а идея разделения проекта на этапы была еще неизвестна. Я выполнял работу короткими итерациями в один-два дня. Встречался с заказчиком, мы набрасывали на бумаге эскиз желаемого результата и обсуждали его до полного понимания. Затем я шел на свое рабочее место, проектировал и кодировал решение, пробивал перфокарты и компилировал программу. После успешной компиляции я тестировал программу, а затем возвращался к заказчику с вопросом: «Это то, что вы хотели?» Тогда мы не осознавали, каким райским было это время для разработчиков.

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

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

Разработчики и менеджеры ставят заказчикам условие: «Мы собрали ваши требования и на их основании создали модели. Вместе они составляют полное и точное описание того, что вы хотите, посмотрите его. Имейте в виду, что после ответа “да” вам будет стоить намного дороже передумать!» Такая формулировка подразумевает контракт между заказчиками и разработчиками: «Если вы согласны с тем, что представленное нами является полным описанием ваших требований, мы начнем их реализацию. Если нет, то мы продолжим сбор требований, пока вы не сдадитесь!» Личного сотрудничества практически не остается.

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

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

Давайте рассмотрим некоторые примеры, в которых скрам помог владельцам продуктов и группам разработчиков работать вместе, чтобы максимизировать ценность проекта. В Service1st мы увидим, как высшее руководство приняло непосредственное участие в работе через роли владельцев продуктов. В TechCore мы увидим, как молодой предприниматель смог удачно продать свою компанию, сосредоточив усилия на роли владельца продукта. Наконец, в MegaBank мы увидим, как скрам-мастер аккуратно добился того, чтобы заказчики стали владельцами продуктов, и одновременно он сократил временные затраты на обучение и внедрение скрама.