Заказчик всегда доступен

Одно из требований экстремального программирования — заказчик всегда доступен.

Заказчик не просто отвечает на вопросы команды разработки, а является частью команды. Он принимает решения, которые непосредственно влияют на достижение целей бизнеса.

Во всех проектах среднего и большого размера коммуникации с заказчиками происходят постоянно.

Участие в процессах

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

User Stories пишутся заказчиками (с помощью разработчиков), что позволяет сформировать оценки трудозатрат и приоритизировать функционал. Заказчики помогают убедиться, что как можно большая часть требуемого функционала описана в пользовательских историях.

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

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

Так как User Stories не включают подробности реализации, разработчики должны общаться с заказчиками, чтобы собрать дополнительные требования, необходимые для реализации декомпозированных задач.

Заказчики также помогают в формировании приёмочных тестов, в частности подготавливают данные для тестирования. Может случиться так, что перед релизом ПО проходят не все зафиксированные тесты. В таком случае заказчик может принять решение о выпуске или доработке релиза.

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