Agile: что это, принципы методологии управления проектами, примеры | Calltouch.Блог

Что такое пропускная способность

Пропускная способность – реализованное количество «пользовательских историй». Это пожелания клиентов, которые формируются в задачи. Например, установка фильтров поиска в приложении, улучшение обратной связи с клиентами, работа над службой техподдержки. Пропускная способность измеряется количеством отработанных пользовательских историй в неделю.

Основные этапы

Однако вернёмся к концепции гибкой разработки. Графически её можно представить следующим образом:

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

1. Планирование. Ограниченный по времени этап из-за большого числа итераций и постоянно меняющихся требований.
2. Обратная связь. Она может поступать от клиентов, программистов, тестировщиков и самих разработчиков — любых заинтересованных лиц.
3. Реализация. Собственно сама разработка кода и графики.
4. Тестирование. Автоматическое или ручное выявление ошибок и несоответствий требованиям заказчика.

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

Что почитать

Отечественный и зарубежный рынок насыщен книгами по гибкой разработке, поэтому интересующимся не составит труда найти себе подходящее чтиво. Вот мой список ТОП-3:

1. «Постигая Agile. Ценности, принципы, методологии», Эндрю Стеллман, Дженнифер Грин. Издательство O’Reilly редко разочаровывает, эта книга – определённо не исключение. В ней вы узнаете и про общую концепцию, и подробнее про Scum, Kanban, XP и Lean.
2. «Гибкая разработка программ на Java и C . Принципы, паттерны и методики», Роберт С. Мартин. Agile в прикладном применении.
3. «Пользовательские истории. Гибкая разработка программного обеспечения», Майк Кон. Истории правильного и неправильного применения гибкой разработки ПО, советы по внедрению конкретных методологий.

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

Что такое agile

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

С моей точки зрения, общепринятый перевод полного термина Agile software development как «гибкая разработка программного обеспечения» не очень точный. Авторы термина изначально рассматривали в качестве названия вариант Adaptive, и мне он кажется немного точнее, чем Agile.

Во-вторых, Agile — это философия, мировоззрение, выкристаллизованное из многолетнего опыта практиков. Прежде чем был сформулирован Agile-манифест, его авторы более 10 лет прорабатывали различные подходы к созданию ПО. Сейчас эти подходы известны как «гибкие», среди них — Scrum, eXtreme Programming, Crystal, Feature Driven Development и другие.

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

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

Вместо этого существует группа подходов, позволяющих реализовать ценности и принципы Agile на практике. Помимо упомянутых выше к ним относятся Nexus, LeSS, SAFe и некоторые другие.

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

Kanban

Метод основан на прозрачности процесса. Он функционально распределяет нагрузку на сотрудников, мотивирует членов команды на сотрудничество и обучение. Принципы строятся на:

• постоянной визуализации информации;
• командной работе для сбалансирования усилий;
• ограничении по времени для оптимизации процесса.

Scrum

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

Автономность команд

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

Беспрерывная работа

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

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

Внедрение agile

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

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

Где используется agile

Методика применялась в IT-индустрии и использовалась для разработки ПО. Суть сводилась к внедрению адаптивных методов, которые ускоряют создание продуктов через микропланирование и короткие производственные циклы. Однако впоследствии Agile стала использоваться и в других прикладных областях. Agile сейчас применяют  компании: Netflix, Spotify, Magna International, General Electric, Accenture, М.Видео.

Подобные технологии стали достоянием команд, работающих над созданием клиентских продуктов.

Гибкость методологии

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

Достижение стадии готовности

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

Идеи agile

Ценности Agile говорят, что:

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

Иерархия компетенции в agile

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

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

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

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

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

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

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

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

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

Историческая справка

В 1970 году Уинстон Ройс опубликовал статью под названием «Управление разработкой больших программных систем» (Winston Royce, «Managing the Development of Large Software Systems»). В ней он жестко прошелся по традиционной каскадной модели, показав, что при неитерационной разработке качество продукта получается низкое, а цена каждой ошибки начального уровня велика. Кстати, именно Ройс впервые ввел понятие водопада для описания последовательного программирования.

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

Как внедрить

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

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

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

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

Затем обучите команду. Для старта лучше всего подойдут широко распространенные подходы — Scrum или Kanban. По ним много материалов, проще найти курс для команды и нанять сотрудников, знакомых с методиками и инструментами. Выделите два или три дня для глубокого погружения участников команды и заинтересованных сторон в новый процесс.

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

Следующие шаги индивидуальны — кто-то запускает еще несколько команд. Другие запускают масштабную трансформацию, а некоторые вообще отказываются от Agile.

Как определить последовательность и приоритетность задач

