Искусство Agile-разработки. Теория и практика гибкой разработки ПО
Шрифт:
Если руководство не поддерживает…
Если поначалу вы не можете найти понимание и поддержку у руководства, то не отчаивайтесь. Попробуйте поставить себя на их место. Как Agile может помочь им получить то, что им нужно? Если ответ «не может», то, вероятно, он им и не нужен. Выберите другой подход к разработке программного обеспечения, такой, который лучше впишется в культуру вашей организации. Один из вариантов можно найти во врезке «Как добиться успеха, используя водопадную модель» в главе 4.
Если у вас есть руководитель, которому вы доверяете, то обратитесь к нему за помощью и советом. Если его нет, то попробуйте провести информационное интервью: поговорите с руководителем из другой компании, проходившей через это недавно. (Они могут попытаться нанять вас на работу. Взаимовыгодный вариант, win/win!) Во врезке «Смените организацию» далее в этой главе рассматривается ряд идей на этот случай.
На заре развития Agile, когда это было еще стихийным общественным движением, множество команд приняли экстремальное программирование самостоятельно,
Некоторые используют метод Kanban, чтобы мотивировать организационные изменения [18] . Kanban представляет существующие методы работы таким образом, чтобы подчеркнуть узкие места в исполняемой работе и показать стоимость задержек. Его достаточно легко внедрить, и он может мотивировать переход организации к Agile.
Kanban является кайдзен– подходом к изменениям, он медленный и работает только до определенного предела, но очень эффективен и может привести к появлению разрешения на кайкаку. Более подробную информацию вы можете найти в книге [Anderson2010].
18
Обратите внимание, что метод Kanban – это значительно более широкое понятие, чем доска Kanban, применяемая некоторыми командами для визуализации планирования.
Если ничего из того, что вы делаете, не меняет ситуацию, то задумайтесь, а что нужно вам. Представьте, что статус-кво не изменится, поскольку этого, вероятно, и не случится. И тогда или вас это устраивает, или (а часто это как раз такой случай) пришло время перейти в другую, более подходящую вам компанию.
Изменить организацию
Вы можете изменить свою организацию или сменить ее.
Мартин Фаулер
Изменить организацию изнутри непросто, но возможно. Это отнимает много сил и времени, и не всегда оказывается, что оно того стоило. Поэтому более простой способ изменить организацию – сменив работу – может оказаться более разумным выбором. Для тех, кто все же хотел бы попытаться, ниже приведены 13 советов, почерпнутых из моего собственного опыта изменения организации изнутри.
1. Задумывайтесь о своих мотивах. Отвечает ли Agile в наивысшей степени интересам организации или он нужен вам по личным причинам? Есть ли у вас время, энергия и энтузиазм, чтобы проповедовать эти изменения? Есть ли у вас стратегия поиска выхода из проблем, которые могут возникнуть вследствие ваших усилий? Если ответ на любой из этих вопросов – «нет», то смена работы может оказаться лучшим выходом.
2. Организуйте надежную сеть поддержки. Изменения в направлении снизу вверх – неблагодарная работа, часто ведущая к разочарованию. Полагайтесь на семью и друзей, уходите домой вовремя и не живите рабочими проблемами в нерабочее время.
3. Находите для себя маленькие удовольствия. Без поддержки сверху организационные изменения в значительной мере находятся вне вашего контроля. Находите небольшие ежедневные рабочие задачи, благодаря выполнению которых вы будете чувствовать удовлетворение.
4. Не сдавайтесь. Небольшие изменения накапливаются. Поначалу эффект от ваших усилий будет незаметным, но они будут постепенно менять стиль мышления людей в сфере решения проблем. В конце концов, по достижении некоего порога все внезапно начнет меняться.
5. Уважение – ваша валюта. Чем больше люди уважают вас, тем больше ваш авторитет. Завоевывайте авторитет своими действиями и уважительно относитесь к другим, даже в мыслях.
6. Оставайтесь внутри сферы своего влияния. Изменения снизу требуют постоянного повторения. Пытайтесь вносить изменения только в тех отделах организации, с которыми вы находитесь в постоянном контакте.
7. Пополняйте ряды сторонников. Найдите хотя бы одного человека, который уважает вас и ваши идеи и имеет большее влияние, чем вы. Привлеките его к распространению ваших идей.
8. Находите пробелы. Люди должны хотеть изменений, но они будут их хотеть, только если это дает им что-то, что они не могут получить другим способом, или если это убережет их от потери чего-то ценного для них. Фокусируйтесь на этих моментах.
9. Вникайте в причины. Всегда есть причины, почему что-то делается именно так, а не иначе, и вы можете сделать свое вмешательство более эффективным, если разберетесь, что это за причины.
10. Повторяйте. Продвигайте свою идею изменений снова и снова, разными способами и разным людям. Но старайтесь не быть назойливым.
11. Не критикуйте все подряд. Выберите что-то одно и работайте с этим. Если вы будете находить
12. Не ищите признания. Если вы успешны, то люди начнут повторять ваши идеи, как если бы они были их собственными. Это не плагиат. Ваши усилия на самом деле могут изменить мышление людей, при этом они даже не будут это осознавать. Пусть они так думают. Они будут более усердно трудиться ради собственных идей.
13. Будьте осторожны в своих желаниях. Если ваш проект изменений будет успешен, то готовы ли вы взять на себя ответственность за то, что будет дальше?
Если вы захотите прочесть историю изменений, вдохновившую автора на эти советы, то можете найти ее онлайн на веб-странице [Shore2006]. Подробное руководство по изменениям изнутри содержится в книге More Fearless Change: Strategies for Making Your Ideas Happen [Manns2015].
Заинтересуйте команду
Agile ставит интересы людей на первое место, поэтому для вас не должно стать сюрпризом, что нужно получить согласие вашей будущей Agile-команды на то, чтобы попробовать новый подход. Можно заставить людей согласно кивнуть, стиснув зубы, но (и я говорю это, основываясь на моем нелегком опыте) это обычно приводит к потере кадров.
Когда меня просят помочь компаниям с внедрением Agile, я всегда разговариваю с каждой командой отдельно от ее руководителей. Нужно дать членам команды возможность высказаться в комфортных для них условиях, не опасаясь возмездия. Пригласите на встречу и коуча команды, и если вы сами руководитель, то начните разговор с того, что поддержите решение команды, каким бы оно ни было. Затем дайте людям поговорить с коучем без вас.
Вы или коуч можете сказать команде, что ее выбрали возможным кандидатом на тестирование Agile. Я обычно объясняю, почему руководство заинтересовано в Agile, какие выгоды он принесет организации и как это повлияет на членов команды лично. Я также объясняю, что изменение рабочих привычек – это стресс и команде следует ожидать хаоса (обычно на период до трех месяцев), пока каждый разберется, как сработаться с Agile. Еще я часто рисую набросок и поясняю модель изменений Вирджинии Сатир (см. рис. 5.1).
Я говорю: «Если вы согласитесь, то я предложу вам попробовать стандартный вариант Agile в течение трех месяцев. После этого мы оценим, что работает, что нет, и попробуем что-то улучшить [19] . Спустя шесть месяцев у вас будет возможность принять решение – продолжаем мы работать с Agile или остаемся с тем, что есть сейчас».
Затем я даю всем возможность задать вопросы. У команд обычно множество вопросов касательно процесса, но один вопрос возникает всегда: «Что будет, если мы скажем “нет”?» Мой ответ всегда один и тот же: «Ничего не произойдет». Это важно! Должна быть реальная возможность наложить вето. Если вы не дадите людям возможность сказать «нет», то их «да» ничего не будет значить. Давая людям шанс отказаться сейчас и конкретную возможность передумать позже, вы позволяете им в безопасном режиме попробовать что-то новое.
19
Это не совсем правда. Agile подразумевает постоянное совершенствование, поэтому мы оценим, что работает, а что нет, уже в течение нескольких недель. Но по истечении трех месяцев мы делаем паузу, чтобы дать более значительную оценку.
Выделите достаточно времени на то, чтобы ответить на все вопросы. Встреча обычно занимает около часа, но иногда может затянуться. Ответив на все вопросы, напомните, что не будет никаких последствий для проголосовавших против. Еще раз подчеркните это. И затем приступите к голосованию.
Если команда настроена скептически…
Скептический настрой – нормальное явление, его следует ожидать. Будьте честны с вашим коллективом: изменения разрушительны, но результаты себя оправдывают. Поясните практики, которые, по вашему мнению, люди поначалу могут счесть странными или даже раздражающими, например парное программирование. Это поможет снизить градус скептицизма и в будущем облегчит процесс внедрения этих практик.
Может быть полезно подчеркнуть, что это эксперимент и за командой будет последнее слово в вопросе, придерживаться Agile или нет.
Если несколько членов команды против…
Если не согласны лишь несколько человек, то попросите их объяснить причины и подумайте, можно ли разрешить эти разногласия. Если не получается, то предложите им пока воздержаться от суждений и присоединиться к остальным членам коллектива на ближайшие шесть месяцев.
Если они все равно не согласны, то предложите им перейти в другую команду, при условии, что руководство одобрит это решение. Если же это невозможно или вы не знаете, кто именно не согласен (в случае анонимного голосования), что ж, значит, эта команда – неподходящий кандидат.
Если большинство членов команды против…
Если команда не согласна, то вам придется выбрать другую. В моей практике это случалось редко, но так бывает. В одном из случаев это было потому, что коллектив не верил, что их организация даст им достаточно времени на обучение. Теперь, оглядываясь назад, я понимаю, что они были правы, и хорошо, что мы тогда не приступили к изменениям.