Хабрахабр

Пересечение тестирования и архитектуры: интервью с Нилом Фордом

А что значит совсем уж непонятная должность «meme wrangler»? Что может значить должность «QA architect»? Как менять процессы в организации так, чтобы люди при встрече с первой же сложностью не возвращались к старым? С какого момента при работе над архитектурой надо подключать тестировщиков?

Вскоре на нашей конференции Heisenbug он расскажет о создании «эволюционных архитектур», которые возможно менять при изменении внешних обстоятельств. Нил Форд на своём сайте представляется тремя вариантами: «ThoughtWorker» (сотрудник компании ThoughtWorks, которую многие знают из-за Мартина Фаулера), «Software Architect» и «Meme Wrangler». А пока что Михаил xomyakus Дружинин (участник программного комитета Heisenbug) расспросил Нила: и о том, как тема его выступления пересекается с тестированием, и о многом другом.
— Можете для начала рассказать о себе и о своей карьере?

Я в ThoughtWorks почти 14 лет. — Конечно. Первые три книги я написал до того, как я присоединился к ThoughtWorks. До этого был техническим директором в небольшой фирме по консультированию и обучению, примерно из 25 человек, и там начал пробовать свои силы в технологиях вроде Java. Самая первая была о Delphi, на тот момент довольно популярном в России и в Европе.

Когда ты знаешь больше, чем люди вокруг, ты особо не развиваешься. Когда я был техническим директором, подустал быть альфа-гиком. И я стал неосознанно подыскивать компанию, в которой бы в основном работали действительно умные и заинтересованные люди. Я начал выступать на множестве конференций, и мне очень понравилось находиться среди других спикеров, потому что они были очень умными и заинтересованными людьми. По таким вещам, как CruiseControl и библиотека для тестирования NUnit, я заметил, что они делают огромный вклад в open source и делают много очень интересных вещей. И буквально споткнулся о ThoughtWorks, как и многие, на сайте Мартина Фаулера. Это было для меня хорошим шагом, потому что это очень умные и очень увлечённые разработчики. И так я нечаянно начал процесс собеседования с ThoughtWorks, в конце которого получил предложение работы.

Первая — ты должен сам заниматься всеми бизнес-делами: выставлять счета, гоняться за людьми ради денег, регулировать денежные потоки и всякое такое. Я мог бы быть независимым консультантом, но в этой роли мне не нравятся две вещи. Моя страсть — программное обеспечение и разработка. Я способен этим заниматься, но меня это не увлекает.

Ты почти всегда сам по себе, а мне очень нравится командная разработка. И второе: если ты независимый консультант, то тебе редко удаётся поработать в сотрудничестве с кем-то, в команде. Мне кажется, что при совместной работе результат получается большим, чем сумма отдельных составляющих. Я даже несколько книг написал совместно с другими авторами, включая мою последнюю книгу «Эволюционная архитектура». Когда ты сотрудничаешь в творческой работе, будь то писательский проект или программа, можешь получить больше точек зрения и более общее представление, поэтому и результат получится лучше.

Я так хорошо знаю это, потому что одно из интересных преимуществ работы в ThoughtWorks — если ты проработал в компании 10 лет, получаешь 12-недельный оплачиваемый творческий отпуск, когда ты можешь делать всё, что угодно. Так что в апреле будет уже 14 лет, как я в ThoughtWorks. 12-недельный мне очень понравился, и я предвкушаю следующий. А после этого каждые 5 лет получаешь 6-недельный оплачиваемый творческий отпуск, так что мне остался год до первого 6-недельного. Так что ты всегда помнишь, какой десяток лет ты уже здесь: они отмеряются такими приятными отпусками.

— Это очень ощутимая длина отпуска, круто.

Большая часть моей работы и сейчас относится к области архитектуры программного обеспечения, я провёл много времени на пересечении архитектуры и инженерных практик (например, continuous delivery) — подозреваю, что тут мои интересы пересекаются с интересами аудитории Heisenbug. — Я был нанят ThoughtWorks на должность архитектора и выполнял эту роль какое-то время, пока не перешёл на директорский уровень.

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

— А что значит «Meme Wrangler»?

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

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

