39.Двенадцать правил экстремального программирования.

• разумное планирование (краткосрочное планирование, в ходе которого определяется, что будет включено в следующую версию)

• небольшие версии (выгоднее часто устанавливать новые версии с небольшими изменениями.)

• метафора (простая история, аналог, которая в доступной форме описывает работу системы.)

• простой дизайн (максимальную простоту реализации версии.)

• тестирование (используется на протяжении всей разработки тесты заказчиков, программистов)

• переработка (система на протяжении жизненного цикла постоянно перерабатывается с целью улучшения и упрощения кода)

• программирование парами ( разработка ведется парами программистов, сидящих за одним компьютером)

• коллективное владение (каждый участник проекта является владельцем не только им написанного кода, но всего кода системы.)

• постоянно продолжающаяся интеграция (система приводится в рабочее состояние несколько раз в день в процессе разработки)

• 40-часовая рабочая неделя (спорно, что программист не должен работать сверхурочно)

• заказчик на месте разработки

• стандарты кодирования

40. Риски легких методологий (на примере экстремального программирования).

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

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

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

Очевидно, что она хорошо подойдет для варианта разработки небольшого проекта в мало известной или быстро меняющейся области. Крупные системы для устоявшегося производственного процесса лучше проектировать традиционными методами. Для ХР, видимо, будут мало пригодны формальные коллективы разработчиков, характерные для больших организаций. Скорее всего, особенно на начальных стадиях внедрения методологии, не все правила удастся реализовать, возможно, часть из них так и не будет реализована. Несмотря на то, что авторы методики утверждают, что эффект получается лишь при использовании всех правил, не всегда это возможно. В настоящее время известны коллективы, успешно использующие идеи ХР, применяя правила частично. В целом эта методология, хоть и не идеальная, но все же интересная альтернатива «тяжелым» подходам.