Брайан Шепард, исполнительный вице-президент по развитию продуктов компании РТС, был настроен скептически, когда в 2007 году Джейн предложила новый процесс производства программного обеспечения.
Она просила позволить ей раньше подключать программистов к разработке, задействовать контроль качества и не выпускать продукты, которые не прошли полного тестирования. Джейн подчеркнула, что функциональные характеристики могут быть несовершенными, так как группа управления разработкой часто будет получать и использовать части разрабатываемого продукта в течение всего цикла разработки, чтобы давать обратную связь. Брайан согласился попробовать новый процесс – гибкий метод разработки под названием Scrum. При этом он предупредил Джейн: «У тебя нет права на ошибку!»
Когда Джейн сообщила своим сотрудникам о новом методе, они также отнеслись к этой новости скептически и не сразу вникли в суть нового метода, по-прежнему изо всех сил пытаясь добиться совершенных результатов на каждом этапе разработки, стараясь уточнять, что они делают именно то, что другие хотели. Тем не менее, по мере того как менеджеры проектов накапливали опыт в использовании нового метода, они больше не старались получить идеальные функциональные характеристики перед передачей в разработку, так как дополнительные характеристики добавляются в течение всего времени до выпуска релиза. Поскольку теперь РТС разрабатывала полностью функционирующее программное обеспечение каждые 30 дней, ее разработчики смогли напрямую сотрудничать с клиентами в рамках каждой итерации. Разработчики получили понимание требований и то, как эти требования могут быть реализованы лучше всего. Клиенты заметили изменения и начали работать с командами разработчиков в течение каждой итерации. Клиенты помогали авторам создавать функционал и получали именно то, что хотели.
Команда управления продуктами имела в своем распоряжении трех-, двух- и однолетний набор требований. За три года до выпуска это было всего лишь видение продукта с описанием самых главных возможностей. Более детальная картина будущего продукта прорабатывалась во второй год разработки. Для текущего года 30-дневные итерации определялись на первые шесть месяцев и составлялась дорожная карта на последующие шесть. Набор требований для каждого года имел больше деталей, чем предыдущий. Разработчики трудились над набором требований для одного года совместно с клиентами РТС, чтобы выяснить больше деталей. Вся организация стала средоточием творчества и продуктивности.
В течение двух лет все обязательства Джейн перед Брайаном были выполнены. Джейн и ее сотрудники выпускали программное обеспечение каждые 12 месяцев, в то время как ранее выпуск занимал 24 месяца. Продукт был высокого качества. К 2011 году РТС изменилась – она превратилась в прозрачную организацию как внутри, так и для потребителей. Сюрпризы случались редко, клиенты знали, чего и когда ждать. Дефекты были редкими и к 2012 году практически равнялись нулю. Новые детали, пользовательские интерфейсы и возможности рабочего потока были добавлены. Продукт был переработан, стал безопасным от внешних угроз. В итоге бюджет и организационные расходы упали каждый более чем на 10 %. По поручению Брайана Шепарда для организации по разработке программного обеспечения было построено новое здание, которое отражало прозрачность, столь важную для перемен: все располагались в едином пространстве, без отдельных кабинетов, и стены были из стекла.
Недавно Джим Хепперманн, СЕО РТС, во время обсуждения с менеджерами вопроса о повышении бюджетов подразделений попросил их всех поблагодарить Джейн за снижение расходов при одновременном повышении качества и функционала. Сэкономленные ее усилиями средства он может разделить между всеми подразделениями компании.
Однажды Джейн и Джим присутствовали на конференц-связи с компанией в Израиле, оценивающей возможность применения продуктов РТС. Джейн сказала CEO, что компания Raytheon использует продукты РТС по всему миру, и просила связаться с их руководством. Она знала, что в Raytheon не только впечатлены продуктами РТС, но и вдохновлены тем, что новый процесс РТС по разработке программ исключает сюрпризы и есть возможность корректировать свои графики с РТС в режиме реального времени. Компания Raytheon даже переняла у РТС процесс разработки программного обеспечения. Джим сообщил потенциальным клиентам, что последний релиз – самый красивый продукт, когда-либо выпущенный РТС, в первую очередь потому что Джейн изменила процесс разработки.
Итог
Ранее разработка программного обеспечения была скорее неудачной, в первую очередь по причине использования предиктивных процессов для комплексных работ. Переход к Scrum, эмпирическому процессу, значительно увеличивает шансы на успешное завершение проекта разработки программного обеспечения.
Можно получить функции программного обеспечения, готовые к использованию, в течение 30 дней или даже меньше. Не позволяйте вашим разработчикам убедить вас в обратном, потому что сотни тысяч их коллег делают это с 2000-х годов. Программный продукт может быть большим, но его можно собрать фрагмент за фрагментом – каждый за 30 дней.
2. Scrum: правильный процесс приводит к правильному результату
В предыдущей главе мы узнали, что эмпирический процесс – правильный для девелопмента программного обеспечения. Теперь давайте посмотрим, как эмпиризм работает и как можно с его помощью создать ПО. Мы изучим эмпиризм через призму гибкого процесса разработки программного обеспечения, который мы назвали Scrum.
Эмпиризм в действии
В эмпирическом процессе информацию получают путем наблюдения, а не предсказания. Известно, что эмпирические процессы лучше всего подходят для сложных задач, когда неизвестного больше, чем изученного. Чтобы в этой ситуации эмпирический процесс работал, должно выполняться два требования.
1. Проверка и адаптация. Следует часто проверять, где мы сейчас, чтобы адаптировать следующие шаги и добиться оптимальных результатов. Частота проверок и адаптаций зависит от того, какие риски мы готовы принять. Чем больше неизвестных, тем быстрее мы может отклониться от цели. Чем дальше мы уходим от цели, тем больше потеряем на изменении курса, переделке того, что сделано неверно, или выполнении работы сначала.
2. Прозрачность. Когда мы проводим проверку, то должны иметь возможность оценить, что мы видим в тех же условиях, в которых находится наша цель. Если наша цель – разработка системы с определенными признаками или функционалом, то мы должны проверять то, что составляет часть этого признака, функции или их сочетания. Если бы мы использовали предиктивный процесс, то должны были бы задать требования для разработки программного обеспечения, которое может занять годы. Но мы знаем, что в случае с программным обеспечением в течение такого долгого периода накапливается слишком много рисков и потерь. Вместо этого мы используем короткие периоды, обычно 30 дней или меньше. (Позднее мы обсудим значение более коротких периодов.) По окончании первых 30 дней проверяем результаты и определяем, что делать дальше для достижения нашего видения, и, если необходимо, вносим изменения.
