Agile — это не методология, как её многие называют. Это философия гибкого подхода к работе и система ценностей, которая задаёт направление действиям команды.
В этом тексте последовательно проведём сквозь гибкую философию. Начнём с ценностей и принципов.
Ценности и принципы Agile
Agile опирается на четыре ценности и 12 принципов, записанных в манифесте. Они направлены на постоянное корректирование хода работы, отслеживание процессов, общение команды между собой и с заказчиком.
Ключевое, что надо знать:
- В центре внимания — клиент. Это позволяет создавать ценные продукты
- Команда быстро адаптируется к новым условиям
- В коллективе плоская иерархия, самоорганизация, равная ответственность, а каждый член команды обладает базовыми знаниями из сфер коллег
- Нет долгосрочных дедлайнов, и работа идёт небольшими блоками
Создание манифеста Agile — история разочарования в традиционных методах. На заре нулевых модели разработки программного обеспечения, где работа строилась последовательно по чёткому сценарию, уже не успевали за переменами на рынке. Тогда в 2001 году 17 разработчиков создали «Манифест Agile». Его можно прочитать по ссылке.
Вот четыре принципа работы из манифеста:
✅ Люди и взаимодействие важнее процессов и инструментов
✅ Рабочее программное обеспечение важнее комплексной документации
✅ Сотрудничество с клиентами важнее переговоров по контракту
✅ Реагирование на изменения вместо следования плану
А вот 12 принципов Agile:
▶️ обеспечивай удовлетворённость клиентов за счёт своевременной и непрерывной поставки ценного продукта
▶️ прими перемены
▶️ выпускай продукт часто, добивайся результата на протяжении всего проекта
▶️ работайте сообща
▶️ создавай проекты вокруг мотивированных людей
▶️ личное общение — лучший метод передачи информации
▶️ продукт не должен быть идеальным, он должен работать
▶️ продвигай постоянный и устойчивый способ работы
▶️ уделяй внимание техническому совершенству
▶️ простота имеет важное значение
▶️ самоорганизующиеся команды принимают лучшие решения
▶️ регулярно размышляй о том, как стать более эффективным
Теперь давай про то, кому будет комфортно работать с такими ценностями и принципами.
Кому подойдёт Agile
По характеру проектов
Гибкие подходы подходят проектам, которые часто меняются или имеют открытые требования — например, разработка мобильных или веб-приложений. Никакие предварительные интервью и оценки рынка не дадут 100% верный ответ на вопросы, что именно нужно клиенту и на что направить усилия.
Сверяйся со схемой для выбора подхода:
Если говорить о компании в целом, то Agile подходит, если она:
- нацелена на оптимизацию работы
- работает на рынке, который требует постоянных инноваций
- часто сталкивается с неопределёнными требованиями клиентов
- стремится к улучшению сотрудничества внутри компании
По типу команды
Чтобы оценить совместимость команды с философией Agile, ответь на вопросы:
- Способны ли члены команды быстро думать и адаптироваться к меняющимся потребностям?
- Прокачаны ли у них навыки коммуникации?
- Могут ли они находить решения сами, а не ждать указаний сверху?
Одно из главных преимуществ небольших команд — простое общение, а как раз это и нужно для гибкости. В большой команде коммуникацию выстроить сложнее.
Рисунок Ричарда Хэкмена, профессора Гарварда и специалиста по командной динамике, как раз иллюстрирует, как сложно общаться и выстраивать связи в больших командах:
Но размер — не главное, важнее качества команды.
Для работы по Agile команда должна:
- Готовиться к настоящей командной работе. В Agile не получится отсидеться без лишних контактов с руководством и коллегами — придётся активно участвовать в работе других людей
- Быть профи в своей области. Или стремиться к этому. Обладать высокой самодисциплиной — или стремиться к этому. Мотивацией — или… ну, ты понимаешь
- Отказаться от вертикали власти в стиле руководитель-подчинённый. Agile основан на принципах совместной работы, где мнение каждого ценно. Не каждая организация способна адаптироваться к этому
- Уметь отбрасывать неактуальные результаты работы и провальными гипотезами. Команда должна понимать формат гибкой работы, чтобы не страдать от ощущения бесполезного труда
- Открыться командной работе и обучению
Сферы применения Agile
Agile пришёл из программирования и отлично чувствует себя в сфере IT. Со временем философия разошлась дальше — и теперь используется в продажах, производстве, финансах, HR, поддержке и маркетинге.
Agile в разработке
Agile придумали, чтобы ускорить процессы разработки ПО и повысить качество результатов.
Вот как это работает:
- Обновления продукта выходят постепенно и в краткие сроки — итерациями
- Работа над новым инкрементом (приростом функциональности) длится в среднем от двух до четырёх недель
- Клиенты имеют доступ к продукту на всех стадиях
- Планы свободно корректируются
- Источник изменений — фидбек от клиентов
- Регулярное тестирование — обязательная часть разработки
Agile в производстве
Работают те же принципы, что и при разработке ПО. При этом надо учитывать, какой продукт развивается:
- Для цифровых продуктов подходят те же принципы, что и для разработки. Продакт-менеджер внедряет изменения, собирает и передаёт запросы пользователей, руководит итерациями
- Для физических продуктов это работает немного по-другому. Возьмём производство корма для животных: можно пересматривать содержание кормов, выводить из ассортимента неликвидные линейки, придумывать новые форматы, анализировать фидбек от покупателей и по нему улучшать линейку
Agile в поддержке
Вот как принципы манифеста помогают организовать работу поддержки:
- Поддержка переходит в удобные для клиента чаты и мессенджеры и повышает доступность
- Команды в техподдержке отдельные, самостоятельные единицы, которые хорошо знают продукт
👉 Кстати, у сервиса «Мовавика» есть кейс внедрения Agile-подходов в службе поддержки — советуем посмотреть ролик с руководительницей отдела техподдержки
Agile в маркетинге
Agile поможет маркетологам быстро реагировать на изменения в поведении потребителей, технологиях и рыночных тенденциях.
В гибком маркетинге:
- Работают гипотезами — гипотеза выдвигается, быстро проверяется, затем идёт следующая. Такой вариант итераций
- Маркетинговая кампания адаптируется и развивается на основе фидбека от рынка и клиентов, плюс на базе отчётов
- Планирование строится на короткий срок — месяц, максимум квартал
Agile в продажах
Здесь гибкость бьёт частые проблемы области — нехватка ценности, клиентоориентированности и медленная реакция:
- Общение с клиентом по принципу обмена ценностями — для клиента создают ценность, в обмен он отдаёт деньги
- Постоянный фидбек задаёт направление движения отделу продаж
- Быстрая реакция на запросы клиентов и рынка
Agile в сфере финансов
Гибкие подходы помогают расшевелить довольно традиционную область, внедрить технологии, автоматизацию, межкомандное сотрудничество.
- Внедрение технологий и автоматизаций. Вместо ручного перевода из 1С в Excel, а затем из Excel в PowerPoint — автоматизация отчётов и аналитики, построение дашбордов
- Открытость и отчёты в режиме реального времени — заинтересованные стороны сами анализируют данные, генерируют информацию и принимают решения
- Финансовая команда, бизнес-подразделения и высшее руководство сотрудничают — общаются, держат обратную связь, обмениваются аналитикой
Agile в HR
В сфере управления персоналом Agile используется:
- Для сбора фидбека у соискателей и сотрудников — что устраивает, а что хотелось бы изменить. Потом процессы адаптируются и меняются
- Для мотивации сотрудников к обучению и развитию навыков
- Чтобы побуждать команды обсуждать проекты, предлагать идеи и принимать предложения других
- Для поощрения сотрудничества между командами вместо конкуренции
- При гибком подходе сотрудники могут заменять друг друга, развиваться внутри команды, менять там должность и даже специализацию — красота!
Преимущества и недостатки Agile
✅ Плюсы — если сделать всё правильно
- Команда способна адаптироваться к любым переменам
- Сотрудники ответственны и вовлечены в общее дело
- Лучше соблюдаются сроки в проектах с жёсткими дедлайнами
- Продукт получается нужным и качественным
☝️ Минусы — или подводные камни
- Всё завязано на команде и её мотивации
- Нет чёткого долгосрочного плана работы
- Не получится быстро перестроиться с негибких методологий на гибкие — и обратно
- Не получится быстро развернуть компанию в сторону Agile. Здесь требуется время
Инструменты и методы Agile
Рассмотрим пять основных инструментов и методов философии Agile.
Канбан
Основан на визуализации потока работы: задачи проекта передвигаются по колонкам на Канбан-доске. Колонки обозначают этапы работы. По умолчанию они такие: К работе, В работе и Готово.
Канбан позволяет оценить планы и объёмы, нагрузку сотрудников, скорость работы. Уделяет большое внимание незавершённым задачам и «узким горлышкам» — этапам, где дела буксуют.
Канбан — универсальный метод организации работы. Идеально подходит для разработки, но с ним удобно строить процессы и в маркетинге, продажах, HR.
👉 Про метод Канбан у нас есть подробный текст
Так выглядит бэклог продукта на доске, где колонки разделены по кварталам
Канбан используется в создании дорожной карты. Визуализация работы на досках и разбивка задания на выполнимые задачи поддерживает согласованность команды, прозрачность и оперативность в течение всей жизни проекта.
Это вариант формирования дорожной карты на доске
В WEEEK есть готовый шаблон Дорожной карты. Чтобы воспользоваться им, зайди в свой аккаунт в WEEEK и слева внизу найди Шаблоны.
Scrum
По фреймворку Scrum продукт создаётся сериями — спринтами. У каждого спринта есть цель, задачи и срок — от одной до четырёх недель. По итогам этого срока (за одну итерацию) появляется прирост функциональности продукта — инкремент, или улучшение в продукте.
В этом и заключается гибкость: команда быстро реагирует на внешние запросы и учитывает их при планировании на коротких промежутках. Команды в Scrum всегда небольшие, что упрощает контроль за процессами.
👉 Про Scrum у нас есть отдельный текст
Lean
Или «бережливое производство» — про то, как делать больше и лучше, а тратить меньше.
Элементы Lean:
- Главная ценность — клиент и то, что он хочет от конкретного проекта или продукта
- Продукт создают по запросу в указанном количестве. Никакого производства «про запас» и складирования
- Оптимизация за счёт устранения отходов. Это удаление неважных процессов: ненужных встреч, лишней документации, неэффективных методов
- Обеспечение непрерывного потока работы через балансировку рабочей нагрузки, разбивку этапов, обучение сотрудников
Экстремальное программирование (XP)
Лучшие практики гибкого программирования, выкрученные на максимум.
В традиционном программировании есть код-ревью — это когда одни программисты проверяют код других перед попаданием его в проект. А ХР-программисты применяют парное программирование: один разработчик пишет код, а второй тут же проводит код-ревью и следит за ошибками.
ХР похож на Scrum, но предполагает более тщательное планирование и правила. Характерная черта — активное участие и команды, и клиентов в разработке продукта. Ещё тут есть чёткий набор практик: разработка через тестирование, планирование отдельных итераций ПО и интеграции между ними.
Crystal
Crystal основан на первом принципе манифеста: «Люди и взаимодействие важнее процессов и инструментов».
Есть четыре варианта системы Crystal:
⚪ Чистый: для команд 1–6 человек с объектно-ориентированными проектами
🟡 Жёлтый: для средних проектов с участием нескольких команд
🟠 Оранжевый: для крупных проектов с дополнительными сложностями
🔴 Красный: для крупномасштабных проектов со значительной сложностью и рисками
Crystal признаёт, что команды разного размера по-разному работают над проектами разного приоритета, — и призывает адаптировать фреймворк:
- небольшая команда может поддерживать регулярное общение — не нужно много отчётов о состоянии и документации
- большая команда потеряет в синхронизации, но в целом выиграет от более структурированного подхода
Как выбрать инструмент или метод из Agile для своей команды
🔸 Определи масштаб, цели и задачи проекта
- Поговори с заинтересованными сторонами и узнай их ожидания
- Определи размер проекта, его сложность и сроки достижения результатов
🔸 Проведи анализ знаний команды о методах и фреймворках Agile:
- Что им известно о гибких методиках
- Есть ли опыт работы в Agile и его методологиях
🔸 Выяви ограничения проекта: бюджет, время, ресурсы
- Узнай, можно ли адаптировать выбранную тобой методику к этим ограничениям
🔸 Изучи фреймворки, пойми их цели, принципы и роли, связанные с каждой структурой
🔸 Сравни плюсы и минусы каждой методики с требованиями проекта. Учитывай гибкость каждой структуры для внесения изменений по ходу работы
🔸 Оцени размер проектной команды
🔸 Оцени сложность и масштаб проекта:
- Для сложных проектов подойдёт Scrum. Сложные проекты отличает высокий уровень нагрузки, сжатые сроки и большее количество рисков. Итерации помогают вовремя отследить эти проблемы, чтобы перераспределить нагрузку, отработать риски и скорректировать дедлайны
- Для небольших, быстроразвивающихся проектов с меняющимися приоритетами — Kanban и Crystal
- Для стабильных, давно существующих процессов и продуктов — Lean
- Для сработавшейся команды и динамичных проектов — XP
🔸 Учитывай сроки реализации проекта и его совместимость с фреймворками:
- Scrum хорошо работает в проектах, которые можно разделить на множество итераций фиксированной длины
- Kanban предполагает непрерывность
🔸 Оцени важность обратной связи и итераций
- Определи, насколько важны регулярная обратная связь и итерации для успеха проекта. Например, в Scrum и XP упор делается на частую обратную связь и итерации
🔸 Оцени культуру организации и готовность принять Agile-практики. Выбери Agile-структуру, которая вписывается в ценности и принципы компании
Как внедрить Agile в управление проектами
Agile внедряется в команду в пять этапов.
Изучить положение дел
Внедрение методологий всегда нужно начинать с анализа текущего положения дел — business as is — чтобы понять, что работает, а что нет. К примеру, новые фичи клиентам неинтересны, они не удерживают и не привлекают аудиторию, а команда деморализована и работает вяло.
Значит, пригодятся такие сильные стороны гибкого подхода:
✔️ выпускать проекты быстрее и с меньшими рисками
✔️ освободить ресурсы и обеспечить быстрое реагирование на запросы клиентов
✔️ улучшить сотрудничество
✔️ добиться прозрачности
✔️ повысить результативность
Далее нужно изучить свою команду: посмотреть, какие качества помогут реализовать внедрение Agile, а какие могут помешать. Например, вот так:
✔️ команда разработчиков и продукта из 10 человек — подходит
❌ команда не кросс-функциональная — не подходит, придётся многому учить
✔️ нормальная внутренняя коммуникация — подходит, но можно улучшить
✔️ команда молодая и готова учиться — подходит
Важно оценить, насколько команда готова к внедрению методологий управления. Это зависит от опыта работы по методологиям и в совместном цифровом пространстве — или желания этому учиться.
Если все звёзды сошлись, компания и проекты подходят для методов Agile. Выбрали метод и инструмент — переходим к внедрению.
Донести до команды новости про изменения и начать внедрение
Суть этапа — убедить команду, что изменения необходимы. Обычно придётся также переформировать команду, распределить роли и наладить систему приоритетов.
Этап состоит из нескольких шагов:
- Объяснить, зачем переходить на гибкие методы — рассказать причины изменений, подсветить преимущества гибкого подхода
- Отработать возражения — а они будут. Это поможет успокоить команду и помочь ей двинуться к гибкому мышлению
- Сформировать атмосферу поддержки — призвать к открытому диалогу, обеспечить обучение. К примеру, дать время на изучение манифеста и принципов Agile, отвечать на возникающие вопросы
Теперь отдельно про формирование команды.
Сформировать команду и распределить роли
Даже в гибких подходах нужны чёткие командные роли. К примеру: Scrum-мастер, продуктовый менеджер, тимлид разработчиков, руководитель продукта.
Не получится просто отобрать людей внутри команды и сказать: «Ты теперь скрам-мастер, прими это и делай нам скрам!» Тут важны и хард, и софт-скиллы. Можно обучить членов команды на специальных курсов или найти спецов извне.
Для каждой роли нужно прописать чёткий пул обязанностей и зон ответственности. В этом помогут регламенты и описание должностей, зафиксированные в корпоративной базе знаний компании.
В распределении ролей и зон ответственности для отдельных проектов лучше использовать матрицы RACI и DACI. RACI указывает, кто и за что отвечает на проекте, а DACI устанавливает ответственность за принятие решения в той или иной ситуации.
👉 Классный текст про RACI и DACI
При этом команда остаётся гибкой — потому что её члены постоянно обучаются, вникают в обязанности и действия друг друга. А ещё поддерживают атмосферу открытости, когда даже джуны могут высказаться и поучаствовать в принятии решений.
❗Ещё крайне важны способности команды к самоорганизации — тут никуда без самодисциплины и ответственности. Если в команде преобладает инфантилизм, переходить к гибким подходам пока рано.
Внедрить правила приоритизации работы
На этом этапе надо определить, как команда будет решать, что разрабатывать, внедрять и изменять — то есть как будут строиться дорожная карта и бэклог.
Дорожная карта — это наглядное представление стратегических планов: то, каким будет продукт.
Роудмап создаётся совместными усилиями команды, но содержание в первую очередь определяют внешние факторы. Это желания пользователей — просьбы что-то исправить или добавить — и запросы стейкхолдеров. А ещё изменения на рынке и решения конкурентов.
Всю эту информацию собирают из разных источников обратной связи: кастдевов, продуктовой аналитики, CJM, отзывов, анкетирований и опросов. Потом, как правило, её анализируют СЕО, владелец продукта и продуктовый менеджер. Мнение этих членов команды и определяет содержание дорожной карты.
🤔 Где же здесь гибкость? В адаптации дорожной карты под запросы и внешние обстоятельства.
Пример. На дорожной карте запланирована важная функция — но на третий квартал, а сейчас только первый. Продуктом интересуется крупный клиент и хочет именно эту фичу. Гибкой команде стоит перестроиться, изменить планы и пересобрать дорожную карту, чтобы не упустить важную сделку.
Когда дорожная карта готова, на основе неё формируют бэклог.
Бэклог — планы по развитию продукта в более короткий промежуток времени: то, чем команда будет заниматься в ближайшее время.
Разделяют бэклог продукта — крупные планы по разработке и развитию на кварталы и годы вперёд, и бэклог спринта — детализированные планы по разработке и развитию на ближайшие 1–4 недели.
К составлению бэклога подключается уже вся команда. Надо хорошо понимать, хватит ли сил и ресурсов в этот промежуток времени, сколько задач потянет команда, как распределить усилия и расставить приоритеты.
Для формирования бэклога Agile-команды используют такие методы:
🔹 Planning Poker — оценка времени на задачу с помощью карт
🔹 ICE и RICE — методы приоритизации задач по двум формулам:
ICE считает три фактора: влияние (Impact), уверенность (Confidence) и лёгкость (Ease). Показатели оценивают в цифрах и умножают друг на друга.
RICE считает четыре фактора: охват (Reach), влияние (Impact), уверенность (Confidence) и усилия (Effort). Тоже считается умножением.
🔹 Story mapping. Метод идёт от пользователя — составляется история взаимодействия юзера с продуктом.
🔹 MoSCoW — метод определения приоритетов, который разделяет задачи на четыре группы: Must Have — обязательно сделать, Should Have — нужно реализовать, Could Have — хорошо бы сделать, W — фичи из разряда «хотелок» и дополнений
👉 У нас есть статьи о методах приоритизации бэклога и покере планирования
Оптимизировать работу
Нарисовать дорожную карту, составить бэклог и расставить приоритеты — всё это не гарантирует, что работа будет делаться, а команда не сгорит в первом же спринте.
Гибкой команде придётся… проявить жёсткость.
🔹 Определите пропускную способность работы. Ограничьте максимальное количество задач или часов нагрузки на каждом этапе рабочего процесса. В Agile такие ограничения называют WIP-лимиты (WIP — work in progress, работа в процессе).
WIP–лимиты вводят на Канбан–досках — на каждую колонку свой лимит. Они не позволяют впихнуть в колонку больше задач, чем было оговорено членами команды. Важно только, чтобы ограничения были оговорены совместно.
👉 Про WIP–лимиты мы всё рассказали в этом тексте
🔹 Следите за проблемами с помощью метрик. Это может быть время, затраченное на работу в общем и отдельные задачи, количество незавершённой работы на конец спринта, процент реализованных планов. И то, как часто нарушались WIP-лимиты.
🔹 Проверяйте ход развития продукта и состояние команды. Первое можно сделать с помощью общения с пользователями, второе — проводя ретроспективы, то есть внутренние встречи и созвоны по итогам работы.
И без гибкости тут тоже никуда — если что-то не работает, важно вовремя пересматривать правила и адаптировать формат работы.
Хоть Agile и гибкий подход, в нём много правил, нюансов и проблем — как и сложностей на пути. О них дальше.
Как работать с препятствиями и проблемами при внедрении Agile
Собрали частые проблемы Agile-команд и предложили решения. Все проблемы мы взяли из большого отчёта-опроса о состоянии дел в Agile-индустрии.
Сопротивление переменам
Порой команды сопротивляются изменениям — это нормально. Мы не любим менять привычки. А если речь о традиционных процессах и иерархии, то тут совсем сложно, ведь работать в предсказуемой среде проще.
✅ Решение
- Выяснить причины сопротивления: страх, неуверенность в своих силах, недостаток знаний. Часто банально не хватает ответа на вопрос: «Зачем нам это?»
- Рассказывать о плюсах гибких подходов с точки зрения компании и сотрудников
- Отдельно подчеркнуть, что обращаться к руководству по вопросам и проблемам — можно и нужно
- Дать людям обучение и наставничество! Без этого не получится никакой гибкости
- Вовлечь команду в процесс изменений: пригласить особо сопротивляющихся принять участие в организации процессов по-новому. Пусть выскажутся и расскажут свои идеи
Отсутствие подготовки и образования
37% респондентов заявили, что команды не понимают, что такое Agile и на что он способен.
✅ Решение
- Ознакомить команду с манифестом Agile для понимания базовых ценностей
- Найти и позвать в команду опытного тренера или консультанта по Agile
- Сделать внутреннюю программу обучения — например, собрать мини-библиотеку материалов про Agile
Нет поддержки со стороны руководства
Когда начальник сам не следует принципам Agile — то есть не даёт команде ни гибкости, ни свободы, ни поддержки, а только микроменеджерит.
✅ Решение
- Не внедрять гибкие подходы, если их принципы не отзываются, а просто кажется, что все так делают и это модно
Заинтересованные стороны не участвуют
Это лица, прямо или косвенно заинтересованные в результате проекта: клиенты, пользователи, менеджеры, спонсоры. Из-за плохого взаимодействия с ними у гибких команд не совпадут ожидания и приоритеты. Как итог — низкое качество продукта, срывы сроков, рост трат и вероятности рисков.
✅ Решение
- Наладить и поддерживать связь через встречи, письма и демонстрации. Общение должно охватывать видение проекта, цели, объём, прогресс, проблемы и риски
- Вовлечь в процессы — например, в планирование спринта или приглашать на ретро. Или сделать публичной дорожную карту. Либо наладить публикацию новостей об изменениях в продукте
- Делиться результатами — прототипами, макетами, каркасами, пользовательскими историями
Отсутствие доверия и прозрачности
Члены команды плохо знают друг друга, когда нет представления о целях, ролях и обязанностях проекта.
✅ Решение
- Описать структуру команды. Отразить там роли и должности, кратко описать зоны ответственности
- Внедрять инструменты, повышающие прозрачность. Например, таск-менеджер, через который видно, кто и чем занят, статусы задач и загруженность коллег
- Поощрять открытое и честное общение, быстро устранять конфликты. Отмечать успехи и неудачи, признавать и ценить вклад друг друга
Отличия Agile от других методологий
Есть понятие «гибкий зонтик». Мы тебе его уже показали — вот ещё раз.
Этот зонтик намекает, что Agile не методология, а значит, сравнивать его с другими методологиями некорректно. Зато сам Agile породил кучу методов, методологий, фреймворков, инструментов. Они-то и укрылись под зонтиком гибкой философии!
Сравнить Agile как подход к работе можно только с другим подходом. А именно с традиционным подходом — методом водопада, Waterfall:
| Особенность | 🌊 Водопадная модель | 🧘🏻 Гибкая модель |
|---|---|---|
| Подход | Каждый этап проекта завершается перед началом следующего | Этапы реализуются параллельно |
| Гибкость | Изменения вносить сложно и дорого, если проект уже находится в стадии реализации | Изменения вносятся даже на поздних стадиях |
| Планирование | В начале проекта составляется план, его изменения не приветствуются | Минимальное предварительное планирование. Планы меняются по мере продвижения проекта |
| Вовлечение клиента | Ограничено после этапа требований | Непрерывный и высокий уровень на протяжении всего проекта |
| Тестирование | Проводится после завершения этапа разработки | Интеграция на протяжении всех циклов разработки |
| Доставка | Единая в конце | Поэтапная доставка на протяжении проекта |
| Управление рисками | Риски выявляют и устраняют на начальных этапа | Рисками управляют на протяжении всего проекта |
| Обратная связь | Обратная связь обычно учитывается в будущих версиях | Обратная связь может быть включена в текущий проект |
| Объём проекта | Чётко определён в начале проекта, меняется редко | Динамичный и адаптируемый на основе постоянной обратной связи |
| Структура команды | Команды работают разрозненно в зависимости от фазы проекта | Межфункциональные, сотрудничающие команды |
| Документация | Комплексная, составляется в начале проекта | Облегчена и создаётся по мере необходимости |
| Пригодность | Подходит для проектов с чёткими и фиксированными требованиями | Подходит для проектов с меняющимися требованиями |
👉🏻 Про модель водопада у нас есть отдельный текст
Как использовать WEEEK для работы по Agile
WEEEK позволяет развернуть рабочее пространство как раз для работы по принципам гибких методологий.
Какие фичи в этом пригодятся:
✔️ Спринт-доски — для планирования спринтов, можно выставить период работы
✔️ Множество досок в одном проекте — подходит для учёта разных аспектов продукта
✔️ WIP-лимиты в досках — правила, которые ограничивают количество задач или рабочих часов на каждом этапе процесса
✔️ Трекинг времени и аналитика для управления загрузкой команды:
- Трекинг помогает отследить время, затраченное на отдельную задачу, — по таймеру и вручную. Пригодится для оценки продуктивности, оценки пропускной способности и оптимизации работ Agile-команды
- Сервис Аналитика поможет увидеть, кто, сколько и над какими задачами работал
✔️ Сервис Пользователи для создания и настройки команд
- Позволяет назначать роли пользователям и создавать собственные, с выбором доступов к сервисам и разделам
- Юзеров можно объединять в команды — так каждый участник сможет вникать в работу коллег и быть в курсе процессов
- Подробное описание пользователя в профиле: его должность, контакты, часы работы и другие детали
- Можно делиться промежуточным результатом с клиентами и заинтересованными сторонами с помощью роли Гость
У нас есть три гайда, которые помогут внедрить гибкий подход с помощью WEEEK:
Гибко переходим к главному
- Agile — не методология, а философия с собственным манифестом и принципами, основанная на адаптивности, гибкости и самоорганизации команд
- У Agile есть множество инструментов и методов, которые позволяют внедрить гибкость в разные по составу и характеру команды и разные проекты
- Гибкий подход позволяет создавать ценный для клиента продукт в короткие сроки
- Внедрять гибкость нужно только в тех областях, которые нуждаются в оптимизации
- Чтобы внедрить гибкий подход, придётся потрудиться — и команда должна быть к этому готова
- В WEEEK множество фич для гибкой работы: от спринт-досок и WIP-лимитов до аналитики загруженности пользователей
Подписаться 