Архитекторы программного обеспечения, думаю, по своей природе такие «pattern matchers»: мы пытаемся применять паттерны ко всему, что видим, даже к вещам из реального мира. А одно из преимуществ разработки на заказ — то, что ты можешь знакомиться с большим количеством различных проектов. И я понял, что, на самом деле, моя работа — что-то вроде сбора интересных идей из экосистемы программного обеспечения. Так что, если ты архитектор в разработке на заказ, тебе доводится видеть множество разных проектов, ты видишь в них повторяющиеся паттерны, видишь, какие из них работают. Отсюда пошло «Meme Wrangler».

Всем знакомы мемы из интернета — это некая остроумная штука, которая цепляет и распространяется как вирус. Meme (мем) — это термин, который придумал писатель Ричард Докинз, это широко распространённая единица для обозначения идей. И я выбрал себе должность Meme Wrangler, потому что это более точно отражает то, чем я сейчас занимаюсь. И у слова «wrangle» есть два полезных значения, первое — выступать судьёй в споре, а второе значение — «сгонять в стадо». Более того, теперь, когда я выпускаю очередную книгу, я пишу в Твиттере, что «заарканил очередной мем» и поместил его в эту книгу.

— Можете пояснить, что должен делать архитектор программного обеспечения, чем вы занимаетесь как архитектор ПО?

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

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

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

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

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

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

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

— К вопросу об архитектуре и должностях: я всё чаще вижу на визитных карточках и в LinkedIn должность «архитектор QA».

Я встречал и «архитекторов QA», и «архитекторов данных», «архитекторов систем», «архитекторов решений», «технических архитекторов» — я встречал архитекторов всех возможных мастей. — Это одна из проблем термина «архитектор»: каждой компании приходится изобретать свои названия для этого. И это проблема, потому что никто не может дать чёткого определения, и дают то, какое хочется.

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

Понимаете, это такая расплывчатая должность. Эти навыки применимы и к области QA, и того, кто это делает, тоже можно назвать «архитектор». Типа, знаете, сениор-сениор-сениор разработчик — окей, архитектор. Многие организации просто приходят к тому, что называют самого старшего инженера архитектором, потому что это круто звучит и они не могут придумать, как его ещё назвать. По сути, это выдуманные должности. И я встречал компании, где есть один тип архитекторов, и я встречал компании, где есть десятки разновидностей архитекторов. Моя «meme wrangler» в этом смысле лучше, потому что она очевидно выдуманная.

Вы выступите на конференции по тестированию — а что для вас самого качество ПО? — Давайте поговорим в направлении вашего выступления на Heisenbug.

Я знаю, что мир QA больше рассматривает ПО как чёрный ящик, то есть смотрит с позиции пользователя, нет ли там ошибок и сбоев, корректно ли оно функционирует. — Я лично рассматриваю качество архитектурных компонентов системы. Здесь я должен быть последним рубежом обороны, выясняя, из-за чего это происходит. Безусловно, я тоже в этом заинтересован, но меня больше волнуют первопричины ошибок: почему приложение ненадёжно, почему оно периодически вылетает? О них сейчас много разговоров в мире UI, у них есть чёткие показатели: если твой мобильный сайт загружает видимый контент дольше, чем 3 секунды, пользователи уйдут и перейдут куда-то ещё. И есть такие вещи, как производительность и отзывчивость.

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

— Можете привести самый интересный кейс из практики, связанный с качеством?

— Сложно сказать, все проекты разные, так что лучший — это всегда последний, над которым я работал!

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

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

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

Приложения типа Dropbox и Google Drive решили эту задачу так, что она стала невидимой. А со стороны это кажется простой задачей. Но когда мы пытались её решить, оказалось, что существует миллион пограничных случаев. И она кажется лёгкой. Так что без надёжного QA трудно найти их все, каждый из которых должен быть возвращён на согласование со структурой приложения, чтобы проследить, что общая структура всё ещё работает.

