#17: Гибкие требования: парное программирование, Agile

[00:20] Здарова! Меня зовут Саша Пахомов, и я инженер, который любит своё дело. Это семнадцатый выпуск подкаста «Тысяча фичей». Сегодня мы поговорим про то, зачем нам требования и как разрабатывать их с кайфом. Чуть-чуть затронем тему экстремального программирования и разоблачим agile-коучей. В конце вас ждёт хорошая новость и, конечно, полезняшка. Поехали!

[00:51] «Идеал достигнут не тогда, когда нечего добавить, а когда нечего убрать». Такой цитатой я хотел бы начать выпуск подкаста про требования. И действительно: когда из требований, из описания какой-то системы или продукта сложно что-то убрать без значительного искажения цели и смысла продукта, фичи или софтверного решения, — как будто бы это и есть наш идеал. А вот когда туда хочется что-то добавлять, накидывать больше, больше и больше, — идеала мы никогда не достигнем, потому что кажется, что добавить можно всегда.

[01:23] А вообще, говоря про требования — requirements по-английски, — вы тоже испытываете дискомфорт, когда слышите термин «требования к программам» или «требования к программному обеспечению»? Не обеспечение — у нас это в универе преподавали. Это что-то такое, что большие дяди в больших корпорациях спускают сверху вниз в виде документов, где всё расписано по пунктам, и мы по этим документам начинаем что-то реализовывать. Какая-то такая картина строится у меня в голове — ну или, по крайней мере, строилась раньше, когда я слышал термин «требования».

[01:52] Вообще говоря, я сам довольно недавно начал задумываться о таком явлении, как требования. До этого как-то… Ну, когда ты джун или мидл-разработчик, ты в целом оперируешь понятиями фичей, багфиксов, тикетов в Jira, максимум — user story. То есть какие-то маленькие штуки, в которых требования если и написаны, то это очень хорошо, а как правило, их там нет либо они выражены неявно, не пунктами. Просто написано, что нужно вот такое сделать, реализовать, такие-то ожидания — а дальше как бы сам.

[02:24] Но когда я начал разрабатывать более-менее серьёзные, сложные системы, где цена имплементации чего-то не так — то есть цена ошибки, которую мы можем внести в код, или недопонимания между заказчиком, продуктом и инжинирингом, — настолько велика, значимость требований, обсуждения и выбора направления, в какую сторону мы идём и что разрабатываем, кажется намного выше. Ну представьте: кто-то будет разрабатывать два месяца, полгода какую-нибудь фичу — например, специальную систему конфигурации, — хотя её и не надо было разрабатывать и под конфигурацией подразумевался один YAML-файл, а мы решили целую вундервафлю слепить. Представляете, какова цена ошибки в таких системах? Поэтому требования — это то, о чём я думаю в последнее время и о чём прочитал в главе книги «Программист-прагматик».

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

[03:57] Давайте разберём на конкретном примере. От бизнеса к нам приходит такая фича: доставка в нашем сервисе должна быть бесплатной, если цена заказа превышает 50 долларов. Мы получили этакий фича-реквест — и, как разработчики, начинаем потихоньку специфицировать требования к этой фиче. Ну что значит «больше 50»? А включаются ли налоги в эти 50 долларов? Вопрос. Дальше: а цена доставки, если она платная, входит в эти 50 долларов или нет? А если нам сказали, что 50 долларов действуют только для заказов на бумажные книги, — что делать с электронными книгами, входят ли они в эти 50 долларов? А будет ли этот порог в 50 долларов меняться? А будут ли потом включаться другие товары? То есть вы понимаете, да, — что вообще такое заказ, что такое корзина? И все эти вещи мы начинаем узнавать и проговаривать, разрабатывая так называемые требования в диалоге. Нам дали то, что хотят: «мы хотим такую фичу», — а мы вместе с бизнесом, с заказчиком, начинаем разрабатывать требования к ней. То есть немного обговариваем и закрепляем контракт того, что будем имплементировать. И это в первую очередь нужно, как я уже говорил, нам, разработчикам.

