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

Кэтрин – первый разработчик

Тимати – второй разработчик

Дэн – их руководитель

Акт III. И вот еще что (опять?!)…

– Кэти, у тебя есть минутка? У меня отличные новости.

Кэтрин поморщилась, услышав, что Дэн зовет ее в свой кабинет. Она подумала: «Я никогда не привыкну к этому». Но все-таки зашла, села в кресло и приготовилась слышать «отличные новости».

– Вы проделали замечательную работу, используя гибкие методологии. Просто фантастическую.

Кэтрин припомнила все те восемь месяцев, которые они с Тимати потратили, чтобы при помощи Канбана улучшить процесс работы.

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

После того как она установила очередь на выполнение работ, произошла удивительная вещь: менеджеры начали соперничать за место в очереди и постепенно перестали требовать от нее и Тима выполнения непосильного объема заданий.

Впервые за месяц Дэн вызвал ее, чтобы поделиться действительно «отличной новостью».

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

– Я рада слышать, что ты счастлив, Дэн, – с усмешкой сказала Кэтрин.

Дэн продолжал:

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

– Подожди. Так ты просишь, чтобы я… стала их коучем? – воскликнула Кэтрин.

– Точно, – сказал Дэн.

– Я понятия не имею, как это делается, – ответила Кэтрин.

Дэн посмотрел ей в глаза.

– Это не обсуждается, Кэти. Встряхнись – и за дело.

Коучи понимают, почему люди не всегда хотят меняться

Большую часть своего времени agile-коучи тратят на то, чтобы помочь людям изменить способ их работы. Это непростая задача, потому что только коуч видит всю картину целиком. Люди, которых просят работать по новым правилам, могут не понимать, зачем им это.

Существует много способов такого внедрения практики, когда команда, имеющая самые благие намерения, умудряется сделать так, что практика не работает. Например, в главе 5 описано, что команды часто превращают ежедневный scrum-митинг в статус-митинг. Важная задача scrum-митинга – замена командно-административной формы управления на самоорганизующуюся. Три вопроса, которые каждый задает в ходе встречи, позволяют команде самостоятельно контролировать план проекта. Но многие команды, пытающиеся внедрить Scrum, в итоге используют его как простое ежедневное совещание, где члены команды озвучивают состояние своей работы. Scrum-мастер фактически выступает на нем в роли руководителя проекта и распределяет задания между сотрудниками.

Точно так же некоторые команды добавляют пользовательские истории в документированные бизнес-требования, но рассматривают их как обычные спецификации, характерные для каскадной модели разработки.

Эти команды по-прежнему создают громоздкие спецификации до начала разработки продукта (BRUF, big requirements up front development) и просто добавляют к ним пользовательские истории. А вместо того, чтобы использовать разработку через тестирование, некоторые при попытке внедрить ХР просто хотят убедиться, что их код полностью покрыт тестами, которые они разрабатывают после сборки кода, что означает, что тесты никаким образом не влияют на архитектуру, потому что она полностью завершена к моменту, когда пишутся тесты.