Софт за 30 дней. Как Scrum делает невозможное возможным - стр. 9
Parametric Technology Corporation (PTC) – международная компания, насчитывающая около 5000 сотрудников, которая занимается разработкой программного обеспечения управления жизненным циклом продуктов. Эти продукты, которые выросли из CAD/CAM (систем автоматизированного проектирования/производства), помогают некоторым крупнейшим в мире организациям, например Raytheon, BAE System, Airbus, управлять разработкой массивных систем, таких как «Аэробус-А380». Они делают это отчасти путем отслеживания конфигурации всех частей, узлов и сборок.
В 2005 году компания PTC страдала от всех симптомов предиктивного процесса разработки программного обеспечении.
1. Выпуск новой версии продукта занимал все больше и больше времени. Выпуск релизов сползал с 18 месяцев к 24, и казалось, что текущий релиз опять займет больше времени.
2. График разработки релиза не выполнялся. Сдвиг от первоначального графика уже составлял девять месяцев и увеличивался шаг за шагом. Потребители, которые полагались на этот график, были не в восторге.
3. Стабилизация продукта перед релизом также занимала все больше и больше времени. Стабилизация была причиной как минимум двух третей задержек времени.
4. Планирование занимало все больше и больше времени и было неправильным. До шести месяцев занимало планирование следующей версии продукта, и даже в этом случае план был неправильным и требовал внесения изменений.
5. Внести изменения в середине разработки оказывалось проблематично. Было трудно сказать, сдвиг графика, процесс стабилизации или проблемы качества становились причиной необходимости внесения изменений, но определенно имелась необходимость в ряде важных изменений.
6. Качество ухудшалось. Это было серьезной и усиливающейся проблемой.
7. Авралы наносили моральный вред. РТС испытывала проблемы с наймом хороших специалистов.
В РТС использовали в процессе разработки каскадный процесс и, для того чтобы он работал лучше, пытались зафиксировать все требования. Требования, касающиеся функционала, и требуемые спецификации собирались в исчерпывающий документ. Только после того как финальные требования были утверждены, они передавались разработчику. Пока формулировались требования, разработчики либо исправляли текущие обнаруженные ошибки, либо просто скучали без дела. Персоналу по качеству не позволялось начинать тестирование, пока продукт не был полностью закончен. Таким образом, у них оставалось меньше времени на выполнение работы. Затем они были вынуждены выпускать недостаточно хорошо протестированный продукт, поскольку приближалась дата релиза.