И это отличная иллюстрация того, насколько важно иметь очень хорошо налаженный цикл обратной связи между разработкой архитектуры и такими частями, как QA. Собственно, пока мы разрабатывали эту систему, вносили фундаментальные изменения в структуру, мы поняли, что пограничные случаи будут частыми и неприемлемыми. Если наладить тесный контакт между разработкой архитектуры и тестированием, то можно находить эти пограничные случаи и менять структуру гораздо быстрее. Слишком многие компании откладывают это на самый последний момент, но если так делать, то в итоге многие вещи будут сделаны неправильно, и придётся возвращаться назад и тратить уйму времени, чтобы переделывать. И у нас была очень сильная команда тестировщиков. К счастью, в этом проекте мы были крайне гибки — так как это был проект ThoughtWorks, у нас был очень быстрый цикл.

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

Люди же любят, когда им такое говорят! — Мне кажется, что тестировщикам было бы полезно прийти к архитекторам и объяснить им, что они плохо делают свою работу, а тестировщикам лучше знать, как её выполнять. Вообще-то нет, не любят, ничего хорошего из этого не выйдет.

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

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

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

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

Исходя из вашего опыта, как бы вы сказали, темп изменений в области разработки ПО замедляется или ускоряется?

— Ускоряется.

Причём даже темп ускорения тоже ускоряется! — Конечно! Потому что частью этого жизненно важного цикла обратной связи должно быть именно тестирование (QA). Так что любая компания, любая организация, которая НЕ стремится наладить цикл обратной связи с дизайном, совершает большую ошибку. Это последний рубеж обороны, который позволяет как раз делать то, как вы заявили, что ваша система будет делать.

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

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

— Когда вы разрабатываете архитектуру, на каких стадиях проекта вы привлекаете тестировщиков?

Когда мы начинаем проект, у нас обычно присутствуют архитекторы, разработчики, бизнес-аналитики и QA-инженеры, и если есть кто-то, кто занимается инженерией данных, архитектурой данных или data science, они тоже присутствуют. — С самого начала. Потому что глупо составлять такую архитектуру, которую будет сложно тестировать.

Потому что всегда, снова и снова в самых разных проектах, бывает так. Их фидбэк нужен, начиная с самых ранних стадий. А потом кто-то из мира данных или тестирования говорит: «Знаешь, если делать так, то нам будет очень сложно с этим работать, но если сделать вот так, то и нам будет проще, и для вас задача тоже не сильно усложнится». Сначала архитектор придумывает какую-то структуру и говорит: «Мы будем делать вот так». Ты же не хочешь свести с ума своих архитекторов данных. И собирать эти идеи на ранних стадиях очень важно, потому что так можно сделать такую структуру, которая очень сильно упростит жизнь тестировщикам и всем остальным, не только тестировщикам.

Мы делаем это, когда строим свою инфраструктуру, штуки типа deployment pipeline. Есть одна фраза, которую мы часто используем в ThoughtWorks, «прокладывать мощёные дорожки» для людей. А ещё мы считаем, что нужно иметь надёжную QA, так что нужно, чтобы они принимали участие в разработке архитектуры с самого начала, чтобы мы могли видеть, что для них в дальнейшей работе с этой структурой не будет трудностей, потому что зачем создавать им лишние трудности, если мы с легкостью можем сразу сделать структуру иначе, чтобы сократить большинство этих трудностей. Мы не хотим, чтобы разработчики испытывали трудности с использованием этих инструментов, мы пытаемся проложить мощёную дорожку, чтобы у них возникало как можно меньше помех в том, чтобы делать то, что мы считаем нужным. И сокращение помех это такой способ ускорить цикл обратной связи, что является наиболее насущной целью аджайл-разработки.

А что вы думаете о том, что от чётких ролей «бизнес-аналитик», «QA» и так далее движутся к какой-то обобщённой форме? — Звучит знакомо.

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

— А когда не разделяют даже роли QA и разработчиков?

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

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

Всё это делается для того, чтобы команда была как можно менее многочисленной — это мудрость, пришедшая к нам из 1975 года, которую только сейчас начинают осознавать. Но я совершенно нормально отношусь к тому, чтобы иметь гибкие роли внутри проекта.

— 1975-го?

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

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

— Очень интересно.