Приоритетность задач зависит от направления компании. Например:

• Value Based – оценка ценности для бизнеса. Каждая задача изучается с точки зрения ее прибыльности, повышения репутации и общем уровне удовлетворенности пользователей.
• Technology Risk Based – оценка технологических рисков. Приоритет распределяется на основании риска реализаций требований. Риск в работе компании бывает из-за большого количества поставленных условий, внешнего взаимодействия. 

Как применять аджайл на практике

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

Эти принципы есть в так называемом «Agile-манифесте» — основном документе, содержащем описание ценностей и принципов гибкой разработки программного обеспечения, разработанном в 2001 году. Ниже мы выписали все принципы, но добавили в них один лишний. Сможете догадаться, какой из них не отражает суть аджайла?

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

Правильный ответ: принцип 6 — лишний. Это просто цитата из романа «1984» Джорджа Оруэлла.

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

Общение — ключ к успеху. Оно помогает сократить переделки

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

Результат — это то, чем можно пользоваться. Почему лучше сразу пользоваться, чем ждать, пока доделают?

Менять планы — не страшно. Что делать, если заказчик передумал

Работа — это что-то новое каждый день. Не знать — не стыдно, стыдно — не хотеть учиться

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

Проверьте, насколько хорошо вы усвоили материал:

Как составить график решения задач

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

Какие существуют роли по agile

Роли в системе:

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

Ключевые моменты в применении

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

Курица, яйцо и манифест

Идея гибкой разработки получила массу поклонников и, как следствие, ответвлений. Чтобы хоть как-то объединить их, в 2001 году свет увидел Agile Manifesto — идеологический набор правил разработки, что-то вроде «Цели и задачи в области качества» на предприятиях.

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

Маленькие кросс-функциональные команды

Сотрудники работают в небольших командах. Задача каждой в реализации одной из функций, которая важна для клиента. Численность и состав команд отличаются в зависимости от их задач. Число сотрудников в одной команде до 12 человек.

Манифест agile

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

Минусы agile

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

Некоторые организации очень беспокоят такие издержки. Их можно снизить, если создать для команды условия, в которых она сможет быстро и как можно менее болезненно ошибаться согласно неофициальному девизу Agile «Fail Fast — Fail Safe» («Ошибайся как можно раньше — ошибайся безопасно»). Однако такие структуры и среды также стоят дорого.

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

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

Обратная связь от пользователей на каждом цикле

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

Ограничение объема незавершенной работы

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

Плюсы agile

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

Плюсы и минусы agile

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

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

Недостатки:

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

Полная прозрачность и использование досок со стикерами

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

Популярные методы и средства управления проектами

Agile – система, в которой реализуют методы и подходы. Наиболее востребованные методы — Scrum и Kanban.

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

Начнём с плюсов:

1. Максимальная удовлетворённость клиента. У него есть постоянный контакт с разработчиками, его пожелания быстро находят отклик в проекте.
2. Благоприятная атмосфера в коллективе. Даже в случае разногласий эффективнее все решать словами.
3. Высокие цели. Постоянный фидбек предполагает внимание к мелочам, эргономике, соответствию трендам.
4. Безопасность. Множество итераций исключает существование ошибок, допущенных в самом начале.

Но есть и минусы:

1. Слабое внимание к документации. В случае возникновения претензий и конфликтных ситуаций аргументов в свою защиту у исполнителя просто не будет.
2. Проблемы с реализацией комплексных продуктов. Если в самом начале разработки были заложены ограничения — на поздних этапах исправлять их будет сложно.
3. Вероятность отказа клиентов в процессе разработки. Если у заказчика нет четкого понимания, что он хочет видеть на выходе — выполнять его требования очень сложно.
4. Влияние иерархии. Руководители принимают все решения, так как все процессы цикла реализуются параллельно. Важность рядовых программистов минимальна.

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

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

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

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

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

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

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

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

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

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

Принципы методологии

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

Работа над мини-блоками

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

Распространенные проблемы при реализации

Основные проблемы при внедрении Agile:

Резюме

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

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

Ценности аджайла

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

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

Теперь вы знаете о четырех ценностях аджайла:

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

Чем отличается от других методологий

Она не похожа на предыдущие подходы, описывающие создание продукта в деталях. Agile краток, в нем 4 ценности и 12 принципов. RUP в отличие от Agile – менее гибкая методология, при этом более объемная, описывает процесс работы на десятках страниц. RUP не подходит для небольших задач, состоит из итераций с продолжительностью от 2 до 6 недель. 

OpenUP – преемница RUP. В этой методологии проект делится на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Методология недостаточно гибкая в сравнении с Agile, применима больше в IT-сфере.

Заключение

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