Использование методологии Agile в разработке программного обеспечения

 
Что такое Agile
 
Вероятно, многие команды, работающие по Agile, затруднятся дать ему точное определение. Что это: Философия? Некий набор принципов? Методология?

В целом, вы не ошибётесь, если выберите любой из этих вариантов. Это и методология, и набор принципов, и философия (хотя и не имеющая ничего общего с Сократом, Кантом, или Декартом).

Методология Agile, как понятно из названия, означает гибкость и подвижность, олицетворяя собой готовность к изменениям. Он противопоставляет себя сложившимся практикам в разработке программного обеспечения (хотя сами по себе принципы Agile применимы не только в сфере разработки приложений).

Если раньше были важнее сами процессы и инструменты для достижения целей, то теперь на первый план выходят люди и коммуникации между ними.

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

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

Очевидно, что Agile команды появились не просто так. В принципах методологии сокрыты и изначальные проблемы, с которыми сталкивались заказчики и разработчики в процессе создания ПО.
 

• Выделенная команда разработчиков получила проект, с которым ей предстоит работать. Вот только есть проблема – сам заказчик не до конца уверен в том, что ему нужно.
   
  Благодаря открытости Agile к изменениям, клиенту отныне не нужно описывать свой проект на все 100% — в требования можно вносить изменения (конечно, в разумных пределах – на полпути сворачивать разработку мобильного приложения и превращать его в web явно не стоит).

• Слишком медленное внедрение нового функционала. Проблема тянется ещё с конца прошлого века, когда каждое приложение должно было быть установлено непосредственно на само устройство.
   
  К счастью, в это же время интернет начал развиваться семимильными шагами, что сделало возможным запуск web приложений на стороне сервера с любого устройства.

  Это, в свою очередь, позволило реализовать один из главных принципов Agile – частые поставки дополнительного функционала. Путём небольших итераций (цикл разработки нового функционала) размером в несколько недель, заказчик получил возможность получать рабочие версии приложения ещё задолго до финального релиза.

• Документация. Тонны технической документации. Это та чёрная дыра, которая не несёт для бизнеса никакой практической ценности, но съедает немалую часть бюджета и времени даже при наличии команды опытных разработчиков.
   
  Конечно, Agile не отрицает необходимость определённого минимума документов (без него не обойтись), но постоянная коммуникация с заказчиком и согласование требований после каждой итерации позволяют значительно уменьшить необходимый объем документации и упростить процесс работы.

 
Разберём наиболее популярные виды Agile:
 

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

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

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

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

  Но какой смысл будет во всех этих замечательных видеозвонках, вылизанных стикерах и сложной системой премиум-аккаунтов, если приложение не сможет выполнять свою основную функцию – отправка сообщений? Логично, что для данного приложения приоритетным минимальным функционалом будет возможность отправлять сообщения, а всё остальное команда сможет добавить потом, сделав из него “конфетку”.

• Kanban. Как и множество других хороших бизнес-практик, канбан пришёл в IT из послевоенного японского машиностроения. Существует три основных принципа канбана. Первый – визуализация (это и означает иероглиф “кан”).
   
  Иллюстрируя производственный процесс, команда разбивает его на отдельные этапы (план, разработка, проверка качества, готовые задачи и т.д.), упрощая таким образом его восприятие.

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

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

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

Не только Agile
 
Для большей наглядности следует сравнить Agile с одной из классических моделей – waterfall (водопад). Особо рьяные последовали Agile любят при удобном случае указать на отсталость водопада, забывая при этом, что он вполне себе хорош для больших и фундаментальных проектов.

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

Представьте настоящий водопад. Может ли вода в нём потечь в обратном направлении, когда уже упала с обрыва? Нет. Ну, по крайней мере до тех пор, пока существует гравитация. То же самое можно сказать и в отношении модели «водопад».

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

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

Также данную модель можно использовать в случае, если время и деньги для вас – не проблема, и ваша компания готова потратить много ресурсов на тестирование и «полировку» продукта.
 

Особенности команд, работающих по Agile
 
Многие Agile команды редко могут точно определить, какой тип  Agile они используют. Вряд ли вы найдете себе выделенную команду разработчиков, работающих по чистому scrum, или руководствующуюся исключительно lean-принципами.

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

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

К счастью, практически любая задача при использовании Agile оказывается вполне выполнимой, особенно при наличии опытной выделенной команды разработчиков.