Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [81]

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

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

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

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

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

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

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

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

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

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

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

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

Кент Бек

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

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

Майк Бидл

Джим Хайсмит

Стив Меллор

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

Эндрю Хант

Кен Швабер

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

Рон Джеффрис

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

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

Джон Керн

Дейв Томас

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

Брайан Марик

© 2001, вышеуказанные авторы.

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

Авторы манифеста аджайл определили четыре направления и 12 принципов, которые подкрепляют эту методологию и действительно являются основой ее многочисленных форм. Вполне возможно, что ваша компания практикует аджайл в том или ином виде, но единого определения методологии аджайл не существует. Появился целый спектр практик под флагом аджайл. Вы наверняка слышали о наиболее популярных из них, таких как скрам, канбан и экстремальное программирование. Даже сами эти практики реализуются по-разному и с разной степенью приверженности «правилам». За последние 20 лет методология аджайл распространилась по всему миру. В опросе 2019 г. «Состояние аджайл» 97 % респондентов заявили, что их организации практикуют методы аджайл. Независимо от конкретной реализации все они преследуют одну и ту же цель: создание эффективного ПО. Рассмотрим более детально эту методологию.

Основы аджайл

В основе методологии аджайл лежит гибкость (кто бы сомневался!) – способность быстро и легко двигаться, быстро менять направление и реагировать на изменение исходных данных. Авторы манифеста аджайл видят проблему в практике предварительного планирования, отталкиваясь от неверных предположений, и в отсутствии координации действий владельцев бизнеса и разработчиков. Устраняя эти два ключевых недостатка, методология аджайл позволяет сделать процесс создания ПО более гибким. Хотя существует множество путей реализации методологии аджайл, все они сводятся к трем основным идеям: предвидение изменений, разделение работы на части и поддержание тесного сотрудничества между бизнесом и разработчиками.

Предвидение изменений

Первая идея – это предвидение изменений в технических требованиях, поэтому вместо того, чтобы удивляться их появлению и расстраиваться из-за этого, нужно создать систему, которая ожидает изменения. Аджайл позволяет сделать это несколькими способами. Во-первых, это ограничение объема незавершенной работы. Если у вас сотня заданий, которые выполнены на 10 %, то вероятность появления изменений и прерывания хотя бы одного из потоков работы велика. Однако если сосредоточиться на выполнении одного задания на 100 %, то вам вряд ли придется бросать завершенную работу. Аджайл ограничивает объем незавершенной работы, разбивая ее на короткие спринты, часто продолжительностью не более двух недель, с целью поставки работоспособного продукта в конце каждого цикла. Это не означает, что проект выполняется за две недели, но какая-то его часть становится работоспособной в конце каждого спринта, а не остается незавершенной в течение длительного времени.