Методология Crystal

В 2002 году Алистером Коберном была издана книга «Быстрая разработка программного обеспечения», в которой впервые упоминается предложенная автором методология — Crystal. Она стала одной из первых методологий, пропагандирующих динамические изменения процессов на протяжении всего проекта.

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

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

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

В Crystal принято делить все проекты на жизненно-важные и не жизненно-важные. По хорошему, последний тип проектов нужно дробить и дальше — на те, которые могут привести к потерям, и те, которые с меньшей вероятностью приведут к потерям.

Все методологии Crystal различаются по цвету, причем каждый цвет предназначен для определенных проектов и имеет свои собственные характеристики: «Прозрачная» для самых легких и небольших проектов, затем «Желтая» и т.д., цвет зависит от сложности, объемности и прочих факторов. В некоторых случаях могут применяться даже фиолетовые цвета.

Самая простая из возможных классификаций Crystal — по критерию количества людей в проекте:

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

Вторым ключевым фактором является критичность. Под критичностью принято подразумевать величину возможного ущерба, нанесенного при возникновении ошибки. Так, ошибка в программном обеспечении для самолета или космического корабля несравнима с ошибкой в программном обеспечении для сайта или форума. Наиболее критичные и важные проекты имеют категорию L, наименее критичные — C, что подразумевает собой ошибки, которые будут доставлять легкие неудобства. Также различают и другие типы критичности:

  • E — Essential money (потеря основного дохода)
  • D — Discretionary money (потеря дополнительного дохода)

Ниже рассмотрены несколько самых распространенных цветовых схем. Выбор схемы осуществляется, исходя из критичности функциональной части (строки таблицы ниже) и размера команды (столбцы).

Методология Crystal - Google Документы - Google Ch

Crystal «Оранжевая»

Эта методология отлично подойдет для проектов среднего размера, обладающих следующими характеристиками:

  • общее количество занятых в проекте людей: от 20 до 50;
  • продолжительность работ: от 1 до 2 лет;
  • важно своевременное появление продукта на рынке;
  • нужно поддерживать общение между разработчиками, а также снижать временные и финансовые расходы по возможности;
  • критичность: не жизненно-важная.

Это обычный тип проектов, для которых характерен баланс между количеством поставляемых компонентов (документации, руководств и пр.) и срочными изменениями в требованиях и\или дизайне.

«Оранжевая» методология семейства Crystal относится к методологии D40. Это означает, что она подходит для команды численностью не более 40 человек, работающей в одном помещении или здании над разработкой определенной системы, сбой которой может привести к потере несущественной суммы. Для «Оранжевой» методологии нужна большая структуризация и координация команды, чем для проекта, над которым работает меньшее количество людей. Однако она не предусматривает четкого деления команды на подгруппы и не предполагает строгой проверки дизайна и кода системы (но и не исключает их, как это необходимо для жизненно-важных проектов).

«Оранжевая» методология Crystal характеризуется следующими условиями:

  • Необходимые роли включают в себя спонсора, эксперта в данном виде бизнеса, эксперта по использованию системы, технического посредника, бизнес-аналитика/проектировщика, руководителя проекта, архитектора , проектировщика/программиста, ведущего проектировщика/программиста, инженера по повторному использованию, писателя, тестировщика, дизайнера интерфейсов.
  • Все сотрудники распределяются по командам, которые отвечают за планирование, руководство, архитектуру, технологии, функционирование, инфраструктуру и внешнее тестирование.
  • Программный продукт проходит процесс контроля качества каждые 3 + 1 месяц; прогресс в работе отслеживается по контрольным точкам поставки частей системы, а не по документации; применяется автоматическое регрессивное тестирование функциональности системы; в работах непосредственным образом участвуют пользователи системы (по два пользователя на релиз); вспомогательные виды деятельности начинаются только тогда, когда сама система оказывается достаточно стабильной для ее проверки пользователями. «Настройка» методологии осуществляется на собраниях в начале и середине каждого инкремента.
  • В состав рабочих артефактов входят: документ с требованиями к системе, план релизов, отчеты о состоянии работ по проекту, документ, описывающий дизайн интерфейсов, общая объектная модель системы, внутрикомандные спецификации, руководство для пользователя, исходный код, тесты и код для миграции с предыдущей системы. Каждый из упомянутых здесь документов дорабатывается до той степени, при которой его начнут понимать коллеги по работе, а именно до уровня детализации, допускающего попарную работу.
  • Все шаблоны документов, стандарты кодирования, стандарты построения пользовательских интерфейсов и детали, касающиеся регрессивного тестирования, считаются локальными стандартами (вырабатываться и поддерживаться самой командой разработчиков).

 

Crystal «Прозрачная»

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

Для данной методологии обязательны следующие условия:

  • Отдельные роли: спонсор, старший дизайнер, дизайнер-программист и пользователь (последний может даже работать неполный рабочий день). Все остальные роли распределяются между членами команды: координатор проекта, эксперт в данном виде бизнеса, сборщик требований.
  • Над проектом работает только одна команда.
  • Методологические стандарты те же, что и в «Оранжевой» методологии, за исключением того, что каждый инкремент длится не более двух месяцев т.е более сжатые сроки.
  • Требуется меньшее количество артефактов: план релизов, план просмотра системы пользователями и план поставок, снабженные пояснениями варианты использования системы, наброски по дизайну системы и интерфейсам, различные заметки, общая объектная модель системы, работающий код, код миграции, тесты и руководство для пользователя.
  • Шаблоны для рабочих продуктов, стиль кодирования, стандарты построения пользовательских интерфейсов и детали, касающиеся регрессивного тестирования, точно так же считаются локальными стандартами.

 

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