Лекция 2. Методологии разработки: водопад, Scrum, Kanban и Agile

Вторая лекция — про то, как устроен процесс вокруг кода: кто и в каком порядке работает над проектом, откуда берутся сроки и бюджет и почему одна и та же команда в водопаде и в Scrum живёт совершенно по-разному. Разобраны каскадная модель, Scrum, инкрементальная модель, бережливое производство, Kanban и Agile. Инструменты из первой лекции — ветки, ревью, релизы — это то, во что методология превращается на практике.

1. Каскадная модель (водопад)

Сам термин каскадной модели разработки был сформулирован в 1950 году — в статье, автор которой этот подход критиковал. Именно с этого момента начинается развитие всех остальных методологий: их придумывали в ответ на проблемы водопада.

Главная аналогия лекции — стройка. Нельзя начать возводить дом, пока он не спроектирован, и нельзя перестроить готовый дом из-за того, что фановая группа оказалась не там.

1.1. Этапы

Весь процесс разбит на пять-шесть этапов — точное число зависит от того, насколько подробно расписывают начало.

Аналитики. Никогда не обесценивайте их работу: без неё разработчику нечего показать. Заказчик обычно хочет «что-то примерно такое», а разработчику нужно осязаемое описание, с которым можно работать. Аналитик и превращает первое во второе — в список задач для разработки.

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

Внедрение — самый тяжёлый этап. Внедрение работающей IT-системы у заказчика сродни замене двигателя у летящего самолёта: работу останавливать нельзя, старую систему надо снять, а новую поставить прямо в полёте. Долго и затратно.

Поддержка — самый выгодный этап для IT-интегратора: бумаги подписаны, система передана на сопровождение, и вам платят просто за то, что она работает.

1.2. Плюсы

• Прозрачность. Всегда понятно, на каком этапе проект и на каком этапе команда. Модель придумали инженеры, а инженер привык брать чертёж и по нему понимать, что сейчас происходит.
• Зоны ответственности. Есть этапы, у каждого этапа есть хозяин.
• Предсказуемые деньги и сроки. Заказчику продают не конкретных Васю и Олю, а работу целиком: «мы берём за это два миллиона». Это удобно компаниям, которые планируют бюджет на годы вперёд.
• Запас можно перераспределить. Если разработчики справились раньше срока, освободившиеся часы уходят на следующие этапы.

1.3. Минусы

• Назад ходить нельзя. Именно поэтому важен каждый этап. Если аналитик ошибся, а вскрылось это на тестировании, развернуть процесс уже не получится — дом не перестраивают.
• «Дальше не моя проблема». Типичная фраза в водопаде: «у меня была задача, я её сделал». Ответственность заканчивается на границе этапа.
• Обратная связь приходит поздно. Что рынку нужно было другое, вы узнаете года через три — когда проект сдан.

2. Scrum

2.1. Откуда название

Scrum переводится как схватка — это термин из регби. В схватке вся команда собирается вместе, каждый держится руками и ногами за соседа, внутрь загоняется мяч, и эта конструкция продавливает противника.

Отсюда и смысл: должна быть небольшая самодостаточная сбалансированная команда, которая своими силами доводит мяч до финиша. В отличие от водопада, где на проект можно нагнать сто аналитиков.

Ориентир по правилам — сообщество Scrum Alliance: это тот свод, по которому принято работать.

2.2. Спринты и ритуалы

Работа идёт короткими циклами — спринтами. Спринты бывают недельные и двухнедельные; месячный — тоже не криминал, если команда так договорилась. Важно только, что спринт заведомо короче трёх лет водопадного проекта.

Рабочая неделя команды при недельном спринте выглядит так:

