Agile в мире IT: теория и применение

Сегодня слово Agile известно многим.

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

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

Чем же особенны методы Agile и почему они оказались так успешны — разбираем далее в статье.

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

Концепция Agile-разработки зародилась в информационных технологиях, на встрече ведущих IT-специалистов в США в 2001 году. Они сформулировали «Манифест гибкой разработки программного обеспечения», который и лег в основу гибкой модели управления проектами (Agile).

Основной причиной для формирования модели Agile была попытка преодоления ограничений, связанных с предыдущими методиками разработки. В конце XX века, в IT доминировали каскадные модели проектной работы, такие как Waterfall. Они подразумевали планирование IT-продукта от, А до Я на бумаге до начала работы с самим кодом. Написание кода в рамках Waterfall велось от начала и до конца строго согласно изначальному плану. Создание продукта считалось целостной задачей, а разработка шла без этапности.

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

В уже упомянутом Манифесте изложены четыре основных принципа, на которых строится Agile методология.

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

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

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

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

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

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

Еще одна Agile-модель, опирающаяся на более свободную структуру, нежели Scram.

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

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

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

Продукт создается постепенно; в каждую итерацию команда разработчиков создает только часть функционала, которая затем предоставляется заказчику для оценки.

Итерации разделяются на четыре этапа: кодирование, тестирование, планирование, слушание.

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

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

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

• Вовлеченность заказчика

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

• Скорость реализации

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

• Параллельные разработка и тестирование

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

• Минимизация документооборота

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

• Удовлетворенность команд

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

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

• Необходимость сотрудничества со стороны заказчиков

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

• Наличие опытной команды

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

• Ограничения по местонахождению

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

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