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

В течение двух лет все обязательства Джейн перед Брайаном были выполнены. Джейн и ее сотрудники выпускали программное обеспечение каждые 12 месяцев, в то время как ранее выпуск занимал 24 месяца. Продукт был высокого качества. К 2011 году РТС изменилась – она превратилась в прозрачную организацию как внутри, так и для потребителей. Сюрпризы случались редко, клиенты знали, чего и когда ждать. Дефекты были редкими и к 2012 году практически равнялись нулю. Новые детали, пользовательские интерфейсы и возможности рабочего потока были добавлены. Продукт был переработан, стал безопасным от внешних угроз. В итоге бюджет и организационные расходы упали каждый более чем на 10 %. По поручению Брайана Шепарда для организации по разработке программного обеспечения было построено новое здание, которое отражало прозрачность, столь важную для перемен: все располагались в едином пространстве, без отдельных кабинетов, и стены были из стекла.

Недавно Джим Хепперманн, СЕО РТС, во время обсуждения с менеджерами вопроса о повышении бюджетов подразделений попросил их всех поблагодарить Джейн за снижение расходов при одновременном повышении качества и функционала. Сэкономленные ее усилиями средства он может разделить между всеми подразделениями компании.

Однажды Джейн и Джим присутствовали на конференц-связи с компанией в Израиле, оценивающей возможность применения продуктов РТС. Джейн сказала CEO, что компания Raytheon использует продукты РТС по всему миру, и просила связаться с их руководством. Она знала, что в Raytheon не только впечатлены продуктами РТС, но и вдохновлены тем, что новый процесс РТС по разработке программ исключает сюрпризы и есть возможность корректировать свои графики с РТС в режиме реального времени. Компания Raytheon даже переняла у РТС процесс разработки программного обеспечения. Джим сообщил потенциальным клиентам, что последний релиз – самый красивый продукт, когда-либо выпущенный РТС, в первую очередь потому что Джейн изменила процесс разработки.

Итог

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

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

2. Scrum: правильный процесс приводит к правильному результату

В предыдущей главе мы узнали, что эмпирический процесс – правильный для девелопмента программного обеспечения. Теперь давайте посмотрим, как эмпиризм работает и как можно с его помощью создать ПО. Мы изучим эмпиризм через призму гибкого процесса разработки программного обеспечения, который мы назвали Scrum.

Эмпиризм в действии

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

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

2. Прозрачность. Когда мы проводим проверку, то должны иметь возможность оценить, что мы видим в тех же условиях, в которых находится наша цель. Если наша цель – разработка системы с определенными признаками или функционалом, то мы должны проверять то, что составляет часть этого признака, функции или их сочетания. Если бы мы использовали предиктивный процесс, то должны были бы задать требования для разработки программного обеспечения, которое может занять годы. Но мы знаем, что в случае с программным обеспечением в течение такого долгого периода накапливается слишком много рисков и потерь. Вместо этого мы используем короткие периоды, обычно 30 дней или меньше. (Позднее мы обсудим значение более коротких периодов.) По окончании первых 30 дней проверяем результаты и определяем, что делать дальше для достижения нашего видения, и, если необходимо, вносим изменения.