22. Экстремальное программирование

Одним из наиболее известных примеров практической реализа­ции подхода быстрой разработки ПО является экстремальное про­граммирование (Extreme Programming — ХР). Этот метод предназна­чен для небольших компактных команд, нацеленных на получение более высокого качества и продуктивности, и достигает этого по­средством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дис­циплине и пониманию, сводя к минимуму все промежуточные ра­бочие продукты. Экстремальное программирование — методология быстрой разработки ПО — состоит из набора методик и принципов, позволяющих как по отдельности, так и в комплексе оптимизировать процесс разработки. Этот подход так же регламентирует права разработчиков и заказчиков.

В экспериментальном программировании четко описаны все роли. Две ключевые роли – заказчик и разработчик

Заказчик- это человек или группа людей заинтересованных в разработке конкретного ПП. Имеют следующие права и обязанности.

-Фиксировать сроки выпуска версий продукта

-Принимать решения относительно запланированных составляющих программы.

-Знать ориентировочную стоимость каждой функциональной составляющей

-Принимать важные бизнес решения

-Знать текущее состояние системы

-Изменять требования к системе, когда это действительно важно

-Для успешного использования своих прав заказчик должен полагаться на данные предоставляемые разработчиками.

Разработчик – человек или группа людей от 2-х до 10 человек, занимающихся непосредственно программированием и сопутствующими инженерными вопросами. Права и обязанности:

-Получить достаточно знаний о задачах, которые должны быть запрограммированы.

-Иметь возможность выяснения деталей в процессе разработки.

-Предоставлять ориентировочные, но откровенные оценки трудозатрат на каждую функциональную часть или история пользователя.

-Предоставлять оценку рисков, связанных с использование конкретных технологий.

На стороне заказчика определены следующие вспомогательные роли:

Составитель истории – это человек или группа людей ответственных за написание истории пользователя и прояснения недопонимания со стороны программистов.

Приемщик - человек, контролирующий правильность функционирования системы, хорошо владеющий предметной об­ластью.

Большой босс - следит за работой всех звеньев. Он мо­жет быть также инвестором проекта.

Вспомогательные роли на стороне разработчика:

Программист - человек, занимающийся кодированием и проектированием на низком уровне.

Инструктор - опытный разработчик, хорошо владеющий всем процессом разработки и его методиками; несет ответствен­ность за обучение команды аспектам процесса разработки.

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

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

Одно из требований экстремального программирования — заказ­чик всегда доступен. Он должен не просто помогать команде разра­ботчиков, а быть ее членом. Все фазы проекта требуют коммуника­ции с заказчиком, лучше всего лицом к лицу — на месте.

Для описания функциональных требований к разрабатываемой системе заказчик с помощью разработчиков пишет истории пользова­теля, рассказы пользователя (User Stories). История пользователя — это описание того, как система должна работать.

Заказчик помогает удостовериться, что большинство желаемых функций системы покрыто историями пользователей.

Типичная история пользователя занимает одну-три недели иде­ального времени. Идеальное время — это количество времени, кото­рое, по мнению разработчика, займет выполнение задачи, если ничто больше не будет его отвлекать.

План выпуска версий программы разрабатывают на собрании по планированию. Релиз-планы дают описание всего проекта и исполь­зуются в дальнейшем для планирования итераций. Планирование очередной версии про­граммы представляет набор правил, позволяющих всем участникам принимать свои решения. Эти правила определяют метод выработ­ки плана работ, удовлетворяющего всех.

Сущность собрания по планированию версии для команды раз­работчиков заключается в том, чтобы оценить каждую историю в идеальных неделях. Заказчик решает, какие задачи наиболее важны или имеют наибольший приоритет.

Скорость проекта (скорость) — это мера того, как быстро вы­полняется работа в проекте. Для измерения скорости проекта не­обходимо посчитать объем историй или сколько (по времени) за­дач было выполнено за определенный период времени. Затем под­считывают суммарное время оценки объема работы (идеальное время).

В процессе работы возможны небольшие изменения скорости проекта. Однако при значительном изменении скорости необходи­мо провести перепланирование версии.

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

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

