Подходы и методологии: предиктивный, итеративный, гибкий — и семейство Agile целиком

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

Спорят в основном потому, что слова используются как синонимы. «Мы работаем по Agile» может означать что угодно: двухнедельные итерации, отсутствие документации, доску в Jira, отказ называть сроки или просто то, что менеджер прочитал книгу. Пока участники не согласовали, на каком уровне абстракции идёт спор, спор не сходится в принципе — поэтому глава начинается с лестницы понятий, а не с манифеста. Второй её сквозной тезис: подход — это решение о том, что вы фиксируете, а чем торгуетесь. Не про философию и не про «современность». Классический подход фиксирует объём и торгуется сроком и деньгами, гибкий фиксирует срок и мощность команды и торгуется объёмом; всё прочее — следствия.

1. Терминологическая лестница: семь ступеней

Лестница нужна не ради педантизма. Она объясняет три самые дорогие ошибки в этой области.

Подмена подхода инструментом. «Внедрим Jira и станем гибкими» — самая массовая. Инструмент стоит на седьмой ступени и не меняет ни одного решения о том, что фиксируется; он лишь делает видимым то, что уже происходит. Команда, которая раньше не понимала, кто над чем работает, после внедрения таск-трекера получает красивую доску и то же самое непонимание, оформленное в статусы.

Подмена практики фреймворком. «У нас Scrum, значит с качеством всё хорошо». Scrum — четвёртая ступень: он намеренно ничего не говорит о том, как писать код. Инженерные практики (шестая ступень) в нём — пустота, которую команда обязана заполнить сама, и если она этого не сделала, получится двухнедельный цикл выпуска нестабильного продукта. Об этом — раздел 8.

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

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

2. Подход: что фиксируем, а чем торгуемся

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

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

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

3. Предиктивный подход в двух абзацах

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

4. Agile: что написано в манифесте на самом деле

В феврале 2001 года семнадцать человек — среди них Кент Бек, Мартин Фаулер, Кен Швабер, Джефф Сазерленд, Алистер Кокбёрн, Уорд Каннингем, Роберт Мартин — собрались на лыжном курорте Сноуберд в Юте. Они представляли разные, конкурирующие между собой методологии: XP, Scrum, DSDM, Crystal, FDD, Adaptive Software Development. Задачей было не создать новую методологию, а найти общее в уже существующих. Результат — Manifesto for Agile Software Development: четыре ценности и двенадцать принципов, умещающиеся на одну страницу.

Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Последняя строка — самая цитируемая на конференциях и самая игнорируемая на практике. Манифест не говорит «документация не нужна», «контракт не нужен», «план не нужен». Он задаёт приоритет при конфликте: когда процесс мешает людям договориться, побеждают люди; когда документация конкурирует с работающим продуктом, побеждает продукт.

Двенадцать принципов группируются в четыре смысловых блока, и полезнее помнить блоки, чем формулировки:

• Ценность и поставка (1, 3, 7): удовлетворять заказчика ранней и непрерывной поставкой; поставлять работающий продукт часто, от пары недель до пары месяцев, отдавая предпочтение меньшим срокам; работающий продукт — основной показатель прогресса. Последний принцип уничтожает половину проектной отчётности: «сделано 70%» показателем не является.
• Изменения (2, 4): приветствовать изменение требований даже на поздних стадиях, обращая его в конкурентное преимущество; бизнес и разработчики работают вместе ежедневно.
• Люди (5, 6, 8, 11, 12): строить проекты вокруг мотивированных людей и доверять им; личное общение — самый эффективный способ передачи информации; устойчивый темп бесконечно (не «работайте больше», а «работайте столько, сколько сможете поддерживать годами»); лучшие архитектуры и решения рождаются в самоорганизующихся командах; команда регулярно ищет способы стать эффективнее и меняет своё поведение.
• Качество и простота (9, 10): постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость; простота — искусство не делать лишнюю работу — самый недооценённый принцип.

Чего в манифесте нет: слов Scrum, спринт, стендап, story points, скорость команды, product owner, ретроспектива, бэклог, доска, оценка в попугаях, масштабирование, коуч и сертификация. Всё это — надстройки, появившиеся позже, и ни одна из них не следует из манифеста логически. Полезное следствие: спор «это не по Agile» почти всегда некорректен, потому что апеллирует к тексту, где спорного пункта нет.

Карта нужна ровно для одного: не сравнивать сущности разных ступеней. Вопрос «что лучше, Scrum или TDD» бессмыслен — это фреймворк и практика, они не конкурируют, а сочетаются. Вопрос «Scrum или Kanban» осмыслен. Вопрос «Agile или водопад» осмыслен лишь наполовину: слева философия, справа модель процесса.

