Обзор методов agile — Дмитрий Гуков на

Основные идеи и принципы

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Эти идеи раскрываются в 12 принципах AgileManifesto[1]:

1. работающий конкурентоспособный продукт, удовлетворяющий заказчика — лучший показатель прогресса и измеритель эффективности;
2. оперативная и бесперебойная поставка продукта, удовлетворяющего заказчика;
3. адаптивность продукта к новым требованиям, которые могут повысить его ценность и конкурентоспособность (возможность внесения изменений на любом этапе разработки);
4. простота и прозрачность технических решений, документации, процессов и инструментов, чтобы не создавать лишней работы;
5. частая поставка функционирующего продукта (раз в месяц/неделю или ещё чаще);
6. постоянный темп работы всех участников проекта на протяжении всего его срока;
7. минимизация организационных и информационных барьеров, лучший путь передачи информации — это личный разговор лицом к лицу;
8. тесное и ежедневное общение исполнителей с заказчиком в течении всего проекта;
9. мотивация участников проекта и обеспечение их всеми необходимыми условиями работы, поддержкой и доверием;
10. самоорганизация и самоконтроль команды проекта;
11. непрерывное улучшение профессиональных компетенций команды проекта;
12. систематический анализ и постоянный поиск возможностей оптимизации командной и индивидуальной работы.

Основные принципы agile

Четыре ценности и 12 принципов Agile сформулированы в уже упомянутом Манифесте. При этом ценности были сформулированы в первую очередь, а принципы авторы расписали позднее. Именно ценности являются основой Agile, а их непонимание — источником мифов об Agile.

Ценность 1. Люди и взаимодействие важнее процессов и инструментов

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

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

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

Ценность 2. Работающий продукт важнее исчерпывающей документации

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

Большая часть этой документации не несет также и ценности клиенту! Сначала создайте продукт, а потом документируйте его.

Ценность 3. Сотрудничество с заказчиком важнее согласования условий контракта

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

Ценность 4. Готовность к изменениям важнее следования первоначальному плану

Из этой формулировки следует миф о том, что в Agile нет планирования. Это неверно. Гибкие подходы создавались для условий неопределенности и частых изменений. Предварительное планирование, то есть подход, когда мы сначала долго планируем проект, распределяем ресурсы и задачи, не работает.

Конечно, оно несет определенную пользу, но приоритет отдается планированию оперативному. Как правило, горизонт детального планирования задач составляет 2-4 недели. Если все вокруг меняется часто — ваши планы тоже должны.

Мы не будем разбирать все 12 принципов — этого хватит на несколько статей. Я рекомендую прочесть эту часть манифеста самостоятельно. 

Есть еще одна базовая вещь, которую важно знать для понимания Agile — итеративно-инкрементальный подход.

Итеративно-инкрементальный подход

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

Итеративный и итеративно-инкрементальный подходы. Автор иллюстрации Jeff Patton

Разрабатывая продукт небольшими итерациями, мы получаем возможность не только раньше поставить ценность клиенту. Что гораздо важнее, мы получаем обратную связь от заказчиков. Ценно ли то, что мы делаем? Туда ли мы идем? Поставленная цель еще актуальна? Ответить на эти вопросы можно, только предоставив пользователю что-то, что он может использовать, потрогать.

Чтобы добиться этого, мы декомпозируем наш продукт на более-менее независимые ценные элементы. В Scrum список таких элементов называется «бэклог», однако по сути это приоритизированный лист пожеланий относительно функциональности нашего продукта.

Закон Парето гласит, что 20% усилий дают 80% результата. Иногда даже этих 80% нашего бэклога бывает достаточно для нас или нашего заказчика.

Agile — философия, scrum — ее реализация

Таким образом, Agile — это не методология разработки, а система ценностей, помогающих разработчикам делать новые продукты быстрее и с бОльшим эффектом для бизнеса:

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

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.

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

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

