Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

Основная проблема заключалась в том, что большинство софтверных проектов начиналось с тщательного определения технических требований и планирования на месяцы и годы вперед задолго до поставки работоспособного продукта в конце процесса. Вездесущий и ненавистный календарный график работ показывал, как все части проекта будут сливаться воедино с течением времени, чтобы в конце появилось нечто полезное для клиента. Из-за формы графика этот процесс получил название «каскадной» разработки.

Джефф Сазерленд – один из ученых-компьютерщиков, положивших начало методологии аджайл, и активный критик старого метода каскадной разработки. С 1960-х гг. он считался стандартом в софтверной индустрии, но Сазерленд называет его «колоссальной ошибкой», которая «обошлась в сотни миллиардов долларов из-за провальных проектов только в США». По словам Сазерленда, каскадная разработка заканчивается неудачей в 85 % случаев в проектах стоимостью более $5 млн. В 2004 г. исследование 250 крупных софтверных проектов показало, что 70 % из них страдали от серьезных задержек и перерасхода средств или были прекращены до получения результата.

Австралийская авиакомпания Qantas потратила $200 млн на разработку проекта под руководством IBM и расторгла рассчитанный на 10 лет контракт через четыре года. Но это было только первое ее фиаско. В 2008 г. Qantas отказалась от программного комплекса для управления авиационными запчастями Jetsmart, который обошелся в $40 млн и был настолько плох, что авиаинженеры прозвали его «Тупой самолет» (Dumbjet).

В своей книге «SCRUM: Революционный метод управления проектами»[8] Сазерленд рассказывает историю масштабного правительственного проекта, который был спасен методологиями скрам и аджайл. В 2000 г. ФБР инициировало рассчитанный на пять лет проект Virtual Case File по переводу устаревшей бумажной системы учета в цифровой формат. Исполнители контракта использовали устаревший каскадный метод, и в 2005 г., потратив $170 млн, ФБР пришлось отказаться от проекта и начать все сначала. Исполнение следующего проекта, получившего название Sentinel, с бюджетом $451 млн поручили компании Lockheed Martin. Lockheed также использовала каскадный подход и к 2010 г., за пять лет работы, потратила $405 млн, а сделала только половину. По оценкам компании, ей требовалось еще $350 млн, чтобы закончить работу за шесть‒восемь лет. Однако пара инновационных ИТ-руководителей из аппарата ФБР взяла проект на себя, сократила команду разработчиков с сотен человек до 50, разместила их в подвале штаб-квартиры ФБР и выполнила работу за 20 месяцев и $12 млн. Как? С помощью методологии аджайл.

Методология аджайл решила важную проблему – у разработки ПО не было рабочего процесса, в отличие от многих других технических дисциплин. Когда вы строите небоскреб, геодезист осуществляет съемку местности, архитектор проектирует здание, клиент проверяет проект, а затем архитектор передает его генеральному подрядчику. Подрядчик делит строительство на специализированные этапы и координирует работу. Человечество оттачивало эту модель в течение последних двух сотен лет, и она работает.

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

Помимо прочего, из-за жесткой зависимости между командами замедление работы одной из них нередко тормозит весь проект. А с учетом изменения требований замедление является нормой, а не исключением. Таким образом, даже когда талантливые и исполненные лучших намерений менеджеры проектов предусматривают в планах временной буфер, непредсказуемое каскадное замедление становится неуправляемым. Вот почему миллиарды долларов тратились впустую, у разработчиков и бизнес-руководителей опускались руки, а большинство компаний считали невозможной успешную разработку ПО своими силами.

Решением проблемы могло стать еще более тщательное планирование или запрет на все изменения с началом работ. Однако нашлись головы, которые поняли, что подобный подход – хорошая, но совершенно нереалистичная идея.

В поисках альтернативы в 2001 г. Сазерленд и группа ведущих специалистов по разработке ПО устроили трехдневную встречу. Они разработали одностраничный документ под названием «Манифест аджайл-разработки программного обеспечения», который предлагал более эффективный и реальный подход к создания ПО, повышающий шансы организаций на успешное создание ценности вовремя и в рамках бюджета.

Манифест аджайл-разработки программного обеспечения

Мы постоянно открываем более совершенные методы создания программного обеспечения, занимаясь разработкой сами и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

люди и взаимодействие важнее процессов и инструментов;

работающий продукт важнее исчерпывающей документации;

сотрудничество с заказчиком важнее согласования условий контракта;

готовность к изменениям важнее следования первоначальному плану.

Иными словами, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.

Кент Бек

Джеймс Греннинг

Роберт Мартин

Майк Бидл

Джим Хайсмит

Стив Меллор

Ари ван Беннеком

Эндрю Хант

Кен Швабер

Алистер Кокберн

Рон Джеффрис

Джефф Сазерленд

Уорд Каннингем

Джон Керн

Дейв Томас

Мартин Фаулер

Брайан Марик

Текст манифеста может свободно копироваться в любой форме, но только полностью, включая это уведомление.

Авторы манифеста аджайл определили четыре направления и 12 принципов, которые подкрепляют эту методологию и действительно являются основой ее многочисленных форм. Вполне возможно, что ваша компания практикует аджайл в том или ином виде, но единого определения методологии аджайл не существует. Появился