 |
Экстремальное программирование
|
|
|
|
В настоящее время популярны быстрые жизненные циклы разработки, например, жизненный цикл в методологии eXtreme Programming.
Экстремальное программирование (синонимы: eXtreme Programming, XP, ХР-процесс) - облегченный (гибкий) процесс (или методология) разработки программных систем, основанный на постепенном улучшении системы и разработки ее небольшими итерациями.
ХР-процесс ориентирован на группы малого и среднего размера, строящие ПО в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении.
XP-процесс предполагает командную работу с тесными связями внутри команды и с заказчиком, разработку наиболее простых работающих решений, гибкое адаптивное планирование. ХР-группа имеет дело с изменениями требований на всем протяжении итерационного цикла разработки.
Четырьмя базовыми действиями в ХР-цикле являются: планирование, проектирование, кодирование и тестирование. ХР-процесс должен быть высоко динамичным, причем динамизм обеспечивается с помощью пяти характеристик: непрерывная связь с заказчиком (и в пределах группы), простота (всегда выбирается минимальное решение), быстрая обратная связь (с помощью модульного и функционального тестирования), смелость в проведении профилактики возможных проблем, уважение членов команды друг к другу и к своей работе.
Большинство принципов, поддерживаемых в ХР (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования, экономичность и т.д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто в ХР эти принципы, как показано в табл. 1, достигают «экстремальных значений».
|
|
|
Таблица 1. Экстремумы в экстремальном программировании
| Практика здравого смысла | ХР-экстремум | Каким образом реализовано в XP |
| Проверки кода | Код проверяется все время | Парное программирование |
| Тестирование | Тестирование выполняется все время, даже с помощью заказчиков | Тестирование модулей, тесты приемки |
| Проектирование | Проектирование является частью ежедневной деятельности каждого разработчика | Рефакторинг |
| Простота | Для системы выбирается простейшее проектное решение, поддерживающее ее текущую функциональность | Самая простая вещь, которая могла бы работать |
| Архитектура | Каждый постоянно работает над уточнением архитектуры | Метафора |
| Тестирование интеграции | Интегрируется и тестируется несколько раз в день | Непрерывная интеграция |
| Короткие итерации | Итерации являются предельно короткими, продолжаются секунды, минуты, часы, а не недели, месяцы или годы | Игра планирования |
Наиболее характерными из ХР-методик являются:
1) Игра планирования (Planning game) – быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс) в разработке.
2) Частая смена версий (Small releases) – быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.
3) Инкрементное проектирование (Incremental design) – не следует заниматься подробным проектированием всей системы в самом начале работ. Вместо этого разработчики стараются как можно скорее создавать программный код, чтобы получать отзывы заказчика и улучшать систему по ходу дела. Конечно, чтобы написать хороший код, система должна быть хорошо спроектирована. Однако проектирование (наращивание) функциональности системы должно производиться маленькими порциями, чередуясь с кодированием.
|
|
|
4) Простое проектирование (Simple design) – проектирование выполняется настолько просто, насколько это возможно в данный момент.
5) Тестируй, а затем кодируй (Test-first-coding) – вначале разработчики создают тесты для модулей, а затем пишут программный код модулей, одновременно заказчики составляют тесты приемки для проверки правильности функций модулей со своей точки зрения.
6) Рефакторинг (Refactoring) – система реструктурируется, но ее поведение не изменяется; цель – устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.
7) Парное программирование (Pair programming) – весь код пишется двумя программистами, работающими на одном компьютере.
8) Коллективное владение кодом (Collective ownership) – любой разработчик может улучшать программный код системы в любое время.
9) Непрерывная интеграция (Continuous integration) – система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.
10) Локальный заказчик (On-site customer) – в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.
Игра планирования и частая смена версий зависят от заказчика, обеспечивающего набор «историй» (коротких описаний), характеризующих работу, которая будет выполняться для каждой версии системы. Версии генерируются каждые две недели, поэтому разработчики и заказчик должны прийти к соглашению о том, какие истории будут осуществлены в пределах двух недель. Полную функциональность, требуемую заказчику, характеризует пул историй; но для следующей двухнедельной итерации из пула выбирается подмножество историй, наиболее важных для заказчика. В любое время в пул могут быть добавлены новые истории, таким образом, требования могут быстро изменяться. Однако процессы двухнедельной генерации основаны на наиболее важных функциях, входящих в текущий пул, следовательно, изменчивость управляется. Локальный заказчик обеспечивает поддержку этого стиля итерационной разработки.
|
|
|
Глобальное «видение» полномасштабного продукта обеспечивает «метафора» – экстремально упрощенный вариант архитектуры. XP подчеркивает желательность проектирования при минимизации проектной документации. Точнее говоря, ХР предлагает непрерывное перепроектирование (с помощью рефакторинга), при котором нет нужды в детализированной документации по проектированию, а для инженеров сопровождения единственным надежным источником информации является программный код. Использование рефакторинга приводит к реализации простейшего решения, удовлетворяющего текущую потребность.
Парное программирование – одна из наиболее спорных методик в ХР, оно влияет на ресурсы, что важно для менеджеров, решающих, будет ли проект использовать ХР. Парное программирование приводит к повышению качества и уменьшению времени цикла. Для согласованной группы затраты увеличиваются на 15%, а время цикла сокращается на 40-50%. Для интернет-среды увеличение скорости продаж покрывает повышения затрат. Сотрудничество улучшает процесс решения проблем, улучшение качества существенно снижает затраты сопровождения, которые превышают стоимость дополнительных ресурсов по всему циклу разработки.
Коллективное владение означает, что любой разработчик может изменять любой фрагмент кода системы в любое время. Непрерывная интеграция, непрерывное регрессионное тестирование и парное программирование ХР обеспечивают защиту от возникающих при этом проблем.
«Тестируй, а затем кодируй» – эта фраза выражает акцент ХР на тестировании. Она отражает принцип, по которому сначала планируется тестирование, а тесты создаются для еще несуществующего программного кода, т.е. разрабатываются параллельно анализу требований.
Основным средством управления ХР является количественный показатель, например «скорость проекта» – количество историй заданного размера, которые могут быть реализованы в итерации.
При принятии ХР рекомендуется осваивать его методики по одной, каждый раз выбирая методику, ориентированную на самую трудную проблему группы. Конечно, все эти методики являются «не более чем правилами» – группа может в любой момент поменять их (если ее сотрудники достигли принципиального соглашения по поводу внесенных изменений). Однако, ХР–процесс обеспечивает преимущества только при использовании законченного набора базовых методов.
|
|
|
Основным структурным элементом «идеального» ХР-процесса является ХР-реализация, в которую многократно вкладывается базовый элемент – ХР-итерация. В состав ХР-реализации и ХР-итерации входят три фазы – подготовка, планирование, конструирование. Подготовка – это поиск новых требований (историй, задач), которые должна выполнять система. Планирование – выбор для реализации конкретного подмножества из всех возможных требований. Конструирование – проведение разработки, воплощение плана в жизнь.
Рекомендуется: первая реализация должна иметь длительность 2-6 месяцев, продолжительность остальных реализаций – около двух месяцев, каждая итерация длится приблизительно две недели, а численность группы разработчиков не превышает 10 человек.
XP хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP – сопровождаемость. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации.
Список использованной литературы
1. Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения. СПб.: Питер, 2012. 608 с.
2. Верификация программного обеспечения. URL: intuit.ru/studies/courses/1040/209/info (дата обращения: 30.01.2017).
3. Куликов С.C. Тестирование программного обеспечения. Базовый курс. Минск: Четыре четверти, 2017. 312 с.
4. Леоненков А.В. Самоучитель UML – 2-е изд., перераб. и доп. СПб.: БХВ-Петербург, 2006. 432 с.
|
|
|
