Что такое Agile и почему компании-разработчики используют его?

Введение

Имея более чем десятилетний опыт разработки программного обеспечения, компания ESK Solution определила agile как наиболее продуктивную форму реализации проектов. Мы сочетаем несколько agile-подходов, таких как Kanban и SCRUM, и выбираем наиболее подходящий для каждого конкретного клиента. 

Давайте разберемся, почему мы советуем многим нашим клиентам отказаться от распространенного водопадного подхода и обратить внимание на agile-методологии разработки.

В чем разница между agile и waterfall?
Что такое водопадная методология?

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

В чем заключаются преимущества водопада?

• Полный объем проекта известен с самого начала и не может быть изменен в ходе разработки.
• Проект включает подробную документацию, в которой четко описывается каждый этап разработки. 
• Даты начала и окончания разработки фиксированы. Методология не допускает изменения сроков.
• Практически полное отсутствие участия заказчика. Этот метод особенно подходит для отраслей, где заказчики не хотят погружаться в процесс разработки, а желают получить готовый продукт без их участия.

Каковы недостатки водопада?

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

Что же представляет собой методология agile?

Agile, напротив, подходит для проектов с динамичной структурой благодаря своей гибкости. Метод agile ориентирован на адаптивные, одновременные рабочие процессы и разбивает объем работ на итеративные фазы, называемые спринтами. Спринты хорошо подходят для продуктов, требующих регулярного пересмотра в течение цикла разработки. 

В начале каждого спринта список требований приоритизируется на основе обратной связи с заказчиком. В конце спринта разработчики и заказчик анализируют и оценивают проделанную работу, делая основные выводы для будущих спринтов. Различные agile-методологии, которые мы используем:

• Канбан - разновидность agile-методологии, названная в честь доски Канбан - инструмента, используемого для разделения бэклога на этапы. Каждая задача записывается на листе бумаги и помещается в столбцы со статусами от "Начато" до "Закончено" по мере выполнения задачи. Это помогает производственной команде координировать, распределять и балансировать усилия по разработке. Сегодня этот процесс, разумеется, полностью переведен в режим онлайн.
• SCRUM - еще одна agile-методология. Она направлена на быстрое выполнение большого объема работ. Бэклог SCRUM разбивается на этапы длиной в неделю\/две, называемые спринтами. Конкретная задача каждого спринта прорабатывается во время его старта. После выполнения спринт анализируется и оценивается его успешность. Для отслеживания прогресса и распределения бэклога между членами команды используется диаграмма Burnout Chart. Мастер SCRUM играет важную роль, помогая остальным членам команды контролировать весь процесс: он ставит перед ними задачи, а также проводит стенд-апы.  Однако SCRUM-мастер никогда не берет управление проектом полностью на себя.

Каковы преимущества agile?

• Более быстрый жизненный цикл разработки программного обеспечения. Настоящая сила исходит от быстрого обучения и открытий.
• Рабочий объем в спринте совершенно ясен.
• Основное внимание уделяется постоянной коммуникации с клиентом, что гарантирует удовлетворенность.
• При сдаче результат будет в большей степени соответствовать ожиданиям - даже если требования изменились в процессе работы.
• Гибкость в принятии изменений - в любой момент можно изменить любой аспект проекта.
• Стимулирует вовлеченность каждого члена команды и позволяет командам эффективно управлять проектами
• Члены команды имеют возможность наблюдать и тестировать на протяжении всего проекта.

Каковы недостатки agile?

• Agile требует высокой степени вовлеченности заказчика, которую не каждый клиент готов обеспечить.
• Большое количество новых правок с последующим повторением итераций может привести к сокращению бюджета и сроков.
• Agile предполагает наличие у каждого члена проектной команды чувства личной ответственности, без чего ослабевает принцип самоуправления.

Почему мы выбираем agile-разработку?

Как уже было сказано выше, компания ESK Solution выбирает agile-методологии для большинства жизненных циклов своих разработок. Этот выбор обусловлен многолетним опытом работы с различными типами клиентов - от небольших стартапов до крупных предприятий и государственных структур. В процессе совместной работы с бизнес-аналитиками и программистами ESK Solution наши клиенты часто расширяют первоначальные требования к проекту, что полностью противоречит сути водопадной методологии. Чтобы лучше проиллюстрировать это, расскажем историю одного из наших проектов, в котором столкнулись agile- и водопадная методологии.

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

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

В результате заказчик получил нечто большее, чем просто копию существующей системы, построенную на современных технологиях. Клиент получил возможность устранить множество узких мест в своем бизнесе и получить новые возможности для роста.

Все эти возможности стали доступны клиенту потому, что он вовремя оценил риски и возможности и отказался от водопадного метода, который ограничивал весь потенциал разработки.

Как использовать Agile в нашем рабочем процессе?

Может показаться, что agile описывает только специфику рабочих процессов разработчиков, но это не совсем так. Agile - это всего лишь методология, которая может быть применена на любом этапе и участке проекта - даже на самом раннем! Как известно, одной из четырех ценностей agile-разработки ПО является реакция на изменения, а не следование плану. Давайте рассмотрим, как компания ESK Solution использует agile-методы для выявления требований нового проекта и его начальной фазы:

