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

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

1. быстрая доставка полезного кода, переход от больших и редких развёртываний кода к меньшим и более частым релизам.
2. усовершенствование через рефлексию — получение сведений о том, что работало хорошо и плохо в предыдущей версии программы для улучшения следующей версии ПО.
3. «осмотическая» коммуникация — Алистер объяснил восприятие и обмен информацией между разработчиками приложения в одной комнате как фоновый шум, напоминающий явления осмоса.

• Clear — от 2 до 8 человек, которые сидят вместе в одном или смежных офисах
• Yellow — 10-20 человек
• Orange — 20-50 человек в команде
• Red — от 50 до 100.

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

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

1. Проектный цикл — хоть проект сам по себе — единица продукта, за ним обычно следует другой проект, повторяющий цикл. Проектный цикл состоит из трёх частей: подготовка (сбор команды, исследование на 360°, определение методологии), серия из двух и более циклов доставки и «ритуала завершения». Длится от нескольких дней до недель.
2. Цикл доставки — состоит из повторной калибровки плана выпуска ПО, серий из одной или нескольких итераций, в результате которых создаётся протестированный интегрированный код, доставки реальным пользователям и «ритуала завершения». Длительность — от 1 недели до 3 месяцев.
3. Итерация — состоит из трёх больших частей: итерационное планирование, дневная и интеграционная деятельность цикла и «ритуал завершения» проекта.
4. Рабочая неделя/день — выбор дня или недели в виде единицы времени цикла зависит от формата проекта и команды. Например, в таком формате проводятся еженедельные встречи отделов, отчётные встречи тимлидеров, «brown-bag» семинары (когда каждый приносит собственный ланч и за перекусом решаются вопросы по проекту).
5. Период интеграции — разработка, интеграция и тестирование системы. В некоторых командах процесс сборки-тестирования проходит не прекращаясь, за что отвечает отдельная машина, другие идут по пути интеграции раз в день или три раза в неделю. Чем короче цикл интеграции, тем лучше. Длительность от 30 минут до 3 дней (зависимо от опыта команды).
6. Разработка — написание и проверка части кода. Это по сути основа работы программиста в «гибкой разработке». Член команды берёт небольшую задачу, программирует решение (в идеале с тестированием) и проверяет её в конфигурации с целой системой. Занимает от 15 минут до нескольких дней.

• Исследование на 360° — в самом начале работы над проектом команде необходимо понять, насколько полезен и осмыслен продукт, и можно ли его создать с имеющимися ресурсами и технологиями. Для этого проект рассматривается в следующих направлениях: бизнес-ценность, требования, требуемые технологии, план проекта, состав команды, выбранные методологии. Реализация стратегия занимает от пары дней до 1-2 недель.
• Ранняя победа — победа сплочает команду и повышает уверенность каждого из её членов. При работе над приложениями стратегия ранней победы заключается в поиске первого куска рабочего кода. В его роли обычно выступает небольшой элемент полезной системной функции (например, возможность добавить объект в базу данных системы и посмотреть на него), который называют «ходячим скелетоном». Члены команды на основе этой маленькой победы изучают стили работы друг друга, пользователи получают раннее представление о системе, спонсоры (заказчики) видят работоспособность команды.
• Инкрементальная смена архитектуры — архитектура системы должна развиваться, ведь технологические и бизнес-требования меняются со временем. Чем больше проект, тем менее эффективно останавливать разработку для проведения архитектурного пересмотра. На решение проблемы и направлена стратегия: команда меняет архитектуру поэтапно, без нарушения работы всей системы. Эту же стратегию можно применять для внесения изменения в функционал конечной системы.
• Информационные радиаторы — дисплей, который размещают там, где люди могут его видеть во время работы или отдыха. Он показывает нужную информацию без необходимости задавать лишние вопросы, а это воплощает в жизнь важное для Crystal Clear правило «больше общения, меньше перерывов».
  Информационный радиатор должен быть большим, легкодоступным, простым в использовании и считывании, содержать актуальную информацию. Яркий пример таких объектов — Scrum- и Канбан-доски, менее очевидный — рабочий глоссарий, в котором прописана интерпретация терминологии, используемой в проекте.

1. Формирование методологии — настройка Crystal Clear проходит в два этапа: проектные интервью (из которых создаётся мини-библиотека опыта организации, которая покажет слабые и сильные стороны проектной команды) и воркшоп по формированию методологии (изучение опыта для усиления сильных и компенсации слабых сторон организации). Как видите, информация, полученная на первом шаге, используется во втором.
2. Воркшоп рефлексии — время от времени команда должна делать часовую паузу, во время которой проводить «воркшоп рефлексии» — обсуждение таких моментов как: что работает хорошо или плохо, что необходимо улучшить, что можно сделать по-другому на следующих этапах проекта.
3. Блиц-планирование — возможность для заказчика (спонсора), пользователя и разработчиков совместно составить карту проекта с временными ограничениями.
4. Ежедневные «стенд-ап» встречи — короткие встречи для определения статуса проекта, прогресса и проблем. Ключевое слово здесь — «короткие». Эти встречи не для обсуждения, а только для идентификации проблем. Полученные результаты указывают в онлайн таск-менеджере или на физической канбан-доске.
   
5. Парное программирование — в рамках процесса двое людей работают над одной задачей по программированию на одном устройстве. Парное программирование часто критикуют за лишение индивидуальности подхода к задаче и повышенным требованиям к качеству личных взаимоотношений членов проектной команды.
   Этого лишена альтернативная техника — «slide-by-slide», при которой двое людей сидят достаточно близко друг к другу, чтобы видеть, что происходит на экране соседа, но работа происходит на отдельных рабочих станциях над разными заданиями. Это соответствует концепции «осмотического взаимодействия», о котором мы писали в начале статьи.

• «Crystal Clear: A Human-Powered Methodology for Small Teams» Алистера Кокбёрна — ключевая книга для изучения методологии от создателя семейства Crystal. В книге много кейсов, примеров и мини-руководств по внедрению отдельных элементов Clear в работу организации.
• «Pair Programming Illuminated» Лори Вильямс — детальный разбор одной из техник Crystal Clear — парного программирования. Согласно исследованию автора, использование техники повышает качество исходного кода и одновременно уменьшает затраченное на разработку время. В книге нашлось место и практическим советам по использованию PP в разработке ПО.
• «Agile Software Development: The Cooperative Game» Алистера Кокбёрна — в книге детально объясняется концепция разработки программного обеспечения как «кооперативной игры изобретения и общения». В ней Алистер развил идеи методологии Crystal Clear, которые позже оформил в отдельную книгу «Crystal Clear: A Human-Powered Methodology for Small Teams».
• «Гибкое управление проектами и продуктами» Бориса Вольфсона — отдельная глава в книге посвящена Crystal Clear. Кратко и чётко, со схемой, описанием стратегий и техник.
• Официальный сайт создателя Crystal Clear — не книга, но информации здесь можно найти на целую библиотеку. Много интервью, схем, публикаций в разных блогах, обсуждений по методологии. Единственный минус — недружелюбный дизайн страницы.