Сразу несколько знакомых, с которыми мы за виртуальной кружкой пива обсуждали #metrics, прислали мне эти ссылки 🙂

"Спецвыпуск. Метрики процесса разработки софта"
"Вред и бред корпоративных метрик"

На самом деле все равно в какой последовательности их слушать, но "Вред и бред корпоративных метрик" мне больше понравились (ну и записывалась она первой на самом деле).

Будет ли какое-то мое мнение? Только за виртуальной (а лучше реальной) кружкой пива 🍻
Но размышления в подкасте очень хорошие, рекомендую.

Не может умирать то, что толком и не жило (пост отсюда)
Ну и начиная с 22года - сильно поменялась модель бизнеса и то, где деньги зарабатываются.
Могу ошибаться, но думаю, что и в зарубежном IT сейчас много где не до agile.
А просто "сжали сраки" и погнали, куда и как менеджеры сказали. В эффективных процессах.
#мысли_вслух #процессы

"What's the Ideal Percentage for Spending on Tech Debt?"

Актуальненько 😏
Закину прям перевод, настолько зашло.

Чтобы дать нам иллюзию контроля, которую мы жаждем, мы придумываем эмпирические правила, такие как:
• Выделяем 10% на технологический долг
• Еще 20% для инноваций
• И не забываем про 25% на устранение ошибок

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

Конечная причина этих эвристик заключается в том, что они легко защищаются и помогают защитить нас от потенциальной негативной реакции.

«Достаточно ли мы внедряем инновации?» становится ➔ «Мы тратим 20% на инновации».

«Выделяется ли достаточно времени для решения существующих ошибок? ➔ «Мы выделили на это 25%».

«Работает ли вы, чтобы взять наш технический долг под контроль?» ➔ «Мы тратим 10% нашего времени на исправление технического долга».

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

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

Если вы видите такие проценты как ответы на вопросы, то вы должны задаться вопросом: что мы потенциально заметаем под ковер, чрезмерно упрощая реальность таким образом?

Не путайте простоту с истиной.

PS обожаю моменты, когда нахожу уже написанные кем-то свои мысли.

#процессы

Интересный опыт, даешь интервью, беседуешь.
Бац и статья 🫣
Большое спасибо редакторам 🙂

https://habr.com/ru/companies/ncloudtech/articles/930320/

#management

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

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

У меня в командах открыто 2 позиции:

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

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

Если есть вопросы - велком ✍️
Заходите сами, советуйте друзьям 🙂

Немного кофейного сумбура в попытке помусолить вопрос в комментах: “Agile часто превращается в формальность, когда бизнес давит. Как думаешь, можно ли вернуть реальную гибкость?”
Можно, вопрос на каком уровне?
Хорошо получалось там, где все остальные процессы вокруг (или до/после) разработки тоже на Agile-рельсах. Я про собственно бизнес/организацию.
Но чаще всего разработка играла в agile, а вокруг был или суровый энтерпрайз или просто бардак (хотя со стороны того же бизнеса и в разработке бардак, всегда 😃).
В общем, нюанс в том, на каком уровне этот Agile начинался и заканчивался.
Ну и степень вовлеченности сотрудников во все это действо влияла. Увлеченных людей в принципе немного, по жизни, и когда компания хочет расти приходится выбирать между "качеством" людей и скоростью роста. И в этом месте начинается трение в одном из пунктов манифеста про "людей и процессы".
В целом, если посмотреть на пункты манифеста, то в каждом можно найти моменты, которые своими понятийными нюансами уже больше 20 лет будоражат “общественность”.

“Люди и взаимодействие важнее процессов и инструментов” - в этом месте как раз сильно влияет вовлеченность.
“Работающий продукт важнее исчерпывающей документации” - уже избитое “это что же, мы не описываем как принимали решение” и даже архитектуру не прорабатываем?
“Сотрудничество с заказчиком важнее согласования условий контракта” - ага, скажи это заказчику у которого заявленная функциональность не работает, а у него от сроков внедрения премия зависит или штраф за нецелевое использование средств, потому что продукт в эксплуатацию не введен.
“Готовность к изменениям важнее следования плану” - и рядом “стратегия на 7 лет” или “годовой роадмап с объяснительными в случае отклонения”.

Или, слышал недавно такую гипотезу, Agile был придуман для заказной разработки, когда мы делаем типовую работу, которую понятно, как оценивать. При этом же именно при продуктовой разработке “проще” вовлечь команды в работу: ты видишь, как влияют принимаемые тобой/командой решения на то, как продукт живет, развивается и продается.
Ахаха, ага, а продается он сейлами, которые любят продавать привычные для себя вещи и то, что нужно заказчикам (даже если этого еще нет в продукте). Че ты там в продажах увидишь - хз.

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

#процессы #ваши_вопросы

Не умирайте, везде важен баланс 🙂

Следует ли при разработке программного обеспечения действовать реактивно или проактивно?
Стоит ли взять за основу YAGNI или Hammock Driven Development? Стоит ли использовать только Agile или водопадную методологию?

Ответ: Это всегда смесь умеренного количества того и другого. Лучший способ сбить проект с рельсов — идеологически требовать приверженности той или иной стороне.

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

Если вы не планируете - вы умрете.
Если вы не отреагируете - вы умрете.

(с) отсюда от дяди Боба

#процессы

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

#мысли_вслух #management

Как часто вы слышите фразу "нужно выделить время"?
Теперь, благодаря пятничным #it_memes, у вас будет возможность ее визуализировать.

Как связаны стратегия и васаби?

The 5C Strategy Framework: Why Most Companies Suck at Strategy

ЗЫ ответ: они оба чрезвычайно редки
#strategy

И снова про наши мои любимые специализации и "профессии". Одну из самых любимых...

We should have just said: “Hey, developers should deploy their own code.” More than that—they should also be responsible for keeping it running. They should monitor it, respond to issues, and use their programming skills to automate deployments so they’re safe, repeatable, and easy for the team to use. Production-minded developers (who are part of the team!) should do a little extra work to make things better for everyone. This was the correct mindset—a necessary shift away from isolated ops teams managing production without developer participation.

When cloud services arrived, this shift became even more natural. Spinning up a server was no different than calling an API. Infrastructure could be programmed. It could be versioned. It could be tested.

But then we made a terrible mistake: we gave it a name—DevOps.

Suddenly, developers who were good at working with production systems were given a new title. And as soon as “DevOps engineer”

...

Originally, DevOps was about trusting developers with production. But modern DevOps teams operate on the belief that developers can’t be trusted with production

...

So what did creating a “DevOps” role actually get us?

It pulled production-minded engineers off their teams and stripped those teams of both the interest and the permission to manage their own production environments. We ruined the idea of DevOps by formalizing it.

P.S. Platform Engineering is the same story. In the words of Yogi Berra, “It's déjà vu all over again.”

Спиралька...

In retrospect, DevOps was a bad idea.

Ну и да, аргументов "за/против" такой специализации много: сложность и развесистость предметной области (уже даже среди девопсов есть свои специализации), рост компании и необходимость унификации внутри нее (как бы я ее не бухтел на нее) и тдтп. Все это неизбежно ведет к появлению новых "профессий".

Интересно, что нас ждет дальше?
Какие новые специальности уже наклевываются?

#holywar

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

"Багофикс в свежем деплое" в пятничных #it_memes

PS все совпадения с реальностью являются лишь плодом вашей фантазии

И снова про микроменеджмент.
Интересно про то, что это на самом деле не всегда плохо.
Но понятно, что это "это" у всех разное (см. прошлые мысли)

I’m not a micromanager, but I’m microinterested

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

#management

Прикольненько...
Ох уж эти AI-инновации в продуктах :)

Храните пароли/ключи в записной книжке на столе 😂

Любишь нанимать, умей и увольнять…

#менеджерские_пословицы #management

Начинаем неделю “с ноги”

Есть 3 большие категории технических менеджеров:
1 - те, для кого в управлении техничка первична и остальное можно игнорировать
2 - те, кто верят в правильные процессы
3 - те, кто во главу угла ставят людей

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

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

Без процессов (на людях и их договоренностях) работает ровно до момента интенсивного роста. Про это мы уже говорили: вовлеченных людей немного.

Без “люди - главное” может работать, но тогда процессы-процессы-процессы и все это обернуто процессами. И готовность к тому, что в процессах не предусмотрели, какую-то ситуацию и оно или остановилось, или ушло в сторону. Кстати, далеко не все вовлеченные люди могут и любят работать с процессниками и там где они потрудились.

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

ЗЫ Есть еще 4я категория, те кто верят, что умеют, в какой-то из способов. А на самом деле ни в какой не умеют.

#management #мысли_вслух@IT_without_miracles

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

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

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

Спонсор заметки: "новостная лента соцсетей" и определение "оракулы тестирования" (это была первая из прочитанных мной статей по теме ).
Тестировщики конечно в курсе (правда ведь? "мем с падме"), а остальным может быть интересно, добавить себе энциклопедических знаний 🙂

ЗЫ у меня есть универсальное определение на все, что не знаю: это "опыт и чуйка". Но не советую им пользоваться на регулярной основе.

#testing

Неожиданно (нет), но часто все, что вы думали придали сами, может быть придумано задолго до вас.

Here we deliberately alter the development team's organization structure to encourage the desired software architecture, an approach referred to as the Inverse Conway Maneuver

И вот это интересно

While the inverse Conway maneuver is a useful tool, it isn't all-powerful. If you have an existing system with a rigid architecture that you want to change, changing the development organization isn't going to be an instant fix. Instead it's more likely to result in a mismatch between developers and code that adds friction to further enhancement. With an existing system like this, the point of Conway's Law is that we need to take into account its presence while changing both organization and code base. And as usual, I'd recommend taking small steps while being vigilant for feedback.

ЗЫ но приятно, что ты однажды шлепая к метро, формулируешь, один в один, как Martin Fowler (ну ок, почти 😉)

ЗЫ2 но, обычно, никто про архитектуру не думает, а просто реструктурирует команды 🪄🙂

#it_философия

Когда инженер стал менеджером. Начало...

в пятничных #it_memes