Индустрия разработки программного обеспечения понимает эти трудности и годами пыталась решить их путем наращивания усилий по планированию. Проект планирования мог занимать столько же времени, сколько и сам девелопмент. Подготовительный этап стал включать в себя сбор требований, определение архитектуры и детальную разработку планов.
Но весь этот труд был полезен, только если план основывался на точной информации и не изменялся в течение времени. Метод эффективен, когда задача хорошо понятна и относительно стабильна, а план, соответственно, остается неизменным. Если это не так, то предиктивный процесс терпит неудачу. Он не приспособлен к тому, чтобы справляться с неизвестным и неожиданным, его возможности по решению проблем ограниченны.
Множество традиционных производителей успешно используют модель прогнозируемого процесса. Выигрыш такого метода в повторном выполнении разработанного плана, создании машины за машиной или тостера за тостером. В девелопменте программного обеспечения подобного преимущества нет, план его разработки выполняется только один раз. Именно то, что делает предиктивные процессы подходящими для производства, где единственный цикл производственного процесса создает большой объем продукта, плохо подходит для программного обеспечения, где один цикл разработки предоставляет только один продукт.
Полезный инструмент, оценивающий уверенность и предсказуемость проекта, график Стейси[2]. График Стейси измеряет уверенность в сравнении с непредсказуемостью различных аспектов работы и определяет, где план будет провален.
Полезный инструмент, оценивающий уверенность и предсказуемость проекта, график Стейси[2]. График Стейси измеряет уверенность в сравнении с непредсказуемостью различных аспектов работы и определяет, где план будет провален.
Мы использовали его, чтобы смоделировать три аспекта в разработке программного обеспечения: требования, технологии и люди, как показано на рис. 1.3.
Рис. 1.3. График Стейси
Можно изобразить проекты по разработке программного обеспечения так, как показано ниже.
Требования: от близко к определенности без риска изменений до далеко от определенности со смутными, сложными характеристиками и множеством ожидаемых изменений.
Технологии: от хорошо известных и понятных до неопределенных, когда разработка и используемые технологии обычно состоят из множества продуктов, взаимодействующих через интерфейсы на различных уровнях разработки и выпуска программного обеспечения.
Люди: от знакомых и постоянных, когда разработкой занимается одна команда с малым количеством людей, до проектов, включающих больше чем четыре-пять человек, часто сотни, которые постоянно меняются. У каждого человека своя точка зрения на тот или иной вопрос, свой характер и настроение, поэтому при взаимодействии в группах или командах непредсказуемость результатов работы является значительной.
Используя график Стейси, можно увидеть, что проекты по разработке программного обеспечения как минимум сложные, а иногда и хаотичные. Предиктивный процесс, на котором основаны каскадный и традиционный методы девелопмента софта, пригоден только для простой, повторяющейся работы. Вы можете определить, правильный ли процесс вы используете, по ставке доходности, степени успеха. Если бы предиктивный подход был подходящим для проектов разработки программного обеспечения, ставка доходности (или процент успешного завершения проектов) была бы очень высокой около 99,99 %. Однако рассмотренный ранее отчет The Standish Group оценивает процент успеха проектов разработки программного обеспечения, использовавших предиктивный метод, в 14 %.
Предиктивный процесс не подходит для решения проблем в девелопменте софта. Разработка программного обеспечения нелегкая задача, и построение ее на предиктивном процессе приведет к неудаче. Наши доказательства основаны на повышении процента успешности проектов, в которых стал применяться Scrum-метод.
Люди иногда сравнивают разработку программного обеспечения со строительством мостов. Такие инженерные дисциплины находятся на графике Стейси где-то посередине между простыми и сложными. Стандартизация относит эту работу к сложным. Существует три формы стандартизации. Во-первых, есть законы Ньютона, объясняющие, как физические объекты взаимодействуют друг с другом. Во-вторых, применяются стандартные материалы, такие как деревянный брус, стальная арматура, крепления с известными размерами и характеристиками. В-третьих, есть различного рода стандарты, описанные в разных документах и проверяемые различными органами. Ничего из этого не существует в программном обеспечении. Более того, при таком быстром развитии технологий, как сейчас, это вряд ли изменится.
Пример: Parametric Technology CorporationParametric Technology Corporation (PTC) международная компания, насчитывающая около 5000 сотрудников, которая занимается разработкой программного обеспечения управления жизненным циклом продуктов. Эти продукты, которые выросли из CAD/CAM (систем автоматизированного проектирования/производства), помогают некоторым крупнейшим в мире организациям, например Raytheon, BAE System, Airbus, управлять разработкой массивных систем, таких как «Аэробус-А380». Они делают это отчасти путем отслеживания конфигурации всех частей, узлов и сборок.
В 2005 году компания PTC страдала от всех симптомов предиктивного процесса разработки программного обеспечении.
1. Выпуск новой версии продукта занимал все больше и больше времени. Выпуск релизов сползал с 18 месяцев к 24, и казалось, что текущий релиз опять займет больше времени.
2. График разработки релиза не выполнялся. Сдвиг от первоначального графика уже составлял девять месяцев и увеличивался шаг за шагом. Потребители, которые полагались на этот график, были не в восторге.
3. Стабилизация продукта перед релизом также занимала все больше и больше времени. Стабилизация была причиной как минимум двух третей задержек времени.
3. Стабилизация продукта перед релизом также занимала все больше и больше времени. Стабилизация была причиной как минимум двух третей задержек времени.
4. Планирование занимало все больше и больше времени и было неправильным. До шести месяцев занимало планирование следующей версии продукта, и даже в этом случае план был неправильным и требовал внесения изменений.
5. Внести изменения в середине разработки оказывалось проблематично. Было трудно сказать, сдвиг графика, процесс стабилизации или проблемы качества становились причиной необходимости внесения изменений, но определенно имелась необходимость в ряде важных изменений.
6. Качество ухудшалось. Это было серьезной и усиливающейся проблемой.
7. Авралы наносили моральный вред. РТС испытывала проблемы с наймом хороших специалистов.
В РТС использовали в процессе разработки каскадный процесс и, для того чтобы он работал лучше, пытались зафиксировать все требования. Требования, касающиеся функционала, и требуемые спецификации собирались в исчерпывающий документ. Только после того как финальные требования были утверждены, они передавались разработчику. Пока формулировались требования, разработчики либо исправляли текущие обнаруженные ошибки, либо просто скучали без дела. Персоналу по качеству не позволялось начинать тестирование, пока продукт не был полностью закончен. Таким образом, у них оставалось меньше времени на выполнение работы. Затем они были вынуждены выпускать недостаточно хорошо протестированный продукт, поскольку приближалась дата релиза.
Джейн Вачутка, вице-президент по разработке продукта Windchill в компании PTC, как новый сотрудник попыталась применять используемый в компании каскадный метод и столкнулась со всеми обычными для этого метода проблемами. На предыдущей работе она использовала множество некаскадных процессов, подобных тем, что помогли достигнуть успеха проекту ФБР «Страж». В соответствии с этим методом проект состоит из одного или нескольких повторений работы (итераций), каждый из которых длится не более 30 дней. Множество небольших команд разработчиков выбирают наиболее важные требования для каждой итерации и превращают их в часть готового к употреблению программного обеспечения. Все эти части затем объединяются в одну полностью законченную и готовую к применению программу. В конце каждой последующей итерации другие части и надстройки программы добавляются к существующему функционалу.
Брайан Шепард, исполнительный вице-президент по развитию продуктов компании РТС, был настроен скептически, когда в 2007 году Джейн предложила новый процесс производства программного обеспечения.
Она просила позволить ей раньше подключать программистов к разработке, задействовать контроль качества и не выпускать продукты, которые не прошли полного тестирования. Джейн подчеркнула, что функциональные характеристики могут быть несовершенными, так как группа управления разработкой часто будет получать и использовать части разрабатываемого продукта в течение всего цикла разработки, чтобы давать обратную связь. Брайан согласился попробовать новый процесс гибкий метод разработки под названием Scrum. При этом он предупредил Джейн: «У тебя нет права на ошибку!»
Когда Джейн сообщила своим сотрудникам о новом методе, они также отнеслись к этой новости скептически и не сразу вникли в суть нового метода, по-прежнему изо всех сил пытаясь добиться совершенных результатов на каждом этапе разработки, стараясь уточнять, что они делают именно то, что другие хотели. Тем не менее, по мере того как менеджеры проектов накапливали опыт в использовании нового метода, они больше не старались получить идеальные функциональные характеристики перед передачей в разработку, так как дополнительные характеристики добавляются в течение всего времени до выпуска релиза. Поскольку теперь РТС разрабатывала полностью функционирующее программное обеспечение каждые 30 дней, ее разработчики смогли напрямую сотрудничать с клиентами в рамках каждой итерации. Разработчики получили понимание требований и то, как эти требования могут быть реализованы лучше всего. Клиенты заметили изменения и начали работать с командами разработчиков в течение каждой итерации. Клиенты помогали авторам создавать функционал и получали именно то, что хотели.
Команда управления продуктами имела в своем распоряжении трех-, двух- и однолетний набор требований. За три года до выпуска это было всего лишь видение продукта с описанием самых главных возможностей. Более детальная картина будущего продукта прорабатывалась во второй год разработки. Для текущего года 30-дневные итерации определялись на первые шесть месяцев и составлялась дорожная карта на последующие шесть. Набор требований для каждого года имел больше деталей, чем предыдущий. Разработчики трудились над набором требований для одного года совместно с клиентами РТС, чтобы выяснить больше деталей. Вся организация стала средоточием творчества и продуктивности.