четверг, 13 мая 2010 г.

В чем сила 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 с ротацией пар позволяет знаниям о коде распространяться по команде без дополнительных затрат на документирование.


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

Спасибо!

Комментариев нет:

Отправить комментарий