Хороший коуч старается максимально понятно объяснить, как ежедневные scrum-митинги помогают самоорганизоваться, а разработка через тестирование – мыслить функционально и двигаться в сторону инкрементального проектирования. Как пользовательские истории дают возможность каждому члену команды понять позицию людей, применяющих программное обеспечение. Коуч помогает выйти за рамки простого принятия новых правил, и люди начинают видеть правильное направление движения и то, что оно способно им дать.
Если вы обучаете много команд, то слышите одинаковые мнения от разных людей. Приведем несколько высказываний членов команды, которые могут свидетельствовать об их дискомфорте в связи с изменением, а также о том, что можно предпринять в такой ситуации. На все это полезно взглянуть с точки зрения коуча, даже если вы им не являетесь.
Трудно спорить с успехом. Если вы работаете с командой, которая имеет свою историю разработки ПО для клиентов, то у нее есть право знать, почему нужно меняться. Недостаточно просто сказать, что это решение руководства, – такое заявление ослабит моральный дух. Как коуч вы должны позитивно относиться к работе, которую проделала команда. Но не нужно стесняться указывать на недостатки. Практики в каждой методологии Agile направлены на решение проблем команды. Если вы сможете помочь понять, почему эти проблемы возникают, и предложить команде решения, то шансы, что они будут одобрены, возрастают.
Это очень распространенная реакция на Agile, особенно среди тех, кто привык к командно-административному стилю управления проектом. Где все эти буферы, реестр рисков, лишняя бюрократия, которая тормозит проект и дает возможность в случае чего спасти свою шкуру? План проекта может быть непрозрачным, что порой удобно для команды: им не нужно делиться деталями, кроме как при завершении отдельных этапов; они могут вставлять буферы в промежутках, чтобы уменьшить и даже ликвидировать неопределенность. При использовании отчетов о статусе в качестве основного показателя прогресса разработки вам удается контролировать информацию, которая поступает к пользователям и клиентам. Команды, работающие по таким принципам, чувствуют в Agile угрозу. В главе 3 упомянут agile-принцип, в котором говорится, что работающее программное обеспечение – основной показатель прогресса проекта. Если в agile-команде что-то идет не так, то все об этом знают. Задача agile-коуча – помочь менеджерам, пользователям и клиентам освоиться с этими неприкрашенными критериями достигнутого прогресса и предоставить команде безопасную среду, в которой она получит возможность ошибиться, чтобы впоследствии иметь возможность учиться на собственном опыте. Но если пока это нереально, то ваша задача подсказать всем, а особенно руководителю, какую поставить перед собой цель и как изменить климат и настрой команды в будущем.
Программист, привыкший работать в одиночку, может интуитивно чувствовать, что парное программирование будет тормозить его работу. Особенно понятна такая позиция, когда человек работает в атмосфере, не принимающей ошибок. Вполне объяснимо, что он чувствует себя неуютно в присутствии другого человека, наблюдающего за тем, как он пишет код. И каждому, кто когда-либо обучал юного новичка водить автомобиль, знакомо неприятное чувство, которое испытывает старший член команды, передавая клавиатуру неопытному сотруднику при работе в паре. Существует много причин, по которым люди чувствуют себя некомфортно при использовании этих практик, особенно когда мировоззрение команды им не соответствует. Хороший agile-коуч сначала поможет команде выбрать практики, совместимые с ее мышлением. И в процессе их применения члены команды увидят преимущества и поймут, как и почему эти практики работают. Под руководством коуча все начинают активнее воспринимать гибкое мышление.