• Если Agile-мышление не свойственно людям, Scrum приводит лишь к удорожанию разработки, поскольку нужно больше времени выделять на коммуникации и обратную связь, требуются новые роли, нужны ресурсы на обучение, на повышение взаимозаменяемости сотрудников и т.д.
• И наоборот: без конкретного подхода (вроде Scrum) Agile останется лишь красивой философией — абстракцией, которую большинство людей не смогут превратить в руководство для повседневной работы.

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Гибкость против жесткости: agilevswaterfall

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

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

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

За пределами концепции

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

В частности, для анализа модели зачастую необходимо ее упростить, чтобы сэкономить время на сложные расчеты и симуляции. С помощью Creo инженеры могут быстро удалить ненужные конструкторские элементы, а аналитики — внести изменения в модели и провести испытания до передачи обратно конструктору. Осваивать сложное параметрическое моделирование при этом не требуется.

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

Еще одним «узким» местом, влияющим на скорость подготовки к производству, является необходимость внесения изменений в модель в процессе согласования с заказчиком. Гибкое моделирование минимизирует время, затрачиваемое на этот процесс: внести изменения можно максимально оперативно — прямо в процессе обсуждения или совещания.

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

Таким образом, гибкое моделирование предоставляет инструменты для решения проблем, с которыми сталкивается большинство разработчиков. Flexible Modeling позволяет разработчикам уменьшить количество итераций, а предприятию — экономить время и деньги, сокращая время разработки и проверки изделий, а также упрощая процессы утверждения моделей и взаимодействия с партнерами.