1. Планирование. Садимся и обсуждаем, что команда делает в этом спринте: берём задачи, оцениваем, распределяем.
2. Ежедневный стендап — 15 минут. Каждый говорит: вчера я сделал это, сегодня буду делать это. Технические подробности не обсуждаются — только задачи.
3. Демо в конце спринта. Вся команда собирается и показывает продакт-оунеру, что сделано. В ответ — обратная связь, и она может быть как положительной, так и отрицательной. Это просто обратная связь.
4. Следующие полчаса — снова с продакт-оунером: что берём в следующий спринт. Задачи достаются из бэклога, куда в течение недели падают новые хотелки.

Ритуалы стоят времени: из сорокачасовой рабочей недели 2,5–3 часа стабильно уходит на встречи. У того, кто работает сразу в нескольких командах, эти часы складываются, и рабочий день расползается на вечер.

2.3. Роли

Продакт-оунер. В Scrum заказчик реально участвует в обсуждениях команды. Это прямая противоположность водопаду, где заказчика к разработчику не пускают: между ними стоит проект-менеджер, который берёт удар на себя.

Скрам-мастер. Он не входит в команду и не пишет код — он следит за ритуалами. Если обсуждение выбивается из тайминга, он реально останавливает разговор: дай одному поговорить языком, и встреча растянется. Скрам-мастер может быть общий на несколько команд и приходить со стороны.

Команда. Нельзя сказать «мы завтра сходим к аналитикам, они сделают, а потом мы вернёмся»: работает вся команда целиком и взаимодействует внутри себя. Отсюда первое, что ждёт вас в Scrum: общаться придётся очень много. Если вы считаете себя интровертом и вам тяжело с коллегами — над этим придётся работать.

2.4. Состав команды

Общепринятый стандарт — 5–7 человек, больше не надо. Типичный баланс: на одного тестировщика два разработчика, плюс «полуаналитик» и «полудокументатор» — то есть люди, которые часть времени заняты анализом и документацией.

Отсюда и требования к квалификации. В водопаде можно было нагнать сто-двести дешёвых джунов и раздать им мелкие задачи. В Scrum так не выйдет: пятеро школьников за вас проект не сделают, нужны дорогие и квалифицированные люди.

2.5. Принципы работы

• Часть команды — часть корабля. Выдернуть человека посреди процесса и заменить другим не получится: команда сбалансирована. В отличие от водопада, заказчику продают именованных людей — Васю, Петю, Олю.
• Постоянное самосовершенствование. Вышел новый фреймворк, новая библиотека, обновление по безопасности — разобрались и рассказали команде. Без этого движения вперёд не будет.
• Новичка подтягивает команда. Придёте джуном — вас будут максимально быстро втягивать в рабочий процесс, чтобы вы тянули наравне. Иногда это выглядит жёстко.
• Автономность. Каждый отвечает в основном за своё, но немного и за соседа: кто-то заболел, кто-то ушёл в отпуск — команда должна продолжать работать. Поэтому фраза «мне аналитик так написал, я так и сделал» в Scrum не работает.
• Кросс-функциональность. Разработчик неизбежно занимается немного анализом, немного документацией, немного тестированием.

2.6. MVP: зачем показывать недоделанное

Водопад пилит проект три года, и через три года он может быть уже никому не нужен — а деньги потрачены. Scrum каждый спринт показывает минимальный работающий продукт, и заказчик может менять направление по ходу.

Пример с калькулятором:

1. Вы реализовали одну функцию — сложение. Калькулятор целиком не работает, но сложение работает.
2. Хороший продавец продаёт его в таком виде. Вы получаете первые деньги.
3. Дальше разработка идёт уже не за ваш счёт, а за счёт заказчика.
4. Заказчик говорит: «деление и вычитание не нужны, нужно извлечение квадратного корня» — и вы делаете корень, хотя не планировали.

Через три года у вас получается продукт, который действительно соответствует рынку, и вы за него не платили.

2.7. Минусы

• Зависимость от инвестора. Деньги могут кончиться на любом этапе: инвестор скажет «всё, дальше не двигаем», и продукт останется недоделанным. Отсюда куча мёртвых стартапов и брошенных проектов на GitHub — идею потестировали, не взлетела, пошли дальше.
• Качество страдает. Когда каждый спринт что-то меняется, о целостности продукта думать некогда.
• Финал не виден. В водопаде вы знаете, что получится в конце; в Scrum — нет.

