4. Планирование занимает слишком много времени и выполняется неправильно. «Мы выяснили, что разработка и развертывание релизов занимают слишком много времени, потому что мы не планировали достаточно хорошо в начале работы. Наши требования были не четко определены и не полностью разработаны, а оценки включали больше догадок, чем возможно. Чтобы это исправить, теперь мы больше времени тратим на планирование. Новые идеи продолжают поступать постоянно. Так как люди пересматривают планы, они находят части, которые должны быть переделаны или уточнены. Теперь мы тратим гораздо больше времени на планирование, чем раньше, но наш график плывет, и периоды стабилизации программного обеспечения все еще большие и ужасные. Несмотря на наши значительные усилия, во время разработки происходят изменения, которые не были и не могли быть учтены во время планирования».

5. Изменения трудно вносить в процессе разработки. «Текущий процесс не приспособлен к внесению изменений. Мы тратим много времени на планирование всего в начале разработки, и все необходимые этапы предусмотрены планом. Но часто необходимо вносить критические изменения или новые функции близко к дате релиза. Для этого мы должны настроить всю ранее проделанную работу для приспособления нового изменения. Это очень сложно, потому что трудно предсказать, как именно это изменение повлияет на стабильность программы. Даже если оно очень важное, есть ощущение, что для его приспособления в процессе разработки требуется в сто раз больше времени, чем если бы знать об этом изменении в самом начале. Но что мы можем сделать? Если важное изменение не внести в текущую разработку или релиз, нужно ждать два и более года до следующего релиза».

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

7. Авралы наносят моральный вред. «Мы обращаемся с людьми так, как нам бы не хотелось. Однако у нас есть обязательства, и бизнес требует, чтобы все, кто работает над проектом, выходили в выходные и задерживались по вечерам. Их семьи и здоровье страдают. Как следствие, у нас есть проблемы с наймом хороших разработчиков, а наши лучшие разработчики уходят в другие организации. Персонал настолько деморализован, что его производительность ухудшается, несмотря на увеличение часов работы».

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

Использование традиционного, или предиктивного, процесса разработки программного обеспечения – основная причина, лежащая в основе провала многих проектов. Предиктивный процесс, также называемый каскадным, зависит от точности плана проекта и неизменности исполнения. Он полагается на перечисленные ниже факторы.

1. Требования не меняются и полностью понятны. Любые изменения в требованиях нарушают план. Требующиеся изменения в плане создают значительные изменения в уже проделанной работе, часто превращая ее в полностью бесполезную. К несчастью, более 35 % всех требований меняются в процессе типового проекта по разработке программного обеспечения. Бизнес-клиенты стараются изо всех сил, чтобы полностью определить эти требования, но постоянно меняющийся рынок, их недостаточное понимание того, что им действительно нужно, и трудности в полном описании ожидаемой системы до ее реализации делают изменения требований практически неизбежными.

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

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

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

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

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

Полезный инструмент, оценивающий уверенность и предсказуемость проекта, – график Стейси[2]. График Стейси измеряет уверенность в сравнении с непредсказуемостью различных аспектов работы и определяет, где план будет провален.

Мы использовали его, чтобы смоделировать три аспекта в разработке программного обеспечения: требования, технологии и люди, как показано на рис. 1.3.

Рис. 1.3. График Стейси

Можно изобразить проекты по разработке программного обеспечения так, как показано ниже.

Требования: от близко к определенности без риска изменений до далеко от определенности со смутными, сложными характеристиками и множеством ожидаемых изменений.

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

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