Agile определяет ценности и принципы

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

Agile Manifesto разработан и принят 11—13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.

Основные идеи:

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

Основополагающие принципы Agile Manifesto:

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

Критика

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

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

Методологии Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto, некоторые из них:

Agile Modeling (англ.) — набор понятий, принципов и приёмов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения. Не включает в себя детальную инструкцию по проектированию, не содержит описаний, как строить диаграммы на UML. Основная цель: эффективное моделирование и документирование; но не охватывает программирование и тестирование, не включает вопросы управления проектом, развёртывания и сопровождения системы. Однако включает в себя проверку модели кодом. Agile Unified Process (AUP) упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений. Agile Data Method (англ.) — группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд. DSDM основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя. Essential Unified Process (англ.) (EssUP). Экстремальное программирование (англ. Extreme programming, XP). Feature driven development (FDD) — функционально-ориентированная разработка. Используемое в FDD понятие функции или свойства (англ. feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций. Getting Real — итеративный подход без функциональных спецификаций, использующийся для веб-приложений. В данном методе сперва разрабатывается интерфейс программы, а потом её функциональная часть. OpenUP — это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как лёгкий и гибкий вариант RUP. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение. Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения. Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта. Бережливая разработка программного обеспечения (англ. lean software development) использует подходы из концепции бережливого производства.

Agile — это образ мышления, основанный на ценностях и принципах Agile–манифеста.

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

Оригинал манифеста находится здесь: https://agilemanifesto.org/iso/ru/principles.html Видео, кратко объясняющее что такое Agile: https://www.youtube.com/watch?v=VRIevtlCdc4 Больше про то что такое Agile: https://leadstartup.ru/db/agile Agile-манифест разработки программного обеспечения

Мы постоянно открываем для себя более совершенные методы разработки

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

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

Мы следуем таким принципам:

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

это фреймвор

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

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