[05:15] Есть такой инсайт, интересная цитата: никто не знает на 100%, чего они хотят. И это в том числе наша задача как разработчиков, как инженеров — уточнить, чего именно хочет человек, для которого мы разрабатываем софт. И, возможно, даже отговорить его — ну, не отговорить, а позадавать наводящие, исследовательские вопросы, — так что заказчик скажет: «Да я, вообще говоря, сам не знаю, нужна ли мне эта фича, может, мы её не будем делать». А ненаписанный код — это лучший код. Поэтому наша задача, разработчиков, — обговорить вот эти детали. С заказом и скидкой мы их обговорили.

[05:54] Заказчика детали на самом деле не интересуют. Да вы и сами подумайте: когда вы используете какой-нибудь программный продукт или приложение, вас сильно интересует, в каком положении слайдер, и прочие низкоуровневые штуки, о которых мы, разработчики, естественно, думаем, когда пишем код? А клиент о них не думает — и не надо ему об этом думать. Поэтому детали волнуют нас, разработчиков. Требования мы в первую очередь разрабатываем для себя — чтобы все эти детали, корнер-кейсы рассмотреть, обсудить и провалидировать: что как мы понимаем, как будем писать код, так и человек (или система, компания), для которого мы этот код разрабатываем, тоже его понимает. Программисты помогают людям понять в деталях, чего именно они хотят.

[06:52] Ну и говоря непосредственно про сами требования — в каком виде они могут быть представлены? Лично я считаю, что в любом виде, который удобен и комфортен вам. На самом деле все эти истории из универа, когда мы проходили курсы про менеджмент проектов и тому подобное, — вот там как раз этот страх документов, требований, аудита, всех этих слов, которые будто бы только большие дяди-профессионалы могут делать и знать, а наша задача — понять, что это вообще такое. Вообще говоря, это всё условность. В реальном мире, в реальной разработке — если мы не в каких-то жёстких банках или корпорациях типа Amazon, где действительно есть некоторые уставные штуки, — в большинстве компаний таких жёстких требований, таких жёстких рамок нет, и не нужны они. Мы всё это делаем для себя, для разработчиков, для коммуникации. Это просто инструменты. Поэтому должен ли это быть талмуд, документ, на котором ставят печать компании и подписывают requirements? Да нет, наоборот. Они должны быть максимально простыми, написанными максимально доступным языком, чтобы все понимали, о чём речь. Ведь конечная цель всего этого — чтобы мы поняли друг друга и написали именно тот код, который нужен, а который не нужен — не писали. Вот и всё.

[08:15] Как они могут выглядеть? Есть, например, такое понятие, как user story. Это небольшое описание маленькой части продукта — с точки зрения пользователя, как он должен с ней взаимодействовать, а не с точки зрения архитектуры, имплементации, требований. Вот тот же самый пользователь: «Если я накидал себе в корзину на 50 баксов, то хочу бесплатную доставку». И всё. Это как бы нужда, feature request. А дальше уже из этого user story, из верхнеуровневого пользовательского представления фичи, мы начинаем делать интервью. И в ходе интервью можем намайнить инсайтов — типа: «А что если я куплю книжку на 25 долларов и закажу супердорогую доставку за 26?» В итоге у меня будет заказ на 51 доллар, и по идее доставка должна быть бесплатной — а это хак системы: человек купил всего на 25 баксов, а доставка ему бесплатная. И тут заказчик может сказать: «А, ну да, смотри, в этом случае нужно вот так». И это уже требование — мы его записываем. Но верхнеуровнево у нас это всё ещё user story: на борде, в Jira, мы оперируем именно user story и приоритизируем, что и в какую сторону будем прорабатывать вперёд, на уровне user story. А детали нужны уже непосредственно, когда приступаем к имплементации. То есть требование — это часть подготовки к тому, чтобы начать что-то имплементировать.

