Kitobni o'qish: «Искусство Agile-разработки. Теория и практика гибкой разработки ПО», sahifa 6

Если требования безопасности не допускают гибкости…

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

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

Если вам требуется дополнительный этап ревью кода…

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

Руководство по устранению неполадок

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

Члены команды не пытаются применять новые практики

Команда не заинтересовалась Agile (см. «Заинтересуйте команду» главы 5); или

В команде нет коуча, который может научить ее практикам (см. раздел «Выберите Agile-коучей» текущей главы); или

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

Внутри команды слишком много конфликтов

Команды слишком часто переформируются (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

Команда испытывает слишком большое давление (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или

Менеджеру команды приходится постоянно помогать улаживать конфликты (см. раздел «Измените стиль управления командой» текущей главы); или

Политики отдела кадров поощряют конкуренцию (см. раздел «Измените вредные кадровые политики» текущей главы).

Члены команды не сотрудничают друг с другом

Команда не заинтересовалась Agile (см. раздел «Заинтересуйте команду» главы 5); или

Члены команды не имеют возможности посвятить все свое время команде или не ладят друг с другом (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

В команде нет коуча, который может научить ее сотрудничеству (см. раздел «Выберите Agile-коучей» текущей главы); или

Распределение или отслеживание задач требует индивидуальной работы (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или

Рабочее пространство не подходит команде (см. раздел «Организуйте рабочие помещения» текущей главы); или

Команда испытывает слишком большое давление (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или

Менеджер команды раздает индивидуальные задания (см. раздел «Измените стиль управления командой» текущей главы); или

HR-политики поощряют индивидуальную работу (см. раздел «Измените вредные кадровые политики» текущей главы).

Команда тратит слишком много времени на предварительную оценку, планирование и отслеживание работ

Команда вынуждена использовать корпоративную систему отслеживания задач (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или

От команды требуют составления предварительных планов и детальных прогнозов (см. раздел «Смените водопадные подходы в управлении» текущей главы); или

Команде нужно развивать свободное владение навыками на уровне фокусировки (см. часть II).

Программное обеспечение, созданное командой, не делает то, что нужно стейкхолдерам

У команды нет доступа к нужному представителю бизнеса, или ей нужны люди с большим опытом в сфере деятельности заказчика и пользователей (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

В команде нет коуча, который может научить ее работе со стейкхолдерами (см. раздел «Выберите Agile-коучей» текущей главы); или

У команды нет доступа к стейкхолдерам (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).

Команде тяжело привлекать внимание стейкхолдеров

Стейкхолдеры не поддержали инициативу с Agile (см. раздел «Заручитесь поддержкой стейкхолдеров» главы 5); или

У команды отсутствуют необходимые навыки в сфере деятельности заказчика (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

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

Программное обеспечение, созданное командой, делает то, что хотят заказчики и пользователи, но не имеет коммерческого успеха

У команды нет доступа к нужному представителю бизнеса или опыта в бизнесе (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

Команде нужна более подходящая цель (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или

Команде нужно развивать свободное владение навыками на уровне оптимизации (см. часть IV); или

Команда свободно владеет навыками в оптимизации, но не может контролировать свои планы и расходы (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).

Программное обеспечение, разрабатываемое командой, имеет очень долгие циклы выпуска версий, много багов или эксплуатационные проблемы

В команде нет людей, уверенно владеющих навыками на уровне поставки (см. раздел «Выберите или создайте Agile-команды» текущей главы); или

В команде нет коуча, который может научить ее практикам поставки (см. раздел «Выберите Agile-коучей» текущей главы); или

Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или

Команда свободно владеет навыками на уровне поставки, но не может полностью контролировать свою разработку, выпуск версий и эксплуатацию (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или

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

Разработка идет медленнее, чем ожидалось

Команда завершает предыдущие задачи, которые были до Agile, или все еще учится (см. раздел «Найдите время на обучение» текущей главы); или

Команде нужно больше коучинга (см. раздел «Выберите Agile-коучей» текущей главы); или

Рабочее пространство не подходит командам (см. раздел «Организуйте рабочие помещения» текущей главы); или

Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или

Команда не может полностью контролировать свой процесс разработки (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или

Команда работает с существующим кодом (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или

Команда ограничена требованиями руководства, отданными на высоком уровне (см. раздел «Смените водопадные подходы в управлении» текущей главы); или

Команда ограничена требованиями безопасности (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).

Глава 5. Инвестируйте в изменения

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

Осознание изменений

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

Понять, как люди реагируют на изменения, можно с помощью модели изменений Вирджинии Сатир (рис. 5.1)¹⁴. Согласно рисунку, существует пять ступеней перемен. Они применимы к Agile следующим образом.

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

2. Сопротивление. Люди, желающие перемен, начинают получать поддержку, и какие-то изменения в направлении Agile становятся возможными. Это называется внешним элементом изменения. Люди начинают по-разному реагировать на возможность перемен. Многие противостоят им. Они говорят, что в Agile нет необходимости, что вряд ли его внедрение будет успешным или что это пустая трата времени. Некоторые злятся. Чем больше людей касаются изменения, тем больше сопротивления вы встречаете.

3. Хаос. Проект изменений одобрен, и команды начинают использовать практики Agile. Старые методы работы и привычные ожидания больше не действуют. Люди растеряны, находятся в замешательстве, и настроения в коллективе переменчивы. В какие-то дни все хорошо, в другие – все плохо. Люди периодически демонстрируют ребяческое поведение. Производительность и моральный климат ухудшаются.

4. Интеграция. С течением временем, практикуясь, люди начинают осваивать новые методы работы. Они открывают для себя тот аспект Agile (его называют трансформирующей идеей), который особенно убедителен для них (для каждого человека он свой). Люди начинают осознавать возможности, которые дает им Agile, и прикладывают реальные усилия, чтобы Agile заработал. Ощущение хаоса снижается, моральный климат улучшается, производительность растет.

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

Рис. 5.1. Модель изменений Вирджинии Сатир (The Satir Change Model)

Такие реакции на изменения неизбежны. Попытки ускорить процесс только ухудшают ситуацию. Вот почему организациям следует отвести время на обучение (см. раздел «Найдите время на обучение» главы 4). Обратите внимание на параллели между моделью Сатир, представленной на рис. 5.1, и J-кривой, показанной на рис. 4.1 (см. выше).

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

Вы можете снизить (но не полностью устранить!) хаос, применив технику, которой я научился у Дианы Ларсен: поддержка, информация и структура (Support, Information, Structure – SIS)¹⁵.

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

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

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

Масштабные изменения

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

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

Руководители организаций часто недооценивают важность управления изменениями. Это большая ошибка! Используя терминологию модели Сатир, к тому времени, как вся остальная организация узнает об изменениях, руководство организации уже восприняло «трансформирующую идею», которая избавила их от ощущений неприятия и хаоса. Для руководства изменения уже кажутся очевидными и необходимыми. Так почему кто-то может быть не согласен?

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

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

Процессы изменений

Кайдзен – общий термин в сообществе Agile. Это японское слово, означающее «совершенствование». В Agile-сообществе этот термин означает непрерывное постепенное совершенствование¹⁷.

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

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

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

Я вижу команды Agile, которые работают посредственно, значительно чаще, чем те, которые функционируют прекрасно. Первых объединяет то, что их компании в свое время не пошли ва-банк. Они пытались проложить свой путь к Agile через кайдзен. Поначалу кажется, что это работает, но потом все неизбежно останавливается. Люди выгорают из-за несовпадения идей Agile и ценностей компании. Они устают впитывать новые идеи. Изменения вызывают переутомление, прогресс начинает тормозиться и после многолетних усилий полностью останавливается. По иронии судьбы, разрушения при таком способе продвижения к Agile значительно более длительные, чем при кайкаку.

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

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

Команды, уже работающие по Agile, могут использовать кайдзен для достижения лучших результатов в рамках их нынешних областей компетентности. Более подробная информация доступна в главе 11. Чтобы добавить новые области (например, если команда компетентна на уровне фокусировки и хочет стать таковой на уровнях поставки и оптимизации), лучше всего выбрать кайкаку. Новые уровни требуют новых инвестиций и серьезных изменений, и лучше делать все сразу.

Успешный кайкаку требует дисциплины и заботы. Рассмотрим, с чего все начинается.

Заручитесь поддержкой руководства

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

1. Начните с разговора

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

В этих разговорах, начиная с того самого первого руководителя, говорите о проблемах в разработке ПО, с которыми сталкивается ваша организация. Возьмите за основу преимущества, описанные в предисловиях к частям II–IV, и расскажите о том, насколько, по вашему мнению, разработка программного обеспечения могла бы вестись лучше в вашей компании. Не монополизируйте разговор; вовлеките в него вашу аудиторию. Вкратце обрисуйте преимущества свободного владения навыками на каждом соответствующем уровне и поинтересуйтесь, какие уровни важны по мнению собеседников. Спросите почему. Слушайте больше, чем говорите. Прежде всего фокусируйтесь больше на том, что они могут получить и к каким потерям может привести бездействие, чем на продвижении Agile ради него самого. На самом деле, учитывая степень всеобщего недопонимания, что такое Agile, вам может быть лучше вообще не упоминать этот термин.

2. Получите одобрение экономичного покупателя

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

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

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

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

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

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

Заполучив в команду союзников экономичного покупателя, начните говорить об инвестициях. Не перегружайте собеседников излишними подробностями; кратко перечислите несколько ключевых инвестиций, необходимых каждому уровню (врезка «Список необходимых инвестиций» в главе 4 поможет вам подготовиться), а также то, как эти уровни соотносятся с пожеланиями покупателя. Спросите его, какой компромисс между размером инвестиций и выгодой он считает приемлемым. Если вы предложите несколько вариантов, а не потребуете ответа «да или нет», это понизит шансы категорического отказа.

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

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