Agile-разработки для SAP: освойте методику Scrum!

31 марта 2010 |

Если проекты разработки в компании излишне бюрократизированы, имеют недостаточный методологический базис или отличаются известной неорганизованностью – попробуйте перейти на Agile. "Agile" – это обобщенное название, относящееся приблизительно к десятку разных, но связанных между собой и в чем-то похожих методов, целью которых является сокращение затрат на разработку программного обеспечения с одновременным улучшением качества результатов. В этой статье в качестве примера рассматривается проект разработок SAP, иллюстрирующий практическое применение концепции Agile – а именно, методики Scrum. Здесь подробно описывается подготовка к первому шагу цикла разработки, приводятся рекомендации по проведению ежедневных совещаний (ключевая особенность методики Scrum!), а также рассматриваются факторы, имеющие критически важное значение для успешной реализации проекта.

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

Клиенты (будущие пользователи программного обеспечения) запираются в комнате на несколько дней или недель с целью разъяснения группе разработчиков всех требований, предъявляемых к функциям программного обеспечения.
При этом желательно, чтобы клиенты подписали выработанные требования и пообещали, что они не изменят принятых решений. Затем, после утверждения этих требований, предпринимаются соответствующие меры, имеющие своей целью запретить какие-либо изменения требований со стороны клиента (например, создается комиссия по контролю за внесением изменений).
После этого разработчики удаляются на несколько месяцев для создания соответствующего программного обеспечения, в то время как клиенты ожидают получения готового продукта.

Этот принцип является краеугольным камнем методики преподавания, принятой во многих высших школах, на котором по-прежнему базируются процессы разработки в отделах информационных технологий. К сожалению, этот подход не всегда гарантирует создание именно того программного обеспечения, которое удовлетворило бы реальным требованиям клиентов. Вполне вероятно, что к моменту подтверждения клиентом соответствия поставляемого программного обеспечения заданным требованиям изменятся бизнес-задачи компании, либо клиент начнет рассматривать проблему под другим углом зрения. Возможно даже, что сотрудники, в свое время сформулировавшие требования к программному продукту, перейдут в другую компанию, и теперь клиента будут представлять совершенно новые люди. Традиционная модель разработки, известная под названием “водопадной” модели, все чаще подвергается справедливой критике, поскольку не позволяет обеспечить соответствие постоянно изменяющимся требованиям клиентов. Наглядная иллюстрация этой модели представлена на Рис. 1.