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. Рассмотрим некоторые из них.

Скрам представляет собой наиболее распространенную 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. может взять эту задачу на себя.