Примеры неправильного использования DORA-метрик:

1. Фокус на DORA-метриках вместо бизнес-показателей компании/продукта
2. Сравнение метрик 2х команд между собой, вместо того, чтобы отслеживать их изменения для одной команды
3. Неверное толкование и понимание метрик.
4.Фокус на количественных значениях метрик в ущерб удовлетворенности инженеров
5. Культурное несоответствие между тем, что и как декларируется и что на самом деле применяется в процессах

И есть у меня ощущение, что это можно отнести ко многим метриками и процессам их запуска...
#metrics

Что общего у морского огурца и архитектуры ПО?

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

Григорий Петров: "Изменяющиеся требования — проклятье индустрии"

#tech_read

А что такое архитектура ПО на самом деле?

"Software architecture is about the significant design decisions, where significance is measured by cost of change"

Simon Brown "Software Architecture for Developers"

Очень откликается это определение. Весь вопрос в том, как это все описано.

#tech_read

А как же эту архитектуру ПО лучше описывать?

The Ultimate Guide To Software Architecture Documentation
• Why should we document software architecture?
• How should we structure software architecture documentation?
• How should we visualize software architecture?
• How do we write and manage software architecture documentation?

Еще полезного из прошлых постов:
• Про полезные практики фиксации принятых решений по реализации фичей.
• Как принимать архитектурные решения?

#tech_read

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

#it_memes

“Тестирование никогда не покажет того, что ошибок нет. Только то, что они есть.”

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

Поэтому тут без ссылки на автора, вдруг потом мне припишут 🫠
#мысли_вслух #testing

Да будет срачик.

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

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

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

Или "мы не продумали архитектуру". Да не можете вы продумать архитектуру навека, у вас требования к продукту меняются каждые полгода. Все что можно и нужно попытаться "продумать" - это то, как быстро менять реализацию. А быстро - это только с тестами получится, но на них часто забивают (времени много ведь занимают)...

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

#holywar

"Разрабатываем без нянек" (с) или как минимизировать участие тестировщиков в вашей работе

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

#классика #testing

И вроде уже далеко не в первый раз, но каждый раз он удивляет...

#it_memes в картине "Релиз - ты умеешь удивлять"

What we talk about when we talk about ‘root cause’

Автор пытается ответить на вопрос о причине использования этого термина? Почему мы применяем его только в случае проблем, но не успеха?

“There is no root cause. The problem with this term isn't just that it's singular or that the word root is misleading: there's more. Trying to find causes at all is problematic...looking for causes to explain an incident limits what you'll find and learn. And the irony is that root cause analysis is built on this idea that incidents can be fully comprehended. They can't. We already have a better phrase for this, and it sounds way cooler: it's called a perfect storm. In this way, separating out causes and breaking down incidents into their multiple contributing factors, we're able to see that the things that led to an incident are either always or transiently present. An incident is just the first time they combined into a perfect storm of normal things that went wrong at the same time.”

....

A challenge for readers and listeners
I’ll offer a few questions to consider the next time you read or hear the term ‘root cause’:

• What is the author (or speaker) trying to convey by using the term?

• What agenda(s) might the author (or speaker) have in their version of the story, other than providing the richest description they can?

• What else can you imagine is influencing the outcome of the story being told, besides what is deemed the ‘root cause’?

• What details seem to be noticeably absent in the story you’re being told?

• What questions can you imagine being dismissed or discounted by the storyteller, if you had the chance to ask them?

Questions like these are garden-variety critical thinking exercises. But they might help us explore what the story doesn’t tell us, or what might be missing in the story.

#процессы #it_философия

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

#мысли_вслух из древних интернетов...

Сначала не поймет, а потом как пойме-е-е-т. Но это неточно. И потом это будет уже совсем другая история.

Хотя есть и другая версия, версия тех, кто верит, что с тестами быстрее и в каком-то смысле дешевле.

#test_automation

Есть тут менеджеры с хай-перформерами? Как вы их, менеджите или не менеджите?

OK, but how do I manage high performers?” The answer is simple — you don’t!

These types of people need rock-solid communication, a good framework of rules and boundaries and your trust, a lot of trust. They will manage themselves as long as they understand the expectations.

vs

Manage Them!

Weak managers let high performing reports do whatever they want.

PS на самом деле статьи пересекаются по идеям, вопрос лишь в том, что понимать под "менеджментом".
PS2

there’s no such thing as a “high performer”, only people who are high performing at a given time. “High performer” is used as a shorthand for “people who are currently performing exceptionally well in their role.”

#management

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

#мысли_вслух из древних и забытых интернетов

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

#management

Примерно так выглядит Confluence любой конторы старше 5 лет. (сперто)

#it_memes

No Wrong Doors.
Про культуру коммуникации и направление/корректирование информационных потоков.
Очень часто наблюдаю истории аналогичные первому примеру из статьи.

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

#процессы

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

чужие #мысли_вслух

А ведь что-то в этом есть...
И это правда еще и потому, что начинать что-то менять, если сейчас типа все неплохо - это капец, как трудно. Типа "а нафига?"

С другой стороны, "и так хреново, еще и эти изменения...". Можно и не вытянуть. В этом месте и времени важна поддержка команды, руководителя.

ЗЫ я вот иногда(?) занудничаю в последнее время(только ли?) в таких ситуациях и может даже мешаю...

#рефлексия_без_гуглежа и чудес

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

М.Болтон 2016

Я уже писал как-то , что у меня есть фразы-триггеры.
Так вот "это не баг - этого не было в проработке", тоже одна из них...

Напомню, про возможные причины ошибок было тут:
- сделали, но ошибка в коде (или настройках среды и тд)
- сделали, но не то, что ожидалось
- даже не делали, так как этот сценарий не предусмотрели
- ошибка во “внешнем” коде (open-source)

#quality

Принес я вам сегодня чудесную историю, написанную уже очень давно, но все так же актуальную.

Это #классика с "много букв", так уже никто не пишет, и она прекрасная..

Про автоматизацию, тестировщиков, качество и вот это все…

“Good enough” так “good enough” (https://testitquickly.com/2013/06/03/good-enough/)

PS Кстати, пошарьтесь по статьям Алексея, это самые "вкусные" статьи на русском про то, что можно назвать "теорией тестирования".

#quality