Софт за 30 дней. Как Scrum делает невозможное возможным

Рассредоточенная команда в Iron Mountain. Iron Mountain Digital – это компания по хранению и управлению данными стоимостью 3,1 миллиарда долларов. Она предоставляет услуги по внеофисному хранению резервных цифровых данных с помощью продукта LiveVault. В 2006 году продукт LiveVault испытывал трудности. Новая версия программного обеспечения не выходила более 12 месяцев. Отдельные люди в LiveVault читали об эмпирическом методе разработки программного обеспечения Scrum, но по-прежнему использовали старые методы. Не зная этих трудностей, маркетинговое крыло компании Iron Mountain заключило контракт с Microsoft в июне 2007 года. Microsoft обеспечивала своих пользователей программным обеспечением, постоянно создающим резервные копии. Резервные копии создавались на локальном сервере, и в Microsoft хотели предложить внеофисное хранение резервных данных в LiveVault в качестве альтернативы.

Как менеджер по продукции компании Пол Луппино заключил соглашение с Microsoft на выпуск нового релиза LiveVault. Контракт предполагал, что Microsoft начнет обеспечивать своих клиентов внеофисным хранением резервных данных к февралю 2008 года. Компания Iron Mountain предложила Полу стать менеджером по разработке этого продукта. Трудиться над ним предстояло в течение шести месяцев.

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

Он слышал о Scrum, поэтому немедленно заказал обучающие курсы для всех участников проекта в Iron Mountain и одновременно начал разработку итераций. Пол не знал, какие у него могут возникнуть проблемы, но он знал, что, если все исследовать и обдумывать планы, могут пройти месяцы. Он решил начать разработку сразу, а проблемы решать по мере их поступления. Итерации позволят ему и Iron Mountain знать в пределах 30 дней, есть ли у них проблемы и выполним ли проект.

Все испытывали трудности из-за физической дистанции между командами разработчиков. Видеоконференции были дорогими, Skype работал недостаточно хорошо, и расходы на переезды также очень высоки. Каждый участник координировал свою работу во время ежедневных совещаний (используя дорогостоящие видеоконференции, электронную почту и инструменты социальных сетей), связывающих разработчиков из Iron Mountain в Массачусетсе, разработчиков Microsoft в Индии и менеджеров Microsoft по продуктам в Вашингтоне, чтобы оценивать прогресс в разработке и вносить изменения в дальнейшие планы.

Все менеджеры проверяли прогресс в создании инкремента каждые 30 дней. Сначала люди, находясь в разных местах, изучали законченный инкремент и затем в формате телеконференции обсуждали прогресс и проблемы, а также планировали объем работы для следующей итерации. Обучающие курсы помогли каждому стать более организованным. Пол обновил рабочее пространство в Iron Mountain, чтобы команда разработки стала более продуктивной и эффективной. Потери от нескоординированной работы, которую приходилось переделывать, были устранены. Потери от ручного тестирования, которое можно делать автоматически, также были устранены. Высшее руководство Iron Mountain решило развивать LiveVault. Новая маркетинговая программа и усилия по продвижению были запущены. Еще три релиза выпустили в течение следующих шести месяцев.

Подумайте, что вы хотите сделать

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

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

1. Может ли команда разработки создать приложение в рамках существующей технологии?

2. Можно ли приложение эффективно подключать к функционалу портала без использования интерфейса интернет-портала?

3. Как должно выглядеть это приложение?

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