В первой части обзора мы познакомились с методологией RUP, которая отличается достаточно строгой формализацией и большим весом. На противоположном полюсе находится методология XP. Она не терпит формализма и решительно отвергает все лишние артефакты. Познакомимся с ней поближе.

XP

Методология eXtreeme Programming разработана Кентом Беком. Ее основы зародились в сообществе программистов на Smalltalk, а окончательно процесс оформился при работе над проектом C3 компании "Крайслер".

XP держится на четырех определяющих понятиях: коммуникации (communication), простоте (simplicity), обратной связи (feedback) и кураже или смелости (courage). Эти понятия определяют XP.

Итеративность

Как и RUP, XP является итеративным процессом, причем сами итерации рекомендуется делать как можно меньшими, 2-3 недели, но, во всяком случае, не более 1 месяца. В этом отличие от RUP, где длительность итерации может быть значительной. За одну итерацию реализуется несколько свойств системы, каждое из которых описывается в пользовательской истории.

Пользовательские сценарии

Как RUP основано на прецедентах (use cases), так XP основано на историях пользователей (user stories). На первый взгляд, вещи одинаковые, но отличия есть. Во-первых, истории пользователей достаточно краткие (1-2 абзаца). Прецеденты же обычно пишут достаточно подробными, с основным и альтернативными потоками, так что получается примерно страница. Во-вторых, истории пользователей пишутся самими пользователями (которые в XP являются частью команды). В RUP прецеденты обычно пишутся системным аналитиком.

Истории пользователей служат для планирования длительности итерации. Фактически, они являются требованиями к системе. Если в RUP требования собирались в отдельный документ System Requiriment Specification, то в XP ничего подобного нет, а есть просто куча отдельных историй.

Практики

Обычно XP характеризуют набором из 12 практик. Практики - это действия, которые надо выполнять для достижения хорошего результата. Надо отметить, что выполнение всех практик не гарантирует результат. Как сказали Ken Auer, Erik Meade и Gareth Reeves в одной их статей, "практики XP не определяют саму XP, XP определяет эти практики".

Сами практики достаточно простые и часто применялись ранее, но в XP они сведены вместе.

1. Планирование процесса
2. Частые релизы
3. Метафора системы
4. Простая архитектура
5. Тестирование
6. Рефакторинг
7. Парное программирование
8. Коллективное владение кодом
9. Частая интеграция
10. 40-часовая рабочая неделя
11. Стандарты кодирования
12. Тесное взаимодействие с заказчиком

Давайте рассмотрим их более подробно, чтобы понять, почему же XP работает.

Планирование процесса

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

Частые релизы

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

Метафора системы

Вообще если удается найти хорошую метафору системы, то называть классы, методы и переменные становится гораздо проще. В реальной жизни поиск метафоры - крайне сложное занятие, и найти хорошую метафору непросто. В любом случае команда должна иметь единые правила именования. Это сэкономит время и улучшит взаимопонимание.

Простая архитектура

Любое свойство системы должно быть реализовано как можно проще. Программисты в XP команде работают под девизом: "Ничего лишнего!". Например, реализовывается какая-то пользовательская история, и программист видит, что через две-три итерации понадобятся некоторые свойства, но сейчас они не нужны. Он сейчас может легко их запрограммировать, но, по правилу XP, этого делать не нужно. На первый взгляд, звучит странно, но на самом деле очень часто оказывается, что эти свойства и вовсе не нужно реализовывать. Тем самым экономится время программиста.

Тестирование

В отличие от большинства остальных методологий, тестирование в XP - одна из важнейших вещей. Экстремальный подход заключается в том, что тесты пишутся до написания кода. В результате код получается гораздо более качественным и экономится время на исправление ошибок. Большинство ошибок исправляются на стадии кодирования, а стоимость исправления ошибки на стадии кодирования и на стадии выпуска системы значительно отличается.

Рефакторинг

Рефакторинг - это оптимизация существующего кода. Если программисту необходимо реализовать новое свойство системы, то он должен подумать, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с дизайном, то есть если создается новый код, рефакторинг надо отложить. А уж после создания заняться им.

Парное программирование

Одна из самых известных XP-практик. Все программисты должны работать в парах. Один пишет код, другой сидит рядом и смотрит. Парное программирование имеет много преимуществ: получается более качественный код и более продуманный дизайн, знания в команде передаются быстрее. На первый взгляд кажется, что общая скорость разработки снизится при парном программировании, но на самом деле это не так. Время выигрывается за счет быстрого решения возникающих проблем, скорости нахождения ошибок и более качественного кода. Стадия исправления ошибок после общего тестирования значительно сокращается. Плюс ко всему, какому управляющему проектом не захочется, чтобы команда быстрее обучалась, что напрямую ведет к увеличению скорости?

Коллективное владение кодом

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

Частая интеграция

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

40-часовая рабочая неделя

Программист не должен работать больше 8 часов в день. Усталый программист делает больше ошибок, и эффективность его работы оставляет желать лучшего.

Стандарты кодирования

Стандарты кодирования нужны для обеспечения других практик: коллективное владение кодом, парное программирование и рефакторинг. Без единого стандарта выполнять эти практики гораздо сложнее. Не нужно разрабатывать детальные стандарты, которые описывают все, что только возможно. Надо стандартизировать только важные вещи.

Тесное взаимодействие с заказчиком

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

В последнее время наметилась тенденция расширения набора практик, так как в XP недостаточно описывается процесс управления проектом.

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

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

XP и CMM

CMM (Capability Maturity Model) - Модель зрелости процесса разработки ПО. Состоит из 5 уровней. Чем выше уровень, тем более качественное ПО выпускает компания. Большинство компаний в Беларуси находятся на первом уровне. Это значит, что успех проекта определяется личным героизмом и компетентностью отдельных членов команды.

Если рассматривать XP в контексте CMM, то можно обнаружить, что практики XP во многом обеспечивают достижение второго и третьего уровней. Организация с таким уровнем CMM с большой вероятностью способна обеспечить успешное завершение проекта (то есть в срок, в рамках бюджета). Очевидно, это значительно повышает конкурентоспособность компании, позволяет выходить на западные рынки и во многом определяет жизнеспособность. Если компания несколько лет находится на уровне CMM1, то лучшим решением будет смена руководителя.

Михаил ДУБАКОВ,
wa.artel.by