Читать «Скрам (Гибкое управление продуктом и бизнесом)» онлайн - страница 50
Кен Швабер
Эти обязанности исполнять непросто. Скрам-мастеру часто приходится бороться с 20-летней историей конфронтаций внутри компании, где каждая сторона видит в другой источник чего-то ценного, но почти недоступного. На основании прошлого опыта заказчик понимает, насколько маловероятно, что команда по его просьбе предоставит систему вовремя и в соответствии с названными потребностями. На основании своего опыта команда убеждена, что заказчик постоянно будет менять свое мнение в самый неподходящий момент, когда они уже разобрались в том, что нужно создать. Обе стороны убеждены, что возможности для взаимовыгодного сотрудничества ничтожны, поэтому и старания тщетны.
«Скрам решил мою проблему с вовлечением заказчиков», – фраза, которую на протяжении многих лет я слышу от ИТ-менеджеров. Скрам предоставляет множество возможностей для решения этой общеотраслевой проблемы: команда и владелец продукта должны постоянно сотрудничать, совместно выясняя, как получить от используемых технологий максимальную отдачу для бизнеса.
Внедрение скрама упрощает сотрудничество между заказчиками и группами разработчиков. В этой главе мы рассмотрим стратегии, тактики и уловки, с помощью которых скрам-мастер может добиться такого сотрудничества. Давайте посмотрим, как скрам помог решить проблему недостаточного вовлечения заказчика в работу команды, когда ни тот ни другие не знали, что применяют скрам.
Когда я начал разрабатывать программное обеспечение, сотрудничество с заказчиками и их вовлечение не были проблемой. В 1960-х годах компьютеры были намного менее мощными, пользователей было меньше, приложения были проще, а идея разделения проекта на этапы была еще неизвестна. Я выполнял работу короткими итерациями в один-два дня. Встречался с заказчиком, мы набрасывали на бумаге эскиз желаемого результата и обсуждали его до полного понимания. Затем я шел на свое рабочее место, проектировал и кодировал решение, пробивал перфокарты и компилировал программу. После успешной компиляции я тестировал программу, а затем возвращался к заказчику с вопросом: «Это то, что вы хотели?» Тогда мы не осознавали, каким райским было это время для разработчиков.
Технологии и программное обеспечение становились все более комплексными. Для координации возрастающего числа заинтересованных лиц и участников проекта мы договорились о некоторых процедурах взаимодействия. Например, собирали все требования до начала разработки, полагая, что система должна отвечать консолидированному списку требований всех заказчиков. Документирование оказалось не самым подходящим средством передачи информации, поэтому мы начали использовать картинки с комментариями. Но и картинки оказались неточными, тогда мы разработали языки моделирования для формального представления изображений и схем. Преследуя благие намерения, каждая такая формализация все больше разделяла заинтересованные стороны и разработчиков. Мы перешли от непосредственного общения к документированию, от коротких задач в один-два дня к длительным этапам сбора требований, от простого языка пользователей к тяжелым, узкоспециализированным и непрозрачным артефактам.
