[65]. Оно простое, быстрое, дешевое, расширяемое и неплохо выглядит.
Наши способы вести работы постоянно изменяются. Сначала была SCCS, потом RCS, потом CVS, потом Subversion и потом уже Git. В течение многих лет мы видели море изменений в способах управления исходным кодом. Похожую эволюцию мы наблюдали на примере инструментов тестирования, средств развертывания и прочего (не будем перечислять). Вероятно, мы увидим и похожее развитие систем ALM.
Если смотреть на текущее состояние большинства систем ALM, то разумнее и безопаснее начать с простых физических инструментов. Возможно, позже вы задумаетесь о внедрении ALM. Удостоверьтесь, что систему легко изучить, она прозрачна для повседневного использования, легко адаптируется и в ваших возможностях ее приобрести и запустить. Самое главное, убедитесь, что с ее помощью удастся организовать работу так, как нужно вам, и что вложения будут не напрасны.
Коучинг — альтернативный взгляд
Дэймон Пул — это мой друг, который во многом со мной не соглашается. Коучинг в Agile как раз предмет наших разногласий. Вот я и рассудил, что его точка зрения также интересна и будет полезно ее вам поведать.
Автор Дэймон Пул, 14 мая 2019 года[66]
Множество путей к Agile
Можно прийти к Agile разными способами. И на самом деле многие из нас пошли по этому пути непреднамеренно. Кто-то может утверждать, что Манифест Agile появился из-за того, что его авторы заметили, что им было по пути, и они решили рассказать о нем, чтобы другие могли отправиться в этот путь вместе с ними.
Мой путь в Agile начался с того, что в 1977-м я посетил один магазин бытовой техники, в котором, как оказалось, продавали компьютеры TRS-80. Я был новичком и помогал одному опытному программисту проводить отладку игры Star Trek тем, что просто задавал ему вопросы. Сейчас это называется парным программированием. И, оказывается, задавать вопросы — важная часть коучинга.
С того времени примерно до 2001-го я, сам того не зная, работал по Agile. Я писал код только в небольших командах, где задачи тасовались между их членами. Клиентом в основном была фирма, в который мы работали. Я уделял большое внимание тому, что сейчас называют карточками с историями, и мы выпускали продукт только небольшими и частыми релизами. Но потом, когда я уже работал в AccuRey, наши мажорные релизы стали выходить все реже, и в 2005-м разрыв дошел до полутора лет. Целых 4 года я непреднамеренно работал по каскадной модели. Это был ужас, а я даже не понимал почему. Более того, меня считали специалистом по каскадной модели. Если не углубляться в подробности, эта история знакома многим.
Путь к Agile
Мое знакомство с Agile было болезненным. Еще в 2005 году, до того как конференции Agile Alliance и им подобные стали сказочно популярными, были конференции, которые проводил журнал Software Development. Я выступал докладчиком на конференции Software Development East, и после моего выступления о методах управления распределенными командами разработчиков, в котором не было ни слова об Agile, я вдруг обнаружил себя в окружении ведущих мыслителей отрасли, среди которых были Боб Мартин, Джошуа Кериевский, Майк Кон и Скотт Эмблер. Мне казалось, что все интересующие их темы сводились к карточкам, пользовательским историям, разработке через тестирование и парному программированию. Я был в ужасе от того, чем были заняты мысли таких гигантов, их слова резали мне слух, словно бритвой.
Спустя несколько месяцев, во время изучения Agile с целью его разоблачить, меня будто ударило током. Как программиста и предпринимателя меня озарило, и я понял, что Agile — это алгоритм поиска наиболее ценных функций для рынка ПО и скорейшего превращения их в доход.
После такого воодушевления во мне развилась страсть советовать Agile всем. Я вел бесплатные вебинары, выкладывал посты в блог, выступал на конференциях, присоединился и участвовал во встрече Agile New England, проходившей в окрестностях Бостона. Делал все, чтобы распространить Agile повсюду. Когда люди делились, какие трудности у них возникали при внедрении Agile, я был полон решимости им помочь. Я перешел в режим решения проблем и объяснял, что нужно делать.
И я стал замечать, что мой подход часто вызывал возражения и все больше вопросов. Так было не только у меня. Я видел, как многие сторонники Agile на конференциях вступали в противоборство с теми, кто еще не осознал всю его прелесть. И до меня стало доходить, что людям, которые по-настоящему приняли Agile и с отдачей его применяют, нужен другой подход для передачи знаний об Agile и опыте его использования, который бы учитывал особенности и обстоятельства каждого обучаемого.
Зачем нужен коучинг в Agile?
Замысел Agile прост. Его описали всего 264 словами в Манифесте Agile. Но постичь Agile не так-то просто. Если бы все было так просто, каждый бы уже использовал Agile и не было бы потребности в специальных коучах. Людям вообще тяжело принимать какие-то изменения, не говоря уже о том, сколько всего нужно изменить, чтобы полностью принять Agile. Постижение Agile включает в том числе пересмотр застарелых убеждений, культуры, методов, мышления и подходов к работе. Заставить человека думать иначе и помочь ему понять, что же «будет от этого», довольно сложно. В масштабах целой команды сложности усугубляются, а когда обучение Agile происходит в среде, которая специально подготовлена под привычные способы работы, становится еще сложнее.
Для всех изменений справедливо, что люди делают то, что они хотят. Ключ к устойчивым изменениям — находить задачи или возможности, которые известны, в которые есть желание вкладывать средства, а потом помогать достигать людям своих целей. Общество требует и нуждается в компетентности специалистов. Все остальное ждет провал. Коучинг помогает людям находить пробелы и основополагающие убеждения, которые мешают им продвинуться вперед. Коучинг помогает преодолевать сложности и достигать своих целей, а не просто предписывает решение.
Становление коуча Agile
В 2008-м на сцену вышла Лисса Адкинс с совершенно другим подходом к коучингу в Agile. Она сделала упор на чистоту коучинга в Agile посредством внедрения навыков, полученных от профессиональных коучей, в мир Agile.
В то время, когда я узнавал больше о профессиональном коучинге и подходе Лиссы и стал применять это в своей работе, я пришел к тому, что можно получить потрясающую отдачу, будучи коучем самому себе. Полученная польза никак не связана с улучшением знания об Agile или набором опыта, которые коуч также может передать.
В 2010-м Лисса полностью описала свой подход к коучингу в книге Coaching Agile Teams[67]. В то же время она начала предлагать курсы по коучингу. В 2011-м программы этих курсов легли в основу программы IC Agile’s Certified Agile Coach (ICP-ACC), а затем консорциум International Consortium for Agile начал аккредитацию других тренеров, которые предлагают обучение по программе ICP-ACC. Курсы ICP-ACC в настоящее время представляют собой наиболее полный источник знаний для подготовки профессиональных коучей в области Agile.
За рамками ICP-ACC
Сертификация ICP-ACC включает в себя навыки, необходимые коучу: активное слушание, эмоциональный интеллект, подача себя, умение дать четкую и прямую обратную связь, задавать открытые и наводящие вопросы, а также держаться беспристрастно. Полный набор профессиональных качеств коуча еще шире. Например, Международная федерация коучинга (ICF), которая объединяет более 35 000 сертифицированных профессиональных коучей, различает 70 специализаций по 11 категориям. Чтобы стать сертифицированным профессиональным коучем, нужно пройти сложную подготовку и строгую сертификацию, для которой требуется проявить навыки во всех 70 специализациях и документально подтвердить сотни часов оплаченного коучинга.
Инструменты коуча
Многие системы, практики, методы и техники, применяемые в сообществе Agile для обучения этой методологии и работе по ней, совместимы с целями профессионального коучинга. Существуют некие «инструменты коуча», чтобы помочь отдельным людям и группам открыть для себя, какие преграды встают у них на пути, и принять самостоятельное решение, как продвигаться вперед.
Коучинг дает еще ценный навык — многосторонний опрос, одно из назначений которого «задавать вопросы, которые приводят к открытиям, озарениям, заинтересованности или действиям». Взгляд в прошлое, особенно способы вроде «команда с лучшими результатами во все времена» или «шесть шляп», помогает команде самостоятельно находить возможности для изменений и независимо решать, как эти возможности использовать. Открытое пространство (иными словами, не конференция) — это способ провести многосторонний опрос в большой группе, даже в целой организации.
Если вы проходили формальное обучение по Agile или его методам, то, вероятно, участвовали в каких-то играх, которые давали представление о понятиях, принятых в Agile. Это игра с монетами, симуляторы Scrum, пицца Kanban или постройка городка из кирпичиков лего.
Благодаря этим играм участники получают наглядное представление о силе самоорганизации, размере небольших партий, командах с тасовкой функций, разработке через тестирование, Scrum и Kanban. Когда игры проводят с намерением повысить уровень осведомленности участников, а затем позволяют им решить, что делать дальше, участники чувствуют дух профессионального коучинга.
Число таких игр неуклонно растет. Многие из них можно найти на tastycupcakes.org, retromat.org и liberatingstructures.com.
Профессиональных навыков коуча недостаточно
Если мы работаем с командой, которая ничего никогда не слышала о Kanban, но ей это может пойти на пользу, никакие многосторонние опросы или другие профессиональные техники коуча не помогут вдруг нарисовать Kanban в голове участника обучения. В таком случае Agile-коуч переключается в режим, в котором предлагает поделиться потенциально полезным опытом. Если участники проявляют интерес, тогда коуч делится своими знаниями, стараясь вернуться в русло проводимого обучения поскорее, как только команда усвоит новые знания.