Экстремальные методологии. Экстремальные методологии
 Скачать 19.83 Kb.
|
|
Экстремальные методологии (ЭМ) представляют собой наборы рекомендаций, которые по отдельности выглядят противоречащими здравому смыслу и классическим схемам – отсюда и пошло название – экстремальные методологии. Но эти рекомендации, собранные в правильной комбинации, превращаются в эффективно работающий инструмент. В первую очередь ЭМ нацелены на скорейшее получение конкретного результата, удовлетворение главных требований пользователя и более медленную доработку системы в соответствии с дополнительными требованиями. При этом новые требования компонуются в виде набора и реализуются в течение одной итерации цикла, продолжительность которой обычно не более недели. Направление развития системы рассматривается прежде всего с точки зрения потенциальных рисков: сложные и сомнительные функциональные возможности откладываются на более позднее выполнение. Несомненным достоинством легких методологий является значительное уменьшение документации. Практически вся документация включается в код и представляет собой списки правил, принципов, пожеланий и уточнений, связанных с требованиями заказчиков. В принципе суть легких методологий заключается в постоянном стремлении минимизировать реальные объемы работ и делать это везде, где только возможно. Однако работать ЭМ будут только при наличии высокопрофессиональной команды, в которой отлажен механизм взаимодействия, а каждый сотрудник способен переключаться на разные виды работ. Рассмотрим более подробно одну из наиболее популярных ЭМ – экстремальное программирование (ЭП, ХР, eХtreme Programming). 2.7.2. Экстремальное программирование (ХР) Для создания ХР его автор Kont Beck исходил из следующих соображений [4]. Если в классических методиках считается, что тестирование – это хорошо, то тестировать следует все что можно и при этом непрерывно. Если полезно проектирование системы, значит анализ и синтез структуры продукта будут выполняться ежедневно. Если важна простота при построении системы, то целью разработки ставится скорейшее создание реальной работающей системы, реализующей минимум самой главной функциональности. Если эффективны комплексные сборки, позволяющие выявить проблемы с нестыковкой нескольких модулей, и итерационное тестирование, значит они будут выполняться несколько раз в день. Наконец, если хорошо работают короткие итерационные циклы «анализ-проектирование-разработка-тестирование», значит их продолжительность будет составлять не недели и месяцы, а часы или минуты. Главная идея ХР заключается в том, что после того, как сформулирована задача, программист готовит тестовый пример, проверяющий базовую функциональность будущей программы. Затем эта функциональность реализуется в виде программы с ориентацией на подготовленный тест. Если проверка с его помощью выполнена успешно, начинается следующая итерация – готовится новый тест, уточняющий и расширяющий требования предыдущего, под новые требования дописывается программный код и т.д. Главное в таком цикле разработки – стараться плавно расширять требования тестов, чтобы удавалось быстро создать новое правильно работающее приложение. При таком подходе гарантируется, что ненужные или излишние требования, вошедшие в первоначальный проект (например, на уровне описания классов) не будут реализованы. Таким образом, система разрабатывается максимально короткими, частыми и гибкими итерационными циклами, которые выполняются на фоне непрерывного улучшения качества этих циклов, при непрерывной связи с заказчиком и избавлении от избыточной документации. Рассмотрим теперь более подробно принципы ХР, которые определяют его достоинства. Разработка через тестирование. На протяжении всего проекта усилия сосредоточены на проверке создаваемой системы. Программисты на основе требований заказчика предварительно (и в этом основной смысл) создают тесты, а затем пишут программное обеспечение, которое должно соответствовать этим тестам. Если разработанные таким образом программы будут выполняться на соответствующих тестах, то дополнительной отладки уже не потребуется, гарантируется соответствие продукта заказанной функциональности, и разработчикам будет заранее известно, как будет выглядеть ИС (схема взаимодействия с пользователем, реагирование на различные типы входных данных, структура пользовательского интерфейса и т.д.). Парное программирование. Этот важный принцип ХР заключается в организации одновременной работы двух программистов над одним кодом: один пишет код, другой контролирует его работу или работает над архитектурой программы, периодически меняясь местами. Таким образом обеспечивается контроль за чужим исходным текстом и получение обратной связи в реальном времени. При одинаковом уровне квалификации программисты будут постоянно поправлять друг друга, перехватывать инициативу, не давать друг другу отвлекаться в сторону наращивания функциональности. При разном уровне подготовки программистов менее опытный программист намного быстрее освоится при наблюдении за работой более опытного. Простота проектирования. Создаваемая программа реализует только текущие требования заказчика, в нее не закладываются возможности на будущее. При этом требуемая заказчиком функциональность должна быть очень просто реализована с помощью имеющегося набора средств, повторного использования готового кода (рефакторинг). Функциональные требования к проекту (каждая из них называется story) записываются на обычных липких листочках. Каждая story (история) записывается пятью словами с помощью активных глаголов. Если заказчик не укладывается в этот лимит, то полагают, что он сам не знает, чего хочет от конкретной возможности системы. При этом история должна быть сформулирована так, чтобы по ее описанию было легко построить тест.  Планирование релиза (версии). Заказчик определяет, какие задачи наиболее важны или имеют высокий приоритет. С учетом этого выбора задач заказчик и разработчик вместе выбирают карточки c историями (story), которые будут составлять следующий релиз. Отобранные карточки сортируются по приоритету, выбирается наиболее приоритетная, уточняются задачи, пишутся все необходимые тесты и начинается фаза кодирования. Затем на готовом коде запускаются все написанные тесты и если они проходят успешно, то выбирается следующая по приоритету карточка и процесс повторяется. Такой подход, основанный на выборе приоритетов, гарантирует, что разработчик всегда занимается самой приоритетной задачей по проекту, что облегчает быстрое завершение итерации. Для заказчика такое планирование также удобно: он практически безболезненно для хода проекта может изменять требования к системе (что-то улучшить, что-то поменять и что-то вообще выбросить из системы). Итерацией в ХР называется фаза разработки, в результате которой создается рабочая версия проекта (релиза). Небольшие релизы. Разработчики выпускают работоспособную версию очень рано и расширяют ее возможности очень часто. Чем короче итерации, тем чаще заказчик может оценить текущее состояние продукта, опробовать его в рабочих условиях, протестировать готовую функциональность. Если команда разработчиков делает продукт долго и без связи с заказчиком, то такая ситуация считается большим риском – наверняка делается то, что не надо, или не так, как надо. Рекомендуется выпуск релизов не реже раза в 1-2 недели. Непрерывная интеграция. Сборка продукта выполняется много раз в день. Такой подход снимает множество проблем, связанных со стыковкой модулей, разработанных разными программистами, а также позволяет избежать ситуации, когда новая функциональность оказывается несовместимой с остальным проектом. Для сведения к минимуму риска нежелательных последствий интеграции рекомендуется выполнять ее на отдельном компьютере парой программистов. Непротиворечивая совокупность принципов ХР способна ввести в процесс разработки интеллектуальный резонанс, заметно повысив качество продукта и приблизив время его выпуска. Основное достоинство ХР – прогнозируемость и сведение к минимуму затрат на разработку; предоставление заказчику продукта, который он желает получить на момент выпуска; общение и обучение разработчиков в процессе разработки проекта. В ХР четко описаны роли, которые могут быть совмещены в одном человеке. Со стороны заказчика рекомендуют три роли: составитель историй, приемщик и большой босс. Составитель историй должен быть специалистом предметной области, способный доступно изложить и описать требования к разрабатываемой системе. Этот человек или группа людей ответственны за написание историй (story) пользователя и консультации с программистами. Приемщик контролирует правильность функционирования системы, хорошо разбирается в предметной области, в его обязанности входит также написание приемочных тестов. Большой босс следит за работой всех звеньев от разработчиков до конечных пользователей, контролирует внедрение системы и сопутствующие организационные моменты. Может быть инвестором проекта. Со стороны разработчика вводятся четыре роли: программист, инструктор, наблюдатель и дипломат. Программист занимается кодированием и проектированием на низком уровне, достаточно компетентен для решения текущих задач разработки. Инструктор – опытный разработчик, хорошо владеющий всем процессом разработки и его методиками. Несет ответственность за обучение команды, контролирует правильность выполнения методик. Наблюдатель – член команды разработчиков, пользующийся доверием всей группы, который следит за прогрессом разработки. Он сравнивает предварительные оценки трудозатрат и реально потраченные трудозатраты, выводя количественные показатели работы команды. Дипломат – коммуникабельная личность, инициирующая общение между членами команд и обеспечивающая передачу опыта внутри команды. Дипломат регулирует и упрощает общение между заказчиками и разработчиками. Можно также отметить, что ХР позволяет небольшим командам разработчиков выжить в условиях современного бизнеса со всеми его рисками и проблемами. Но перед обращением к ХР надо всегда объективно определить, будет ли сам проект экстремальным, например сроки сжаты, а требования к системе не определены, или же можно обойтись классическим подходом. |