Потому что на их диалоговых окнах Wi-Fi есть два настолько ужасных примера страдательного залога, что я прямо закипаю каждый раз, когда их вижу. — Кстати, я считаю, что Apple стоит нанять корректора, чтобы вычитывать глупые тексты на их диалоговых окнах. Не надо позволять разработчикам писать тексты для UI, пусть разработчики пишут код. Потому что я писатель и я ненавижу плохие тексты. И стоит нанять корректора в команду QA, чтобы исправить их и меньше раздражать пользователей.

Вероятно, у вас в ThoughtWorks большой опыт — как перейти к таким? — Окей, возвращаясь к теме небольших команд.

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

Сколько тикетов я должен создать? Допустим, мне нужно изменить выгрузку из каталога в моём приложении. Если у вас одна команда, и вы все вместе, то вам нужно ноль сообщений, потому что вы все сидите вместе и вам достаточно сказать: «Эй! Один для слоя UI, один для разработчиков, один для администратора баз данных, один для отдела эксплуатации — и сразу понятно, что это просто шум и помехи. Давайте изменим процесс выгрузки из каталога!» И у вас одна автономная команда и нужно всего одно сообщение о том, что будет изменена выгрузка из каталога, а не 50 тикетов в Jira, которые болтаются по всей компании.

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

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

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

Разделение сотрудников по их функциям в работе очень удобно для отдела HR, но ужасно для разработки ПО. А мы делаем разделение сотрудников по их функциям в работе. Это безумие — иметь целый отдел тестировщиков, отделённый от того, что им нужно тестировать. Разделение по командам гораздо лучше. Тестировщикам нужны глубокие знания в предметной области, как это всё работает, а если у них очень ограниченный доступ к бизнес-аналитикам, потому что они находятся в другой части компании, то как тут получить все те знания по предметной области, которые нужны тестировщику для эффективной работы? Как ты должен погружаться в предметную область, если ты далеко от бизнес-аналитиков и разработчиков? А если изменить это значение на то, то должен происходить кредитно-дефолтный своп? Но если вы сидите в одной комнате, то тестировщику будет гораздо проще наклониться к бизнес-аналитику и сказать:
— Эй! Это так и должно быть?
— Да.
— Хорошо.

Так что иметь команду, которая находится в одном помещении, то есть когда есть возможность поговорить, не выходя из комнаты, это действительно крайне важно. Этот 15-секундный разговор позволил избежать полного цикла движения тикетов Jira, электронных писем, суеты и всего того, что только вызывает помехи в работе. И это гораздо лучше, находиться в одной комнате, чем пользоваться чем-то типа Slack, потому что если вы в одной комнате, ты можешь посмотреть, а не занят ли этот человек, а не закидывать его отвлекающими сообщениями через Slack.

Предположим, что мы вернулись во времени на 30 лет назад и вам нужно узнать погоду в Чикаго. Есть аналогия, которую я привожу, поясняя удобство нахождения в одной комнате. Можете включить канал с прогнозами погоды по телевизору и надеяться, что там дойдёт дело до Чикаго. Как вы это сделаете? Или позвонить кому-нибудь. Или, может быть, пойти в библиотеку и посмотреть, нет ли там чикагских газет. А сейчас её можно узнать мгновенно, достаточно просто открыть приложение на смартфоне. И когда возникает столько сложностей, вам уже не хочется узнать эту погоду.

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

Однако мы движемся к миру с большим количеством распределённых команд. — Логично. То есть всё равно приходится полагаться на средства коммуникации. Вот у вас есть офисы в Лондоне, Нью-Йорке, не знаю, Чикаго или там в Сингапуре.

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

Slack — это новейшая версия того, куда приходит умирать продуктивность. Я так ненавижу Slack! Каждому проекту требуется место «по умолчанию» для свалки всего подряд, и этим стал Slack. Некоторым командам удаётся хорошо его использовать, но большая часть людей пользуется им ужасно, превращая в свалку. И его можно так использовать, нужно только быть очень дисциплинированным, потому что с механизмом, который так постоянно тебя отвлекает, просто невозможно заниматься разработкой. Некоторые пытаются использовать его, чтобы поддерживать коммуникацию «в одном помещении». Я отказываюсь когда-либо пользоваться Slack, потому что он просто уничтожает мою продуктивность, постоянно меня отрывая от работы, потому что всем всё время что-то нужно.

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

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

