Agile

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

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

Agile-манифест разработки ПО

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

  1. Люди и взаимодействие важнее процессов и инструментов
  2. Работающий продукт важнее исчерпывающей документации
  3. Сотрудничество с заказчиком важнее согласования условий контракта
  4. Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. Важно понимать, что мы не отрицаем то, что написано в правой части манифеста. Мы только говорим о том, что мы больше ценим написанное в левой части чем то, что написано в правой части.

Основополагающие принципы Agile-манифеста

  1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
  2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
  3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
  4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
  5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
  6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
  7. Работающий продукт — основной показатель прогресса.
  8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
  9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
  10. Простота — искусство минимизации лишней работы — крайне необходима.
  11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
  12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Из этих принципов важно понять, что главная цель – удовлетворить заказчика (бизнес, стейкхолдеров, пользователей).

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

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

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

Постоянное самосовершенствование является одним из ключевых факторов достижения цели проекта.

Роли

Ответственность за результат делится между тремя ролями:

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

Agile-методологии

  • Agile Data Method — группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд.
  • Agile Modeling — набор понятий, принципов и приёмов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения. Не включает в себя детальную инструкцию по проектированию, не содержит описаний, как строить диаграммы на UML. Основная цель: эффективное моделирование и документирование; но не охватывает программирование и тестирование, не включает вопросы управления проектом, развёртывания и сопровождения системы. Однако включает в себя проверку модели кодом.
  • AUP (Agile Unified Process) упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений.
  • ASD (adaptive software development, адаптивная разработка).
  • Crystal Methods - семейство методологий (the Crystal family), разработанных Alistair Cockburn в середине 1990х. Все методологи семейства Crystal строятся на следующих базовых принципах: "усиленная коммуникация" + "облегченные рабочие продукты". Количество методологических элементов можно уменьшать для того, чтобы чаще выпускать работающие варианты системы и как можно шире использовать каналы межличностного общения. Оба эти принципа можно легко применять и видоизменять в любом проекте.
  • DSDM (Dynamic Systems Development Method) основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.
  • EssUP (Essential Unified Process).
  • FDD (Feature driven development, функционально-ориентированная разработка)
  • Getting Real — итеративный подход без функциональных спецификаций, использующийся для веб-приложений. В данном методе сперва разрабатывается интерфейс программы, а потом её функциональная часть.
  • Бережливая разработка программного обеспечения (англ. lean software development) использует подходы из концепции бережливого производства.
  • OpenUP — это итеративно-инкрементальный метод разработки ПО. Позиционируется как лёгкий и гибкий вариант RUP. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.
  • Scrum
  • XP (eXtreme Programming, экстремальное программирование)

Гибкое моделирование

Метод описания архитектуры программной системы, который следует идее того, что содержимое важнее представления. Это обеспечивает простоту, понятность, достаточную точность и единообразие создаваемых моделей. Простота документа гарантирует активное участие заинтересованных сторон в моделировании артефактов. Более подробно этот подход рассматривается в книге Скотта Амблера «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (J. Wiley, ISBN-10: 0471202827, ISBN-13: 978-0471202820; Питер, ISBN 5-94723-545-5, 0-471-20282-7).

Критика

  • При agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
  • Считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.

См. также

Ссылки

Примеры внедрения agile и других гибких методов в системной инженерии:

Комментарии