2016/07/01 22:33:40

Agile software development

Гибкая методология разработки (англ. Agile software development) — это концептуальный подход, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.

Содержание

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

Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе иногда называемом bullpen. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес-аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

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

4 базовые концепции Agile

Agile, гибкая методология разработки ПО, предоставляет ряд преимуществ перед более консервативной и менее подходящей для производителей софтов системы Waterfall, однако некоторые организации не спешат с переходом. IТ-эксперт Боб Ронан (Bob Ronan) в своей статье перечисляет преимущества, которые следует учесть директорам по информационным технологиям (CIO), рассматривающим возможность перехода на Agile[1].

1. Технические и бизнес-подразделения совместно располагаются в открытой зоне

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

2. Сценарии тестирования разрабатываются до начала этапа программирования

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

3. Утренние планерки проводятся каждый день

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

4. Процесс состоит из рабочих циклов продолжительностью от одной до четырех недель, которые называют «спринтами»

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

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

Распределенная гибкая модель

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

«Когда я впервые опробовал Agile при которой разработчики находились в разных местах, результаты были не очень радужными. Планерки проводились по телефону, и мы часто испытывали трудности с пониманием того, что говорится в другой локации. Наша первая попытка решить проблему была довольно забавной: мы передавали телефон по кругу говорящему. Это решение было не до конца оптимальным, но оно подтолкнуло нас к более удачной идее использовать гарнитуру, подключенную к единой телефонной системе. Благодаря этому все могли слышать друг друга.

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

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

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

10 преимуществ Agile

1. Быстрое выявление неправильных подходов

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

2. Быстрое принятие решений

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

3. Сотрудничество выливается в множество преимуществ

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

4. Изменения признаются неизбежными и приветствуются

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

5. Конечный продукт содержит наиболее полезные функции

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

6. Более привлекательная среда для поколения Y

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

7. Более высокое качество кода готового продукта

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

8. Бизнес-группа испытывает большее удовлетворение итоговыми результатами

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

9. Составление технической документации занимает меньше времени и содержит меньше ошибок

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

10. Более простое обслуживание приложения

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

Выводы

Если Agile настолько хорош, почему он используется не всеми организациями?

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

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

Смотрите также

Примечания