Crystal Clear — гибкая методология разработки приложений и сайтов

Crystal Clear подойдёт для организации работы в маленьких командах и проектах. Пока крупные компании чаще выбирают Scrum или классический Agile, эта методология берёт простотой: минимум формальностей, ставка на живое общение и частые небольшие релизы. Разберём историю методологии, все 7 практик Crystal Clear, чем она отличается от Scrum и Kanban, а также её плюсы и минусы.

В YuSMP Group мы собираем выделенные команды разработки под задачи любого масштаба — от компактных Crystal Clear-команд из 3–5 человек до крупных Scrum-составов, и этот опыт лёг в основу материала.

Немного истории

Crystal Clear разработал Алистер Кокберн, известный в качестве одного из создателей манифеста гибкого программирования. Он долго исследовал и анализировал практики коммерческой разработки, принятые в разных командах.

А в 1994 году использовал свои наблюдения, консультируя проект Orange. По мотивам этой работы он написал книгу, а в 1998 году создал семейство методологий Crystal. Обычно их разделяют в зависимости от количества людей в команде.

Crystal Clear предназначена для групп до 8 разработчиков. Есть еще Red для команд из 50-100 сотрудников, Yellow для 10-20 и т.д.

Семь практик Crystal Clear

Разработка по Crystal Clear стоит на трёх обязательных практиках, а ещё четыре — желательны, но не строго обязательны для самой лёгкой версии методологии.

Три обязательные практики:

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

Ещё четыре практики (желательны, но не обязательны):

4. Чувство безопасности. Участники команды должны свободно высказывать сомнения и признавать ошибки, не опасаясь критики — это ускоряет выявление проблем на ранних стадиях.
5. Фокусировка. У каждого разработчика должно быть понимание приоритетов и достаточно непрерывного времени, чтобы сосредоточенно работать над задачей, а не переключаться между несколькими проектами.
6. Простой доступ к экспертам. Команда может быстро получить консультацию нужного специалиста — пользователя продукта, технического эксперта или заказчика — без долгих согласований.
7. Качественное техническое окружение. Сюда входят автоматизированные тесты, система контроля версий и частая интеграция кода — база, которая снижает цену ошибки при быстрых релизах.

Из чего состоит: циклы разработки

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

1. Проектирование. В него входит подготовка, доставка и так называемый «ритуал завершения», который представляет собой анализ и работу над ошибками. Последние два цикла могут повторяться несколько раз. А общий цикл может длится до двух недель.
2. Доставка. В нее входит дополнительная калибровка плана выхода нового программного обеспечения и несколько итераций. В итоге команда должна выпустить готовый к использованию код. Затем проводится его доставка и последующий анализ. Цикл может длится от одной недели до нескольких месяцев.
3. Итерации. В них входит три основные части: планирование, интеграция и завершение.
4. Единица измерения. В ее качестве могут принимать как один рабочий день, так и неделю. Ими отмеряют каждый цикл. В конце нужно созывать встречу и создавать отчеты.
5. Период интеграции. В него входит собственно написание кода, его интеграция в соответствующий продукт и проверка работоспособности системы. Есть два пути: можно внедрять новый код ежедневно (еженедельно) или сделать это непрекращающимся процессом, параллельным разработке.
6. Собственно разработка. Это процесс программирования, когда каждый из команды пишет код, проверяет его и интегрирует в общую систему.

Основные техники Crystal Clear

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

В качестве техник используют:

• Блиц-планирование с составлением тайминга задач и дорожной карты проекта.
• Парное программирование — совместная работа над одной задачей двух коллег.
• Воркшоп рефлексии — часовое совещание, на котором обсуждают слабые места продукта и возможности по их улучшению.
• Slide-by-slide — техника разработки, в процессе которой два коллеги сидят рядом, могут видеть работу друг друга, но занимаются разными задачами. Именно за счет такой близости должна производиться осмотическая коммуникация.

Семейство методов Crystal: как выбрать вариант под размер команды

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

Crystal Clear vs Scrum и Kanban: в чём разница

Crystal Clear, Scrum и Kanban — все относятся к гибким (Agile) подходам, но по-разному формализуют работу команды. Вот основные отличия:

Плюсы и минусы Crystal Clear

Плюсы:

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

Минусы:

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

Когда применять Crystal Clear

Crystal Clear стоит выбирать, если команда небольшая (до 8 человек), работает в одной локации или на постоянной видеосвязи, а проект не критичен для жизни и здоровья людей — например, внутренний сервис, MVP стартапа или сайт компании. Она плохо подойдёт для распределённых команд, проектов с высокой ценой ошибки (финтех, медицина, госзаказ) или там, где заказчик требует подробную документацию на каждом этапе.

Частые вопросы про Crystal Clear