[09:41] Тут ещё стоит немного поговорить вот о чём. Авторы отмечают, что есть requirements, а есть политики — policy. Отличие в том, что политики — это, можно сказать, бизнес-правила. Например, скидка для всех участников клуба анонимных писателей телеграм-каналов: если человек является участником этого клуба и наш интернет-магазин об этом знает, мы предоставляем ему скидку, даём промокод. Это политика, бизнес-правило, которое по-любому изменится в будущем: дальше будем предоставлять скидку другим участникам, изменится её размер, а в какой-то момент она вообще может уйти. Вот это всё — уже не requirements, не требования, а политика, бизнес-рул, и их не нужно зашивать хардкодом внутрь приложения. Их нужно выносить в так называемую метадату, в конфигурационные вещи, в базу данных. Может быть, вообще написать под это админку, чтобы в ней можно было менять эти правила. И не нужно рассматривать это как требование. Но очень важно в момент, когда мы разговариваем с заказчиком, понять, что есть политика, а что — требование. Поэтому имеет смысл про это говорить, задавать вопросы, интервьюировать в эту сторону.

[11:03] Ну и напоследок про требования. Можно сказать, что стоит иметь так называемый словарь, дикшнери — в документе, на уровне проекта или даже на уровне компании, — в целом, если возникает такая потребность. Например, некоторые различают понятия customer, client и user, когда пишут документ. Это могут быть разные понятия, и они могут сильно влиять на передаваемый смысл. А кто-то — например, я — не различает: что customer, что client, что user, когда я описываю, как он взаимодействует с SQL-интерфейсом, для меня это одно и то же, и я могу эти понятия между собой мешать. А в какой-то системе это может отличаться. Поэтому если есть такие различия, если есть неоднозначные термины, всегда лучше задать словарь и в начале всё расписать. В целом это хорошая практика — и в документе, и вообще в коммуникации с людьми: когда есть раздел, в котором определяется, о чём мы говорим, когда имеем в виду «юзер», — это вот тот и тот, с примером. Может, это банально и немножко скучно, эти словари, но иногда они действительно помогают. Так что если чувствуете, что это нужно включить в документ, в документацию, в README, — лучше это сделать.

[12:24] Дальше в книге «Программист-прагматик» есть раздел, который называется «Решение невозможных задач», или пазлов. Это то, с чем мы, программисты, довольно часто реально встречаемся. Есть какая-то задача, какая-то бага — или вообще что-то непонятное, что даже не назвать: бага это, фича, поведение? Какая-то странность, которую нужно, одним словом, распутать — клубок, узел, который сильно связан. И тут авторы делятся житейскими, иногда, наверное, капитанскими советами о том, как в этой ситуации себя вести.

[13:03] В начале карьеры, помню, сложные задачи вызывали у меня, во-первых, огромный стресс — я не понимал, смогу я это решить или нет. Затем это вызывало огромную озабоченность: я, например, не мог уснуть, если не откопаю проблему; не мог сходить на обед, потому что сидел, психовал, нервничал, но пытался докопаться до истины, решить багу. Сейчас, конечно, с опытом это поменялось, и я спокойно отношусь к любому уровню этих клубков и узлов, которые нужно распутывать, — это вошло в обыденность, стало рутиной. Раз в две недели встречается какая-нибудь реально сложная фигня, и ты тратишь на неё несколько дней. Свои инсайты и лайфхаки я расскажу чуть позже, а давайте посмотрим, что советуют делать авторы «Программиста-прагматика».

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

[14:51] Следующее: они говорят, что можно и нужно прогуляться, если чувствуете, что перегружаетесь, что голова уже кипит и вы начинаете нервничать. Сходите погуляйте с собакой, послушайте какой-нибудь подкаст — например, «Тысяча фичей», — и потом со свежей головой сядьте и всё обдумайте, может, придёт озарение. Или просто утро вечера мудренее: поспите, на следующий день будет полегче. Дальше ещё один капитанский совет — найти уточку: найти человека, которому вы объясните проблему, ту самую классическую ситуацию, когда, пока формулировал вопрос, сам нашёл на него ответ. Это реально иногда работает, и найти уточку просто. Я даже иногда подхожу к людям и говорю: «Можно я об тебя позадаю вопросы?» Мне нужен кто-то, кому я просто задам эти риторические, наводящие себе вопросы; он будет молча на меня смотреть, а я потом такой: «А, ну всё понятно», — и уйду. Редко такое случается, но иногда действительно полезно.

