Небольшое введение
Сегодня Agile — это то без чего сложно представить любую разработку продукта. Его используют вообще все: стартапы, корпорации и даже государственные организации, которые очень сложно назвать гибкими. Но кого ни спроси…
Что такое Agile?
Большинство тебе ответит:
Ну, это методология с разработкой по спринтам
А это ведь совсем не передает суть и дух. Agile — это целая философия, основанная всего на 4 ценностях и 12 принципах, которые придумали на горнолыжном курорте несколько айтишников.
Но об этому чуть позже :)
До Agile: эпоха водопадов
А что же было до Agile? Как люди пытались унять хаос требований?
На самом деле, все по-разному, но базовой моделью индустрии была каскадная модель или Waterfall (водопад по-нашему). Описал эту модель впервые человек, который начинал свой путь еще в аэрокосмическом направлении и назвать его инноватором можно без зазрения совести. Уинстон Уокер Ройс в своей статье "Управление разработкой крупных программных систем" (1970) описал эту каскадную модель (водопадом ее тогда не называли).
Уинстон Уокер Ройс
Американский учёный в области информатики, пионер в области разработки программного обеспечения
Но тут есть важное “НО”!
Еще тогда Ройс приводил каскадную модель как пример неэффективного способа разработки программного обеспечения, который ведёт к ошибкам и выпуску некачественных продуктов. А его коллеги, видимо, не прочитав и половины работы, записали его в авторы так называемого Waterfall’a, популяризировав упрощенную каскадную модель, в которой разработка идет строго сверху вниз без отклонений (короче, утопия).
Небольшое лирическо отступление... Спустя годы могу понять его коллег. Ройс предлагал в этой самой статье свои варианты гибких моделей, которые казались ему более релевантными, но графическое представление этих моделей — ЭТО ПРОСТО УЖАС! На фоне с этим каскад казался более понятным и простым.
Кстати полный текст статьи в переводе и многое другое можно прочитать в моем ТГК
👉 Ссылка
Процесс водопада выглядел так:
System Requirements — определение системных требований
Software Requirements — формирование требований к программному обеспечению
Analysis — анализ требований и архитектурных решений
Program Design — проектирование программы
Coding — разработка (написание кода)
Testing — тестирование
Operations — эксплуатация и использование системы
Почему "водопад"? Как раз дело в том, что весь процесс течет как вода в водопаде: сверху вниз.
А каждый этап начинался только после завершения предыдущего.
Какие есть проблемы у Waterfall'а
Проблем из этого подхода вытекало очень много. Реальные ситуации показывали неудобность этой модели и самое главное — дороговизну! Бизнесу эта модель обходилась очень дорого, а разработке было просто неудобно работать по ней. Вообще большинство выделяло следующие проблемы (в том числе, кстати, и автор):
требования меняются (а это происходит в подавляющем большинстве проектов)
разработка длится очень долго (особенно если не повезет найти какую-то ошибку на финальной стадии)
продукт выходит уже устаревшим (по современным меркам, это вообще смертельно для многих продуктов)
дороговизна доработок при подобном процессе
И вот наша любимая индустрия IT-продуктов начала искать более гибкие подходы, которые помогли бы нам побороть эти проблемные места (в идеале без схем как у Ройса).
Одни из самых известных до 2000-х годов были:
Методология | Год | Автор | Суть подхода | Основные минусы |
|---|---|---|---|---|
Crystal | 1994 | Семейство лёгких методологий разработки. Подход адаптируется под размер команды и критичность проекта. Делает упор на коммуникацию внутри команды. | Отсутствие строгих правил; сложность масштабирования; мало формализованных практик. | |
Extreme Programming (XP) | 1996 | Итеративная разработка с короткими циклами и сильным фокусом на инженерные практики: TDD, парное программирование, continuous integration. | Требует высокой дисциплины команды; сложен для внедрения в крупных организациях; высокая зависимость от культуры разработки. | |
Feature Driven Development (FDD) | 1997 | Jeff De Luca и Peter Coad | Разработка строится вокруг небольших функций продукта (features). Проект разбивается на короткие итерации, каждая из которых добавляет конкретную функциональность. | Сильная зависимость от предварительного моделирования; слабая поддержка изменений требований; плохо подходит для стартапов. |
Lean Software Development | ~2003 | Mary Poppendieck и Tom Poppendieck | Применение принципов Lean manufacturing к разработке ПО: устранение потерь, быстрые итерации, постоянное улучшение процессов. | Не даёт конкретного процесса разработки; требует высокой зрелости команды; часто трактуется слишком абстрактно. |
На самом деле их было гораздо больше (о большинстве вы даже не слышали), тут я отобразил даже не половину. Тот же излюбленный всеми Scrum был представлен в 1995 году на конференции OOPSLA.
Все эти подходы предлагали более гибкие способы разработки по сравнению с каскадной моделью. Однако развивались они все независимо друг от друга и не имели единой философии. Можете представить, каково было айтишникам, когда они переходили из одной компании в другую и слышали "никакого парного программирования". Грустно. Досадно. Не по-agile'овски. Но эта ситуация изменилась в 2001 году, когда группа разработчиков сформулировала манифест Agile.
Рождение Agile
В феврале 2001 года группа из 17 разработчиков и методологов собралась на горнолыжном курорте Snowbird в штате Юта. Среди них были Мартин Фаулер, Кент Бек, Роберт Мартин, Джефф Сазерленд, Кен Швабер, Алистер Кокберн и другие практики, многие из них, к слову, стояли у истоков различных методологий. В общем, ребята эти точно знали, какие есть проблемы и понимали в какую сторону думать, чтобы их решить.
Цель встречи была довольно простой, но амбициозной! Обсудить, что объединяет разные так называемые "lightweight-методы" и попытаться сформулировать их общие принципы/ценности. В течение нескольких дней обсуждений участники сформулировали 4 ключевые ценности и начали работу над 12 принципами разработки, которые позже стали известны как Agile Manifesto.
Произошла своего рода ✨магия синергии✨
Но ребята на этом не остановились и позже для развития своих идей создали организацию "Agile Alliance" и опубликовали свой манифест на сайте AgileManifesto.org (Он еще работает, окунитесь в прошлое).
Кстати, подробнее про саму встречу в Snowbird — как она проходила, кто спорил, как появились формулировки ценностей и почему вообще выбрали слово Agile — я разобрал в отдельном подкасте
👉 Слушать здесь
В истории сохранился и черновик заметок Анди Ханта, который я так любезно отобразил снизу :)
4 ключевые ценности Agile
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
Это не означает, что правые пункты не важны — просто левые ценятся больше.
12 принципов Agile
Главный приоритет — удовлетворение клиента
за счёт ранней и непрерывной поставки ценного программного обеспечения.Изменения требований приветствуются
даже на поздних этапах разработки.Работающий продукт поставляется регулярно,
с интервалом от нескольких недель до нескольких месяцев.Бизнес и разработчики должны работать вместе
ежедневно на протяжении всего проекта.Проекты строятся вокруг мотивированных людей,
которым доверяют выполнение работы.Самый эффективный способ передачи информации — личное общение.
Работающий продукт — главный показатель прогресса.
Agile-процессы поддерживают устойчивый темп разработки,
который команда может сохранять постоянно.Техническое совершенство и хороший дизайн повышают гибкость разработки.
Простота — искусство максимизации объёма невыполненной работы — является ключевой.
Лучшие архитектуры, требования и решения появляются в самоорганизующихся командах.
Команда регулярно анализирует свою работу и ищет способы повысить эффективность.
Источник: AgileManifesto.org
Scrum
И вот, разобравшись. что за штука этот Agile, давайте поговорим какие фреймворки начала объединять эта философия. Пожалуй, самым популярным был и является Scrum.
Scrum — методология управления проекта aka самый популярный Agile-фреймворк. В чём главная идея Scrum? Невозможно идеально спланировать сложную работу заранее (особенно в IT), поэтому нужно двигаться короткими итерациями, проверять результат и корректировать курс.
Sprint — фиксированный промежуток времени (обычно от 1 до 4 недель), в течение которого команда создаёт готовый инкремент (набор фич, доработок) продукта. Каждый спринт имеет цель (буквально), набор задач и завершается демонстрацией результата и анализом проделанной работы. Спринты помогают команде регулярно получать обратную связь и адаптировать дальнейшую разработку под нужды нашего с вами излюбленного бизнес-заказчика.
Именно через спринты (и менеджерскую магию) организуется вся работа команды, они задают ритм в котором команда живет, на короткие управляемые(чаще всего) циклы. И поверьте, я не преувеличиваю, каждый релиз, особенно на старте, будет вашей маленькой победой :)
А теперь давайте немного про ролевые игры в скраме. Это там любят.
Роль | Основная задача | За что отвечает | Кто им является |
|---|---|---|---|
Product Owner | Максимизация ценности продукта | Формирует видение продукта, управляет Product Backlog, расставляет приоритеты задач, принимает результаты работы команды | Представитель бизнеса или продукта. Человек, который лучше всего понимает потребности пользователей и цели продукта. Чаще всего в команде разработки это либо отдельная должность, которая так и называется "Владелец продукта", либо это Product/Project Manager |
Scrum Master | Помогает команде эффективно применять Scrum | Следит за соблюдением принципов Scrum, помогает устранять препятствия, улучшает процессы внутри команды, способствует самоорганизации | Любой член команды или отдельный специалист. Важно не формальное назначение, а понимание Scrum и способность помогать команде |
Developers (команда разработки) | Создание рабочего инкремента продукта | Реализуют задачи из Sprint Backlog, совместно отвечают за результат спринта, планируют и организуют свою работу | Кросс-функциональная команда специалистов: разработчики, тестировщики, дизайнеры, аналитики, DevOps и другие |
Ключевые артефакты Scrum
Product Backlog — это все задачи, функции и идеи, которые нужны для развития продукта. Включает новые фичи, улучшения, исправления багов и технические задачи. За наполнение и приоритизацию вашего бэклога отвечает Product Owner.
Sprint Backlog — это уже более узкий список задач, который формирует команда для реализации в текущем спринте. С ним рука об руку идет и план работы команды для достижения цели спринта. (Например, "Сделать поиск быстрее, чтобы пользователи находили товары на 50% быстрее"
Increment — рабочий результат спринта. Это часть продукта, которая полностью готова к использованию и соответствует установленным критериям готовности. (короче говоря, тут все, что вы нашкодили накодили и протестировали)
Definition of Done (DoD) — список/чек-лист критериев, по которым команда определяет, что задачи могут считаться готовыми.
Все артефакты Scrum призваны сделать прозрачной работу команды: любой участник проекта может понять, что планируется, над чем команда работает сейчас и какой результат уже получен.
Ритуалы
Помимо ролей и артефактов, Scrum включает набор регулярных встреч, которые часто называют ритуалами. Они помогают команде синхронизироваться, планировать работу, оценивать результаты и регулярно улучшать процесс разработки. Каждый из этих ритуалов проходит в рамках спринта и выполняет конкретную задачу.
Ритуал | Пояснение |
|---|---|
Sprint Planning | Встреча в начале спринта, на которой команда определяет цель спринта и выбирает задачи из Product Backlog для выполнения. Также обсуждается план реализации выбранных задач. |
Daily Scrum | Короткая ежедневная встреча команды (обычно до 15 минут), на которой участники синхронизируются по текущей работе и обсуждают продвижение к цели спринта. |
Sprint Review | Встреча в конце спринта, на которой команда демонстрирует готовый результат работы и получает обратную связь от стейкхолдеров. |
Sprint Retrospective | Встреча после завершения спринта, на которой команда анализирует свою работу, обсуждает проблемы и ищет способы улучшить процесс в следующем спринте. |
Kanban
Kanban в отличие от Scrum'a с его спринтами и итерациями предлагает другой более восточно-азиатский подход — непрерывный поток работы.
Для начала поясню, Kanban — это один из методов управления задачами и рабочим процессом, он базируется на визуализации работы, чтобы менеджерам было удобнее контролировать загрузку и улучшать эффективность процессов.
Фан-факт. Изначально Kanban появился в производственной системе Toyota, где использовался для управления производственными потоками. Позже этот подход адаптировали для разработки программного обеспечения и управления проектами. Поговаривают, что Kanban даже частично вдохновил авторов Agile. Во всяком случае подход крайне известный и пользуется популярностью в разработке ПО и на производствах.
Визуализация работы + ограничение количества задач = Kanban
Основные принципы Kanban
1. Визуализация работы
Рабочий процесс отображается на «Kanban доске», где задачи проходят через несколько стадий выполнения.
Например: Backlog → In Progress → Review → Done
Это помогает команде видеть где сейчас больше всего сконцентрировано задач и контролировать эти «Узкие горлышки», которые стопят весь рабочий процесс.
2. Ограничение незавершённой работы (WIP)
Один из главных принципов Kanban — ограничение количества задач, которые могут одновременно находиться в работе на каждой из стадий.
Например:
— максимум 3 задачи в In Progress
— максимум 2 задачи на Review
Логика тут такая, что эти ограничения должны помогать избежать перегрузки команды и ускорять завершение задач, на деле они помогают выявлять несовершенства процесса и избавляться от них. Бизнес не любит, когда процесс тормозится и уж тем более останавливается.
3. Управление потоком работы
Команде нужно постоянно брать новые задачи, при этом часто эти задачи, очень важные, поэтому Kanban команда стремится сделать поток задач максимально плавным и предсказуемым и как только кто‑то из работяг освободится, то сразу же получает новую задачку.
4. Постоянное улучшение процесса
Kanban поощряет своего рода восточный подход с небольшими постепенными изменениями вместо радикальных реформю Команда регулярно анализирует свою работу и ищет способы улучшить процесс.
На практике, Kanban славится и наиболее часто используется в основном для визуализации процесса. И самым главным элементом является Kanban-доска.
Kanban-доска
Это главный инструмент Kanban, за который его так любят. Она показывает:
этапы работы (какие у нас вообще есть этапы)
задачи (какие задачи у нас есть)
текущее состояние процесса (на каком этапе какая задача)
Обычно она выглядит так:
Backlog | In Progress | Review | Done |
|---|---|---|---|
Каждая задача представлена карточкой, которая перемещается между колонками по мере выполнения. | |||
В моей практике регулярно встречалось от 4 до 15 этапов. И этот выбор количества этапов делает сама команда отталкиваясь от своих нужд.
На практике многие команды используют гибрид Scrum и Kanban, который называют Scrumban или выбирают какое-то другое более уникальное название. Если наберем увижу, что тема действительно интересна вам, могу рассказать с какими гибридами в своей практике мне довелось поработать и какие плюсы и минусы я оттуда подчеркнул.
The end
На этом базовое ознакомление с Agile, Scrum, Kanban завершено, жду экспертные мнения о том, что я упустил, перепутал и где наврал в комментах❤️.
