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

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

Существует ли конфликт между Agile и Waterfall

Основное отличие, которое кажется непримиримым у методологий — отношение к изменениям. В Waterfall нужно стараться заранее все планировать по пунктам на весь срок проекта. 

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

Также различаются требования к командам. В каскадной модели все должны четко выполнять задачи по плану, в то время как в Agile от сотрудников ждут инициативности, вовлеченности и самостоятельности. 

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

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

Как это может работать. Если банк решил запустить новый сервис для клиентов, то здесь команде подходит Waterfall. Команда разрабатывает проект и готовит к тестированию. На следующем этапе нужно дать клиентам доступ к сервису для тестов. Можно внедрить Agile конкретно на этом этапе, чтобы методом проб и тестов подобрать лучший вариант реализации. 

Когда каскад неизбежен, но гибкость критична: кейсы и ограничения

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

Работа HR и других отделов

По умолчанию работа этого отдела проходит по каскаду: прием → онбординг → управление производительностью → уход. 

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

HR будет проще не упустить ни одной задачи с каждым кандидатом или сотрудником. Чтобы было удобнее — каждый этап можно оформить в виде чек-листов:

→ Подробнее о том, как можно применить канбан-доски в разных направлениях проектов читайте в статье «Канбан за рамками IT. Неожиданные сферы применения популярного инструмента».

Кейс строительной компании

В чем суть. Компания Good Wood решила заняться улучшением процессов во всех подразделениях организации. С помощью таск-трекера руководителям удалось систематизировать улучшения и управлять ими. 

Как вели работу над улучшениями:

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

Результаты:

• запустили уже более 100 улучшений по всем направлениям;
• убрали время на распределение материалов, чтобы все продукты приезжали на объект уже расфасованными по этапам;
• улучшили условия для рабочих на стройплощадках.

Кейс горно-металлургической компании

В чем суть. «Удоканская медь» — крупное производственное предприятие, где работает +4500 сотрудников. Руководство решило автоматизировать часть процессов и упростить постановку задач.

Как многие крупные производства, предприятие работало по каскадной модели. Но это не помешало внедрить таск-трекер Kaiten и элементы Agile, сделать процессы прозрачнее и улучшить эффективность команды. 

Результаты:

• модернизировали и разложили по колонкам полный цикл задач 1C;
• выстроили сквозные процессы в документообороте; 
• синхронизировали работу бизнес-аналитиков и IT-специалистов;
• научились находить «узкие места» в процессах благодаря дашбордам Kaiten и исправлять их;
• организовали портфельное управление проектами, для каждого направления создали отдельную доску;
• навели порядок в работе команд и визуализировали загрузку каждого сотрудника;
• увеличили эффективность работы команд в 2 раза.

Успешные компании уже используют Kaiten Попробуйте расширенный функционал на своем проекте бесплатно

Попробовать

Стратегии «точечной» адаптивности: Water-Scrum-Fall, гибриды, Mini-Sprints

В этом блоке раскроем 3 варианта практики, когда проект требует навыков подстройки на ходу и важно найти баланс между методологиями. 

Water-Scrum-Fall (или Scrumerfall)

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

Как работает. Проект делят на большие этапы, как в Waterfall. Но затем внедряют спринты Scrum для разработки и тестирования:

1. Проектирование и требования по «каскаду». Команда формирует высокоуровневый план и определяет объем проекта.
2. Разработка и тестирование по Scrum. В этой фазе задачи разбивают на пользовательские истории и расставляют по приоритетам, а затем работают над ними. В конце каждого спринта проводят ретроспективу.
3. Внедрение по «каскаду». Когда разработка завершена, команда возвращается к традиционной методологии для запуска продукта в производство и его обслуживания. 

Особенности. Команда остается гибкой во время разработки и использует все преимущества Waterfall. Но жесткость традиционного метода может приводить к конфликтам в команде.

Для каждого этапа вы можете создать свою доску в Kaiten и вести проект так, как удобно. Виртуальные Kanban-доски позволяют командам визуализировать задачи, видеть, на каком этапе они находятся, и управлять процессами в реальном времени.

Для этапа сбора требований вы можете использовать обычную канбан-доску, а для спринтов — специальную, по шаблону Scrum. Так задачи не будут выпадать из поля зрения и все будет под контролем.

Hybrid Stage-Gate

Гибрид методологии Stage-Gate и некоторых элементов итеративного подхода Agile. Команды используют метод, чтобы поделить каждый этап работы над продуктом на серию итераций. Принимают решение переходить на следующий этап, когда продукт соответствует всем критериям. 

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

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

