Искусство Agile-разработки. Теория и практика гибкой разработки ПО

Если это выглядит слишком трудозатратным…

Этот осторожный процесс привлечения сторонников предназначен для случаев, когда поддержка под вопросом: если вы работаете со множеством команд, запрашиваете большие инвестиции или работаете в бюрократической организации, для которой идеи Agile не комфортны (даже если люди активно используют это название).

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

Если руководство считает, что они уже Agile…

Некоторые организации (а в наши дни таких много) думают, что они уже Agile. Одна организация говорила мне: «Мы пост-Agile!» Или вы можете услышать: «Мы agile с маленькой буквы “а”, а не Agile с большой буквы “A”!» Но сравнив философию, описанную в главе 1, с тем, как действует организация, вы поймете, что это далеко не так.

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

Если руководство не поддерживает…

Если поначалу вы не можете найти понимание и поддержку у руководства, то не отчаивайтесь. Попробуйте поставить себя на их место. Как Agile может помочь им получить то, что им нужно? Если ответ «не может», то, вероятно, он им и не нужен. Выберите другой подход к разработке программного обеспечения, такой, который лучше впишется в культуру вашей организации. Один из вариантов можно найти во врезке «Как добиться успеха, используя водопадную модель» в главе 4.

Если у вас есть руководитель, которому вы доверяете, то обратитесь к нему за помощью и советом. Если его нет, то попробуйте провести информационное интервью: поговорите с руководителем из другой компании, проходившей через это недавно. (Они могут попытаться нанять вас на работу. Взаимовыгодный вариант, win/win!) Во врезке «Смените организацию» далее в этой главе рассматривается ряд идей на этот случай.

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

Некоторые используют метод Kanban, чтобы мотивировать организационные изменения[18]. Kanban представляет существующие методы работы таким образом, чтобы подчеркнуть узкие места в исполняемой работе и показать стоимость задержек. Его достаточно легко внедрить, и он может мотивировать переход организации к Agile.

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

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

Изменить организацию

Вы можете изменить свою организацию или сменить ее.

Мартин Фаулер