Представители заказчиков

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

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

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

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

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

32 Структура группы разработчиков

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

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

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

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

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

Команда разработчиков:

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

    оценивает затраты, связанные с выбором той или иной технологии, на основе которой будет выполняться реализация;

  распределяет задачи между членами команды;

       оценивает риск, связанный с реализацией каждого из пожеланий;

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

Заказчик:

   определяет объем работ (Scope), то есть набор пожеланий для выпуска(release) и набор пожеланий для итерации (iteration);

      определяет дату завершения работы над выпуском (release);

      назначает приоритеты (priorities), то есть, исходя из полезности различных функций с точки зрения бизнеса, определяет, какие из функций продукта должны быть реализованы в первую очередь.

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

Для того чтобы команда ХР могла работать, необходимо, чтобы кто-то взял на себя исполнение некоторых определенных ролей: программиста, заказчика, инструктора, тестера,ревизора.

Тестер ХР – это не отдельный человек, специально нацеленный на разрушение системы и унижение программистов. Однако должен быть кто-то, кто будет регулярно запускать тесты (если вы не можете запустить тесты модулей и функциональные тесты одновременно), оповещать команду о результатах тестирования и проверять правильность работы тестирующих инструментов

Программист (programmer) – роль в команде ХР. Программист анализирует, проектирует, тестирует, программирует и интегрирует.

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

Заказчик (customer) – роль в команде ХР. Заказчик выбирает, какие истории должны быть реализованы в системе, какие из историй необходимо реализовать в первую очередь, а какие могут быть отложены. Заказчик также определяет тесты, благодаря которым можно убедиться в том, что истории корректно выполняются.

Ревизор (tracker) – роль в команде ХР. Ревизор измеряет текущее состояние процесса в численном выражении.