5. Кто есть кто в семействе

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

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

6. Scrum: фреймворк, а не методология

Scrum разработали Джефф Сазерленд и Кен Швабер, впервые применив на проекте в компании Easel в 1993 году и доложив о нём на конференции OOPSLA в 1995-м. Название пришло из статьи Такэути и Нонаки «The New New Product Development Game» (HBR, 1986), где успешные продуктовые команды японских компаний сравнивались со схваткой в регби: команда идёт к цели как единое целое, передавая мяч внутри, а не по эстафете от отдела к отделу. Именно передача «эстафетной палочки» между функциями — то, что Scrum устраняет конструктивно.

Конструкция целиком помещается в одну таблицу — и это её главное свойство, а не бедность.

Практическая механика, которую стоит унести из старых описаний Scrum: бэклог упорядочен, а не просто перечислен; приоритет определяется значимостью для проекта, ценностью для заказчика, ожидаемым доходом и простотой реализации — и в списке всегда есть задачи, до которых не дойдут никогда, это норма, а не дефект планирования. Пользовательские истории формулируются как «как <роль>, я хочу <действие>, чтобы <результат>»: форма заставляет назвать выгодоприобретателя и цель, а не только действие. Оценка ведётся относительно, а не в часах — сравнением задач между собой; покер планирования (описание Джеймса Греннинга) делает расхождение оценок видимым, и ценность его не в числе, а в разговоре: расхождение «2 и 13» почти всегда значит, что участники поняли задачу по-разному. Ничто не переносится в «сделано», пока не выполнен Definition of Done, — и это единственная защита от накопления невидимой незавершённой работы.

Детальный разбор Scrum Guide построчно, события, фасилитация и антипаттерны — предмет отдельного трека (Scrum-мастер); операционная сторона в проектном контексте — в Agile и Scrum. Здесь важно другое: Scrum — намеренно неполный каркас. Он не отвечает на вопросы, как проектировать архитектуру, как тестировать, как выпускать, как работать с несколькими командами, как считать деньги и как принимать решения вне спринта. Это не дефект, это проектное решение авторов: заполнение пустот — работа команды.

7. Kanban: метод управления потоком

Канбан-доску знают все, и почти все считают её сутью метода. Доска — визуализация, первая из шести практик; сутью является ограничение незавершённой работы. Дэвид Андерсон, оформивший метод в книге «Kanban: Successful Evolutionary Change for Your Technology Business» (2010), формулирует шесть практик:

1. Визуализируй поток работы — доска с колонками по фактическим этапам, а не по желаемым.
2. Ограничивай незавершённую работу (WIP) — на каждую колонку назначается лимит.
3. Управляй потоком — измеряй время прохождения, ищи, где работа стоит.
4. Сделай правила явными — что значит «готово к следующей колонке», записано и видно.
5. Введи петли обратной связи — регулярные обзоры на нескольких горизонтах.
6. Улучшай эволюционно — метод не требует реорганизации: начинается с того, что есть сейчас.

Лимит WIP — единственная механика, ради которой стоит внедрять Kanban, и она контринтуитивна: ограничение одновременной работы ускоряет поток. Причина в законе Литтла: среднее время прохождения задачи равно количеству незавершённой работы, делённому на пропускную способность. Задача, лежащая в работе, не приносит ценности, но занимает внимание, стареет и порождает переключения контекста. Команда, у которой в работе двадцать задач при пятерых людях, не делает больше — она делает то же самое, но узнаёт результат позже и обнаруживает проблемы дороже.

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

8. XP: единственный, кто говорит про код

Extreme Programming Кента Бека вырос из проекта Chrysler C3 (1996) и книги «Extreme Programming Explained» (1999). Логика в названии: взять практики, которые считаются полезными, и довести их до предела. Если ревью кода полезно — будем ревьюить постоянно, то есть программировать в паре. Если тестирование полезно — будем писать тесты до кода. Если интеграция болезненна — будем интегрировать по несколько раз в день. Если проектирование полезно — будем проектировать непрерывно, то есть рефакторить.

XP важен для этой главы одним наблюдением, которое подтверждается практикой раз за разом: гибкость невозможна без технической возможности менять систему дёшево. Готовность к изменениям — четвёртая ценность манифеста — это не установка ума, а свойство кодовой базы: наличие тестов, короткое время сборки, возможность выпустить в пятницу и откатиться за минуту. Команда, у которой релиз занимает две недели ручной регрессии, не может «приветствовать изменения» независимо от того, сколько ретроспектив она провела. Именно поэтому исследования DORA (dora.dev) измеряют не соблюдение практик Scrum, а четыре инженерных исхода: частоту развёртываний, время от коммита до прода, долю неудачных изменений и время восстановления (разбор).

