Shape Up: метод разработки от Basecamp — что это такое и как его можно сравнить со Scrum?
В мире, где Scrum уже стал «золотым стандартом», многие команды всё чаще чувствуют усталость от бесконечных спринтов, бэклогов и ритуалов. Basecamp в 2019 году выпустила книгу Райана Сингера и предложила радикально простой подход: Shape Up.
В конце покажу, как подружить Shape Up со Scrum, чтобы не ломать всё сразу, но получить реальные плюсы обоих подходов.
Что такое Shape Up?
Shape Up — это цикл разработки, который состоит из трёх фаз плюс обязательный период охлаждения. Вместо того чтобы планировать на годы и тянуть огромный бэклог, каждые 6 недель (+2 недели cool-down) команда «ставит» только на 1–2 полностью оформленных предложения и доводит их до продакшена.
Сценарии использования
Shape Up отлично работает, когда:
- команда 5–15 человек и выпускает новые фичи раз в 1–2 месяца;
- важна предсказуемость и спокойная работа (используется в Basecamp, GitHub частично, множество продуктовых команд);
- команда уже зрелая и не нуждается в постоянном контроле;
- требования относительно стабильные (SaaS, внутренние инструменты).
Не подходит для:
- финтеха и ежедневных релизов;
- глубокого R&D и AI-проектов;
- огромных корпораций с сотнями зависимостей.
Составляющие и особенности
1. Формирование проекта (Shaping)
Маленькая группа (обычно продакт + дизайнер + иногда техлид) заранее «оформляет» идею за 1–2 недели. Ключевой инструмент — аппетит: вместо вопроса «сколько это займёт?» задают вопрос «сколько времени мы готовы на это потратить?». Инструменты оформления:
- макетные платы (breadboarding) — схемы мест, действий и связей без дизайна;
- наброски толстым маркером — когда важно расположение элементов, но не хочется тонких деталей.
Результат — короткий pitch + грубые скетчи. Все главные риски сняты заранее.
2. Ставки / Голосование (Betting)
Раз в 6-8 недель руководство выбирает из готовых pitch’ей, на какие проекты «ставить» ресурсы. Бэклога нет — только выбранные ставки.
3. Разработка (Building) — 6 недель
Небольшая автономная команда (2–3 dev + дизайнер) получает полный проект и полную ответственность. Они сами разбивают работу, меняют объём и используют карту проекта (hill chart), чтобы показывать прогресс: «вверх по холму» — неопределённость, «вниз по холму» — понятная работа. Выпускают кусками, а не в последний день.
4. Период охлаждения (Cool-down) — 2 недели
После каждого цикла — обязательный перерыв: рефакторинг, мелкие баги, исследования, отдых. Команда перезаряжается - прорабатывает новые идеи/проекты.
Особенности:
- Нет ритуалов типа story points, velocity, Scrum Master и Product Owner в классическом смысле.
- Даже можно без ежедневных стендапов (если не хочется).
- Жёсткое правило: через 6 недель — стоп. Не уложились → проект откладывается на следующий цикл.
Сравнение со Scrum
Shape Up выигрывает в простоте и предсказуемости. Scrum — в частоте фидбека и дисциплине.
Где что подходит
Выбирайте Shape Up, если:
- хотите меньше митингов и больше реальной работы;
- команда устала от вечного бэклога и оценок;
- нужны предсказуемые результаты в ожидаемые сроки.
Оставайтесь на Scrum, если:
- нужны ежедневные/еженедельные релизы;
- высокая неопределённость, нет четких границ и целей;
- задач много, они часто короткие - появляются и меняются каждую неделю пачками
Гибрид Scrum + Shape Up: как это может быть
Расскажу свой опыт, который очень похож именно на гибрид Scrum + Shape Up.
Изначально была команда (7-10 разработчиков) только про 2-недельные спринты.
Задачи которые разрабатывали - по сути делились на 2 группы:
- текущие - как правило короткие задачи, правки, мелкие улучшения - которые регулярно приходят от бизнеса и обычно хорошо решались в рамках спринтов
- разные новые фичи и проекты - которые могут быть довольно длинными - 1-2-3-6 месяцев - которые постоянно буксовали и застревали в спринтах - начинали перетекать от спринта к спринту
Вот 2ю группу мы начали выделять по методу похожему на Shape Up:
- такие проекты бывают не всегда и команда формируется под проект с учетом его особенностей, контекста и необходимых знаний
- команда обычно 1-2-3 разработчика + продуктолог (опционально можно добавлять дизайнера или тестировщика)
- проект анализируется, обсуждается, декомпозируется и планируется в форме дорожной карты - для понимания сколько времени он может занять
- когда все готово и согласовано - проект запускается
При запуске происходит разделение команды. Часть команды остается работать в формате спринтов.
Часть команды уходит на выделенный проект:
- у такой команды нет скрам ритуалов - чистый Канбан, гибкость и автономность на время разработки проекта
- задачи могут перетасовываться и двигаться по доске почти как угодно - главное чтобы это повышало эффективность - и это сильно проще чем в скраме, потому что меньше бюрократии
- состав и формат встреч - команда определяет сама - как удобней и эффективней
- главная цель - завершить проект в установленные сроки
Период кул-дауна тут тоже есть - он занимает примерно от 20 до 30% от MVP. Типа запустили первую версию - начинается реальное использование. Прилетают баги, вопросы - это все надо решать.
Однако в зависимости от объема задач - бывает так что не весь состав проектной команды нужен. И часть разработчиков может вернуться обратно на спринты. А часть остается палировать проект (фиксить баги).
Итого
Shape Up — это не просто ещё одна методология, а настоящий антидот от скрам-выгорания. Книга Райана Сингера возвращает здравый смысл: лучше сделать меньше, но качественно и в срок, чем бесконечно планировать и переносить.
Однако нет гарантий что радикальные решения будут работать в конкретной команде. Иногда это нужно адаптировать под свою команду и делать гибридные процессы.
В нашем случае сработал гибрид где мы взяли плюсы из каждого подхода, а радикальные идеи сгладили:
- под текущие, регулярные и коротки задачи оставили спринты - это хорошо когда есть много коротких задач, от большого числа стейкхолдеров и надо сбалансировать интересы всех, договориться со всеми
- а вот под длинные и крупные задачи - сделали Shape Up - с выделением 1-2-3 разработчиков на время проекта - это хорошо работает когда есть четкий проект, и четкий срок - в который надо уложиться
Таким образом мы получили баланс между операционной текучкой и стратегическими проектами для бизнеса.
А также снизили стресс в команде от постоянных пробуксовок, блокеров и переносов задач - которые появлялись когда мы пытались впихнуть невпихуемое - большие проекты в маленькие спринты.