Agile или Waterfall: какую методологию выбрать для разработки проекта, чтобы управлять им эффективнее
Разбираемся, в каких проектах нужен линейный подход, а когда важно быть гибким и быстро адаптироваться к изменениям.
23.01.2024
Перед стартом нового проекта предприниматель или проджект-менеджер проделывает большую подготовительную работу: собирает требования, планирует бюджет, формирует команду. Одна из ключевых задач на этом этапе — определиться с тем, как управлять процессами и контролировать выполнение бизнес-задач.
Можно сразу спланировать всё «от и до»: прописать этапы, установить сроки и следовать им несмотря ни на что. Но есть подвижные ниши, как например IT, в которых идеи и софт устаревают. В таких условиях удобнее работать короткими спринтами и менять направление по ходу дела.
В статье сравним два подхода в управлении проектами: последовательную модель Waterfall и гибкую философию Agile. Расскажем, как понять, какой из них подойдет вашему бизнесу.
В основе водопадной модели — линейный подход и последовательное выполнение задач
Водопадная модель (Waterfall, каскадная модель) — традиционная методология процесса разработки. Её особенность — в последовательном выполнении задач: каждый этап начинается только после того, как закончится предыдущий. Возвращаться к предыдущим этапам и сдвигать сроки в каскадной модели нельзя: даже если в процессе появятся новые требования, изменения можно будет внести только после запуска проекта.
Ещё одна особенность Waterfall — подробная документация на каждом этапе. Перед началом работы команда обсуждает проект, фиксирует требования и дедлайны. Сдвигать сроки или менять требования в водопадной модели нельзя.
В водопадной модели выделяют пять этапов работы над проектом:
- Сбор требований. Предпроектное исследование (Discovery) проводится до начала этапа разработки. Команда собирает данные, анализирует риски, пишет техзадание и план работы. На этом этапе определяются сроки и бюджет. Все эти решения закрепляются в документе.
- Проектирование. Подробно прописывается функционал продукта, его логика, внешний вид и структура. Под выбранную концепцию команда выбирает инструменты для работы.
- Разработка. Команда создаёт продукт в строгом соответствии ТЗ, требованиям и соглашениям. Ни шагу в сторону — всё только по плану.
- Тестирование. Команда проверяет продукт на соответствие техзаданию и устраняет ошибки.
- Поддержка. На этом этапе команда выпускает продукт и собирает обратную связь от клиентов. По итогам обратной связи улучшает его — например, устраняет ошибки или добавляет новые функции. А если нужны идеи для новых фич, проджект-менеджер может организовать краудсорсинг.
Диаграмма Ганта — один из важных инструментов управления проектами в водопадной модели. Она иллюстрирует, как выполняется запланированная работа с течением времени. Обычно диаграмма включает даты начала и завершения задач, контрольные точки, исполнителей.
Минус диаграммы в том, что, если в середине проекта сроки сдвигаются, приходится переписывать весь график, потому что задачи зависят друг от друга. Это занимает много времени. На практике в больших проектах часто перестают править диаграмму, и она больше не отражает реального положения дел.
Плюсы и минусы Waterfall
| Плюсы | Минусы |
|---|---|
| Чёткие сроки и бюджет. Стоимость проекта и дата релиза утверждены в начале и не меняются в процессе. | Команды зависят друг от друга. Если одна команда сорвёт дедлайн, сдвинутся сроки всего проекта и финальная дата. |
| У сотрудников есть инструкции. Правила для всех участников проекта прописываются до начала разработки. | Тестирование в конце проекта. Ошибку в разработке можно заметить слишком поздно, а вернуться к прошлому этапу, чтобы её исправить, — дорого. |
| Дисциплина. Пошаговая последовательность и строгий менеджмент дисциплинируют сотрудников. | Финальный продукт может не устроить клиента. В процессе разработки клиент и заказчик изолированы и не могут дать обратную связь. |
| Гибкость на ранних этапах. На этапе Discovery и проектирования можно вносить изменения в структуру проекта. | Низкая вовлечённость сотрудников. Каждый работает над своими задачами — нет тесного взаимодействия внутри команды. |
| Легко подключать сотрудников. Благодаря планированию и подробной документации можно вводить новых сотрудников в любой момент реализации проекта. | Нет самоуправления. Команды работают по заранее утверждённому регламенту и инструкциям. Проявлять инициативу и менять что-то в процессе нельзя. |
Таким образом, каскадная модель подойдёт, если:
- у вас крупный проект с точным планированием и ТЗ;
- у заказчика есть проработанная концепция, которую не нужно менять;
- команда уже делала похожие проекты;
- заказчик не хочет участвовать в каждом этапе проекта.
Каскадный подход чаще оправдан в материальном производстве. Например, если вы собираетесь строить многоэтажный дом, нужно заранее всё рассчитать, собрать большой пакет документов, проследить, чтобы в процессе стройки ничего не менялось. В интеллектуальных проектах всё сложнее: там действует среда неопределённости. Это значит, что нельзя всё спланировать, собрать огромный бэклог задач и делать его несколько лет. Представьте, что получится, если команда разработчиков будет создавать мобильное приложение в течение пяти лет. За это время как минимум поменяются версии операционных систем на смартфонах. В итоге получится устаревший продукт.
Agile — подход, основанный на гибкости, сотрудничестве и быстрой адаптации к изменениям
В 2001 году американские разработчики опубликовали в сети Манифест гибкой разработки программного обеспечения — Agile software development. Их не устраивала тяжеловесная водопадная модель: жёсткая последовательность этапов и отсутствие гибкости осложняли работу. Сегодня принципы и инструменты Agile применяют сотни компаний по всему миру.
В философии Agile выделяют четыре главные ценности:
- Люди и взаимодействие с ними важнее процессов и инструментов.
- Работающий продукт важнее, чем точная и подробная документация.
- Сотрудничество с клиентом важнее условий договора.
- Готовность к изменениям важнее следования плану.
Сторонники Agile называют его образом мышления, основанном на здравом смысле.
Для управления проектом по модели Agile удобно использовать Яндекс Трекер. В нём можно организовать, например, разработку ПО, сбор обращений от пользователей или проведение рекламной кампании. Руководителям сервис помогает контролировать бизнес-процессы, сотрудникам даёт возможность отслеживать статус задач и управлять рабочим временем. Здесь можно планировать работу по спринтам и следить за прогрессом на диаграмме сгорания.
Плюсы и минусы Agile
| Плюсы | Минусы |
|---|---|
| Гибкость. Удобно работать в условиях неопределённости: в любой момент можно изменить план и внести новые требования. | Нет чёткой структуры. Поскольку в процессе добавляются новые требования, то на выходе результат может отличаться от ожидаемого. |
| Снижение рисков. Команда постоянно тестирует продукт и получает обратную связь после каждого спринта. Так можно вовремя понять, если что-то идёт не так. | Заказчик должен работать с командой. После каждого спринта ему будут показывать промежуточные результаты и требовать обратную связь. |
| Гибкие сроки. Можно отложить заблокированную задачу на следующий спринт или выпустить продукт с ограниченным функционалом. | Сложно менять команду. Если в процессе нужно заменить ключевых сотрудников, новых специалистов придётся вводить в курс прошлых спринтов. |
| Самоуправление команд. Работники сами решают, какие задачи взять в работу, в каком порядке и какие инструменты использовать. | Фокус на мелочах. Команда может увлечься исправлением частных моментов и потерять из виду главную цель проекта. |
| Быстрая реакция на проблемы. Чтобы устранить ошибку или добавить новую функцию, не нужно переписывать весь проект. Можно сделать это в следующем спринте. | Трудозатратно внедрять. Если команда раньше не работала по Agile, их придётся учить не только инструментам, но и философии. |
| Нет рутины. Сотрудники не тратят много времени на документацию и уделяют больше внимания качеству продукта. | Сроки и бюджет нельзя определить заранее. Они зависят от того, сколько будет спринтов и сколько специалистов в итоге будет задействовано. |
Agile подойдёт, если:
- продукт нужно получить быстро и минимизировать время на исправление ошибок в ходе работы;
- вы готовы адаптировать продукт под изменения в требованиях клиента;
- команда работает над новым проектом с нуля, тестирует гипотезы и новые методы работы;
- заказчик хочет участвовать в проекте, посещать встречи и давать обратную связь.
Agile стоит применять с умом. Нет смысла использовать его в работе колл-центра, на заводе или другом предсказуемом производстве. Этот метод эффективен там, где нужно быстро проверять гипотезы, анализировать результат и при необходимости менять направление. Главная сложность заключается в том, что сотрудники могут быть не готовы разделять ценности Agile. Например, руководитель проекта хочет использовать подход, а люди саботируют или открыто протестуют против нововведений. В этом случае лидеру предстоит долгая, кропотливая работа с командой.
Подведём итог: какую модель выбрать для организации работы над проектом
Водопадную модель: если для вас важна конкретика и чёткая последовательность задач. Она подойдёт для масштабных проектов с проработанной концепцией, в которых важно точное планирование и последовательное выполнение задач. Также её часто выбирают при работе с клиентами, которым важно чётко понимать сроки и стоимость проекта.
Agile: если важна гибкость, взаимодействие с клиентом и быстрая реакция на изменения внешней среды. Agile подойдёт для интеллектуальных проектов, которые создаются в условиях неопределённости.