Mini-Sprints

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

Как работает команда:

1. Разбирается в потребностях пользователей. Анализируют профили, создают портреты ЦА, приоритезирует цели и контекст использования продукта.
2. Анализирует бизнес-требования. Проводит конкурентный обзор, выделяет задачу. 
3. Изучает проект. Определяет приоритеты для дополнительных исследований, закрывает пробелы в знаниях, проверяет предположения. 
4. Генерирует идеи. Собирает сразу несколько вариантов воплощения идей, отбирает лучшие предложения. 
5. Создает рабочий процесс или каркас. На этом этапе команда получает результат, в котором зафиксировано выбранное решение, показывает его стейкхолдерам. 

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

Backlog, daily-sync, review внутри Waterfall-фаз 

Инструменты Agile можно использовать внутри фаз Waterfall также, как сочетать гибкость и структурированность методологий. Разберем, как это может работать на проекте.

Бэклог. Список задач для достижения цели интегрировать в проект по «каскаду» на этапе определения требований. Затем записать функции, расставить приоритеты и задокументировать бэклог. Так будет проще следить за изменениями и вовремя корректировать работу команды.

Расставить приоритеты можно с помощью разных методик. Мы уже рассказывали, как это сделать по методике MoSCoW и не сойти с ума. 

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

Ежедневные стендапы. Обычно короткие встречи на 15 минут проводят в Agile, но их можно внедрить в «каскадной» разработке на этапе реализации. Команда так будет проще сфокусироваться на проекте, обсудить действия каждого сотрудника на день и увидеть проблемы, которые нужно решить. 

Это поможет: 

• получить ранний фидбек; 
• улучшить обмен информацией внутри команды и с заинтересованными сторонами; 
• синхронизировать разработчиков;
• добиться лучшего результата;
• выявить проблемы на ранних этапах.

Обзоры (review). Эти встречи проводят регулярно, чтобы оценить выполненную работу и проверить ее соответствие поставленным целям. Это может быть рабочий прототип или завершенный функционал. Стейкхолдеры на ревью дают обратную связь, команда может анализировать ход спринта и определять, чего уже удалось добиться. 

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

Гибкость без потери контроля: бюджет, планы, документация

Важно, чтобы проект оставался адаптивным к изменениям внутри фаз Waterfall и при этом сохранял структуру, контрольные точки и управляемость для стейкхолдеров. Для этого можно использовать сразу несколько инструментов: Change Budget, Rolling Wave Planning и «живые» документы. 

Change Budget (бюджет на изменения)

В контракте с заказчиком или в уставе проекта можно прописать бюджет на изменения, его размер и процедуру, по которой можно получить финансирование из бюджета. С помощью Change Budget вы сможете покрыть расходы, которые появились из-за изменений в объеме работ, требований или приоритетов. 

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

• собирается комиссия или управляющий комитет проекта;
• оценивается влияние изменения на сроки, другие части проекта и на стратегию;
• принимается решение управляющими лицами. 

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

Бюджет на изменения всегда закладывается, если использовать метод управления проектом PRINCE2. 

Rolling Wave Planning (планирование «набегающей волной»)

Инструмент планирования «набегающей волной» позволяет детально планировать ближайшую фазу или этап работ, а последующие — на более высоком уровне. Когда команда проходит один этап, то детально прорабатывает следующий. Чем ближе к последним фазам, тем детальнее весь проект.

Команда не будет пытаться предугадать и детализировать весь проект на год вперед. Достаточно уточнить и детализировать задачи и методы для выполнения текущей фазы на основе самой свежей информации. Это особенно полезно, если внутри Waterfall-фазы команда использует Mini-Sprints или элементы Scrum.

Один из вариантов детализировать задачи для текущей фазы — использовать модуль «Ресурсное планирование» Kaiten:

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

Living Documents («Живые» документы)

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

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

Чек-лист: как внести изменение

Чтобы зафиксировать обновление графика, бюджета или требования, стоит пройти по пунктам чек-листа:

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

Чтобы было проще выполнить все пункты и ничего не забыть, чек-лист можно добавить в карточку Kaiten:

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

• Требования — внести изменения в спецификацию требований, пользовательские истории, бэклог.
• График — актуализировать план-график проекта в Kaiten, пересмотреть зависимости и критический путь.
• Бюджет — обновить план, зафиксировать источник финансирования.
• Документация — обновить все связанные документы. 

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

Заключение

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