САПР и графика 5`2022

Инструменты agile

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

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

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

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

Существует множество цифровых аналогов этих инструментов с впечатляющим функционалом. Однако при перемещении красочных досок и флипчартов с графиками в диджитал-пространство обычно теряется эффект «радиации» информации.

У нас и так очень много каналов в телефоне и компьютере — и часто полезная информация с досок проигрывает конкуренцию другим каналам вроде почты и мессенджеров. В итоге участникам снова нужно тратить силы на поиск и восприятие этой информации.

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

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта.

В Scrum рабочий процесс делится на равные периоды от 1 до 4-х недель (спринты), в зависимости от проекта и команды. Перед стартом каждого спринта на митинге формулируются его задачи, а в конце обсуждаются результаты. Краткосрочность и измеряемость спринтов позволяет эффективно управлять проектной деятельностью, не перегружая участников проекта авралами [4].

В отличие от Scrum, в команде канбан отсутствуют роли владельца продукта и модератора, а процесс разработки делится не на универсальные спринты, а на стадии выполнения задач («Планируется», «Разрабатывается», «Тестируется», «Завершено»).

Канбан, как и другие практики бережливого производства, пришедшие из Японии, направлен на достижение баланса и выравнивание нагрузки исполнителей. Эффективность работы оценивается по среднему времени жизни задачи, от начальной до конечной стадии. Если задача прошла весь путь быстро, то команда проекта работала продуктивно и слаженно.

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5].

Модель cynefin.

Согласно изречению Эдварда Деминга, потребитель – самый главный элемент производственного процесса.

И что? Потребитель есть разный, где-то он знает что хочет, где-то не знает. Есть производитель, который близок к своему потребителю или далек. Знает как удовлетворить потребность или не знает. Много всяких условий и контекста.

И у нас возникает определенный конфликт. Waterfalls — традиционный подход к проектам с длительным планированием или Agile — где все быстро и все меняется со скоростью света.

Товарищ Сноуден, не тот о котором можно подумать, а Дейв, в начале 2000х разработал удобную управленческую модель для работы с проектами. Эта модель успокоила фанатов традиционных способов управления проектами и сбила спеси с любителей agile. В эту модель укладывается всё, уживаются рядом и waterfalls и agile.

В модели описываются 4 вида систем с разной степенью неопределенности:

1. Упорядоченные простые

2. Упорядоченные сложные

3. Комплексные

4. Хаотичные

Упорядоченные простые.

Здесь понятны: цель, результат, ресурсы, есть опыт у команды, понятен контекст задачи.

Например: производство чего-то простого, например, мебели. Методы управления: каскадный, waterfalls.

Упорядоченные сложные.

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

Например: запуск ракеты, строительство многоквартирного дома.

Методы управления: PMBok, Prince2, PMI

Комплексные системы.

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

Пример: стартап

Методы: scrum, другие методы agile.

Хаотичные системы.

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

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

Область применения agile

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

Судя по числу участников исследования Agile в России 2022, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

Agile — это уже давно не только про разработку программного обеспечения.

Но это не значит, что гибкие подходы есть смысл применять везде без ограничений.

Одно из ключевых ограничений Agile кроется в словах «для разработки новых продуктов». Пусть «продукт» здесь употребляется в самом широком смысле, но вот новые продукты все-таки разрабатывает лишь небольшой процент людей. А особенно эффективно Agile себя проявляет лишь в творческой работе и/или в условиях неопределенности.

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

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).

Общие проблемы

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

Но в реальности эффективно использовать 3D­файлы удается не всем: конструкторский замысел часто бывает забыт или утрачен, а без этого наработки оказываются бесполезными. 40% разработчиков, опрошенных PTC, отметили, что испытывают сложности с изменением моделей других конструкторов, даже если они были созданы в той же системе САПР (CAD).

И это неудивительно: найти того, кто занимался разработкой предыдущей модели, как правило, весьма сложно или невозможно. Так, 35% респондентов рассказали об изменениях в составе рабочих групп: они присоединялись к проектной группе или покидали ее в течение конструирования последнего изделия.

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

В результате вместо простой интеграции важных данных разработчикам приходится заниматься воссозданием модели в используемом рабочем формате. 49% разработчиков испытывают трудности при импорте моделей из других средств CAD с помощью своего текущего программного обеспечения 3D CAD, а 59% — при изменении импортированных моделей. Все это отнимает время и отвлекает от основной работы.

44% разработчиков отметили, что вынуждены вводить много изменений в процессе работы над моделью. 37,9% конструкторов упомянули, что сталкиваются с необходимостью внесения изменений на поздних этапах цикла разработки изделия, а это влечет за собой возникновение серьезных проблем.

Преимущества и недостатки

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

Недостатки Agile являются прямым следствием его достоинств:

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

Примеры проектов и применение agile

Кейсов применения Agile в мире великое множество, и наша страна тоже не отстает. В первых рядах практиков гибких подходов в России стране идут IT-компании. За ними следуют банки и страховые компании. В основном это команды, так или иначе связанные с ИТ. Однако есть и менее типичные кейсы.

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

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

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

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

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

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

Совсем большой масштаб требует дополнительных процессов, таких как Nexus, LeSS или SAFe. Известен кейс создания самолета 5-го поколения компании Saab. Модель Gripen-E создавали больше 100 команд, каждая из которых разрабатывала свой блок, узел или подсистему, в результате чего удалось добиться впечатляющих характеристик продукта при соблюдении установленных ограничений.

Существует ли agile в россии

Чем agile отличается от scrum

Scrum — термин из регби, по-русски — схватка. Название подходу придумал Кен Швабер, один из авторов Скрама и фанат регби. Судя по всему, количество игроков и то, как они всей командой собираются вокруг мяча, напомнило ему команду, работающую по Скраму. Кен Швабер и Джефф Сазерленд создали Скрам в 90-е (а через почти 10 лет участвовали в написании Agile-манифеста).

Так выглядит Скрам в регби

Скрам — это процессный фреймворк, предназначенный для создания, поставки и поддержки сложных продуктов. Это цитата из официального «Руководства по Скраму», и некоторые слова в ней нуждаются в пояснении. 

Фреймворк — это каркас, основа для процесса. То есть Скрам дополняется разными практиками, необходимыми для создания полноценного процесса для одной команды, разрабатывающей любой продукт.

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

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

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

Сложность продукта может происходить из:

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

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

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

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

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

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

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

Чем agile отличается от методологий

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий.

RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

Методология — это совокупность методов и приемов, которые используются в разных сферах деятельности.

Метод — это способ достижения какой-либо цели.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

В отличие от методологий, методов и фреймворков разработки ПО, в основе Agile — не конкретные процессы и даже не элементы процессов, а высокоуровневые ценности.

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

Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2022), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.