Читаем Искусство Agile-разработки. Теория и практика гибкой разработки ПО полностью

<p>Заинтересуйте команду</p>

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

Когда меня просят помочь компаниям с внедрением Agile, я всегда разговариваю с каждой командой отдельно от ее руководителей. Нужно дать членам команды возможность высказаться в комфортных для них условиях, не опасаясь возмездия. Пригласите на встречу и коуча команды, и если вы сами руководитель, то начните разговор с того, что поддержите решение команды, каким бы оно ни было. Затем дайте людям поговорить с коучем без вас.

Вы или коуч можете сказать команде, что ее выбрали возможным кандидатом на тестирование Agile. Я обычно объясняю, почему руководство заинтересовано в Agile, какие выгоды он принесет организации и как это повлияет на членов команды лично. Я также объясняю, что изменение рабочих привычек – это стресс и команде следует ожидать хаоса (обычно на период до трех месяцев), пока каждый разберется, как сработаться с Agile. Еще я часто рисую набросок и поясняю модель изменений Вирджинии Сатир (см. рис. 5.1).

Я говорю: «Если вы согласитесь, то я предложу вам попробовать стандартный вариант Agile в течение трех месяцев. После этого мы оценим, что работает, что нет, и попробуем что-то улучшить[19]. Спустя шесть месяцев у вас будет возможность принять решение – продолжаем мы работать с Agile или остаемся с тем, что есть сейчас».

Затем я даю всем возможность задать вопросы. У команд обычно множество вопросов касательно процесса, но один вопрос возникает всегда: «Что будет, если мы скажем “нет”?» Мой ответ всегда один и тот же: «Ничего не произойдет». Это важно! Должна быть реальная возможность наложить вето. Если вы не дадите людям возможность сказать «нет», то их «да» ничего не будет значить. Давая людям шанс отказаться сейчас и конкретную возможность передумать позже, вы позволяете им в безопасном режиме попробовать что-то новое.

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

<p>Если команда настроена скептически…</p>

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

Может быть полезно подчеркнуть, что это эксперимент и за командой будет последнее слово в вопросе, придерживаться Agile или нет.

<p>Если несколько членов команды против…</p>

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

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

<p>Если большинство членов команды против…</p>

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

<p>Если люди обманывают насчет своего согласия…</p>

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

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

Перейти на страницу:

Похожие книги

Чистая архитектура. Искусство разработки программного обеспечения
Чистая архитектура. Искусство разработки программного обеспечения

«Идеальный программист» и «Чистый код» – легендарные бестселлеры Роберта Мартина – рассказывают, как достичь высот профессионализма. «Чистая архитектура» продолжает эту тему, но не предлагает несколько вариантов в стиле «решай сам», а объясняет, что именно следует делать, по какой причине и почему именно такое решение станет принципиально важным для вашего успеха.Роберт Мартин дает прямые и лаконичные ответы на ключевые вопросы архитектуры и дизайна. «Чистую архитектуру» обязаны прочитать разработчики всех уровней, системные аналитики, архитекторы и каждый программист, который желает подняться по карьерной лестнице или хотя бы повлиять на людей, которые занимаются данной работой.

Роберт Сесил Мартин , Роберт С. Мартин

Программирование, программы, базы данных / Зарубежная компьютерная литература / Книги по IT
Dark Souls: за гранью смерти. Книга 2. История создания Bloodborne, Dark Souls III
Dark Souls: за гранью смерти. Книга 2. История создания Bloodborne, Dark Souls III

Bloodborne и Dark Souls III – одни из самых популярных игр, разработанных компанией FromSoftware. Они имеют много общих элементов геймплея, дизайна уровней и стиля, славятся высокой сложностью и необычным миром.Эта книга погрузит вас в уникальные миры двух легендарных игр Хидэтаки Миядзаки. В предыдущем томе Дамьен Мешери и Сильвен Ромье рассказывали историю первых трех игр серии, а теперь познакомят читателей с Bloodborne и Dark Souls III. Они представят каждый аспект: мир, сюжет, персонажей, тематику и, разумеется, музыку и наследие.Вы узнаете о том, как создавалась каждая игра, какие идеи лежат в их основе и как они повлияли на игровую индустрию. Книга также предлагает интересный анализ геймплея и механик, которые делают эти игры настолько увлекательными и любимыми.Понравилась книга? Поставь бумагу на полку!Покупатели электронной книги найдут внутри скидку на бумажную версию

Дамьен Мешери , Сильвен Ромье

Зарубежная компьютерная литература / Книги по IT