Чистый Agile. Основы гибкости Мартин Роберт

У Git достаточно ясный и понятный интерфейс. Получается, что научившись работать в Git однажды, вам не придется особо думать о самом инструменте. Вас будут волновать куда более насущные вопросы: безопасность хранения данных и управление версиями исходного кода. Инструмент стал прозрачен.

Git — это функциональный и сложный инструмент. И что значит изучить его хорошо? К счастью, работает принцип 80/20. Достаточно малая часть возможностей Git, скажем, процентов 20, поможет вам справиться с более чем 80 % повседневных задач, которые будут встречаться во время управления исходным кодом. Большую часть всего необходимого можно освоить за минуты. Сведения по всему остальному можно найти в Сети.

Простота и эффективность использования Git привели к совершенно непредвиденному новому подходу, как создавать программное обеспечение. Линус Торвальдс подумал бы, что использовать Git как инструмент для быстрого избавления от маленьких кусочков кода — сумасшествие, но это именно то, что продвигают сторонники метода Микадо[62] и TCR (Test&&Commit || Revert)[63]. И даже, хотя ключевой стороной Git является его способность очень эффективно управлять ветками, бесчисленные команды почти без исключения ведут trunk-based разработку с помощью Git. Инструмент претерпел экзаптацию[64], то есть эффективно используется способами, которые не предполагали авторы.

Хорошие инструменты выполняют следующие задачи:

• помогают людям достигать своих целей;

• позволяют их достаточно быстро освоить;

• стремятся быть прозрачными для пользователей;

• способны адаптироваться и экзаптироваться;

• доступны по стоимости.

Мы приводим Git в качестве примера хорошего инструмента… на 2019 год. Возможно, вы читаете это уже в будущем, и на дворе другой год. Времена меняются, меняются и инструменты.

Физические инструменты Agile

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

• Помогают сделать ход работы наглядным и управляемым.

• Интуитивно понятны и не требуют особой подготовки.

• Не требуют значительной когнитивной нагрузки. Их можно легко использовать, сосредоточившись на других задачах.

• Легко экзаптируемы. Ни одно из этих средств не было создано именно для управления ходом разработки ПО.

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

• Все они недороги, и их легко приобрести.

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

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

А может, автоматизируем?

Проект, в котором впервые применяли экстремальное программирование (Chrysler Comprehensive Compensation System), вели преимущественно с помощью физических инструментов. По мере распространения Agile рос интерес к автоматизированным программным средствам. На это есть вполне разумные основания:

• Программные средства хорошо позволяют осуществлять сбор данных в однородном виде.

• С помощью однородных данных можно легко составлять доклады, графики и схемы, выглядящие профессионально.

• Легко вести историю и хранить данные.

• Можно мгновенно делиться данными, вне зависимости от местонахождения адресата.

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

Некоторым ребятам, больше привыкшим к вылизанным презентациям и программам, физические инструменты кажутся чем-то отсталым. И поскольку мы работаем в отрасли разработки ПО, для многих из нас автоматизация всего, чего только возможно, — естественное стремление.

Программные средства в студию!

Или… может, не надо? Давайте остановимся и хорошенько подумаем. В программных средствах может отсутствовать часть функций, которые нужны вашей команде. Если у вас есть инструмент, то путь наименьшего сопротивления — это исходить из возможностей инструмента, вне зависимости от того, отвечает ли он потребностям команды.

Команде сперва следует определиться, каким образом она собирается вести работы, затем уже подбирать средства именно под свои потребности.

Работники используют инструменты, а не инструменты — работников.

Никому не хочется зависеть от чужого мнения. Что бы вы ни делали, вам хочется разобраться в том, как нужно работать, прежде чем что-то автоматизировать. Но вопрос не в том, какие инструменты использовать: физические или программные. Вопрос должен стоять так: хорошие инструменты у нас или нет?

Системы управления жизненным циклом приложений

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

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

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

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

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

Хорошие инструменты способны адаптироваться и экзаптироваться. Хотите добавить поля в виртуальной карточке в ALM? Вам придется найти программиста экспертного уровня, который посвятил (или даже пожертвовал) себя поддержке необходимой программы. Или все закончится тем, что вы отправите запрос на изменение поставщику. Дело пяти секунд при использовании простых физических инструментов оборачивается пятидневной, а может и пятинедельной, задержкой при использовании ALM. Эксперименты с быстрой обратной связью в ходе работ становятся невозможными. И, само собой, если вам вообще не нужны дополнительные поля, кто-то должен обратить изменения и перевыпустить программу в измененной конфигурации. Системы ALM плохо адаптируются.