3. Инкрементальная модель

Третья модель, с которой лектор столкнулся сам и с которой, скорее всего, столкнётесь вы, — инкрементальная. Она очень живучая: в корпоративном секторе её встречают на многих проектах.

Живучи и гибриды. Знакомая лектору история: менеджмент заказчика заявил «мы хотим, чтобы ваш проект был по Scrum», хотя процесс к этому не был готов; спас команду опытный практик, который сел и посчитал, во что такой переход обойдётся. По документам проект идёт по одной методологии, по факту работает по другой — и это нормальное состояние корпоративной разработки.

4. Бережливое производство

Идея пришла не из IT, а из производства: убрать из рабочего процесса всё, что не создаёт ценности.

Пример со станочником. Посмотрели на рабочий круг станочника: он делает два шага влево, берёт деталь, возвращается к станку, обрабатывает; за полчаса до конца смены начинает уборку. Посчитали, сколько времени уходит на ходьбу влево-вправо. Поставили рядом ящик с деталями — и, не заплатив рабочему ни рубля больше, получили рост производительности.

Апофеоз — банк. Зайдите в отделение банка: у сотрудника на столе не должно быть ничего, кроме органайзера. Всё остальное убрано и закрыто.

История про тимлида. К команде пришёл руководитель из банковской среды, где так принято. Он ходил между столами разработчиков и был в шоке: стикеры, черновики, формулы на бумажках. Начал закручивать гайки и требовать чистоту. Через два месяца команда сходила к генеральному с формулировкой «либо мы, либо он». Его убрали — команда снова заработала.

Более мягкая версия — то, из чего складывается идеальный день разработчика: пришёл, отметился, кофе с коллегами, посидел, голова закипела, встал, прошёлся, турник, тетрис, вернулся. Печеньки, анатомические кресла, два монитора, спортзал, закрытый кампус и набережная под окнами нужны ровно для этого — чтобы вы меньше отвлекались и больше находились в офисе.

5. Kanban

С Kanban вы сталкиваетесь каждый раз, когда звоните в службу поддержки. Там он и нужен в первую очередь.

• Жёсткие SLA. Как только появилась заявка, её должны взять максимально быстро. Как только ответил оператор, начинается отсчёт времени обработки.
• Пример нормы: по SLA команда должна обрабатывать обращение за два часа.
• Непрерывное улучшение. Это главное, за что лектор любит Kanban. Менеджер видит по доске, что команда на самом деле успевает за час, — значит, есть запас. Дальше начинается борьба жадности и здравого смысла: выжимать ли из команды этот час или оставить как есть. Kanban позволяет вовремя увидеть проблему.
• Визуализация. Доска показывает, кто чем занят. Поэтому Kanban используют и внутри Scrum — как надстройку над процессом.

6. Agile — это манифест, а не методология

Agile часто подают как отдельный фреймворк или отдельный вид разработки. Это не так: Agile — всего лишь манифест, набор ценностей. Его писали люди для людей, и если дать этот манифест в руки менеджеру, он «сделает Agile» по-своему.

Поэтому на основе Agile появилась куча кастомных фреймворков, которые компании соблюдают каждая по-своему. Формально все позиции соблюдены — а на выходе получается что-то другое.

Лектор прошёл по пунктам манифеста и к каждому показал, чем он оборачивается на практике:

О документации будет отдельная лекция — следующая: почему её всё-таки нужно писать. Аргумент «код self-explanatory» работает ровно до того момента, когда в B2B-сегменте нужно объяснить систему другой компании.

Частые ошибки

