Методологии разработки: обзор

Две команды могут получить одинаковую задачу и делать её совсем по-разному: одна сначала пишет описание на несколько страниц, другая делает первый кусок и показывает его через неделю. От этого зависит, когда в проекте появляются требования, как часто они меняются и сколько нужно писать заранее. Разберём основные подходы на одной задаче «Узелка».

Кейс: одна задача в двух командах

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

Разницу даёт подход к организации работы (его часто называют методологией): набор правил о том, в каком порядке и с каким ритмом команда делает работу, когда появляются требования и как часто показывается результат.

Чем отличаются подходы друг от друга

Подходы делятся на три группы: последовательные делают работу этапами, гибкие короткими шагами, а масштабирующие согласуют работу многих команд. В таблице всё сравнивается по одним признакам, подробно потом разберём только Waterfall, Scrum и Kanban.

Подход	Идея	Ритм	Когда появляются требования	Где встречается
Waterfall (последовательный)	Этапы идут по порядку, возврат назад не предусмотрен	Один длинный цикл	Все сразу, в начале	Проекты с жёстким договором и стабильными требованиями
V-модель (последовательный)	Waterfall, где каждому этапу создания соответствует этап проверки	Один длинный цикл	Все сразу, в начале	Там, где цена ошибки высока и нужна проверка каждого этапа
Agile (идеология)	Четыре ценности Манифеста, готовность к изменениям	Не задан	Частями, по мере необходимости	Как идеология в командах гибких подходов
Scrum (гибкий способ)	Работа спринтами: периодами одинаковой длины, не больше месяца	Спринт одинаковой длины	Частями, перед каждым спринтом	Продуктовые команды
Kanban (гибкий способ)	Доска, ограничение числа задач в работе, ровный поток	Нет фиксированных периодов	По мере поступления задач	Службы поддержки, где задачи приходят вперемешку
XP (Extreme Programming, практики)	Практики программирования: работа в паре, тесты до кода, частая сборка	Короткие периоды	Короткими описаниями перед каждым периодом	Команды разработчиков, чаще всего как набор практик
Lean (философия)	Убирать потери и ускорять путь работы до пользователя	Не задан	Не задано	Как принципы в командах разных подходов
SAFe (масштабирование)	Правила для согласованной работы многих команд над одним продуктом	Общий период планирования для команд	На нескольких уровнях: от продукта до команды	Крупные компании с многими командами

Agile (гибкая разработка) не способ работы, а идеология. В «Манифесте гибкой разработки» 2001 года четыре ценности: люди и взаимодействие важнее процессов и инструментов, работающий продукт важнее исчерпывающей документации, сотрудничество с заказчиком важнее согласования условий договора, готовность к изменениям важнее следования плану. Пункты, которые манифест ставит ниже, тоже ценны, но верхние ценятся больше. Scrum и Kanban описывают, как организовать работу, XP говорит о том, как писать код, а Lean задаёт общий взгляд на потери в работе.

Waterfall и V-модель: этапы один за другим

Waterfall (в переводе «водопад») устроен как последовательность этапов: требования, проектирование, разработка, тестирование, выпуск. К следующему этапу переходят, когда закончен предыдущий, поэтому все требования пишут и согласуют в начале. Зато объём, срок и документы видны до начала дорогой работы. Цена такого порядка в том, что ошибка в понимании требований видна только на проверке, как у первой команды из кейса. Подход работает, когда требования стабильны, а изменения после начала разработки обходятся дорого.

V-модель развивает ту же идею: каждому этапу создания соответствует этап проверки. Описанию требований соответствует приёмка, проектированию системы проверка её частей вместе, написанию кода проверка отдельных модулей. Если расставить этапы на схеме, они образуют букву V, отсюда название.

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

Scrum и Kanban: два способа работать гибко

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

Kanban не заменяет способ работы, а накладывается на уже существующий: он делает работу видимой на доске и ограничивает число задач, находящихся в работе одновременно. Новую задачу берут, только когда освободилось место, поэтому фиксированных периодов нет. Хорошо срабатывает там, где задачи приходят непредсказуемо, например в службе поддержки. Типичная ошибка: называть Kanban просто доской с карточками. Без ограничения числа задач в работе это обычный список.

Как узнать подход команды и почему их смешивают

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

Чистый подход встречается редко. В команде на Scrum может быть доска в духе Kanban, а договор с внешним подрядчиком может быть разбит на этапы, как в Waterfall, хотя внутри работа идёт короткими периодами. Это нормально: важно знать, где в такой смеси появляются требования. Когда над одним продуктом работают много команд, появляется SAFe: набор правил, которые согласуют планирование между командами.

Ошибка первая: считать, что «гибко» значит «без документации». Манифест ценит работающий продукт выше исчерпывающей документации, но не отменяет документацию. Ошибка вторая: верить названию. Если команда говорит «у нас Scrum», но демонстраций и работы периодами нет, это только слово.

Где это встречается в работе

• Первая неделя в новой команде. Сколько писать заранее и в каком виде, зависит от подхода, поэтому первый вопрос коллегам: когда у вас появляются требования.
• Планирование спринта. В команде на Scrum задачи готовят к планированию заранее, чтобы на встрече не тратить время на выяснение очевидного.
• Работа службы поддержки. Обращения приходят непредсказуемо, и им подходит доска с ограничением числа задач в работе, а не периоды.
• Проект с жёстким договором. Когда объём и срок зафиксированы в договоре, работа идёт этапами, а изменения оформляются отдельно.
• Продукт, над которым работают много команд. Планы команд приходится согласовывать между собой, и тут появляются правила вроде SAFe.

Итог

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

Что дальше

• 01-06. От идеи до релиза: жизненный цикл разработки и путь задачи
• 01-08. Как общаться в команде: встречи, согласование, эскалации
• 01-02. Типы компаний и проектов: продуктовая разработка, заказная, аутсорс, внутренняя ИТ
• 01-04. Роль системного аналитика

Источники

• The Scrum Guide. Роли, рабочие списки, встречи и длина спринта.
• Manifesto for Agile Software Development. Четыре ценности, 2001 год.
• The Kanban Guide. Kanban как метод, доска и ограничение числа задач в работе.
• Extreme Programming Rules. Практики XP: работа в паре, тесты до кода, частая сборка.
• SAFe Framework. SAFe как модель для масштабирования Lean и Agile.