Гибкое управление IT-проектами. Руководство для настоящих самураев - страница 21

МАСТЕР:Команда сделает то, что должно быть сделано.

УЧЕНИК:О да, Мастер, но если нет специальной роли тестировщика, как можно быть уверенным, что все необходимые тесты будут проведены?

МАСТЕР:Без тестирования никак не обойтись, поэтому команда будет им заниматься. Команда решает, сколько нужно тестов и сколько сил на это потратить.

УЧЕНИК:А если никто не хочет заниматься тестированием? Что, если всем нравится просто сидеть и писать код?

МАСТЕР:Тогда нужно найти людей, которым нравится тестировать, и самому убедиться, какими ценными членами твоей команды они станут.

УЧЕНИК:Благодарю тебя, Мастер. Я подумаю над этим.

Что дальше?

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

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

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

Многие проекты умирают в зачаточном состоянии. Обычно это происходит по одной из следующих причин:

♦ неумение задавать правильные вопросы;

♦ боязнь задавать сложные вопросы.

В этой части мы поговорим о мощной методике построения перспектив, которую условно назовем стартовой колодой (inception deck). Она помогает найти ответы на 10 вопросов, без которых лучше не начинать какой-либо софтверный проект. Испытав команду на данном этапе, вы узнаете, все ли нужные люди подобраны для проекта и в правильном ли направлении вы движетесь. Это произойдет еще до написания самой первой строки кода.

В начале любого нового проекта люди обычно имеют поразительно разные представления об общей цели.

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