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 («водопад»), потому что работа «стекает» вниз по фазам:

  1. Требования — собираем и фиксируем всё, что нужно сделать.
  2. Проектирование — рисуем архитектуру и экраны.
  3. Разработка — пишем код.
  4. Тестирование — проверяем, что всё работает.
  5. Релиз — отдаём результат пользователям.

Каждая следующая фаза начинается, когда закончилась предыдущая, а возвращаться назад не любят: это дорого. Для моста или здания так и правда разумно — после заливки фундамента этаж не переставишь. Но программа — не мост.

Представьте, что Prowid Shop делали бы так. Три месяца пишут техническое задание, ещё четыре — строят магазин, месяц тестируют, и только на запуске Leyla впервые показывает его покупателям. Выясняется: большинство покупателей хотят платить наличными при доставке, а в ТЗ была только оплата картой. Исправлять придётся то, что уже вплетено в десятки мест.

ПроблемаЧто происходит
Поздняя обратная связьНедопонимание вскрывается через месяцы, когда всё уже построено
Дорогие измененияЧем позже правка, тем больше готового приходится переделывать
Риски копятсяИнтеграция и тесты — в конце, вместе с неприятными сюрпризами
Мир меняетсяТребования, зафиксированные в январе, к осени могут устареть
Один проект на 12 недель: waterfall выпускает всё в самом конце, итеративная разработка — каждые две недели
Один проект на 12 недель: waterfall выпускает всё в самом конце, итеративная разработка — каждые две недели

💡 Waterfall — не «зло». Если требования известны и стабильны (например, их жёстко задаёт закон или контракт), он работает. Проблемы начинаются там, где много неопределённости, а в разработке продуктов её почти всегда много.

Итеративный и инкрементальный подход