— Никогда.

Потому что вы просто можете взглянуть на лицо собеседника и увидеть, о чём он говорит. — Никогда! Если вы замените личное общение на Slack, то вы потеряете все те уровни коммуникации, которые есть при личном общении. Это один из тех коммуникативных каналов, о которых говорит Алистер Кокберн. Поэтому камеры гораздо более выгодны, чем Slack, хотя может показаться, что объём передаваемой информации такой же, но есть огромный пласт невербальной информации, которая передаётся между людьми, когда они разговаривают, и сокращая количество этих каналов, мы делаем этот канал коммуникации гораздо менее ценным.

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

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

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

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

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

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

Если вы просто рассказываете обо всех преимуществах этих безумных хиппи-айджайлов, вы никогда никого ни в чём не убедите. Это всё основывается на объективных результатах, и это в итоге убеждает компанию. Если вы приводите конкретные цифры, никто не сможет поспорить с такими объективными результатами. Но если вы будете подкреплять это цифрами: «Смотрите, наша новая команда, которая применяет этот новый agile-подход, может добавлять фичи в 1,3 раза быстрее, чем команда с «водопадом», и у нас на 30% меньше дефектов в коде». Им будет очень трудно сказать: «О нет, я не могу работать в этой организации, когда у вас есть точные цифры, которые показывают, что одна сторона приносит пользу другой».

— А как вы определяете, что измерять?

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

Нужны объективные определения, потому что если это туманные бессмысленные вещи, то никто не понимает, к чему мы стремимся как организация. Это должно быть определено компанией, и это возвращает нас к тому, что я говорил раньше. И вы избавите себя от бессмысленной суматохи в компании, если вы сможете чётко закрепить эти цели. А если они железно закреплены, то кто-то, будь то QA или архитектор, или архитектор данных, точно знает, куда целиться, при создании и настройке этой программы. Так что это зависит от вас, как вы определите, что это будет, и вы можете собраться коллективом и подумать — что мы ценим как компания, какие показатели будет полезно отслеживать, чтобы понять, что этот эксперимент приносит плоды.

— По сути, вы утверждаете, что цели компании будут влиять на параметры качества для определённой системы и мы будем достигать некоторого компромисса на базе организации, даже не какого-то конкретного проекта в ней?

Это одна из вещей, которые я часто говорю в последнее время: в разработке ПО всё компромиссы, а если вам кажется, что вы нашли что-то, что не является компромиссом, это значит, что вы ещё не поняли, что это компромисс. — Совершенно верно.

Это одна из причин, почему архитекторы всё время такие раздражительные: в нашем мире нет бинарного «да или нет», есть только компромиссы, нет ничего лучшего, есть только наименее плохое. В разработке ПО нет бинарных противопоставлений — всё расположено на спектре, ближе к одной или к другой стороне, важно определить, где именно.

Может быть, вы бы могли чуть подробнее рассказать, что это для вас значит? — У меня есть стикеры с используемой вами фразой «architecture is abstract until operationalized», и она мне очень нравится.

Это один из мемов, которые я собрал, хороший пример для meme wrangler. — Конечно.

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

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

Вы не меняли ни байта на этом компьютере, но весь мир менялся, так что придётся обновлять ПО. — Обновится.
— Да, обновит всё, что можно! Она живая, и даже если вы её не поменяете, весь мир, в котором она находится, будет меняться: выйдет новая версия Docker или ещё чего-то, от этого что-то может сломаться или измениться. Архитектура — это живой организм, её мало построить, нужно сделать так, чтобы она работала, а ещё нужно позволить ей обновляться и развиваться, в чём как раз идея эволюционной архитектуры. И вы знаете о возможных рисках того, если вы не станете обновлять свои системы, они станут устаревшими и дальше их будет ещё сложнее обновить.

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

Увидимся в Петербурге! — Спасибо за ответы.

Кроме него, уже известны многие другие доклады: увидеть их описания можно на сайте, приобрести билеты — там же. Нил выступит на Heisenbug, который пройдёт в Петербурге 17-18 мая, с докладом «Building evolutionary architectures: Fitness functions».

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть