Скрам

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

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

В засекреченном проекте Lapsec я должен был помочь команде начать применять скрам. Лекция по теории и практике скрама оказалась не очень полезной. Без упражнения с настоящими задачами и проблемами команда вряд ли поняла бы суть скрама. Показав участникам учебный пример, похожий на их реальную работу, я пробился к команде и помог ей прочувствовать, как применять скрам. Попав в рамки спринта, ограниченного максимум одним месяцем, участники команды разработки атаковали свою реальную проблему, словно стая диких собак, – ограничение во времени превосходно сработало. Марк Твен однажды сказал об этом: «Ничто не фокусирует ум так, как петля». Упражнение было той самой петлей фокусировки.

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

Глава 5 Владелец продукта

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

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

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

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

Сотрудничество заказчика и команды

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