1. В самом начале мы проводим несколько переговоров с клиентом, чтобы уточнить объем проекта, а также сроки и бюджетные ограничения. Наши специалисты по продажам и аналитики понимают, что заказчик может изменить объем работ после этого ознакомительного звонка. Кроме того, после успешной первой встречи начинается обсуждение предварительных требований к проекту. Они могут быть представлены в различных формах - в виде технического задания, презентационных колод, функциональных или технических спецификаций. Опыт показывает, что у каждого клиента свое понимание того, что такое техническая документация и в каком виде она должна быть составлена, - и мы изучаем всю присланную нам документацию.
2. После каждого звонка наша команда готовит предварительную оценку сроков и бюджета проекта. После каждого разговора с клиентом мы возвращаемся к документации и вносим изменения, чтобы составить наиболее точную смету для конкретного проекта. Следуя принципу приоритета личности и взаимодействия над процессами и инструментами, мы не беспокоим заказчика, представляя каждую версию оценки, а ждем, пока соберем достаточно знаний для отправки окончательной сметы.
3. Принципы agile-разработки позволяют нам двигаться не только последовательно, но и параллельно с задачами проекта. Например, фаза обнаружения, на которой бизнес-аналитик описывает функциональность платформы и помогает сформировать анализ рынка, и фаза проектирования, основанная на дизайн-брифе - форме для заполнения, которую получает от нас клиент, - совершенно независимы друг от друга. Agile позволяет нам работать над реализацией этих двух задач одновременно.

Как видно из приведенного описания, agile позволяет возвращаться назад и вперед между различными задачами и этапами, а также вносить правки и изменения, которые неожиданно требуются в процессе разработки продукта. В водопадной методологии такой возможности нет, поскольку ее суть заключается в прямом следовании плану без возможности возврата к предыдущим этапам. 

На этапе разработки ESK Solution также придерживается инструментария agile-методологии: реализуя одновременно различные функции, мы прислушиваемся к пожеланиям клиента и имеем возможность изменить или добавить желаемую функциональность на любом этапе процесса разработки. Наши менеджеры проектов предпочитают разбивать циклы разработки на спринты продолжительностью 2-3 недели. ESK Solution считает, что заказчик - это не пассивный зритель, а равноправный партнер, а значит, вовлеченность в процесс разработки обоих партнеров является залогом успеха проекта.

Какая модель оплаты используется в agile-методологии?

На заре аутсорсинга разработки, когда единственным способом работы был водопад, способ оплаты даже не обсуждался. Это была фиксированная цена и только она. Со временем появились альтернативы этой модели оплаты, в том числе и ее главный оппонент - "время и материалы" (сокращенно T&M). Выбор правильного ценообразования напрямую связан с выбором методологии разработки и должен соответствовать требованиям и целям проекта, а также общим затратам, которые несет разработчик. Многие компании допускают в своей практике некие гибриды между фиксированной ценой и T&M, но мы в ESK Solution такие варианты не рассматриваем. 

Договор с фиксированной ценой - это договор с одной стоимостью, по которому поставщик услуг отвечает за выполнение проекта в пределах оговоренной суммы, указанной в договоре. Это удобный выбор в тех случаях, когда требования, спецификации и расценки четко определены с самого начала, и клиент не может вносить в проект какие-либо изменения. Таким образом, фиксированная цена наиболее удобна при использовании метода "водопада".

ESK Solution предпочитает использовать модель T&M, поскольку мы считаем, что модели фиксированной стоимости в проектах с высокой неопределенностью являются обманом. Мы либо обманываем себя, не учитывая некоторые нюансы и недооценивая проект, либо обманываем заказчика, называя более высокую цену и в итоге создавая для него большие риски. Ни одна из этих ситуаций нам не нравится. Поэтому мы используем метод T&M, который предполагает выставление заказчику счета за фактически выполненный объем работ на почасовой основе. Клиенты оплачивают только фактическое количество рабочих часов - ни больше, ни меньше. Поскольку в agile мы планируем спринты на 2-3 недели, клиент понимает, что включает в себя тот или иной спринт и сколько времени будет потрачено на выполнение задач в этот период. Если его что-то не устраивает, он может, например, попросить убрать из спринта низкоприоритетную, но дорогостоящую задачу, заменив ее на более важную, но менее затратную. Таким образом, бюджет проекта становится гибким, и клиент может лучше контролировать бюджет.

Метод T&M не ввергает клиента в непредсказуемость, как это может показаться. Несмотря на то, что в договоре нет фиксированной конечной суммы, ESK Solution все равно предоставляет клиенту оценку количества часов работы, необходимых для завершения проекта. Подробные условия сотрудничества и штрафные санкции в случае их нарушения оговариваются в договоре, который подписывают обе стороны - клиент и ESK Solution. 

Наша команда ценит T&M за гибкость и прозрачность метода оплаты. В сочетании с agile-методологией это позволяет нашему клиенту получить современный продукт в кратчайшие сроки и в любой момент внести изменения в техническое задание - без негативного влияния на процесс разработки.

Заключение

Независимо от того, какую методологию используют команды разработчиков, результат во многом зависит от реализации. В компании ESK Solution мы верим в своих менеджеров проектов и разработчиков, поэтому с удовольствием наблюдаем за тем, как они продвигаются по agile-методологиям, как считают нужным.