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

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

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

И не забывайте…

Путей всегда много!

Как и мороженое, гибкая разработка может иметь разные оттенки вкуса.

♦ У вас есть скрам (Scrum) – этот метод управления охватывает гибкий проект как оболочка.

♦ У вас есть экстремальное программирование (Extreme Programming, XP) – требующие высокой дисциплины основные практики разработки программ, жизненно важные для любого гибкого проекта.

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

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

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

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

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

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

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

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

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

♦ клиент (customer) – то же, что и владелец (product owner) [3] «Владелец» – термин условный. Обычно так называют заказчика или его представителя, который определяет требования к продукту. В agile-команде эту роль может исполнять менеджер проекта, бизнес-аналитик или клиент. – Примеч. ред. .

Что дальше?

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

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

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

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

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

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

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

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

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

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

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

Качество выполнения гибкого проекта от начала до конца – задача всей команды. Отдела обеспечения качества (Quality Assurance, QA) нет, качество обеспечиваете вы сами, когда проводите анализ, пишете код или управляете проектом. Качество гарантируется на каждом шагу, поэтому в гибком проекте вы не услышите вопроса: «И как отдел гарантии качества проморгал эту ошибку?»