Итеративная разработка (рис. 1.30) увеличивает гибкость про­цесса. План выпуска версии программы нужно разделить на итера­ции продолжительностью от двух до трех недель, при этом сохра­нять постоянную продолжительность итерации на время проекта. Итерации в таком случае будут пульсом проекта. Это тот ритм, ко­торый позволит сделать измерение прогресса и планирование про­стым и надежным.

Разработчики разбирают задачи и оценивают продолжительность времени, необходимого для их выполнения. Таким образом, каждый разработчик оценивает, сколько времени решение задачи займет имен­но у него.

Перед началом работы выбирают метафору системы (System Metaphor) — простую и понятную концепцию, чтобы члены коман­ды называли все вещи одинаковыми именами. Для понимания сис­темы и исключения дублирующего кода чрезвычайно важно то, как разработчик называет объекты. Следует создать систему имен для своих объектов так, чтобы каждый член команды мог пользоваться ею без специальных знаний о системе.

Тесты отдельных модулей (Unit tests) играют ключевую роль в экстремальном программировании, так как позволяют быстро ме­нять код. Тест модуля пишут для каждого класса, он должен прове­рять все аспекты работы класса — тестировать все, что может не работать. Тест для класса должен быть написан раньше самого класса;

Не следует экономить на тестах модулей, когда для завершения разработки остается мало времени. Практикой доказано, что чем сложнее написать тест, тем больше времени подработчик потом сэ­кономит.

Тесты модулей позволяют осуществить коллективное владение кодом, относительно легко пересматривать плохой код, а также в любой момент иметь стабильно работающую систему.

Схема этапа разработки показана на рис. 1.31. Первоначальным звеном является проведение короткого собрания, на котором об­суждают проблемы и их решения.

Ежедневное короткое собрание позволит избежать многих дру­гих собраний и сэкономит больше времени на осуществление про­екта.

Для работы над проектом создается команда разработчиков. Со­став команды может меняться, поэтому никто не пишет код в оди­ночку (код принадлежит всем) (рис. 1.32). Бывают случаи, когда для агрессивного и экстремального продвижения вперед необходимо понять и скорректировать чужой код. При этом разработчики долж­ны удалить или изменить дублирующий код, проанализировать и улучшить чужие классы и т. п.

Коллективное владение кодом стимулирует разработчиков пода­вать идеи для всех частей проекта, а не только для своих модулей.

Для разработки структуры системы командой используют так назы­ваемые CRC-карточки (CRC — Class, Responsibilities, Collaboration — класс, обязанности, взаимодействие), представляющие собой экзем­пляр объекта. В ходе CRC-сессии участники используют обычно небольшое число карточек. Идеальный вариант — в процессе проектирования принимает учас­тие вся команда.

Простую структуру всегда легче реализовать, чем сложную, по­этому необходимо стремиться к выбору самого простого решения, которое может работать.

Решения необходимо сохранять насколько возможно простыми и как можно дольше. Не стоит добавлять функциональность на буду­щее, до того как в этом появляется необходимость. Однако следует иметь в виду, что сохранять структуру разрабатываемой системы простой — довольно тяжелая работа.

Безжалостно переделывать.Убирая избыточность, улучшая устаревшую структуру проекта, убирая неиспользуемые куски, программист совершает переделку проекта, которая в конеч­ном итоге экономит время и улучшает качество продукта.

Оставляйте оптимизацию на потом.

Весь код для выпускаемой системы, возможно, за исключени­ем пробных решений, пишется парами. Два разработчика сидят рядом: один набирает, другой смотрит; время от времени они меня­ются местами. Не разрешается работать в одиночку.

Необходимо периодически менять задачи у разработчиков для уменьшения риска концентрации знаний и узких мест в коде. Если только лишь один человек в команде может работать в данной обла­сти и этот человек уходит или просто много работы скопилось в данном сегменте программы, может обнаружиться, что проект еле-еле продвигается вперед.

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

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

Каждая пара разработчиков должна отдавать свой код, как толь­ко для этого появляется разумная возможность. Она предоставляет­ся, когда все тесты отдельных модулей проходят полностью на 100%. Отдавая изменения несколько раз в день, можно свести проблемы интеграции практически к нулю.