Итак, в предыдущем посте на эту тему мы разобрали какие ценности приносят в 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 с ротацией пар позволяет знаниям о коде распространяться по команде без дополнительных затрат на документирование.
Эта статья (обе ее части) - это, по сути, обобщенное упражнение по анализу процесса. Здесь я постарался показать, как могут быть связаны элементы вашего процесса и о чем стоит помнить, добавляя или удаляя элементы из него.
Спасибо!
Комментариев нет:
Отправить комментарий