Agile-разработка: в чем ее суть

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

Уже в 1990-х годах команды разработчиков программного обеспечения начали работать с методами, которые сегодня можно считать agile-разработкой программного обеспечения. До конца 20-го века различные разработчики программного обеспечения и команды сделали многое, чтобы сделать программирование более легким, и поэтому метод стал известен в основном под ключевым словом «легкий». В это время были разработаны метод Scrum и Kanban, которые в то время нельзя было подвести под термин «agile разработка продуктов», поскольку такого выражения еще не существовало.

Наконец в 2001 году произошел явный перелом: На встрече, известной сегодня как Snowbird Meeting (по названию горнолыжного курорта в штате Юта, где проходила встреча), 17 разработчиков создали Agile Manifesto. Объединив свой опыт в разработке программного обеспечения и командной работе, они нашли решения, установили принципы и подвели итог под термином, который сегодня является синонимом современного способа работы: agile-разработка программного обеспечения.

Что такое agile-разработка программного обеспечения?

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

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

Факт

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

Ценности

Ценности agile-разработки ПО задают фокус, который команды должны всегда иметь в виду во время разработки. Они отмечаются как пары противоположностей; оба аспекта важны, но в agile-разработке один преобладает над другим:

  • Личности и взаимодействия над процессами и инструментами: Вовлеченные люди и их сотрудничество друг с другом важнее, чем вопрос конкретного процесса или инструмента.
  • Работающее программное обеспечение важнее исчерпывающей документации: Основное внимание уделяется функционирующему конечному продукту. Документирование работы, однако, имеет второстепенное значение.
  • Сотрудничество с клиентами вместо переговоров по контракту: При разработке продуктов Agile больше внимания уделяется удовлетворению потребностей клиента и его требований, чем ведению переговоров по контракту.
  • Реагирование на изменения вместо следования плану: Предполагается, что разработка программного обеспечения должна реагировать на постоянные изменения. Может возникнуть необходимость отменить ранее составленный план.

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

Принципы

Более конкретными инструкциями являются двенадцать принципов Agile Manifesto. Они предоставляют дополнительную информацию и расширяют ценности. Но даже здесь это не настоящие инструкции — инструкции это не то, что хочет предоставить Манифест. Принципы носят широкий характер и служат для отличия agile от не agile методов.

Удовлетворение потребностей клиентов: Благодаря ранней и непрерывной публикации — в смысле непрерывной доставки — клиент должен быть удовлетворен в любое время.

  • Гибкость: Agile-команды всегда оценивают изменения как нечто положительное, даже если они появляются поздно в процессе разработки. Если следовать манифесту Agile, адаптация к изменившимся требованиям дает заказчику конкурентное преимущество.
  • Доставка: Функциональное программное обеспечение поставляется непосредственно в течение нескольких недель или месяцев. Более короткие сроки всегда приветствуются.
  • Сотрудничество: Разработчики и коллеги по продажам должны работать в тесном сотрудничестве. Манифест Agile рекомендует проводить ежедневные совещания.
  • Поддержка: Для того чтобы мотивированные личности и творческие команды работали хорошо, окружающая среда также должна быть подходящей для них. Им нужна поддержка окружающих и, прежде всего, доверие начальства.
  • Разговорная культура: Прямое общение лучше всего подходит для передачи информации максимально эффективно и без недопонимания. Разговор лицом к лицу друг с другом позволяет задавать вопросы и избегать неверных выводов.
  • Успех: Успех команды может быть измерен, прежде всего, публикацией функционального программного обеспечения.
  • Устойчивость: Имеет смысл, чтобы разработка продолжалась равномерно. Все участники, а не только разработчики, должны продолжать работать над релизами.
  • Качество: Разработчики должны всегда следить за тем, чтобы их продукты соответствовали самым высоким техническим и дизайнерским стандартам.
  • Простота: Вы должны делать свою работу как можно проще. Отказ от всего, чего можно избежать, ведет к более бережливому процессу и, следовательно, к лучшим результатам.
  • Организация: Только если вы дадите командам возможность самоорганизоваться, вы можете рассчитывать на выдающиеся результаты.
  • Ретроспектива: Важным аспектом гибкой разработки программного обеспечения является постоянное задавание вопросов самому себе. Для постоянного улучшения работы команды важно, чтобы ее члены регулярно обменивались информацией о том, как они работают, и соответствующим образом адаптировали свой подход.
