Вопрос не «какой подход лучше», а «какой подход этой задаче»
Спор «Agile против Waterfall» почти всегда ведут нечестно: одна сторона продаёт гибкость как лекарство, другая защищает план как дисциплину. Обе подменяют вопрос. Правильный вопрос звучит иначе — какова природа этой конкретной задачи и какой способ работы ей соответствует.
Эта лекция не будет доказывать, что Agile быстрее, дешевле или надёжнее каскадной модели. Такого доказательства нет: самая известная цифра на эту тему не выдерживает проверки, и мы разберём, почему именно (тема 12). Зато есть вещи, которые проверяемы: что записано в Manifesto for Agile Software Development, что дословно требует Scrum Guide, как работает арифметика потока в Kanban и где закон прямо запрещает менять объём работ по ходу.
Гибкие подходы не быстрее каскада. Они дешевле в изменениях и дороже в координации. Каскад — наоборот. Выбор подхода — это выбор, за что вы готовы платить, а не выбор между современным и устаревшим.
Лекцию ждут три профессии — и каждая уносит своё
Куда девается техническое задание и чем его заменяет бэклог. INVEST и критерии приёмки. Где в Scrum живут нефункциональные требования. Почему уточнение бэклога — не встреча в календаре.
Владелец продукта — один человек, а не комитет. Три обязательства: цель продукта, цель спринта, определение готовности. Порядок в бэклоге вместо корзин приоритетов. Что показывать наверх.
Таймбоксы и их смысл. WIP-лимиты, закон Литтла, узкое место. Метрики потока и DORA. Cynefin как диагностика. Где каскад остаётся обязательным по устройству процедуры.
Примеры в темах идут вперемешку из четырёх рабочих контекстов: продуктовая команда в вебе, поток заявок в поддержке и эксплуатации, сбор требований к внутренней системе и проект с фиксированным техническим заданием по контракту. Один и тот же приём в этих четырёх контекстах ведёт себя по-разному, и это важнее, чем определения.
- Утверждения, что каскадная модель устарела или неправильна. Есть задачи, где она единственно возможна.
- Обещания, что сертификат делает человека специалистом — эту претензию мы услышим от самих авторов Манифеста.
- «Нормальных» цифр: сколько недель в спринте, каким должен быть WIP-лимит, какая скорость считается хорошей. Единственные жёсткие числа в теме — таймбоксы Scrum Guide.
- Спорных вещей, поданных как бесспорные. Там, где источники расходятся, лекция скажет об этом прямо.
Восемнадцать тем, пять частей. Начнём с двух документов, вокруг которых построен весь спор, — и оба чаще пересказывают, чем читают.
Манифест 2001: 68 слов и оговорка, которую опускают
С 11 по 13 февраля 2001 года семнадцать человек собрались в лыжном отеле The Lodge at Snowbird в горах Уосатч, штат Юта. Итог встречи — Manifesto for Agile Software Development, опубликованный на agilemanifesto.org. С 2001 года его ни разу не пересматривали.
Это не было изобретением с нуля и не было первой встречей: часть тех же людей собиралась в Орегоне годом раньше. В Юту приехали представители подходов, которые уже существовали и работали, — Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Среди подписавших Кент Бек, создатель XP; Джефф Сазерленд и Кен Швабер, соавторы Scrum; Мартин Фаулер, Джим Хайсмит, Алистер Коберн, Уорд Каннингем, Роберт Мартин, Арье ван Беннекум, Джон Керн, Стив Меллор, Майк Бидл.
Четыре ценности
- Люди и взаимодействие — важнее процессов и инструментов.
- Работающий продукт — важнее исчерпывающей документации.
- Сотрудничество с заказчиком — важнее согласования условий контракта.
- Готовность к изменениям — важнее следования первоначальному плану.
Сразу за четырьмя строчками в Манифесте стоит фраза: «не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева».
То есть документация, контракт и план не отменяются. Речь о приоритете при конфликте, а не об отказе. Половина споров про Agile — это спор с текстом, из которого выкинули вторую половину предложения.
Весь текст ценностей — 68 слов. К нему прилагаются двенадцать принципов. Первый: «Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения». Второй: «Изменение требований приветствуется даже на поздних стадиях разработки». Один из поздних: «Непрерывное внимание к техническому совершенству и качеству проектирования повышает гибкость».
Обратите внимание, чего в Манифесте нет. Там нет ролей, нет встреч, нет спринтов, нет досок с колонками и нет ни одного слова про скрам-мастера. Всё это появилось в конкретных фреймворках, которые существовали до Манифеста и которые в него уложились.
- Scrum и Kanban — не «части Agile». Это самостоятельные фреймворки, которые совместимы с ценностями Манифеста.
- Обратное неверно: работа по Scrum сама по себе не гарантирует соответствия Манифесту. Можно проводить все пять событий и при этом не иметь ни ранней поставки, ни готовности к изменениям.
Дальше нужен аккаунт
Прогресс и монеты сохранятся.