Коротко о главном
В 2001 году 17 уставших от бюрократии разработчиков встретились на горнолыжном курорте в штате Юта, чтобы составить манифест Agile (Agile Manifesto) — документ, в котором прописаны четыре ценности и 12 принципов гибкой разработки.
Позже содержимое манифеста стало отправной точкой в создании гибких методологий и фреймворков управления проектами. Документ не учит нас, как работать и управлять проектами, потому что это не методология. Agile-манифест можно назвать философией или базой, на которой строятся гибкие подходы.
Принципы и ценности Agile-манифеста применяют в работе не только разработчики, но и маркетологи, HR-отделы, продуктовые команды и все те, кому критически важно успевать реагировать на изменения, которые невозможно предвидеть, чтобы не тратить деньги, время и ресурсы на результат, который уже не нужен потребителю.
часто меняются
в одной системе,
чтобы не терять контроль
Что такое Agile
— гибкий подход к управлению разработкой ПО и другими проектами. Помогает командам быстрее адаптироваться к новым требованиям, выпускать рабочие версии продукта и улучшать результат через регулярную обратную связь
Agile опирается на ценности манифеста:
🔹 Адаптивность к изменениям — команда понимает, что в любой момент на стадии разработки рынок может измениться или появятся новые технические требования. Поэтому не страшно переделать продукт даже на финальной стадии
🔹 Итеративность — большой проект разбирают на части и работают над каждой из них поэтапно. Результат каждого — готовый и протестированный продукт или его часть, которыми можно пользоваться. Итеративность ускоряет работу, помогает понять, что нужно или не нужно аудитории, реагировать на её поведение и улучшать продукт
🔹 Самоорганизация — команда не ждёт указаний сверху и сама выбирает, как лучше выполнять задачи. Участники предлагают решения, обсуждают проблемы и вместе отвечают за результат. При этом роли и зоны ответственности всё равно сохраняются
🔹 Кросс-функциональность — это значит, что у каждого достаточно знаний и навыков, чтобы в любой момент заменить коллегу, если понадобится
В повседневной жизни эджайлом чаще называют способ создания продукта, при котором работа ведётся циклами, или итерациями. В этом случае смысл слова очень расширяется, ведь итеративная работа есть и в других методах, например в P3.express
Что такое Agile-манифест
— это документ, который описывает ценности и принципы гибкой разработки программного обеспечения. Его главная задача — помочь командам быстрее создавать полезный продукт и эффективнее реагировать на изменения
«Мы находим лучшие способы разработки программного обеспечения, практикуем их сами и помогаем другим. В ходе этой работы мы пришли к следующим ценностям:
Личности и взаимодействие важнее процессов и инструментов.Рабочее программное обеспечение важнее исчерпывающей документации.Сотрудничество с заказчиком важнее переговоров по контракту.Реагирование на изменения важнее следования плану.
Хотя то, что написано справа тоже имеет ценность, мы больше ценим то, что написано слева», — так начинается текст манифеста.
Почему появился Agile-манифест
В конце прошлого века многие компании использовали каскадную модель разработки (Waterfall). Работа строилась последовательно:
Собирали требования → согласовывали документацию → начинали разработку → тестировали продукт → внедряли его
Последовательность означает, что нельзя взять и откатиться к предыдущему этапу, чтобы что-то поправить. Ошибки в Waterfall стоят дорого.
Ещё одна проблема была в большом объёме документации и долгих согласованиях. Пока команда описывала требования, утверждала детали и проходила все этапы процесса, рынок мог измениться, а вместе с ним — потребности пользователей. В итоге продукт рисковал устареть ещё до запуска.
В феврале 2001 года группа из 17 специалистов по разработке программного обеспечения собралась на горнолыжном курорте Snowbird в штате Юта. Результатом встречи стал Agile Manifesto — короткий документ, который содержал четыре ценности и двенадцать принципов гибкой разработки.
На самом деле, манифест не стал внезапным открытием для индустрии. К началу 2000-х уже существовали более лёгкие и гибкие подходы к разработке: Scrum, экстремальное программирование, DSDM и другие. Манифест скорее объединил эти идеи, дал им общее название и закрепил новый взгляд на разработку: меньше тяжёлых процессов ради процессов, больше внимания работающему продукту, команде, заказчику и готовности к изменениям.
Хотя первоначально Agile-манифест создавался для IT-индустрии, со временем его идеи начали использовать и в других сферах. Практически любая команда, работающая в условиях изменений и неопределённости, сталкивается с теми же проблемами, которые пытались решить авторы документа двадцать пять лет назад.
4 ценности Agile-манифеста
Часто можно услышать упрощённую трактовку Agile: «Люди важнее процессов». На самом деле, ценностей четыре, и работают они вместе.
Наверняка тебе уже удалось заметить маленькую деталь в цитате из манифеста — авторы не говорят, что процессы, документация, контракты или планы вовсе не нужны. Всё перечисленное остаётся важным, но в спорной ситуации команда должна выбирать то, что помогает быстрее создавать ценность для клиента.
Люди и взаимодействие важнее процессов и инструментов
Процессы помогают организовать работу, а инструменты делают её удобнее. Но всё это в совокупности должно существовать для людей, а не наоборот. То есть если в команде есть что-то, что мешает работе, то от этого нужно избавиться.
Например, привычка постановки задач в рабочем чате не помогает закрыть проект быстрее, потому что важная информация может потеряться в сотне непрочитанных сообщений. Из-за этого коллеге приходится бесконечно скроллить чат и тратить время. Когда работаешь в офисе, то в конце концов можно поговорить о задаче лично. На удалёнке — позвонить.
Рабочий продукт важнее исчерпывающей документации
Документация помогает передавать знания, сохранять договорённости и обучать новых сотрудников. Но пользователь не видит количества документов и их содержимое. Он лишь оценивает, решает ли продукт его задачу.
Поэтому Agile предлагает регулярно показывать результат работы. Он не должен быть идеальным и окончательным. Главное условие: продукт или его часть можно показать людям или использовать для проверки гипотез. В дальнейшем это можно доработать и обновлять на основе обратной связи.
Сотрудничество с заказчиком важнее согласования условий контракта
Контракт определяет правила взаимодействия между сторонами. Без него серьёзные проекты никто не станет реализовывать. Но ни один контракт не способен предусмотреть все изменения, которые возникнут в процессе работы.
Если отношения между заказчиком и исполнителем строятся исключительно вокруг формальных обязательств, то любое изменение потенциально может превратиться в конфликт. Agile-манифест предлагает воспринимать заказчика как партнёра по созданию продукта.
Чем чаще команда получает обратную связь и обсуждает ожидания клиента, тем выше вероятность создать полезное решение, которое принесёт деньги.
Готовность к изменениям важнее следования первоначальному плану
Планирование остаётся одной из важнейших управленческих практик. Без плана тяжело оценивать сроки, распределять ресурсы и принимать решения. Но опять же, возвращаемся к тому, что любой проект существует в среде, которая постоянно меняется. Появляются новые данные, меняются требования, возникают технические ограничения или, вообще, заказчик решил, что цель у продукта должна быть другая.
Манифест не призывает отказаться от планирования. Просто важно помнить, что хороший план должен помогать адаптироваться к изменениям, а не мешать им. Если новые обстоятельства показывают, что первоначальное решение больше не работает, то разумнее скорректировать план, чем продолжать работать, следуя провальной стратегии.
12 принципов Agile-манифеста
Четыре ценности Agile-манифеста задают общее направление работы команды. Принципы показывают, как эти идеи применять. Но помним: это не руководство к действию. Принципы помогают понять, как организовать работу, чтобы команда быстрее поставляла ценность для клиента и могла адаптироваться к изменениям.
Удовлетворение потребностей заказчика через раннюю и непрерывную поставку ценного ПО
«Наш высший приоритет — удовлетворять заказчика благодаря ранней и непрерывной поставке ценного программного обеспечения»
То есть клиент должен получать результат как можно раньше. Вместо того чтобы полгода работать над большим релизом, команда регулярно показывает готовые части продукта, получает обратную связь и дорабатывает по мере необходимости.
Изменение требований приветствуется даже на поздних стадиях разработки
«Изменения приветствуются даже на поздних этапах разработки. Гибкие процессы позволяют использовать изменения для получения конкурентного преимущества»
Если появилась новая информация, команда должна иметь возможность скорректировать направление работы на любом этапе. Изменения могут произойти из-за чего угодно: конкуренты выкатили что-то лучше и раньше, появились новые вводные о пользователях или новые ограничения. Некоторые вещи просто невозможно просчитать заранее. Поэтому готовность к изменениям должна быть постоянной, а реакция на них — своевременной.
Рабочий продукт нужно выпускать часто
«Рабочий продукт следует выпускать как можно чаще — от нескольких недель до нескольких месяцев, отдавая предпочтение более коротким срокам»
Чем быстрее команда показывает результат, тем быстрее получает обратную связь. Это снижает риск, что после долгой работы придётся переделывать большую часть продукта, потому что ожидания клиента, потребности пользователей или условия проекта уже изменились.
Бизнес и разработчики должны ежедневно работать вместе
«Представители бизнеса и разработчики должны ежедневно взаимодействовать на протяжении всего проекта»
Команда не должна работать в информационном вакууме. Когда разработчики плохо понимают бизнес-задачи, они начинают принимать решения на основе собственных предположений. Если бизнес не понимает технических ограничений, то могут возникнуть нереалистичные ожидания.
Проекты строятся вокруг мотивированных людей
«Нужно создавать условия для мотивированных специалистов, обеспечивать им поддержку и доверять выполнение работы»
Даже идеально выстроенный процесс не компенсирует отсутствие вовлечённости. Люди работают эффективнее, когда понимают смысл своей работы, обладают достаточными полномочиями, условиями и могут влиять на результат.
Самый эффективный способ передачи информации — личное общение
«Наиболее эффективный способ передачи информации внутри команды — непосредственное общение»
Сложные вопросы быстрее решаются в диалоге, чем через длинные переписки и документы. Если ты не можешь часами ждать ответа на важное сообщение — позвони.
Работающий продукт — главный показатель прогресса
«Основной показатель прогресса — работающий продукт»
Количество проведённых встреч, написанных документов или выполненных задач ещё не означает, что проект движется к цели. Прогресс появляется только в том случае, когда люди получают продукт, которым можно пользоваться.
Гибкие процессы должны поддерживать устойчивый темп работы
«Гибкие процессы должны поддерживать постоянный темп работы. Заказчики, разработчики и пользователи должны иметь возможность сохранять его долго»
Работа в режиме постоянного аврала не делает команду эффективнее. Наоборот, перегруз приводит к ошибкам, эмоциональному выгоранию и снижению качества продукта. Если команда регулярно работает по вечерам и выходным, проблема обычно не в сотрудниках, а в планировании, процессах или приоритетах.
вперёд
и распределяй задачи до того,
как начнётся запара
Постоянное внимание к техническому совершенству повышает гибкость
«Постоянное внимание к техническому совершенству и качественному проектированию повышает гибкость»
Чем качественнее построен продукт, тем проще его развивать в будущем. Когда команда откладывает исправление проблем или упрощает архитектуру ради скорости, то каждая новая доработка начинает требовать всё больше времени и усилий.
Простота — искусство не делать лишнюю работу
«Простота — искусство максимизации количества невыполненной работы — крайне важна»
Не всё, что можно сделать, действительно нужно делать. Одна из самых распространённых проблем заключается в том, что команды создают функции, отчёты, согласования и процессы, которые не приносят пользы.
И в принципах NUPP, на которые опирается метод P3.express, есть аналогичный: «Не делай ничего без чёткой цели»
Лучшие решения рождаются в самоорганизующихся командах
«Лучшие архитектурные решения, требования и проекты создаются самоорганизующимися командами»
Люди, которые ежедневно работают над задачами, обычно лучше понимают детали и ограничения проекта, чем руководители, находящиеся далеко от процесса. Поэтому Agile предполагает, что команда должна участвовать в принятии решений, а не просто выполнять полученные указания.
Команда регулярно анализирует свою работу и улучшает процесс
«Команда должна регулярно анализировать способы повышения эффективности и соответствующим образом корректировать своё поведение»
Ни один процесс не становится идеальным после первого внедрения. Условия работы меняются, команда растёт, появляются новые инструменты и задачи. Поэтому важно останавливаться и анализировать, что работает хорошо, а что мешает достигать результата. С этим принципом связана практика ретроспектив, которую используют многие Agile-команды.
Собрали для тебя сводную табличку, чтобы применять принципы манифеста Agile было проще.
| Принцип Agile | Как применять в работе команды | Как зафиксировать в процессе |
|---|---|---|
| 1. Удовлетворение потребностей заказчика через раннюю и непрерывную поставку ценного продукта | Разбивать крупные проекты на короткие спринты по 2–4 недели и выпускать результат, который приносит ценность пользователю | Создавать задачи на основе пользовательских историй (User Story) и делить большие функции на отдельные этапы, которые можно показывать заказчику |
| 2. Изменение требований приветствуется даже на поздних стадиях разработки | Регулярно пересматривать приоритеты и обсуждать новые вводные на ежедневных встречах | Поддерживать актуальный бэклог проекта и пересматривать порядок выполнения задач во время планирования спринтов |
| 3. Рабочий продукт нужно выпускать часто | Использовать короткие циклы разработки и регулярно демонстрировать промежуточные результаты | Разбивать крупные задачи на небольшие подзадачи и завершать их в рамках каждого спринта |
| 4. Бизнес и разработчики должны ежедневно работать вместе | Создать прямые каналы коммуникации между заказчиком, бизнесом и исполнителями | Использовать единое пространство для задач и базу знаний, где хранится актуальная информация по проекту |
| 5. Проекты строятся вокруг мотивированных людей | Передавать ответственность тем, кто непосредственно выполняет работу | Закреплять ответственных за результат, а не только за отдельные действия внутри процесса |
| 6. Самый эффективный способ передачи информации — личное общение | Обсуждать сложные вопросы лично или на созвонах, а не только в переписке | После встреч фиксировать договорённости в задачах, комментариях или базе знаний |
| 7. Работающий продукт — главный показатель прогресса | Оценивать не объём выполненной работы, а пользу, которую получил клиент | Связывать задачи и цели проекта с конкретными результатами для пользователя или бизнеса |
| 8. Гибкие процессы должны поддерживать устойчивый темп работы | Планировать объём задач исходя из реальной загрузки команды | Отслеживать нагрузку сотрудников, анализировать сроки выполнения задач и оставлять резерв времени на срочные изменения |
| 9. Постоянное внимание к техническому совершенству повышает гибкость | Регулярно улучшать качество продукта и внутренних процессов | Создавать отдельные задачи на рефакторинг, оптимизацию, обновление библиотек и устранение технического долга, включая их в спринты |
| 10. Простота — искусство не делать лишнюю работу | Фокусироваться только на задачах, которые напрямую влияют на результат проекта | Регулярно пересматривать бэклог и удалять задачи, которые больше не создают ценности |
| 11. Лучшие решения рождаются в самоорганизующихся командах | Вовлекать сотрудников в обсуждение решений и планирование работы | Проводить совместное планирование задач и обсуждать способы достижения целей вместо спуска готовых инструкций |
| 12. Команда регулярно анализирует свою работу и улучшает процесс | После каждого проекта или спринта проводить разбор результатов и искать точки роста | Организовать регулярные ретроспективы и фиксировать конкретные улучшения, которые команда внедрит в следующих итерациях |
Как применить Agile-манифест в работе команды
Покажем, как перенести идеи Agile в ежедневные процессы команды с помощью Weeek.
Инструменты не должны усложнять работу команды
Их задача — помогать людям быстрее договариваться, видеть общий контекст и не тратить время на уточнения.
В Weeek это можно реализовать через единое рабочее пространство. Команда ведёт задачи на досках, в списках, календаре или диаграмме Ганта — в зависимости от того, какой формат удобнее для проекта.
В карточке задачи можно описать суть работы, назначить ответственного, поставить срок, добавить чек-лист, файлы, комментарии и метки. Так каждый участник понимает, что нужно сделать и где искать детали.
Не превращать документацию в самоцель
Показатель движения — работающий результат. Его можно протестировать или передать пользователю.
Разбей большой проект на задачи и этапы: так команда видит движение продукта к готовому результату. Документацию при этом удобно хранить в Базе знаний: там можно фиксировать требования, инструкции, решения по проекту и важные договорённости.
Дать заказчику возможность участвовать в проекте
Agile предполагает, что заказчик не только ставит задачу в начале проекта и ждёт финальный результат, но и участвует в обсуждении продукта.
В Weeek заказчика или внешнего специалиста можно подключить к рабочему пространству как гостя и дать доступ только к нужной части проекта.
Например, клиент может видеть отдельную доску, оставлять комментарии, следить за статусами задач и давать обратную связь по готовым этапам. Так взаимодействие становится регулярным, но не превращается в хаотичный поток сообщений в разных каналах.
Регулярно поставлять ценность
Чтобы работать короткими циклами и регулярно доводить задачи до готового результата, создавай в Weeek доску для рабочего цикла: например, спринта на одну-две недели.
Для этого нужно зайти в проект → нажать Добавить доску → выбрать «Спринт» → дать ему название и проставить период → кликнуть Создать.
В бэклог можно вынести все задачи по проекту, выбрать из них приоритетные на ближайший цикл и распределить между участниками. Дальше сотрудники будут двигать задачи по этапам.
В конце цикла можно посмотреть, какие дошли до финального статуса, что показать клиенту или пользователям, а что стоит доработать в следующем цикле.
Постоянно улучшать процесс
Один из принципов Agile — команда регулярно анализирует свою работу и корректирует процесс. Для этого можно проводить ретроспективы: обсуждать, что получилось, что мешало и что стоит изменить в следующем цикле.
В Weeek результаты ретроспективы можно сразу превращать в задачи. Например, если команда поняла, что ей не хватает понятного процесса ревью, стоит создать задачу «Описать правила проверки макетов» и закрепить итоговую инструкцию в Базе знаний.