Примечание

Манифест Agile относит свои ценности и принципы исключительно к разработке программного обеспечения. Это объясняется компиляцией авторов. Разработчики собрались вместе, чтобы выработать лучший способ работы в области разработки программного обеспечения. Однако определенные пункты настолько широки, что их легко можно применить и в других сферах деятельности. Тогда Agile-разработка программного обеспечения становится agile-разработкой продукта, при этом «продукт» — это расплывчатое понятие, которое также можно рассматривать как услугу.

Техники

В среде agile-разработки программного обеспечения сложились определенные практики, с помощью которых можно реализовать agile-подход в своей команде или компании — «agile-разработка» является лишь зонтичным термином для этого. Многие из этих техник можно найти в формах agile-разработки ПО, например, Scrum, Kanban, Extreme Programming, Feature Driven Development, Behavior Driven Development или Crystal.

  • Бэклог: Для agile-подхода характерна идея списка, в котором собраны все задачи, которые еще должны быть выполнены, но над которыми в данный момент не ведется работа. Причиной этого являются короткие фазы работы. Вместо того чтобы решать несколько задач одновременно или назначать фиксированный срок для каждой задачи в большом плане, у вас есть гибкий пул в фоновом режиме. Команда может выбрать следующую задачу из этого пула.
  • Ретроспективы: Эти встречи не только присутствуют как абстрактный принцип в agile-методах, но и отчасти являются конкретным требованием. Особенно Scrum известен тем, что имеет фиксированный план различных встреч. Только если команда регулярно обсуждает задачи и проблемы, а также успехи, она может совершенствоваться в долгосрочной перспективе.
  • История пользователя: Требование сосредоточиться на клиенте или пользователе может быть удовлетворено с помощью пользовательских историй. Здесь используется простой язык для краткого объяснения того, что функция должна быть способна сделать для пользователя. Это описание записывается на так называемую карту историй и все карты сводятся в карту историй.
  • Agile-тестирование: В agile-разработке программного обеспечения тестирование рассматривается как неотъемлемая часть процесса разработки. Как правило, продукт тестируется в команде в конце итерации — короткого этапа работы — до того, как он считается «законченным» и передается заказчику. Только после этого начинается следующая итерация с новой задачей.
  • Парное программирование: Четыре глаза лучше, чем два — это верно и для парного программирования. Два разработчика делят одно рабочее место, и пока один из них пишет код, другой проверяет вводимые данные. Это требует больше времени (проверяющий может написать код самостоятельно), но должно уменьшить количество ошибок в коде.
  • Временной бокс: Некоторые формы гибкой разработки имеют строгие временные рамки. Опять же, хорошим примером является Scrum, где спринты имеют определенную продолжительность. В конце концов, команда должна представить готовый продукт. Для этого необходимо разработать и выбрать задачи соответствующим образом.

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

Плюсы и минусы гибкой разработки программного обеспечения

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

Плюсы

Минусы

Гибкость в работе с изменяющимися требованиями

Неточное описание метода разработки может привести к пористой практике работы

Творческие возможности

Открытость приглашает к эксплуатации и поддерживает непродуктивное поведение

Непрерывное совершенствование рабочих процессов

Сроки трудно соблюсти без долгосрочного плана

Быстро

Предполагает наличие предварительных знаний

Тесный контакт между всеми заинтересованными сторонами — прежде всего с клиентом

Дополнительная коммуникация стоит больше времени

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

Лучше всего работает, когда вся команда работает в одном месте

 

Оцените статью
cdelat.ru
Добавить комментарий