Отсюда диагноз, который стоит выучить: «Agile» без инженерных практик деградирует за 6–12 месяцев. Сначала растёт скорость (сняли согласования), потом — количество дефектов, потом каждая новая фича стоит дороже предыдущей, потом команда начинает объяснять срывы «неопределённостью», и организация делает вывод, что гибкие подходы не работают. Работает не то, что было отменено, а то, что не было добавлено.

9. Что из популярных книг про Scrum правда, а что фольклор

Книга Джеффа Сазерленда «Scrum. Революционный метод управления проектами» (2014) — самый частый первый источник знаний о Scrum на русском языке, и в ней много верного, но написана она в жанре бизнес-бестселлера, а такой жанр систематически усиливает эффекты. Карта трека обещала разделять уровни доказательности — вот пример.

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

10. Где заканчивается гибкость

Барри Боэм и Ричард Тёрнер в книге «Balancing Agility and Discipline» (2003) сделали единственную серьёзную попытку определить границу количественно. Они выделили пять факторов, по которым у гибких и дисциплинированных подходов разные «домашние территории»:

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

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

1. Заказчик не может участвовать. Гибкость требует доступного человека, принимающего решения о продукте. Если ответ на вопрос приходит через две недели через трёх посредников, цикл обратной связи задан не вами.
2. Выпустить нельзя. Промышленное оборудование, встроенное ПО, релиз через регулятора, банковский релизный календарь с окном раз в квартал. Итерации есть, поставки нет — значит, нет и подхода.
3. Объём зафиксирован договором. При фиксированной цене за фиксированный объём торговаться нечем: гибкость упирается в юридический документ, а не в процесс. Здоровые варианты — фикс на этап, T&M с потолком или DSDM-подобная схема с фиксированным сроком и приоритизацией по MoSCoW.
4. Цена ошибки необратима. Там, где регулятор требует прослеживаемости требований до тестов, правая ветвь V-модели не отменяется никаким манифестом.
5. Нет инженерной базы. Отсутствие тестов, ручной релиз, полугодовая регрессия. Гибкость здесь — обещание, не подкреплённое возможностью.

Первые четыре пункта — про среду, пятый — про вас. Только он лечится изнутри команды.

11. Гибрид как норма, а не как признак незрелости

Форрестер в 2011 году ввёл термин water-Scrum-fall: планирование и бюджетирование остаются водопадными, разработка идёт спринтами, выпуск снова водопадный — через релизный комитет и окно. Термин вводился как диагноз, но с тех пор произошла переоценка: если наверху деньги выделяются раз в год, а внизу регулятор требует релизного окна, водопад сверху и снизу — не патология команды, а свойство организации. Полезно смотреть на это через три контура: подход выбирается на контур, а не на компанию.

Патологичным гибрид становится в двух случаях. Двойная отчётность: команда ведёт бэклог для себя и диаграмму Ганта для менеджера, синхронизируя их вручную; это не гибрид, а два процесса с ценой в человеко-неделях. Гибкость только вниз: от команды требуют «приветствовать изменения», а обязательства по срокам и объёму остаются жёсткими — это не подход, а способ переложить риск. Признак здорового гибрида ровно один: на каждом стыке явно названо, что фиксировано, а что переменная, и обе стороны это подписали. Инструменты стыковки существуют готовые — PRINCE2 Agile с его инверсией фиксации (время и стоимость жёсткие, объём и набор критериев качества гибкие), допуски и управление по отклонениям, гейты по рискам из спирали Боэма.

12. Типичные ошибки

13. Как это выглядит в проде

Продуктовая команда в вебе, 8 человек. Scrum как каркас плюс практики XP: транковая разработка, тесты, CI, выкатка несколько раз в неделю, парность на сложных участках. Ретроспектива раз в две недели меняет ровно одну вещь. Никакой сертификации, скорость команды не измеряется как KPI — измеряется время от идеи до обратной связи. Главный эффект достигнут не фреймворком: команда сократила релизный цикл с двух недель до дня, и после этого спор о длине спринта потерял смысл.

Платформенная команда, поток запросов от других команд. Scrum не прижился: половина работы — срочные обращения, такт постоянно ломался. Перешли на Kanban с лимитом WIP по три задачи на человека, явными правилами перехода между колонками и разделением классов обслуживания («срочное», «стандартное», «фоновое улучшение»). Время выполнения стандартного запроса упало вдвое без изменения численности — раньше половина задач одновременно висела в работе.