Хорошие инструменты доступны по стоимости. Лицензия на ALM, которая может стоить несколько тысяч долларов в год, — только начало. Установка и использование этих систем может потребовать значительных дополнительных расходов на подготовку, поддержку и, иногда, настройку под ваши потребности. Текущее обслуживание и администрирование выльются в дополнительные затраты к уже немалым имеющимся.

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

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

Хуже того, системы ALM часто не могут транслировать информацию, в отличие от физических средств. Вам нужно выполнить вход и копаться в данных, чтобы найти нужные сведения. Когда вы находите нужные сведения, они часто идут вместе с кучей ненужных. Иногда два-три графика или изображения, которые вам нужны, могут находиться на разных страницах. Нет повода думать, что ALM никогда не станут хорошим инструментом. Но если вам нужна доска с карточками и нужно использовать ПО, я бы посоветовал какое-нибудь универсальное средство вроде Trello[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-коуч переключается в режим, в котором предлагает поделиться потенциально полезным опытом. Если участники проявляют интерес, тогда коуч делится своими знаниями, стараясь вернуться в русло проводимого обучения поскорее, как только команда усвоит новые знания.

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

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

Коучинг в нескольких командах

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

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

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

Agile в крупных масштабах

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

При попытках согласовать усилия нескольких команд для получения единого результата такие трудности преумножаются и увеличиваются. К несчастью, Agile в крупной организации обычно стараются внедрить традиционным способом организации проекта. То есть происходит командно-административное внедрение огромного количества изменений, выбранных для предварительного преобразования. И когда я говорю об огромном числе, я говорю буквально о тысячах изменений. Речь идет о тысячах, потому что когда вы просите сотни человек предпринимать десятки изменений в их повседневной работе, у них это может как получиться, так и нет, в зависимости от того, насколько сильно эти изменения бьют по каждому из них лично. Достаточно даже сказать, что план изучить тот крупный набор методов Agile выглядит примерно как «по плану нам нужно реализовать вот этот огромный ворох требований».

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

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

Внедрение Agile с помощью Agile и коуча

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

Все эти наборы суть готовые рецепты, состоящие из отдельных методов Agile. Вместо того чтобы действовать по одному из этих рецептов, можно подготовить свой собственный рецепт с Agile и коучем, который безупречно подходит именно вам. Если по вашему рецепту получается SAFe, Nexus, LeSS или Scrum@Scale, то замечательно!

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

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

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

Наращивание внедрения Agile

Ниже приведен список отдельных методов для внедрения Agile. Этот список был изначально создан и периодически обновлялся посредством трех главных ступеней в Agile-коучинге — устранения дублей, сбора идей на стикерах и точечного голосования при участии группы из примерно десятка корпоративных коучей. Для справки здесь приведено обобщенное описание этих методов. Существует гораздо больше методов Agile, которые здесь не перечислены. Рассмотрим для начала этот список. Например, вместо того чтобы внедрять Scrum, Kanban, экстремальное программирование или один из наборов методов для масштабирования Agile, подумайте, какой метод из списка ниже наиболее уместен для текущих потребностей той или иной группы или команды, и внедрите его. Попробуйте его применять некоторое время, потом повторите действия.

• Практики Kanban: методы Kanban основаны на наглядности хода работ (с помощью карточек на стене), ограничении количества выполняемых работ и прохождении работы через разные стадии.

• Scrum и экстремальное программирование (XP): эти две методологии часто увязывают вместе, потому что они очень похожи, за исключением технических методов XP. В SAFe, например, их упоминают совместно как ScrumXP. Обе методологии включают в себя большое разнообразие методов, например короткие ежедневные собрания команды, «владелец продукта», «фасилитатор процесса» (он же «скрам-мастер»), ретроспективы, кросс-функциональность команд, пользовательские истории, небольшие релизы, рефакторинг, заблаговременное написание тестов и парное программирование.

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

• Деревья эскалации: если есть смысл всегда работать над чем-либо, что приносит наибольшую пользу, тогда есть смысл безотлагательно поднимать препятствия по строго намеченному пути эскалации. Они применимы к широко используемому методу Scrum of Scrums и не такому известному retrospective of retrospectives. Одним из паттернов для этого является фрактальный паттерн масштабирования для Scrum@Scale посредством Scrum, Scrum of Scrums и даже Executive Action Team.

• Регулярное межкомандное взаимодействие: этот метод предполагает регулярное взаимодействие между мастерами Scrum, владельцами продукта и членами команды, которые работают сообща на результат. Один из способов это обеспечить — проводить регулярные события на открытом пространстве.

• Kanban портфеля: традиционные способы управления портфелями способствуют распределению работников по нескольким командам, что ведет к неконтролируемой многозадачности. Многозадачность создает трение, увеличивает сложность и снижает производительность. Kanban портфеля накладывает ограничения на количество выполняемых работ на уровне инициативы и обеспечивает постоянное внимание на работе, приносящей наибольшую пользу. Одновременное управление меньшим количеством проектов также значительно упрощает (или даже решает) проблему согласования нескольких команд. Kanban портфеля лучше всего работает в паре с наименее возможным приростом (Minimum Viable Increment).

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

Добиваться большого, сосредоточившись на меньшем

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

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

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

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

• Непрерывная интеграция: в экстремальном программировании делается еще больший упор на согласованность, этот метод призывает проводить слияние всего продукта после каждой отметки об изменении.

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

Будущее Agile-коучинга

В последние несколько лет профессиональный коучинг и фасилитация все прочнее занимают свое место среди дисциплин Agile. На курсах скрам-мастера с расширенной сертификацией (ACSM), проводимых Scrum Alliance, есть несколько учебных задач, связанных с коучингом и фасилитацией, а программы «сертифицированный командный коуч» (CTC) и «сертифицированный корпоративный коуч» (CEC) требуют усвоения еще большего количества навыков фасилитации и коучинга. Руководство по Scrum дает определение скрам-мастера как того, кто проводит коучинг.

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

Кажется, в последние пару месяцев наблюдается рост интереса к профессиональному коучингу. Люди все чаще пропускают обучение по программе ICP-ACC и сразу идут на обучение по ICF. Появилась первая коучинговая школа Agile, аккредитованная ICF, и скоро появится, по крайней мере, еще одна. Agile-коучинг ждет большое будущее!

Заключение (снова Боб)

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

Глава 7. Мастерство высшего уровня

Автор Сандро Манкузо, 27 апреля 2019 года

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

Но большинство из них смогли это сделать и были приятно удивлены. Вдруг все изменилось. У нас появились списки невыполненных задач и пользовательские истории вместо документов с требованиями. У нас появились настоящие доски и диаграммы сгорания задач вместо диаграмм Ганта. У нас появились стикеры, которые мы передвигали каждое утро в соответствии с ходом работ. В стикерах чувствовалась какая-то мощная энергетика — что-то, что вызывало сильную психологическую зависимость. Они как будто представляли нашу приверженность Agile. Чем больше таких заметок было на стене, тем более вовлеченными в Agile мы себя ощущали. Мы стали командой, работающей по Scrum, а не бригадой строителей. У нас больше не было менеджеров проекта. Нам сказали, что нам не нужны менеджеры, теперь наши менеджеры будут «владельцами продукта», а у нас будет самоорганизация. Нам сказали, что владельцы продукта и разработчики будут тесно сотрудничать, словно одна команда. И отныне, поскольку наша команда работает по Scrum, мы наделены правом принятия решений. Не только технических, но и тех, что связаны с самим проектом. Или мы так думали.

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

Менеджеры и заинтересованные лица пришли в восторг. В конце концов, кто бы не хотел испробовать Agile? Кто бы не хотел быстрее выпускать программное обеспечение? Даже среди скептиков Agile вызывал интерес. Если ваши конкуренты хвастаются тем, что используют Agile, а вы нет, что вам мешает? Что о вас подумают ваши потенциальные клиенты? Компании не могут позволить себе отказаться от Agile. За годы, последовавшие за саммитом Agile, компании по всему миру встали на путь перехода к Agile. Началась эра внедрения Agile.

Похмелье от Agile

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

Продать методы Agile менеджерам среднего звена было легко — всем им хотелось, чтобы ПО выпускалось быстрее. «Инжиниринг — это несложно. Если наладить процесс разработки, с ним тоже будет все в порядке, — говорили менеджерам. — Дело всегда в людях». И они покупали. Руководители работают с людьми и покуда занимают свою должность, они счастливы, когда их подчиненные работают быстрее.

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

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

В их модели Agile нет никакой стратегическо-технической работы. В ней нет требований к архитектуре или проектированию. Порядок таков, что нужно просто сосредоточиться на какой-либо невыполненной работе из списка, которую нужно выполнить незамедлительно и которой присвоили наивысший приоритет. И так одно задание с наивысшим приоритетом следует за другим. Такой подход приводит к длинной последовательности итеративных тактических работ и накоплению технического долга. Хрупкое программное обеспечение, знаменитые монолиты (или распределенные монолиты, если говорить о командах, которые пробуют использовать микросервисную архитектуру) становятся в порядке вещей. Ошибки и неполадки оказываются излюбленной темой для обсуждения на ежедневном стендап-митинге и ретроспективах. Релизы выходят не так часто, как ожидали клиенты. Тестирование вручную занимает целые дни, а то и недели. И надежда на то, что применение Agile убережет от всех напастей, бесследно уходит. Менеджеры обвиняют разработчиков, что те слишком медленно работают. Разработчики обвиняют менеджеров, что те не дают им проводить необходимые стратегические и технические работы. Владельцы продукта не считают себя частью команды, поэтому не берут на себя никакой ответственности за то, что дела пошли не так. Начинает преобладать порядок «свои против чужих».

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

Ожидание и реальность

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

Слаженное сотрудничество убирает некоторые барьеры, которые мешают работать, но не обязательно добавляет мастерства работникам.

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

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

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

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

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

Все дальше друг от друга

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

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

Разработчики отдаляются от Agile или Agile отдаляется от разработчиков?

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

Компании до сих пор недостаточно созрели для понимания того, что технические проблемы — на самом деле проблемы бизнеса.

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

Высшее мастерство разработки

Чтобы повысить планку профессиональных навыков разработки и восстановить некоторые изначальные цели Agile, группа разработчиков собралась на встрече в Чикаго в ноябре 2008 года, чтобы создать новое движение — мастеров разработки ПО (Software Craftsmanship). Эта встреча напоминала саммит Agile, который прошел в 2001 году, на ней разработчики утвердили основной набор ценностей и создали новый манифест[68] на основе Манифеста Agile:

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

• Не только работающий продукт, но также и искусно разработанный продукт.

• Не только готовность к изменениям, но также и постоянное увеличение ценности.

• Не только людей и взаимодействие, но также и содружество профессионалов.

• Не только сотрудничество с заказчиком, но также и плодотворное партнерство.

Таким образом, в стремлении к тому, что слева, мы также считаем непременным следовать и тому, что справа.

Манифест мастеров разработки ПО содержит идеологию, менталитет. Он способствует профессионализму с разных точек зрения.

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

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

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

Плодотворное партнерство означает следование профессионализму в отношениях с клиентами и партнерами. Мы всегда будем, насколько возможно, проявлять этичность и уважительность в консультировании и работе с нашими клиентами и работодателями. Мы будем ожидать взаимного уважения и профессионализма, даже если нам придется взять на себя инициативу и показать пример.

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

Мастера стремятся выполнять свою работу как можно лучше не потому, что кто-то за это платит, а потому что они сами хотят хорошо работать.

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

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

Идеология против методологии

Идеология — это система идей и идеалов. А методология — система методов и практик. Идеология определяет идеалы, на которые нужно держать курс. Можно использовать одну или несколько методологий для достижения этих идеалов — они являются средством достижения цели. Если посмотреть на Манифест Agile и его 12 принципов[69], мы можем явно разглядеть идеологию в этих строках. Главная цель Agile — это обеспечить гибкость бизнеса и удовлетворить запросы клиентов, а достичь этого можно через тесное сотрудничество, итеративный процесс разработки, быструю обратную связь и техническое совершенство. Методологии вроде Scrum, экстремального программирования (XP), метода разработки динамических систем (DSDM), адаптивной разработки ПО (ASD), методов Crystal, разработки, управляемой функциональностью (FDD), а также другие методологии Agile служат одной и той же цели.

Методологии и методы — как дополнительное колесико в детском велосипеде: они хороши поначалу. Как и в случае с ребенком, который учится кататься на велосипеде, такие колесики помогут научиться безопасно и легко кататься. Когда ребенок становится увереннее, мы поднимаем колесики, чтобы он мог потренироваться держать равновесие. Потом убираем одно из дополнительных колесиков. А за ним и другое.

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

Джим Хайсмит в своей книге Agile Project Management: Creating Innovative Products пишет: «Принципы без методов — ноль без палочки, в то время как методы без принципов, как правило, заучивают механически, без лишних раздумий. Принципы направляют методы. Методы воплощают принципы. Они идут рука об руку»[70]. Хотя методологии и методы являются средством для достижения цели, мы не должны преуменьшать их важность. Профессионалов определяют по тому, как они работают. Мы не можем заявлять, что у нас есть какие-то принципы и ценности, если наши методы работы не согласуются с ними.

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

Есть ли в мастерстве разработки методы?

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

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

Мастерство разработки ПО — это не только технические методы, инжиниринг и самосовершенствование. Это также профессионализм и помощь клиентам в достижении их деловых целей. И это как раз та область, где Agile, бережливое производство (Lean) и мастерство разработки прекрасно сочетаются. У всех трех концепций схожие цели, но они рассматривают проблему с разных, но одинаково важных точек зрения, которые друг друга дополняют.

Сосредоточьтесь на ценностях, а не на методе

Распространенная ошибка в сообществах Agile и мастеров разработки ПО в том, что они больше внимания уделяют методам, а не ценностям, которые лежат в основе этих методов. Возьмем, к примеру, разработку через тестирование. Один из наиболее частых вопросов, которые задаются в сообществах мастеров разработки ПО: «Как убедить моего руководителя/коллегу/команду применять разработку через тестирование?» Так вопрос ставить нельзя. Проблема здесь в том, что мы скорее предлагаем решение, чем принимаем проблему. Никто не станет работать по-другому, если не показать им ценности.

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

А что, если сократить время до 20 минут? Двух минут? Или даже 2 секунд? А что, если бы могли проводить его в любое время нажатием на кнопку? Даст ли это нам хорошую отдачу от вложений? Станет ли наша жизнь от этого легче? Сможем ли мы выпускать надежное ПО быстрее?

Если мы соглашаемся в том, что ответ будет «да», то можно уже говорить о методах, которые помогут нам достичь наших целей. Разработка через тестирование станет в этом случае естественным выбором. Тех, кому не нравится разработка через тестирование, мы спросим, какой метод они предпочитают. Какой метод, который позволит достичь поставленных целей с тем же или лучшим успехом, они смогут предложить?

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

Обсуждение методов

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

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

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

Выходит, мы говорим о том, что разработчики должны скрывать ход своей работы? Вовсе нет.

Разработчики должны уметь доступно объяснить способы своей работы и преимущества этих способов всем, кому это может быть интересно. Что разработчики не должны позволять другим — так это решать за них, как им нужно работать. Разработчики и бизнес должны обсуждать «что», «зачем» и «когда», но вовсе не «как».

Влияние мастерства на личность разработчика

Мастерство разработки ПО оказывает глубокое влияние на личность. Мы часто видим, как люди проводят разделение между личной жизнью и профессиональной деятельностью. Фразы вроде «я не хочу говорить о работе после того, как выйду из офиса» или «в жизни у меня другие интересы» произносят так, будто работа — это что-то плохое и скверное, или то, чем вы вынуждены заниматься без всякого желания.

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

Философия мастерства в том, что разработка — это профессия. Есть разница между наличием работы и профессии. Работа — это то, чем мы занимаемся, но это не часть нашей личности. Профессия же, с другой стороны, — часть нашего «я». Когда спрашивают про род занятий, человек, который ходит на работу, обычно ответит что-то вроде «я работаю в компании такой-то» или «я работаю разработчиком программного обеспечения». Но человек, у которого есть профессия, ответит: «Я разработчик программного обеспечения». Профессия — это что-то, во что мы вкладываем душу. Это что-то, в чем мы хотим добиться большего. Мы хотим получить больше навыков, чтобы у нас был долгий и успешный трудовой путь.

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

Влияние мастерства на отрасль разработки

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

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

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

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

Влияние мастерства на компании

Мастерство разработки ПО получает все большее признание. Многие компании, которые перешли на Agile, теперь смотрят в сторону сообщества мастеров разработки, чтобы улучшить свои технические возможности. Однако мастерство разработки ПО не так привлекательно для бизнеса, как Agile. Экстремальное программирование для многих менеджеров — это часто то, что они не понимают или что вызывает у них тревогу. Руководство понимает Scrum, итерации, демонстрации, ретроспективы, сотрудничество и быструю обратную связь. Но им не особо интересны техники, связанные с программированием. Для большинства из них экстремальное программирование относится к написанию кода, а не к Agile.

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

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

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

Высшее мастерство и Agile

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

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