[15:52] Дальше, если не помогает — и погуляли, и поспали, и отдохнули, и пообедали, и уточки позадавали, а всё равно не можем решить сложную проблему, — есть ещё одно житейское наблюдение. Знаете, вот этот момент «о!», когда как будто что-то понял, — эврика, когда яблоко упало Ньютону на голову, момент озарения. Он сам по себе из ниоткуда не приходит. Не может быть так, что мы ничего не делаем, и вдруг «о!» — и решили. Нет. Чтобы озарение случилось, нашему бэкграунду — они говорят, unconscious brain, то есть подсознанию — нужно загрузить достаточно много сырых данных: фактов, наблюдений, экспериментов, статей, видео, книг. Всё это нужно загрузить в себя по предметной области и по проблемам, которые мы пытаемся решить, а потом дать подсознанию всё это в фоне обработать, образовать какие-то нейронные связи в голове, чтобы случилась эврика. Понимаете, сама по себе она не случится — ей нужны данные. Поэтому, если не получается решить, давайте просто загружать данные себе в голову.

[17:13] Я, например, часто загружаю данные так. Я уже как-то в подкасте рассказывал, как находил сложную багу в Micronaut — точнее, не в самом Micronaut, а в annotation-процессоре генератора OpenAPI. Там было что-то странное, но у меня были некоторые наблюдения. Я, как исследователь, подошёл к неизвестному объекту: что мы можем про него сказать? Например: если я переношу какой-то класс вот в этот модуль и генерирую — код получается тот, который я ожидаю; а если переношу класс в другой модуль или выношу в интерфейс — не получается тот код, который ожидаю. Это наблюдение, факт, который я себе в голову закидываю. Дальше ещё: если вот это закомментировать — то так, а если вот тут переписать — то этак. То есть я, как пластилин, начинаю это мять, играться, крутить: с этого боку подошёл, посмотрел; сужаю предметную область, делаю клубок поменьше, пытаюсь потихоньку его расковырять. И потом в какой-то момент либо один из экспериментов явно показывает, что что-то не так, либо реально пошёл на обед и думаешь: «А, наверное, это из-за этого. Пойду посмотрю», — приходишь, смотришь, и правда из-за этого. Поэтому да: данные загружать в голову надо, и главное — не нервничать и не психовать. Такой вот капитанский, но всё-таки совет.

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

[19:34] Что ещё хотелось бы отметить: когда мы пытаемся решить что-то сложное, внешний наблюдатель — например, человек, которому мы репортим нашу работу, — видит, что мы сидим над задачей, ковыряемся, потеем уже неделю. И тут важно давать этим людям адекватную обратную связь, объяснять, что вы делаете: «Я попробовал вот так, попробовал вот так, сделал то, пятое-десятое, пока что пришёл к таким выводам». Потому что, во-первых, вы начинаете это проговаривать — и, возможно, что-то нагенерируете: это та самая утка, например, на дейли-созвонах, почему нет. Во-вторых, вы объясняете человеку, что реально работаете, и у вас нет внутреннего давления, что нужно побыстрее это сделать: «Я, блин, над таской сижу уже столько, вон у меня тиммейты сколько тикетов подвигали, а я всё над этой потею». Это внутреннее давление ослабевает, потому что вы объясняете всем вокруг, что делаете. И вообще, вы можете рассказать так интересно, что вам даже позавидуют, что вы такую проблему решаете. А в отсутствие стресса, как мне кажется, проблемы решаются намного лучше и кайфовее. Это вот лично мои мнения, рассуждения. А мы идём дальше.

[20:55] Дальше хотелось бы поговорить про уже всем, наверное, знакомое и немножко, может быть, странное явление — парное программирование. Не знаю, вы вообще писали код вместе с кем-то? Давайте для начала дадим определение. У парного программирования есть достаточно понятное описание: это процесс, в котором два человека — за одной или за двумя клавиатурами, в офисе или онлайн по Zoom или Code With Me, неважно — садятся и начинают писать один и тот же код. Один из них шерит экран и печатает — тест или имплементацию, — а другой в это время думает над более высоким уровнем абстракции: а как этот код туда встроится? А, наверное, нужно сейчас вот здесь соломки подстелить и такой параметр передать — или, наоборот, вернуть значение. Короче, он сидит, думает про код, что-то подсказывает. И с какой-то периодичностью эти люди передают друг другу клавиатуру и пишут код по очереди. Такой вот процесс.

[21:57] Я, честно, чтобы прям целенаправленно по нему писать код, работать так никогда не делал. Мне кажется, вообще мало людей занимаются парным программированием. Почему они этого не делают? Тут, мне кажется, влияет и культурный аспект, и то, что не со всеми вообще хочется сидеть рядом и что-то писать, и то, что выглядит это странно, и «да зачем, я могу всё сам написать». Много-много факторов. Но это не значит, что не нужно этого делать или не принять хотя бы часть практик из этого.

[22:35] Какие практики из парного программирования я беру для себя, и они мне в работе помогают? Во-первых, вместе найти какую-то проблему, багу, посмотреть на код. То есть не писать код, не разрабатывать, а изучать. Потому что когда продукт сложный, кто-то смотрел в один модуль, другой — в другой, третий их оба щупал. И когда люди с разным представлением о кодовой базе, с разной сеточкой в головах, вместе встречаются и начинают что-то искать — какой код за это отвечает, где вот эта часть, — это происходит, как по мне, намного быстрее. И здесь нет вот этого неудобства и лёгкой робости, когда ты что-то печатаешь и ошибаешься. Небольшой дискомфорт, когда на тебя смотрят, пока ты печатаешь код, — вот эта проблема лайвкодинга, почему многие его не любят: людям некомфортно печатать и разрабатывать, когда на них смотрят. Я их в целом понимаю, хотя у меня дискомфорта абсолютно никакого нет — в том числе потому, что я знаю слепую печать, могу быстро печатать, и мне это, наоборот, доставляет удовольствие. Но это ладно, я отошёл от темы.

[23:45] Так вот, что ещё можно взять из парного программирования, кроме совместного исследования кода вдвоём-втроём (хотя вдвоём более чем достаточно)? Например: когда я написал какой-то документ, я могу скинуть его тиммейтам — «ребят, почитайте, посмотрите». Но знаете, как люди читают документы: первые немножко прочтут, а дальше забьют. А вот если мы созвонимся — «давай сейчас обсудим документ, не прочитаем, а обсудим», онлайн, — и я начинаю: «Здесь я описываю вот это, здесь вот это», — то есть добавляю условно голосовое сопровождение к документу… Хотя хороший документ самодостаточен и создан, чтобы его читали, и объяснять его не нужно. Но иногда проговорить какие-то вещи голосом — оно больше привлекает внимание людей, они более включены в процесс, и вы получите лучший фидбэк от тиммейта, если сделаете это вдвоём, в онлайне, нежели будете в оффлайне пинать документ туда-сюда.

[24:46] Сейчас поклонники асинхронной коммуникации меня просто сожрут, но я считаю, что коммуницировать надо так, как комфортно двум людям. Если оба хорошо умеют в асинхронную коммуникацию — в документах, в комментах вокруг, — и у них всё хорошо получается, это круто, я тоже так общаюсь: у меня есть коллеги, например, которые живут в Америке, и пока я сплю, они работают, и наоборот, — тут созвон уже физически почти невозможен. Поэтому асинхронная коммуникация — да. Но если созвон возможен и никто не против, и вы это обговорили, то, я считаю, можно созвониться, обсудить документы и идти дальше — и не быть тем снобом, которые появились в Твиттере во время ковида: умники, говорившие, что асинхронная коммуникация — это будущее, нужно уметь настроить почту, настроить мессенджер, а созвоны уйдут в прошлое и людям вообще не надо будет разговаривать. В общем, это какой-то бред. Я как автор подкаста, где я говорю, естественно, с этим не согласен. Я считаю, что голос и обсуждение вживую — это очень ценно, и не надо этим пренебрегать.

[25:56] Ну, это я тоже немного заговорился. А завершая раздел про парное программирование, я бы хотел привести цитату из книги — она и там приведена в виде цитаты. Переведу вольно, но сразу скажу, что не одобряю такого рода риторики, таких высказываний в целом, — просто не хочу искажать. Она мне кажется довольно интересной, хотя я её не одобряю. Так вот: «Я никогда не встречал человека, который хотел бы прочитать 17 тысяч страниц документации. А если бы встретил — убил бы его, чтобы он дальше не распространял свои гены». Такой вот перевод. Да, концовка немного странная, я бы такое в книжку не включал. Но если разобраться в мысли, которую пытается донести эта цитата, она интересная. Реально никому не интересно читать огромные талмуды документации, потому что мы люди — особенно сейчас, когда у нас есть TikTok, Reels, Shorts, YouTube, Netflix. Ну, Netflix уже, конечно, нет, но вот эти короткие форматы подачи информации, даже в виде видео, а не текста… Начинает присутствовать и выпирать то, что старики немножко обзывательно называют клиповым мышлением. И когда нам говорят, что нужно прочитать документацию к продукту, прежде чем им пользоваться, — да нифига. Кто сказал, что я должен читать документацию?

[27:27] Вот я, например, считаю, что продукт — да и вообще что угодно… Возьмём язык программирования, отличный пример. Помню, в Твиттере кто-то рассуждал про кейс с JavaScript, когда он что-то делит и, если не может что-то на что-то поделить, вместо того чтобы кинуть ошибку, возвращает какое-то странное число — вообще не то, ошибочное число. И я был на стороне тех людей — там была дискуссия: а должен ли вообще язык программирования кидать ошибку в таких случаях, быть строгим и бить по рукам, если что-то не так происходит в моменте? Либо это проблема программиста, что он не знает, как определено деление в каком-то очередном фреймворке на JavaScript, — и, значит, он дурак, раз использует инструмент, которым не умеет пользоваться. Я считаю, это полный бред — отправлять людей читать документацию вместо того, чтобы задизайнить нормальный продукт, который без документации будет самоописывающим. Ну вот когда вы первый раз в жизни зашли в YouTube — вы смотрели документацию по YouTube? Или, может быть, в IDEA… Ну, IDEA — ещё ладно, такой спорный момент: может, видосик какой-нибудь посмотрели, чтобы понять, как она работает. А документацию — ну не знаю.

[28:40] Заканчивая все эти вольные рассуждения: не всегда нужно быть тем снобом, который говорит «сначала прочитай, а потом иди». Иногда можно реально созвониться, вместе что-то сделать, разобраться в чём-то, посмотреть в код, в имплементацию — и решить проблему, вместо того чтобы говорить: «Ну давай сначала прочитаем вот это; а ты README читал? а devnotes? а там есть пунктик, который говорит об этом поведении?» Мне кажется, нужно всегда быть адекватным, соблюдать баланс и не упарываться ни в одну сторону: ни «опишите всё документацией, чтобы всё было понятно и зафиксировано», потому что никто это в здравом уме читать нормально не будет, — ни постоянно созваниваться и всё решать на созвонах, не оставляя после себя никаких артефактов вроде summary или вещей, которые потом можно найти в истории. Нужно соблюдать баланс. Когда ищем проблему, пытаемся с ней разобраться — можем вместе посидеть, разобраться, потом написать в pull request summary по этой проблеме и пойти дальше. По-моему, отличный вариант взаимодействия. Давайте пойдём дальше.

[29:47] И последнее, последний топик на сегодня, последняя мысль, которую я прочитал в книжке, — и с которой в целом согласен. Ребята-авторы начинают стебать так называемый agile coaching. Я тоже, знаете, чувствую вот эту раздражённость разработчиков на этих странных людей, которые в какой-то момент внезапно появляются у вас в компании. И теперь у вас есть улыбающийся, с отличным английским акцентом agile coach. И вот он сейчас построит вам процессы, будет сидеть у вас на созвонах, на митингах, и своей улыбкой, своим знанием мира и Jira построит вам процессы — вы станете agile. Ну, это я, конечно, утрирую, но такие кейсы прям были у меня в жизни, и не раз. И меня всегда это очень сильно отталкивало — было настолько некомфортно. Это выглядит, как будто человек приходит и начинает насаждать какой-то культ, какую-то религию: «Agile — это вот спринты, это вот…» В общем, я ярый противник любых таких штук, которые больше похожи на идеологию, нежели на практические, реальные наблюдения. Всегда этого сторонился и думал: может, я немного молодой и реально не понимаю, как выстраиваются процессы, а вот эти люди, все, кто говорят про agile, что-то понимают, — просто я ещё не дорос. Всё время так думал.

[31:13] Вообще, давайте так: как agile воспринимаю я? Для меня agile равно гибкость. Я не знаю, я не читал agile-манифеста, не смотрел книжек, не ходил на конференции для тимлидов и так далее. Я, как обычный инженер, воспринимаю это слово как гибкость: быть гибким, готовым к изменениям и делать что-то итеративно. Вот моё понимание этого термина. Авторы раскрывают его примерно так же и выделяют, по их мнению, несколько пунктов, на которые стоит обратить внимание. Они говорят, что agile — это набор ценностей, даже приоритетов в ценностях. Индивидуальности и interaction (как это перевести — коммуникации между людьми): люди и коммуникации важнее, чем процессы и тулы. Затем: работающая software, работающая программа, намного важнее, чем сложная и серьёзная документация. Тесное взаимодействие с кастомером, коллаборация с ним важнее, чем какие-то контракты и документы. Изменение планов под меняющиеся окружение и требования, environment — гибкость, одним словом, — важнее, чем следование какому-то составленному плану, которому мы должны следовать. Это теоретика, те вещи, которые авторы выделяют, по-моему, из agile-манифеста. И я плюс-минус согласен, что всё это про одно и то же.

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

[33:27] Я вот считаю, что когда у меня будет своя компания — а она у меня, конечно же, будет, софтверная, — у меня не будет никаких agile-коучей, и вообще процесс будет построен, наверное, немножко по-другому. Потому что сейчас большинство людей реально привыкли работать по так называемым спринтам. Это тоже одна из частей agile — вот эта итеративность: мы сделали итерацию, разработали на ней что-то конечное, что можем посмотреть, оценить, понять и скорректировать дальнейшее направление, — а не делать план на год, год его разрабатывать, а потом понять, что половина уже и не нужна. Вот эти спринты, как по мне, как раз про это. Но в некоторых командах — даже не компаниях, а командах — спринты начинают быть про какие-то другие вещи: люди по накатанной работают в спринтах просто потому, что так работали на предыдущем месте, и на предпредыдущем, и на следующем тоже будут, — значит, и мы сейчас будем. А как по мне, иногда это не всем подходит.

[34:23] Да, у спринтов есть плюс: мы так или иначе видим итерацию. Мы дробим тикеты так, чтобы они умещались в спринт, и результаты своей работы видим раз в неделю, в две, в три — и в целом чувствуем себя психологически комфортнее, нежели когда полгода что-то делаешь, делаешь, делаешь, а как будто ничего не делаешь. Но в целом для меня это больше какой-то… Мне кажется, лет через десять мы по спринтам уже не будем работать. Ну, посмотрим. Я-то, наверное, точно уже не буду работать по спринтам в своей компании — я буду чем-то другим заниматься. Но, кроме шуток, мне кажется, что мы как сообщество пересмотрим спринты: как по мне, они не всегда полезны. А что вы думаете про agile-спринты? Смущает ли вас то, что иногда это выглядит как какой-то культ, какая-то идеология? Пишите в телеграм-канале подкаста «Тысяча фичей» — для меня это очень важно, давайте дискутировать в комментариях к посту.

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

[35:57] Ну и в конце полезняшка — телеграм-канал под названием Java Swag. Я давний подписчик этого канала, и недавно мне даже удалось познакомиться с автором, с Димой, потому что он позвал меня к себе в подкаст. У него есть телеграм-канал с рассылкой интересных статей, которые Дима сам читает, и подкаст, в котором он приглашает гостей и интервьюирует их на всякие интересные темы. Этакий дуайен из мира Java-подкастов. Надеюсь, скоро выйдет — или, может, уже вышел, не знаю, — выпуск со мной. Так что подписывайтесь на телеграм-канал, он интересный. Ну и не забывайте делиться подкастом «Тысяча фичей» со своими друзьями и коллегами. Давайте прокачивать себя и людей вокруг. Ну а на этом всё. Услышимся!