ФБР перевело всю команду по разработке проекта «Страж» в подвал здания в Вашингтоне и сократило персонал с 400 человек до 45, 15 из которых были программисты. Технический директор ФБР лично возглавил проект. Целью управления разработкой стало предоставление части функционала «Стража» каждые 30 дней. Все приращения функционала обязаны были соответствовать окончательным характеристикам, это не должен был быть «сырой продукт». Каждые три месяца ФБР объединяло три ранее полученные части в единый пилотный проект.
К ноябрю 2011-го, через год после возобновления работы с использованием нового подхода, все стадии проекта «Страж» были закончены. Программное обеспечение установили для пилотной группы агентов ФБР, оснащение оставшихся агентов новым программным обеспечением было запланировано к июню 2012 года. ФБР удалось закончить проект «Страж» за 30 миллионов долларов в течение года. Экономия средств составила более 90 %. Сотрудники так же усердно трудились и над первыми стадиями проекта «Страж», но сам подход к разработке программного обеспечения отбрасывал их назад. После применения нового метода, описанного в этой книге, они продолжили работать столь же усердно, как и раньше, но наградой им стали гораздо лучшие результаты. Если такая организация, как ФБР, смогла сделать это, почему не может ваша?
Неправильный подход: предиктивные процессыПроцесс, который ФБР изначально использовало для «Стража», мы называем предиктивным, или последовательным. По сути, до 2005 года большинство проектов по разработке программного обеспечения использовали предиктивные процессы, которые при определенных обстоятельствах наиболее подходят и могут обеспечить успех. Эти обстоятельства, однако, скорее исключение, чем правило. Если кто-то может создать окончательное видение, определить все требования к нему и затем разработать детальный план по воплощению их в жизнь, тогда предиктивный процесс будет эффективным. Но любое отклонение от изначального видения, требований или плана создает большой риск. При частой смене требований бизнеса и технологий, которые присутствуют в реальных условиях, очень редко встречается, чтобы все элементы проекта оставались неизменными. Как результат, о чем и сообщает отчет The Standish Group, 86 % проектов по разработке программного обеспечения, основанных на предиктивных процесах, неуспешны. На самом деле мы считаем использование предиктивных процессов самой распространенной причиной проблем при разработке программного обеспечения.
Организации, с которыми мы сотрудничаем, стараются изо всех сил, чтобы увеличить процент успеха своих проектов по разработке программного обеспечения. Они ищут помощи у нас из страха, что их организация процесса девелопмента ПО выходит из-под контроля. Существующий процесс подвел их, а альтернативных подходов они не знают. Проблемы с разработкой программного обеспечения приносят их организациям огромные потери, и они вынуждены мириться с этим, поскольку должны создавать программное обеспечение на конкурентном уровне.
Организации, с которыми мы сотрудничаем, стараются изо всех сил, чтобы увеличить процент успеха своих проектов по разработке программного обеспечения. Они ищут помощи у нас из страха, что их организация процесса девелопмента ПО выходит из-под контроля. Существующий процесс подвел их, а альтернативных подходов они не знают. Проблемы с разработкой программного обеспечения приносят их организациям огромные потери, и они вынуждены мириться с этим, поскольку должны создавать программное обеспечение на конкурентном уровне.
Руководители и менеджеры обычно описывают проблемы, с которыми сталкиваются, следующим образом.
1. Выпуск продукта занимает все больше и больше времени. «Каждый релиз занимает больше времени, требует больше усилий и затрат до момента передачи потребителю. Несколько лет назад выпуск новой версии занимал 18 месяцев, теперь на разработку, комплектацию и установку требуется 24 месяца. И при этом каждый релиз становится стрессом и требует значительных усилий. Мы тратим все больше, при этом получаем все меньше и меньше.
2. Срыв графиков релизов. «В проспектах мы даем обязательства нашим нынешним либо потенциальным клиентам, которые делают определенные приготовления в соответствии с нашим графиком релиза. Им нужен наш релиз с обещанным нами функционалом именно тогда, когда запланировано. И мы обычно подводим их в самый последний момент. Их планы нарушаются, они теряют деньги и доверие в глазах своих клиентов. Следовательно, мы можем не получить от них новые заказы, их отзывы о нашей работе вряд ли будут хорошими, и они могут начать поиск другой компании разработчиков».
3. Создание стабильной версии перед релизом занимает все больше и больше времени. «Мы установили разработчикам четкие, неизменяемые даты выполнения заказа. Они уложились в эти сроки, но программное обеспечение было нестабильным, не функционировало, как требуется. У нас даже не получилось отгрузить этот софт как бета-релиз, так что мы смогли получить отзывы только от ограниченного количества пользователей. Дефекты оказались настолько значительными, что наши бета-тестеры отказались участвовать. Нам потребовалось еще девять месяцев, чтобы выпустить релиз, и даже тогда он был нестабилен и требовал множества доработок и оправданий перед пользователями».
4. Планирование занимает слишком много времени и выполняется неправильно. «Мы выяснили, что разработка и развертывание релизов занимают слишком много времени, потому что мы не планировали достаточно хорошо в начале работы. Наши требования были не четко определены и не полностью разработаны, а оценки включали больше догадок, чем возможно. Чтобы это исправить, теперь мы больше времени тратим на планирование. Новые идеи продолжают поступать постоянно. Так как люди пересматривают планы, они находят части, которые должны быть переделаны или уточнены. Теперь мы тратим гораздо больше времени на планирование, чем раньше, но наш график плывет, и периоды стабилизации программного обеспечения все еще большие и ужасные. Несмотря на наши значительные усилия, во время разработки происходят изменения, которые не были и не могли быть учтены во время планирования».
5. Изменения трудно вносить в процессе разработки. «Текущий процесс не приспособлен к внесению изменений. Мы тратим много времени на планирование всего в начале разработки, и все необходимые этапы предусмотрены планом. Но часто необходимо вносить критические изменения или новые функции близко к дате релиза. Для этого мы должны настроить всю ранее проделанную работу для приспособления нового изменения. Это очень сложно, потому что трудно предсказать, как именно это изменение повлияет на стабильность программы. Даже если оно очень важное, есть ощущение, что для его приспособления в процессе разработки требуется в сто раз больше времени, чем если бы знать об этом изменении в самом начале. Но что мы можем сделать? Если важное изменение не внести в текущую разработку или релиз, нужно ждать два и более года до следующего релиза».
6. Ухудшение качества. «Мы знаем, что не должны давить на разработчиков, чтобы получать все, что запланировано, и с учетом изменений вовремя, но наш бизнес страдает от проблем планирования, срыва сроков и изменений. Мы требуем от разработчиков ужесточения работы для соблюдения сроков. Каждый раз после таких требований они сокращают срок выпуска за счет ухудшения качества программного обеспечения либо сокращения времени тестирования на стабильность. Результат настолько плохой, что мы возвращаемся на стадию стабилизации или выпускаем некачественный продукт».
7. Авралы наносят моральный вред. «Мы обращаемся с людьми так, как нам бы не хотелось. Однако у нас есть обязательства, и бизнес требует, чтобы все, кто работает над проектом, выходили в выходные и задерживались по вечерам. Их семьи и здоровье страдают. Как следствие, у нас есть проблемы с наймом хороших разработчиков, а наши лучшие разработчики уходят в другие организации. Персонал настолько деморализован, что его производительность ухудшается, несмотря на увеличение часов работы».
Этих примеров достаточно, чтобы обескуражить любого руководителя, занимающегося разработкой программного обеспечения. Несмотря на 20 лет титанических усилий и огромных затрат, в этой отрасли к началу 90-х был достигнут незначительный прогресс в обеспечении успешного результата проектов по разработке программ. Процесс, который мы опишем в этой книге, устраняет подобные проблемы.
Неправильные результаты: провал проектаИспользование традиционного, или предиктивного, процесса разработки программного обеспечения основная причина, лежащая в основе провала многих проектов. Предиктивный процесс, также называемый каскадным, зависит от точности плана проекта и неизменности исполнения. Он полагается на перечисленные ниже факторы.
1. Требования не меняются и полностью понятны. Любые изменения в требованиях нарушают план. Требующиеся изменения в плане создают значительные изменения в уже проделанной работе, часто превращая ее в полностью бесполезную. К несчастью, более 35 % всех требований меняются в процессе типового проекта по разработке программного обеспечения. Бизнес-клиенты стараются изо всех сил, чтобы полностью определить эти требования, но постоянно меняющийся рынок, их недостаточное понимание того, что им действительно нужно, и трудности в полном описании ожидаемой системы до ее реализации делают изменения требований практически неизбежными.
2. Технология работает без каких-либо проблем. Все технологии, используемые при разработке программного обеспечения, должны надежно работать, как и планировалось изначально. К несчастью, в проект часто включают такие технологии, которые до того не использовались целиком, в комбинации или для тех же целей. Более того, технологические стандарты иногда меняются прямо во время разработки проекта.
3. Люди должны быть предсказуемы и надежны, как машины. План требует выполнения специфической сети задач, каждая из которых требует определенного количества часов от сотрудника, имеющего специальные навыки, которому даны четко определенные исходные данные. К сожалению, сеть задач меняется с каждым изменением требований. Еще большая проблема то, что люди не машины. У них бывают хорошие и плохие дни, разный уровень профессионализма, отношение к делу и умственные способности. В итоге задачи выполняются не так, как изначально планировалось.