В чем сила XP-2

Итак, в предыдущем посте на эту тему мы разобрали какие ценности приносят в XP-процессы те или иные практики заявленные как must have для настоящего XP. В принципе, цель этого анализа - именно разбор этих самых практик, который, надеюсь, поможет сделать ваш особый уникальный процесс и назвать его как-нибудь красиво :)

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

• Onsite Customer
• Pair Programing
• Collective Code Ownership
• Planing Games
• Coding Standards & Conventions

Перечисленные элементы образуют коммуникационную среду проекта, реализуя принцип Agile "меньше документации - больше кода". Сказать, что это некая ценность я не берусь, так как Agile сам по себе не является таковой с точки зрения проекта. В то же время мы понимаем смысл и предназначение этого набора и можем отдавать себе отчет в том, какие функции выполняют эти элементы. Нельзя, конечно, сказать что это полный набор средств коммуникации (даже напротив - для нормального процесса, на мой взгляд, этого мало :)), однако, надо понимать, что если вы начинаете из этого набора что-то выкидывать, то скорее всего вам придется заплатить за это дополнительной писаниной (переписка по e-mail, wiki, etc).

• Рафакторинг

Рефакторинг с одной стороны поддерживает TDD (который без него просто не работает), с другой стороны(как уже было сказано в первой части этого поста) позволяет привести в порядок код, написанный в концепции KISS, YAGNY и прочий "simple design". То есть, не дай бог у вас в проекте по XP вы начинаете экономить на рефакторинге - иначе готовьтесь получить отсутствие TDD и абсолютно не сопровождаемый код.

• Pair Programing

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

Эта статья (обе ее части) - это, по сути, обобщенное упражнение по анализу процесса. Здесь я постарался показать, как могут быть связаны элементы вашего процесса и о чем стоит помнить, добавляя или удаляя элементы из него.

Спасибо!

В чем сила XP

Хотя чистый XP сейчас и мало кто использует, в основном, комбинируя практики из XP с другими процессами, я все же хочу немного разобраться с тем, из чего, собственно состоит Экстремальное Программирование. Итак, вот основные практики, принципы и правила XP:

1. Onsite Customer
2. Small Iterations
3. Simple Design
4. Continuous Integration
5. Refactoring
6. TDD
7. Coding Standards & Conventions
8. Pair Programing
9. Collective Code Ownership
10. Planing Games

А теперь давайте посмотрим, какую функцию выполняет тот или иной компонент XP в процессе. Итак:

1. Onsite Customer + Small Iterations + Simple Design

Распишем, что это значит: команда имеет возможность взаимодействия с заказчиком "на-лету" для получения новых/измененных требований и предоставления результатов работы на ревью. При этом за счет коротких итераций ставятся близкие задачи, результат работы над которыми обсуждается с заказчиком и принимаются меры по корректировке курса. А за счет простых технологических решений команда может выдавать конкурентоспособный темп.

Итого:

Onsite Customer + Small Iterations + Simple Design = Maximum Agility

то есть мы получаем действительно настоящую гибкость разработки и отсутствие "лишней" работы.

2. Continuous Integration + Refactoring + TDD + Coding Standards

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

Непрерывная Интеграция позволяет быстро выявлять и исправлять ошибки кодирования. Рефакторинг приводит в порядок тот код, который появляется под флагом "Simple Design", да и для TDD он необходим как воздух. Сам TDD позволяет поддерживать принцип "SimpleDesign". Стандарты кодирования помимо положительного влияния на качество, так же необходимы для другого принципа XP, который будет упомянут ниже - Совместное Владение Кодом.

Итого:

Continuous Integration + Refactoring + TDD + Coding Standard = Quality Assurance

3. Pair Programing + Collective Code Ownership + Planing Games

Это значит, что вся команда вместе планирует задачи, по ходу уточняя и разъясняя для каждого суть задачи и особенности ее реализации (да-да-да...и убивая часа по 2-4 на Planing Session в каждой итерации). А потом вся команда дружно программирует, меняясь парами и осуществляя перекрестное Code Review. За счет этого нам становятся не страшны такие вещи как неожиданная болезнь ключевого разработчика, отпуск, перемещение на другой проект, увольнение ( :) ) и прочая фигня, которая иногда так некстати сливает все планирование в унитаз. Так же мы снижаем затраты на ввод новых разработчиков в команду.

Таким образом:

Pair Programing + Collective Code Ownership + Planing games = Reliable Process

Итак, мы определили, что заявленные компоненты XP дают нам следующие ценности:

1. Высокая Гибкость
2. Высокое Качество
3. Высокая Надежность Процесса

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