Внедрение скрама упрощает сотрудничество между заказчиками и группами разработчиков. В этой главе мы рассмотрим стратегии, тактики и уловки, с помощью которых скрам-мастер может добиться такого сотрудничества. Давайте посмотрим, как скрам помог решить проблему недостаточного вовлечения заказчика в работу команды, когда ни тот ни другие не знали, что применяют скрам.
Сотрудничество заказчика и команды
Когда я начал разрабатывать программное обеспечение, сотрудничество с заказчиками и их вовлечение не были проблемой. В 1960-х годах компьютеры были намного менее мощными, пользователей было меньше, приложения были проще, а идея разделения проекта на этапы была еще неизвестна. Я выполнял работу короткими итерациями в один-два дня. Встречался с заказчиком, мы набрасывали на бумаге эскиз желаемого результата и обсуждали его до полного понимания. Затем я шел на свое рабочее место, проектировал и кодировал решение, пробивал перфокарты и компилировал программу. После успешной компиляции я тестировал программу, а затем возвращался к заказчику с вопросом: «Это то, что вы хотели?» Тогда мы не осознавали, каким райским было это время для разработчиков.
Технологии и программное обеспечение становились все более комплексными. Для координации возрастающего числа заинтересованных лиц и участников проекта мы договорились о некоторых процедурах взаимодействия. Например, собирали все требования до начала разработки, полагая, что система должна отвечать консолидированному списку требований всех заказчиков. Документирование оказалось не самым подходящим средством передачи информации, поэтому мы начали использовать картинки с комментариями. Но и картинки оказались неточными, тогда мы разработали языки моделирования для формального представления изображений и схем. Преследуя благие намерения, каждая такая формализация все больше разделяла заинтересованные стороны и разработчиков. Мы перешли от непосредственного общения к документированию, от коротких задач в один-два дня к длительным этапам сбора требований, от простого языка пользователей к тяжелым, узкоспециализированным и непрозрачным артефактам.
Улучшая подходы к разработке программного обеспечения, мы увеличивали разрыв между заказчиками и разработчиками. Последним шагом в этом отчуждении стало внедрение водопадного процесса, который вобрал в себя все недостатки последовательной разработки. Водопадный процесс подразумевает, что необходимо сначала определить все требования, затем спроектировать архитектуру системы, потом написать код, разработать и провести тесты и наконец внедрить систему. После каждого этапа или фазы проводится статусная встреча, на которой заинтересованные лица проверяют достигнутые результаты.
Разработчики и менеджеры ставят заказчикам условие: «Мы собрали ваши требования и на их основании создали модели. Вместе они составляют полное и точное описание того, что вы хотите, посмотрите его. Имейте в виду, что после ответа “да” вам будет стоить намного дороже передумать!» Такая формулировка подразумевает контракт между заказчиками и разработчиками: «Если вы согласны с тем, что представленное нами является полным описанием ваших требований, мы начнем их реализацию. Если нет, то мы продолжим сбор требований, пока вы не сдадитесь!» Личного сотрудничества практически не остается.
Есть и другой подход к взаимодействию между заказчиком и командой – сашими, один из ингредиентов скрама. Сашими – японский деликатес, состоящий из тонких ломтиков сырой рыбы. Каждый кусочек является завершенным сам по себе, он обладает полноценным вкусом, похожим на вкус любого другого ломтика. Скрам использует подход сашими, требуя, чтобы каждый созданный разработчиками фрагмент функциональности был завершенным. Сбор и анализ требований, проектирование архитектуры, кодирование, тестирование и создание документации – все необходимые для создания продукта работы должны быть завершены в каждом спринте, а готовый к поставке инкремент продукта должен быть продемонстрирован на событии по обзору спринта. Спринты должны быть достаточно короткими, чтобы заинтересованные лица не потеряли интерес к проекту и понимали, что у них есть возможность скорректировать направление проекта в начале каждого спринта для оптимизации получаемой ценности. Описание требований, модели и другие внутренние артефакты могут быть полезны разработчикам, но в конце каждого спринта показываются заинтересованным лицам не они, а новая функциональность.
Основным инструментом, который скрам-мастер может использовать для повышения вовлеченности заказчиков, является предоставление быстрых результатов, которые потенциально можно использовать в организации. События по планированию и обзору спринта – своего рода ключевые точки в начале и конце спринта для реализации этой возможности. Если команда полностью укомплектована и проект технологически осуществим, заинтересованные лица и владелец продукта не должны упускать возможность взаимодействия с командой.
Давайте рассмотрим некоторые примеры, в которых скрам помог владельцам продуктов и группам разработчиков работать вместе, чтобы максимизировать ценность проекта. В Service1st мы увидим, как высшее руководство приняло непосредственное участие в работе через роли владельцев продуктов. В TechCore мы увидим, как молодой предприниматель смог удачно продать свою компанию, сосредоточив усилия на роли владельца продукта. Наконец, в MegaBank мы увидим, как скрам-мастер аккуратно добился того, чтобы заказчики стали владельцами продуктов, и одновременно он сократил временные затраты на обучение и внедрение скрама.
Руководители Service1st снова в действии
Как я упоминал выше, раньше разработка систем была проще. Но программные приложения и их окружение становились все более комплексными, поэтому люди и организации запутались.
Вы уже знакомы с Service1st по второй и четвертой главам. Для инициации, планирования и отслеживания прогресса исполнения проектов компания использовала предопределенный процесс управления проектами с диаграммами Ганта, распределением ресурсов и отчетами о потраченном времени. И хотя высшее руководство регулярно получало информацию о статусе каждого проекта в виде процента выполненных работ, текущего положения на диаграмме и других ключевых показателей, этой информации было недостаточно. Вице-президенту по разработке поручили лично отчитываться на еженедельной встрече руководства.
Два топ-менеджера – основатели компании Service1st Том и Хэнк – были ее первыми программистами. По мере роста Service1st им стало ясно, что придется отказаться от повседневного контроля за разработкой и делегировать полномочия другим. Однако со временем они все сильнее расстраивались, потому что релизы стали все чаще отставать от графика, а качество продукта ухудшалось.
Ситуация казалась терпимой, пока не осталось два месяца до завершения цикла разработки и выпуска релиза. Чтобы успеть, все не сговариваясь начали работать сверхурочно. Количество дефектов продолжало расти, а разработчики изо всех сил старались поддерживать его на приемлемом, хотя и плачевном уровне. Service1st решила внедрить скрам и посмотреть, можно ли улучшить ситуацию в течение следующего цикла разработки.
