Практики экстремального программирования

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

Основные практики:

1. Рассказы. Функциональность приложения описывается короткими рассказами, которых работа с системой изложена с точки зрения заказчика. Эти рассказы являются основной движущей силой разработки приложений.

2. Еженедельный цикл. Вся разработка проекта происходит в виде череды еженедельных циклов. В начале недели определяются “рассказы”, которые надо сделать за эту неделю.

3. Ежеквартальный цикл. Планирование в большом масштабе происходит каждый квартал. Оно состоит из обсуждений работы команды и темпов разработки.

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

5. Работа в одном помещении. Команда разработчиков должна сидеть в одном большом помещении – это облегчает общение.

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

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

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

9. Парное программирование. Код всегда пишут два программиста, сидящих за одним компьютером.

10. Инкрементное проектирование. Проектирование должно происходить инкрементально во время написания программного кода. Команда программистов старается как можно быстрее начать писать программный код, чтобы получить отзывы пользователей о системе и улучшать ее по ходу дела.

11. Сначала тесты. Перед тем как редактировать старый код или писать новый, нужно написать тесты, которые будут его проверять. Это поможет решить четыре проблемы:

• Программирование по-ковбойски. Если сначала написать тесты, которые затем будут затем проверять код, придется сосредоточиться на задаче, которую пытаемся решить, а так же проверить насколько правильно мы спроектировали данную часть системы.

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

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

• Ритм. Стоит приучить себя к ритму: тест, код, рефакторинг.

12. Десятиминутная сборка. Систему должно быть можно собрать с учетом прогона всех тестов за 10 минут.

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