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

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

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


Гибкий аналитик



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

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

Аналитик выполняет в гибком проекте множество задач: помогает клиенту писать пользовательские истории (см. главу 6); выполняет глубокий анализ, когда дело доходит до разработки; помогает создавать имитационные объекты (mock-ups) и прототипы; использует в ходе анализа все доступные ему инструменты, чтобы донести до разработчика сущность пользовательских историй.

Подробнее о функционировании гибкого анализа мы поговорим в разделе 9.4.


Гибкий программист



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

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

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

♦ Они пишут много тестов и часто пользуются ими при разработке (см. главы 12 и 14).

♦ Они постоянно дорабатывают и оптимизируют архитектуру программы по мере работы (см. главу 13).

♦ Они уверены, что базовый код всегда готов к использованию и может быть развернут по первому требованию (см. главу 15).

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


Гибкий тестировщик



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

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

Что, если начинать каждый проект вот так?

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

• В чем я особенно хорош?