1. Считать Agile методологией. Agile — манифест, набор ценностей. Методологии и фреймворки строятся на его основе, но это не одно и то же.
2. Путать Scrum и Kanban. Scrum организует команду и спринты, Kanban — поток задач и его улучшение. Kanban-доска внутри Scrum-процесса — нормальная ситуация.
3. Думать, что водопад устарел. Он живёт там, где нужны фиксированный бюджет и предсказуемые этапы, и остаётся основой проектного менеджмента.
4. Обсуждать технические подробности на стендапе. Стендап — это «вчера сделал / сегодня буду делать» за 15 минут, а не проектная встреча.
5. Считать скрам-мастера членом команды. Он не делает продукт: он следит за ритуалами и убирает препятствия.
6. Считать, что Scrum бесплатен по времени. 2,5–3 часа в неделю из сорока уходит на ритуалы, и в нескольких командах эти часы складываются.
7. Набирать в Scrum-команду дешёвых джунов. Модель нагнать сотню исполнителей работает в водопаде, а не здесь.
8. Считать MVP «недоделкой, которую стыдно показывать». Калькулятор с одним сложением — это то, что уже можно продать и на что можно получить обратную связь.
9. Думать, что в водопаде можно вернуться на шаг назад. Нельзя: поэтому цена ошибки аналитика там особенно высока.
10. Считать печеньки и спортзал заботой о сотруднике. Это бережливое производство: их задача — чтобы вы меньше отвлекались и дольше оставались в офисе.

Мини-тренажёр

1. Аналитик неверно записал требование, и это вскрылось на тестировании. Что произойдёт в водопаде и что — в Scrum?
2. Заказчик требует зафиксировать стоимость и срок на три года вперёд. Какая модель подходит и почему?
3. Сколько человек в типичной Scrum-команде и как они распределены по ролям?
4. Сколько часов из сорокачасовой недели уходит на ритуалы Scrum?
5. Перечислите ритуалы недельного спринта по порядку.
6. Чем занимается скрам-мастер и входит ли он в команду?
7. Кто в водопаде общается с заказчиком, а кто — в Scrum?
8. Вы сделали калькулятор, который умеет только складывать. Зачем его продавать в таком виде?
9. Назовите главный риск Scrum с точки зрения денег.
10. Почему Kanban обычно всплывает в разговоре про службу поддержки?
11. Agile — это методология, фреймворк или что-то ещё?
12. Чем на практике оборачивается ценность «работающий продукт важнее документации»?

Ответы

1. В водопаде процесс развернуть нельзя — ошибка уедет дальше, а исправлять её придётся отдельным проектом. В Scrum ошибка вскроется на ближайшем демо, и следующий спринт можно перепланировать.
2. Водопад: он продаёт заказчику работу целиком по фиксированному плану и бюджету, что удобно тем, кто планирует деньги на годы вперёд.
3. 5–7 человек. Баланс: на одного тестировщика два разработчика, плюс «полуаналитик» и «полудокументатор».
4. 2,5–3 часа стабильно; у того, кто состоит в нескольких командах, — больше.
5. Планирование спринта → ежедневные пятнадцатиминутные стендапы → демо продакт-оунеру с обратной связью → полчаса на выбор задач следующего спринта из бэклога.
6. Следит за ритуалами и таймингом, останавливает затянувшиеся разговоры, убирает препятствия. В команду не входит и может быть общим на несколько команд.
7. В водопаде — проект-менеджер, заказчика к разработчику не пускают. В Scrum заказчик участвует напрямую в лице продакт-оунера.
8. Чтобы получить первые деньги и обратную связь: дальше разработка идёт за счёт заказчика, а он сам подскажет, какая функция нужна следующей.
9. Зависимость от инвестора: деньги могут кончиться на любом спринте, и продукт останется недоделанным.
10. Потому что там жёсткие SLA на время взятия и обработки заявки, а Kanban как раз показывает поток и позволяет его улучшать.
11. Ни то, ни другое: это манифест, набор ценностей. Фреймворки строятся на его основе.
12. Тем, что документацию «напишут потом», и это «потом» не наступает никогда.

Шпаргалка