♦ У вас есть бережливая разработка (Lean) – сверхэффективный аналог производственной системы, нацеленный на постоянную оптимизацию рабочего процесса (такая философия принята в компании «Тойота»).

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

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

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

Несколько слов о терминологии

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

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

♦ итерация (iteration) – то же, что и спринт (sprint);

♦ журнал пожеланий (master story list) – то же, что и бэклог (product back log);

♦ клиент (customer) – то же, что и владелец (product owner)[3].

Что дальше?

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

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

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

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

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

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

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