Фреймворки и методологии
GIST Framework
G - Goals, I - Ideas, S - Step-projects, T - Tasks. Методика продуктового менеджмента и планирования работы, предложенная Itamar Gilad.
Методология старается уменьшить бюрократию и сделать планирование гибким.
Как работает:
- Goals - долгосрочные цели, например “увеличить удержание пользователей”.
- Ideas - гипотезы и инициативы, которые могут привести к достижению целей.
- Step-projects - короткие проекты, обычно до 10 недель, чтобы проверить гипотезы.
- Tasks - конкретные задачи для реализации проекта.
Вместо фиксированного roadmap тут используется адаптивное управление через приоритизацию идей и быстрые эксперименты.
На практике
GIST хорошо работает в продуктовых командах, которые устали от роадмапов, превращающихся в списки фич без обоснования. Начните с формулировки 2-3 целей на квартал и генерации идей под каждую - это уже даёт эффект. Выбирайте GIST, если хотите перейти от feature factory к гипотезо-ориентированной разработке.
Event Modeling
Способ проектирования информационных систем через описание событий, которые происходят во времени.
Как работает:
- Всё приложение описывается как поток событий и состояний.
- Используются таймлайны: “Событие → Команда → Проекция → UI”.
- Помогает разработчикам и бизнесу говорить на одном языке.
Особенность: альтернатива UML/ER-диаграммам, ближе к Event Sourcing + CQRS. Отлично подходит для систем с высокой сложностью бизнес-логики.
На практике
Event Modeling лучше всего раскрывается на совместных воркшопах, где разработчики и доменные эксперты собирают таймлайн на стене из стикеров. Используйте его при проектировании новых сервисов или при рефакторинге монолита - визуальная карта событий помогает найти границы контекстов. Не стоит применять для простых CRUD-приложений, где событийная модель создаст лишнюю сложность.
OMG Essence
Используется для сравнения методологий разработки.
Вместо жёсткого следования Scrum/XP/SAFe и т.д., есть “кирпичики” (альфы, активности, компетенции), из которых можно собирать свою методологию.
Особенность:
- Универсальный язык для описания практик.
- Позволяет “легализовать” кастомные процессы, а не только канонические Scrum/Kanban.
- Используется как фреймворк для методологий, а не методология сама по себе.
На практике
OMG Essence полезен крупным организациям, которые хотят описать и стандартизировать свои процессы без привязки к конкретному фреймворку. Если ваша команда уже работает по гибридной методологии - Essence поможет формализовать то, что вы делаете. Для небольших команд обычно избыточен - проще взять готовый фреймворк и адаптировать.
Scrumfall
Гибрид Scrum + Waterfall.
Как выглядит:
- Вроде бы команды работают по Scrum: спринты, демо, стендапы.
- Но при этом сверху идёт классический waterfall-подход: фиксированные требования, долгие согласования, жёсткий roadmap.
Спринты есть, но менять требования нельзя.
Зачастую встречается в корпорациях, где agile хотят внедрить, но полностью перестроить процессы не получилось.
На практике
Scrumfall - это не цель, а промежуточное состояние. Если вы обнаружили себя в нём - это нормальный этап трансформации, но не стоит на нём останавливаться. Главный сигнал: команды проводят ретроспективы, но ничего не могут изменить из-за внешних ограничений. Используйте как осознанный переходный период при внедрении agile в организации с жёсткой иерархией.
Crystal Clear
Из семейства Crystal Methods, автор - Alistair Cockburn.
Минималистичный Agile-процесс для малых команд до 8 человек.
Принципы:
- Частая доставка работающего ПО, каждые 2-3 месяца.
- Удобное взаимодействие в команде, лучше в одной комнате.
- Минимум артефактов и правил.
- Адаптивность к проекту и людям.
Основные понятия:
- Проектирование
- Доставка
- Итерации
- Период интеграции
- Собственно разработка
Особенность: одна из самых “лёгких” agile-методологий, где упор на общение и результат, а не на формальности.
На практике
Crystal Clear подходит маленьким сплочённым командам, которым Scrum кажется слишком церемониальным. Если ваша команда из 3-6 человек сидит рядом и может общаться напрямую - попробуйте убрать лишние артефакты и оставить только доставку и рефлексию. Не подойдёт распределённым командам или проектам с высокой критичностью, где нужна формальная документация.
DSDM
Одна из первых Agile-методологий (1994, UK).
Идея: управление проектами с жёсткими ограничениями по срокам и бюджету.
Принципы:
- Timeboxing (фиксированные итерации).
- Приоритизация по правилу MoSCoW (Must, Should, Could, Won’t).
- Активное участие заказчика.
- Частая поставка работающего продукта.
Особенность: предшественник Scrum и XP, но до сих пор используется в Европе как более формализованный agile-подход.
На практике
DSDM хорошо работает в контрактной разработке, где бюджет и сроки зафиксированы, но хочется гибкости в скоупе. MoSCoW-приоритизация - одна из самых полезных техник из DSDM, которую можно применять независимо от фреймворка. Выбирайте DSDM, если работаете с заказчиком, которому нужен понятный и предсказуемый процесс с элементами agile.
Shape Up
Подход к разработке продуктов от Basecamp (авторы - Ryan Singer и команда).
Ключевая идея Shape Up - фиксированное время, переменный скоуп. Вместо оценок используются аппетиты: сколько времени команда готова потратить на решение проблемы.
Как работает:
- Циклы по 6 недель для основной работы + 2 недели cooldown для свободных задач, багов, исследований.
- Shaping - старшие участники команды формируют задачу до нужного уровня детализации перед передачей в работу. Задача не слишком абстрактная, но и не расписана до пикселей.
- Betting table - руководство “делает ставки” на задачи для следующего цикла. Бэклога в традиционном смысле нет - если задача не выбрана, она просто теряется, и это нормально.
- Команда из 1-2 дизайнеров и 1-2 программистов получает полную автономию внутри цикла.
Принципы:
- Аппетиты вместо эстимейтов - не “сколько времени займёт”, а “сколько мы готовы на это потратить”.
- Нет бэклога - идеи, которые не прошли отбор, не копятся. Действительно важные вещи всплывут снова.
- Нет спринтов - 6 недель дают достаточно пространства для значимой работы без давления коротких итераций.
- Hill charts вместо burndown - визуализация прогресса через фазы “выясняю” и “реализую”.
На практике
Shape Up лучше всего подходит небольшим продуктовым командам, которые хотят делать значимые вещи без микроменеджмента. Cooldown-период между циклами критически важен - без него команда выгорает. Не пытайтесь применять Shape Up в сервисных компаниях с внешними заказчиками - подход заточен под продуктовую разработку, где команда сама определяет, что строить.
Lean Startup
Методология запуска и развития продуктов в условиях высокой неопределённости, предложенная Eric Ries.
Центральная идея - validated learning. Цель стартапа не создать продукт, а как можно быстрее узнать, что нужно рынку.
Как работает:
- Build-Measure-Learn - основной цикл. Построить минимальный продукт, измерить реакцию пользователей, сделать выводы.
- MVP (Minimum Viable Product) - минимальная версия продукта, достаточная для проверки гипотезы. Это может быть лендинг, прототип, видео или даже ручной процесс.
- Pivot or persevere - на основе данных принимается решение: продолжать текущий курс или кардинально сменить направление.
- Innovation accounting - метрики для измерения прогресса стартапа, которые отличаются от метрик зрелого бизнеса. Фокус на actionable metrics вместо vanity metrics.
Ключевые практики:
- Формулировка гипотез до написания кода.
- Самый дешёвый способ проверки предположений.
- Cohort analysis для понимания поведения пользователей.
- Split-тестирование (A/B) для валидации решений.
- Continuous deployment для быстрой доставки экспериментов.
На практике
Lean Startup незаменим на этапе поиска product-market fit, когда вы ещё не знаете, что именно строить. Главная ошибка - делать MVP слишком большим. Если на создание MVP уходит больше 2-4 недель, скорее всего скоуп завышен. Подход работает не только для стартапов - любая новая фича в зрелом продукте может быть запущена через цикл Build-Measure-Learn.
Итоги
| Методология | Основное назначение | Размер команды | Уровень формализации | Сфера применения | Особенности |
|---|---|---|---|---|---|
| GIST Framework | Управление продуктом, приоритизация идей и гипотез | Любой | Низкий | Продуктовый менеджмент, стартапы | Goals → Ideas → Step-projects → Tasks, быстрые эксперименты |
| Event Modeling | Проектирование ИС через события | Средние и крупные | Средний | Сложные бизнес-системы, event-driven | Визуальные таймлайны событий, альтернатива UML |
| OMG Essence | Конструктор методологий, унификация процессов | Любой | Высокий (метамодель) | Организации, которые создают/адаптируют процессы | ”Лего” из практик: альфы, активности, компетенции |
| Scrumfall | Компромисс Scrum + Waterfall | Средние и крупные | Средний | Корпорации, госзаказы | Формально Scrum, фактически Waterfall сверху |
| Crystal Clear | Лёгкий agile для маленьких команд | до 8 человек | Очень низкий | Малые команды, пилоты, R&D | Минимум артефактов, упор на общение и быстрые поставки |
| DSDM | Управление проектами в жёстких рамках | Малые и средние | Высокий | Классические IT-проекты, Европа | Timeboxing, MoSCoW-приоритизация, активное участие заказчика |
| Shape Up | Продуктовая разработка с автономией команд | 2-6 человек | Низкий | Продуктовые команды, SaaS | 6-недельные циклы, аппетиты вместо эстимейтов, нет бэклога |
| Lean Startup | Запуск продуктов в условиях неопределённости | Любой | Низкий | Стартапы, новые продукты, R&D | Build-Measure-Learn, MVP, pivot or persevere |
Нет "лучшего" фреймворка - есть фреймворк, подходящий вашему контексту. Начните с проблемы, а не с методологии.