Проблемы Agile-методологии и способы их решения

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

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

Что такое Agile?

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

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

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

• Личность и взаимодействие важнее процессов и инструментов: Команда разработчиков и владелец продукта стоят на первом месте, разработка программного обеспечения - это человеческая деятельность, которая выигрывает от технологий, а не наоборот.
• Рабочее программное обеспечение важнее исчерпывающей документации: Конечной целью разработки программного обеспечения является создание интуитивно понятного программного обеспечения, поэтому это должно быть на первом месте в проекте. Документация не должна быть словарем для понимания программного обеспечения.
• Сотрудничество с заказчиком вместо переговоров по контракту: Заказчик активно участвует в процессе разработки, владелец проекта постоянно дает обратную связь, тестирует продукт, ставит новые цели и вносит свой вклад.
• Реагирование на изменения вместо следования плану: Создание программного обеспечения - это не прямая линия, ситуация может резко меняться от одного момента к другому, и команде разработчиков приходится адаптироваться, что может означать возврат к предыдущим этапам проекта, чтобы что-то изменить или полностью переделать.

В рамках Agile существуют десятки фреймворков, каждый из которых имеет свой набор инструментов и практик. У команды, работающей по Scrum, будет совершенно иной подход к достижению цели, чем у команды, использующей Kanban или Crystal Clear, но все они имеют одну и ту же базовую философию.

Работает ли это? Да, при правильном подходе Agile-фреймворки позволяют повысить производительность разработки ПО, а также улучшить моральное состояние и удовлетворенность команды разработчиков.  

Итак, с какими же трудностями сталкивается agile-разработка?

Привлечение людей к работе

Клиенты и разработчики, привыкшие к водопадным методологиям, часто воспринимают agile как путаницу и хаос, а некоторые даже считают, что команда придумывает все на ходу. Одним из наиболее распространенных критических замечаний в адрес Agile-систем является то, что в них отсутствует прочная методология.

На самом деле все обстоит совсем наоборот. Сторонники Agile стремятся создать методологию, отвечающую требованиям разработки программного обеспечения. На самом деле Agile-системы могут быть достаточно строгими, с четко разграниченными ролями и структурами - просто эти структуры были построены с учетом гибкости.

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

Ползучесть функций

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

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

Итак, каково же решение? Масштабирование - отличная вещь, а добавление функций по мере продвижения - одно из основных достоинств Agile-фреймворков. Фокус здесь в том, чтобы очень четко представлять себе ресурсы команды и не переборщить с обещаниями.

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

Отсутствие документации

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

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

Для Agile документация не должна быть ни слишком длинной, ни слишком короткой - ее должно быть достаточно. Но это влечет за собой целый ряд проблем, а именно: чего достаточно? И для кого?

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

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

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

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

Стоит ли переходить на Agile?

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

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