· XP
· Scrum
· Crystal
· RUP
Здесь стоит сделать оговорку. RUP как таковой не является гибкой методикой, однако существует возможность настроить его таким образом, что он превратится в низкоформализованный, итеративный процесс.
Итак, эти методологии ориентированы на итеративную разработку программного обеспечения, а также или изначально созданы как низкофрмализованные, или существует возможность настроить их на минимальную формализацию процесса.
Рассмотрим Scrum в сравнении с остальными методологиями, и таким образом объясним, почему для разрабатываемой системы была выбрана именно она.
· Возьмем такой критерий, как легкость внедрения методики в процесс разработки. XP содержит в себе достаточно жесткие правила ведения проекта, которые не все разработчики могут принять, или просто может понадобиться продолжительное время, чтобы получить от них хорошую отдачу. А это рискованно, если проекты не очень большие и не рассчитаны хотя бы на год. Но в компании-заказчике дела обстоят именно таким образом. Если внедрение методологии идет тяжело, то велика вероятность не уложиться в сроки и потерять большую прибыль. Естественно, это недопустимо.
· XP – это больше набор методик, которые ничто не мешает внедрить и в другие методологии, в тот же Scrum или RUP. Они никак друг другу не противостоят. Scrum – это всего лишь каркас, а работу внутри самой команды можно наладить различными способами, включая, например, парное программирование.
· Если рассматривать RUP в его тяжелом варианте, то он совершенно не подходит для компании-заказчика, потому как создание слишком большого объема артефактов при коротких проектах – совершенно не выгодно. Облегченный же RUP – более подходящий, однако для его внедрения необходимо, чтобы весь управляющий персонал, включая менеджеров, досконально его знали, чтобы процесс разработки пошел в нужном направлении. В этом случае тоже требуются достаточно большие усилия и некоторая перестройка того процесса, который естественным образом сложился в компании. Scrum же очень близок к существующему на данный момент процессу заказчика, поэтому его внедрение займет минимум усилий и затрат.
· Из семейства методологий Crystal самой подходящей является Crystal Clear, но уж очень она абстрактная и общая. В ней не предусмотрены конкретные меры по организации работы в коллективе или планированию, а значит, в эффективности она проигрывает остальным методологиям, а по своей жесткости очень далеко отстоит от XP. Она не имеет смысла внедрения в работу компании-заказчика, так как по большому счету процесс, описанный Crystal, сам по себе сложился в данной организации.
Для того чтобы иметь полное представление о выбранной для компании-заказчика методологии разработки, приведем наиболее подробное ее описание.
Методология Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения. Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта.
Основа Scrum — итеративная разработка. Scrum определяет правила, по которым должен планироваться и управляться список требований к продукту для достижения максимальной прибыльности от реализованной функциональности; правила планирования итераций для максимальной заинтересованности команды в результате; основные правила взаимодействия участников команды для максимально быстрой реакции на существующую ситуацию; правила анализа и корректировки процесса разработки для совершенствования взаимодействия внутри команды. Каждую итерацию можно описать так: планируем — фиксируем — реализуем — анализируем. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разработки.
Scrum — простой каркас, который можно использовать для организации команды и достижения результата более продуктивно и с более высоким качеством за счет анализа сделанной работы и корректировки направления развития между итерациями. Методология позволяет команде выбрать задачи, которые должны быть выполнены, учитывая бизнес-приоритеты и технические возможности, а также решить, как их эффективно реализовать. Это позволяет создать условия, при которых команда работает с удовольствием и максимально продуктивно. К примеру, возможность самостоятельного выбора объема и пути решения задач без внешнего давления позволяет всем участникам команды почувствовать себя активными игроками, вовлеченными в процесс, а не простыми исполнителями, от которых требуется лишь четкая реализация поручений.
Scrum фокусируется на постоянном определении приоритетных задач, основываясь на бизнес целях, что увеличивает полезность и доходность проекта на его ранних стадиях. Так как при инициации проекта его доходность определить почти невозможно, Scrum предлагает концентрироваться на качестве разработки и к концу каждой итерации иметь промежуточный продукт, который можно использовать, пусть и с минимальными возможностями. Например, результатом итерации может быть каркас сайта, который можно показать на презентации.
Методология Scrum ориентирована на то, чтобы оперативно приспосабливаться к изменениям в требованиях, что позволяет команде быстро адаптировать продукт к нуждам заказчика. Такая адаптация достигается за счет получения обратной связи по результатам итерации: имея после каждой итерации продукт, который уже можно использовать, показывать и обсуждать, легче собирать информацию и делать правильные корректировки и изменять приоритеты требований. Например, если каркас сайта показать потенциальным пользователям, то появится много вопросов, на основании которых можно скорректировать то, что уже написано или еще не реализовано, понять что более важно пользователю.
Девиз Scrum — «анализируй и адаптируй»: анализируй то, что получил, адаптируй то, что есть, к реальной ситуации, а потом анализируй снова. Чем меньше формализма, тем более гибко и эффективно можно работать, — это основной принцип данной методологии. Но это не означает, что формальных процессов не должно быть совсем, их должно быть достаточно для организации эффективного взаимодействия и управления проектом. Формальная часть Scrum состоит из трех ролей, трех практик и трех основных документов.
Владелец продукта (Product Owner) — человек, поставляющий требования программистам. От того, как четко написаны требования, зависит, насколько часто команде придется переключаться с задачи на задачу в связи с отсутствием нужной информации, как много нужно задавать вопросов, на которые уходит дополнительное время, как сильно придется изменять уже написанную функциональность от итерации к итерации и, соответственно, эффективность разработки в целом. Обычно владелец продукта является представителем или доверенным лицом заказчика, а для компаний, выпускающих коробочные продукты, он представляет рынок, на котором реализуется продукт. Владелец продукта должен составить бизнес план, показывающий ожидаемую доходность и план развития с требованиями, отсортированными по коэффициенту окупаемости инвестиций. Исходя из имеющейся информации, владелец продукта подготавливает список требований, отсортированный по значимости. Чем лучше владелец продукта описывает требования, управляет приоритетами и чем быстрее выдает информацию, тем больший финансовый эффект получит компания от методологии. В обязанности этого сотрудника входит своевременное предоставление требований к продукту, определение дат и содержания релизов, эффективное управление приоритетами и корректировка требований для достижения максимальной окупаемости инвестиций в продукт.
От человека, исполняющего роль Scrum-мастера (Scrum Master), во многом зависит самостоятельность, инициативность программистов, удовлетворенность сделанной работой, атмосфера в команде и результат всей работы. Этот человек должен быть одним из членов команды разработки и участвовать в проекте как разработчик. Он отвечает за своевременное решение текущих проблем, от ремонта сломанного стула до обеспечения необходимой информацией членов команды для продолжения их работы и загруженности, за поддержание нужных технических практик, используемых на проекте. В обязанности Scrum-мастера входит обеспечение максимальной работоспособности и продуктивности команды, четкого взаимодействия между всеми участниками проекта, своевременное решение всех проблем, тормозящих или останавливающих работу любого члена команды, ограждение команды от всех воздействий извне во время итерации и обеспечение следования процессу всех участников проекта.
Scrum-команда (Scrum Team) — группа, состоящая из пяти–девяти самостоятельных, инициативных программистов. Первая задача этой команды — поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача — сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по определенным проектом «стандартам кодирования» (coding guidelines), программа протестирована полностью, а все найденные дефекты устранены. Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализировать и улучшать качество взаимодействия и работы. В обязанности всех членов Scrum-команды входит участие в выборе цели итерации и определение результата работы. Они должны делать все возможное и невозможное для достижения цели итерации в рамках, определенных проектом, эффективно взаимодействовать со всеми участниками команды, самостоятельно организовывать свою работу, предоставлять владельцу рабочий продукт в конце каждого цикла.