Искусство Agile-разработки. Теория и практика гибкой разработки ПО. Шэйн Уорден
Чтение книги онлайн.
Читать онлайн книгу Искусство Agile-разработки. Теория и практика гибкой разработки ПО - Шэйн Уорден страница 25
Разработка идет медленнее, чем ожидалось
Команда завершает предыдущие задачи, которые были до Agile, или все еще учится (см. раздел «Найдите время на обучение» текущей главы); или
Команде нужно больше коучинга (см. раздел «Выберите Agile-коучей» текущей главы); или
Рабочее пространство не подходит командам (см. раздел «Организуйте рабочие помещения» текущей главы); или
Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или
Команда не может полностью контролировать свой процесс разработки (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или
Команда работает с существующим кодом (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или
Команда ограничена требованиями руководства, отданными на высоком уровне (см. раздел «Смените водопадные подходы в управлении» текущей главы); или
Команда ограничена требованиями безопасности (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).
Глава 5. Инвестируйте в изменения
Вы решили, что Agile сделает вашу команду более успешной. Вы знаете, какие уровни предлагают наилучший компромисс между затратами и выгодой. Вы определились с инвестициями, которые должна сделать ваша компания. Теперь осталось понять, как все это сделать на практике.
Осознание изменений
Изменения разрушительны, и внедрение Agile – не исключение. Степень разрушительности зависит от того, скольких команд они коснулись и насколько успешно вы управляете этими изменениями. Если у вас одна команда, жаждущая попробовать Agile при полной поддержке со стороны организации, то это не должно быть большой проблемой. Если вы пытаетесь изменить 50 команд в организации, не знакомой с идеями Agile… что ж, это очень большая проблема.
Понять, как люди реагируют на изменения, можно с помощью модели изменений Вирджинии Сатир (рис. 5.1)[14]. Согласно рисунку, существует пять ступеней перемен. Они применимы к Agile следующим образом.
1. Имеющийся статус-кво. Это стиль работы, который был до Agile. Он удобен и всем хорошо знаком. Все знают, чего от них ждут и как делать свою работу. Некоторые, тем не менее, не очень довольны и считают, что Agile должен помочь. Они хотят перемен.
2. Сопротивление. Люди, желающие перемен, начинают получать поддержку, и какие-то изменения в направлении Agile становятся возможными. Это называется внешним элементом изменения. Люди начинают по-разному реагировать на возможность перемен. Многие противостоят им. Они говорят, что в Agile нет необходимости, что вряд ли его внедрение будет успешным или что это пустая трата времени. Некоторые злятся. Чем больше людей касаются изменения, тем больше сопротивления вы встречаете.
3. Хаос. Проект изменений одобрен, и команды начинают
14
У Стивена Смита есть хорошая статья об этой модели (https://oreil.ly/1KQ38), включающая советы о том, как помочь команде на каждом этапе.