Nigar только что устроилась junior-разработчицей в команду Prowid Shop — это онлайн-магазин, который делает небольшая команда из пяти человек. На первом созвоне Murad говорит: «У нас Agile, спринты по две недели». Слово «Agile» слышали почти все, но объяснить, что именно за ним стоит, получается не у каждого. В этом уроке разберём, зачем придумали Agile, чем он отличается от «водопада», что на самом деле записано в Agile-манифесте и каких мифов стоит остерегаться. Дальше в разделе будут Scrum, Kanban и рабочий процесс разработчика; сейчас — фундамент, на котором всё это держится.
Знакомьтесь: команда Prowid Shop
Во всех уроках раздела мы смотрим на работу глазами одной и той же команды:
- Leyla — Product Owner: отвечает за то, что и в каком порядке делать, чтобы продукт приносил пользу.
- Murad — Scrum Master: следит, чтобы команда хорошо работала, и убирает препятствия.
- Aysel и Kamran — разработчики.
- Nigar — новая junior-разработчица; в наших примерах «вы» — это она.
Персонажи вымышленные, а ситуации типичны для реальных команд — в том числе в бакинских компаниях и при удалённой работе.
Как было раньше: waterfall («водопад»)
Долгое время разработку устраивали как стройку: сначала всё продумываем, потом строим. Такая модель называется waterfall («водопад»), потому что работа «стекает» вниз по фазам:
- Требования — собираем и фиксируем всё, что нужно сделать.
- Проектирование — рисуем архитектуру и экраны.
- Разработка — пишем код.
- Тестирование — проверяем, что всё работает.
- Релиз — отдаём результат пользователям.
Каждая следующая фаза начинается, когда закончилась предыдущая, а возвращаться назад не любят: это дорого. Для моста или здания так и правда разумно — после заливки фундамента этаж не переставишь. Но программа — не мост.
Представьте, что Prowid Shop делали бы так. Три месяца пишут техническое задание, ещё четыре — строят магазин, месяц тестируют, и только на запуске Leyla впервые показывает его покупателям. Выясняется: большинство покупателей хотят платить наличными при доставке, а в ТЗ была только оплата картой. Исправлять придётся то, что уже вплетено в десятки мест.
| Проблема | Что происходит |
|---|---|
| Поздняя обратная связь | Недопонимание вскрывается через месяцы, когда всё уже построено |
| Дорогие изменения | Чем позже правка, тем больше готового приходится переделывать |
| Риски копятся | Интеграция и тесты — в конце, вместе с неприятными сюрпризами |
| Мир меняется | Требования, зафиксированные в январе, к осени могут устареть |
💡 Waterfall — не «зло». Если требования известны и стабильны (например, их жёстко задаёт закон или контракт), он работает. Проблемы начинаются там, где много неопределённости, а в разработке продуктов её почти всегда много.