Каскадная модель разработки (Waterfall) — подход к разработке программного обеспечения, при котором процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Гибкая методология разработки (Agile) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.
На одной из презентаций, посвященных преимуществам подхода Agile, докладчик начал выступление с перечисления недостатков каскадной методологии (Waterfall). В основе Waterfall-подхода лежит логическая последовательность этапов разработки — каждый последующий этап начинается после завершения предыдущего и не предусматривает возможности исправить ошибку в процессе разработки. Таким образом, если в исходном дизайне есть ошибка, она будет и в конечном продукте. Методология Agile, напротив, дает возможность менять параметры проекта. Разработчики получают больше информации о потребностях клиента во время тестирования и вырабатывают «гениальные» идеи.
Пока я слушал описание этого «волшебного» подхода, подумал: «А что если принципы Agile используются просто для того, чтобы закрепить за менеджментом среднего звена законное право менять свое мнение и управлять проектом на свое усмотрение? Вдруг все разговоры о внедрении Agile — способ подготовить разработчиков к условиям методологически обоснованной безрассудной свободы?» Если применять инструменты Agile без системы управления, помогающей вести проекты к намеченной цели, подход Agile на самом деле уступает методу Waterfall.
LShift в Лондоне: «Необходимо максимально исключить из процесса менеджмент среднего звена»
Создавая компанию по разработке программного обеспечения LShift, мы собрали группу инженеров и спросили их: «Что нужно сделать компании, чтобы вам захотелось в ней работать?» По их мнению, сначала нужно искоренить ситуации, когда в разгаре проекта менеджер сообщает разработчикам, что во время обеда с клиентом «в приступе великодушия» он согласился добавить новые функции, заменить основную платформу или завершить проект на месяц раньше запланированного срока. В результате разработчики вынуждены работать сверхурочно.
