Примерно в четверти проектов IBM по созданию программных систем сейчас в той или иной степени используется методология так называемой «скорой» (agile) разработки.
«Это вовсе не дань модной тенденции, — подчеркнула Сью Макинней, вице-президент IBM Software Group по стратегии и интеграции в разработке. — Мы уверены, что именно таким образом надлежит создавать программы». Скорая разработка отличается от традиционного поэтапного, или «каскадного» подхода к созданию программного обеспечения, при котором проект начинается с определения набора требований и последовательно проходит различные этапы, такие как проектирование, реализация и тестирование.
При скорой разработке программисты выполняют несколько «итераций» проекта в течение определенных промежутков времени, скажем, один раз в месяц. Такая система, теоретически, позволяет менять требования к приложению в процессе разработки и добиваться большего вклада в окончательный результат со стороны внутренних бизнес-пользователей и внешних клиентов.
Однако, как считает Макинней, при масштабе IBM внедрение того или иного метода разработки по приказу сверху себя не оправдает.
«Невозможно в декларативном порядке потребовать использование этой методики во всех проектах», — подчеркнула она.
Макинней, 23 года проработавшая в IBM, столкнулась с определенным сопротивлением со стороны разработчиков.
«У нас есть сотрудники-консерваторы, которые утверждают, например, что реализация такого-то проекта потребует три года, и считают полной чепухой все, что мы предлагаем», — рассказывает Макинней. Она согласна, что на выполнение определенных проектов требуется несколько лет, но быстрая разработка позволяет активнее привлекать к участию пользователей и в течение срока реализации выпускать дополнительные бета-версии.
Еще одна проблема связана с широким распространением скорой разработки в больших группах программистов, которые создают основные семейства продуктов IBM, такие как Websphere.
«Методология скорой разработки оправдывает себя в небольших группах. Вопрос заключается в том, как ее распространить на более крупный коллектив», — заметила Макинней.
Попытка ответить на этот вопрос была предпринята при реализации проекта Jazz, платформы совместной разработки, которую создают в IBM.
Пока не ясно, когда именно в IBM методика скорой разработки найдет действительно широкое применение, но, по оценкам Макинней, компании уже удалось добиться ощутимого прогресса: «Сейчас, когда я говорю об скорой разработке, ее уже не воспринимают как чужеродную концепцию».
Джеймс Говернор, аналитик компании Redmonk, считает, что выбор IBM этого направления вполне логичен.
«Совершенно очевидно, что классическая методика неэффективна, — утверждает он. — Она не оправдывает возложенных на нее ожиданий. Требования всегда меняются в процессе разработки. Если вы не предоставите пользователям возможность принять участие в процессе как можно раньше, то, скорее всего, в результате вы предложите им совсем не тот продукт, который они хотели получить».
«IBM далеко не единственная компания, признающая определенные недостатки у методики, которую они применяли раньше, — добавил Говернор. — Производители уже давно используют скорую разработку. Теперь мы наблюдаем следующую стадию, когда они стремятся представить это как свое достижение».