Банк, платёжное ядро и мобильное приложение. Осознанный гибрид. Ядро: предиктивный подход, прослеживаемость требований до тестов, релизное окно раз в квартал, изменения через контроль изменений. Приложение: двухнедельные итерации, еженедельные выкатки. Стык оформлен контрактом API с версионированием и фиксированной каденцией согласования. Работает потому, что обе стороны знают, что фиксировано у соседа: приложение не ждёт от ядра гибкости, ядро не требует от приложения полного ТЗ.

Где не сработало. Аутсорс-контракт с фиксированной ценой и фиксированным объёмом, внутри — Scrum «по правилам». Заказчик приносил изменения каждый спринт, ссылаясь на четвёртую ценность манифеста; подрядчик принимал их, ссылаясь на неё же. Через полгода объём вырос на 40% при неизменной цене, проект закрыли с убытком. Причина не в Scrum: на уровне подхода объём был зафиксирован договором, а на уровне процесса — объявлен переменной. Противоречие между ступенями лестницы всегда разрешается в пользу той, что выше.

Мини-итог

• Лестница из семи ступеней — парадигма, подход, методология, фреймворк, метод, практика, инструмент — снимает большую часть споров: сущности разных ступеней не сравнивают, а сочетают. Чем выше ступень, тем дороже её менять.
• Подход — это решение о том, что фиксируется, а чем торгуются. Предиктивный фиксирует объём и торгуется сроком и деньгами; адаптивный фиксирует срок и мощность и торгуется объёмом. Остальное — следствия, включая форму договора.
• Манифест Agile — четыре ценности с оговоркой «то, что справа, тоже ценно» и двенадцать принципов. В нём нет ни Scrum, ни спринтов, ни story points; всё это надстройки, и апелляция к манифесту в споре о них некорректна.
• Scrum — намеренно неполный фреймворк, Kanban — метод управления потоком, XP — методология с инженерным ядром, TDD — практика, Lean — набор принципов. Рабочая конфигурация большинства команд: каркас из Scrum или Kanban плюс инженерные практики XP; без второй половины гибкость деградирует за 6–12 месяцев.
• Отделяйте эвристику от измеренного факта. «Плюс 300–400% производительности» не воспроизводится, закон Брукса имеет понятный механизм, «ровно 23 минуты» — фольклор. Обещание, которое нельзя проверить, стоит дороже, чем кажется.
• Границу гибкости задают пять факторов Боэма и Тёрнера — размер, критичность, динамизм, персонал, культура — и пять практических сигналов: недоступный заказчик, невозможность выпускать, зафиксированный договором объём, необратимая цена ошибки и отсутствие инженерной базы.
• Гибрид — норма для крупных организаций, а не признак незрелости. Подход выбирается на контур; здоровый гибрид отличается от больного тем, что на каждом стыке явно названо, что фиксировано, а что переменная.

Источники

• Manifesto for Agile Software Development и двенадцать принципов, 2001 — первоисточник, читается за пять минут.
• Takeuchi H., Nonaka I., «The New New Product Development Game», HBR 1986 — статья, из которой пришло слово scrum.
• Beck K., «Extreme Programming Explained», 1999 — практики XP и логика доведения до предела.
• Anderson D., Kanban — шесть практик, лимиты WIP, эволюционные изменения.
• Poppendieck M., Poppendieck T., «Lean Software Development», 2003 — перенос принципов Toyota в разработку.
• Boehm B., Turner R., «Balancing Agility and Discipline», 2003 — пять факторов и домашние территории подходов.
• Brooks F., «The Mythical Man-Month», 1975 — закон Брукса и механизм коммуникационных издержек.
• Larman C., Basili V., «Iterative and Incremental Development: A Brief History», IEEE Computer 2003 — итеративная разработка задолго до Agile.
• Grenning J., «Planning Poker», 2002 — относительная оценка и ценность разговора.
• DORA Research и Forsgren N., Humble J., Kim G., «Accelerate», 2018 — измеряемые исходы вместо соблюдения ритуалов.
• Kanban/Agile/Scrum/Lean — гибкие методологии разработки и разбор книги Сазерленда — популярные русскоязычные обзоры, из которых выросла эта глава.

Что дальше

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

Самая полная попытка такого ответа — PMBOK: свод знаний, а не методология. Следующая глава разбирает его целиком: как из 44 процессов и 9 областей знаний он вырос до 49 и 10, а затем в седьмом издании развернулся на 180 градусов — к 12 принципам и 8 доменам исполнения; что такое ITTO и почему их не надо зубрить; почему управление интеграцией стоит над остальными областями и не поддаётся планированию; и что из этой энциклопедии имеет смысл брать в IT-проект.

Читайте: PMBOK: от 49 процессов и 10 областей знаний к 12 принципам и 8 доменам