Предназначение xp
Рассмотрим ключевые направления, на которые нацелена XP:
Работа с заказчиком. Выяснение того, что в действительности нужно заказчику. Как правило, это не то, что он себе представляет. Своевременное выяснение подробностей и планированиесбережет много сил, средств, времени и нервов.
Гибкая разработка. Пресловутый простой дизайн, частые выпуски версий, регулярное планирование – все это служит тому, чтобы максимально быстро и безболезненно реагировать на меняющиеся требования заказчика и оперативно реализовывать функциональность, наиболее критичную прямо сейчас.
Непрерывная работоспособность кода. Постоянные интеграции кода и большое количество тестов – это все дает уверенность, что код работоспособен и работает он правильно.
Упрощение поддержки кода. Рефакторинги и cтандарты кодирования облегчают дальнейшие изменения в коде и облегчают понимание кода всеми разработчиками.
Повышение скорости и качества разработки. Парное программирование, коллективное владение кодом, заказчик в команде, 40-часовая рабочая неделя и метафора системы – эти практики делают разработку более быстрой и качественной.
Таким образом, можно сформулировать предназначение XP.
XP как методология предназначена для уменьшения затрат на разработку и поддержку ПО. При этом она обеспечивает гибкость процесса разработки, качество продукта и его соответствие реальным потребностям заказчика.
Тем не менее, XP имеет свою схему процесса разработки (хотя широко используемое понимание «процесса разработки» противоречит «живости» разработки).
1
6
Представители заказчиков
Представители заказчиков являются важнейшим звеном успешной разработки по технологии XP. Представители должны не просто контактировать, но буквально физически присутствовать в непосредственной близости и работать в команде разработчиков. Любая проблема должна быть обнаружена на самом раннем этапе, любые пожелания или вопросы должны решаться в реальном времени. Представители заказчика являются источником историй пользователей и тестовых наборов данных, они принимают участие в планировании плана релизов. Кроме того, открытый процесс позволяет инспектировать спорные участки кода в любой момент времени, создавая полностью прозрачную атмосферу между разработчиками и заказчиками.
Пользовательские истории выступают в качестве инструмента планирования заказчика, с помощью которого он может отслеживать соблюдение технических требований на всех этапах разработки проекта.
Хотя это не очевидно, но практически происходит экономия времени заказчика, который все время находится в курсе дел — дополнительно время экономится на детальных спецификациях в начале работы, поскольку любой аспект можно выяснить в процессе работы. Впоследствии не придется инструктировать персонал заказчика, поскольку заказчик уже располагает высококачественными специалистами по данному продукту.
При этом многие документы-посредники становятся ненужными, поскольку многое решается устно, без вовлечения технических и бюрократических механизмов. Значение имеют только конечные результаты работы — но не промежуточные решения и дискуссии, так что нет необходимости документировать все возможные ходы мысли и альтернативы.
Помимо тесного взаимодействия с заказчиками, особого внимания требует и структура группы разработчиков.