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

Ну а сами встречи 1:1- одна из практик, которая часто выставляется как обязательная, но редко проводится "по уму".

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

#management #ваши_вопросы

09.09
Говорят, сегодня день тех, кто профессионально не любит баги 🙂 Пусть ваша работа не перестает быть нескучной 🫣

10 признаков, что вы не подходите для работы тестировщиком:
1. Вы нервничаете из-за глючного ПО
2. Вы тестируете не зная ожиданий бизнеса
3. Вы устаете от объяснения того, как воспроизвести ошибку
4. Вы не читаете блоги, книги и не посещаете конференции по тестированию ПО
5. Вы стыдитесь своей роли в проекте
6. Вы знаете, как проверять, но не знаете, как исследовать
7. Вы не в курсе технических аспектов IT
8. Вы не любите общаться
9. Вы не знаете о жизненном цикле разработки приложений
10. Вы не можете забыть о найденных дефектах и страдаете, если их не исправляют

ЗЫ это вам немного романтики из прошлого... Эти советы давно уже игнорируются многими

#testing

Просто репост. База про то чем же они, млин, отличаются друг от друга :)

Logging, tracing and metrics are 3 pillars of system observability.

The diagram below shows their definitions and typical architectures.

ЗЫ подробнее в комментах

#observability

Хорошо, про то, как выделять время на "технику"

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

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

#процессы #мысли_вслух

Про аналогии

Из древних интернетов "Где та тонкая грань между "9 женщин не родят ребёнка за месяц" и "9 лесорубов срубят лес в 9 раз быстрее"?"

Всегда, когда вы пытаетесь придумать аналогию для описания какой-то истории или, кажется про то же, модель описывающую систему, вы должны понимать, что
1. это всегда упрощает и часто отбрасывает за пределы взгляда важные нюансы
2. Не всегда эта аналогия, хорошо применяемая для истории/команды/компании А, так же хорошо применима для Б

ЗЫ кстати, если лесорубы не договорятся, то лес может рубиться не так быстро, как может казаться в начале работ, а к концу леса лесорубов может стать меньше 9 (несчастные случаи, знаете ли)...

ЗЫ2 все выше написанное относится и к бест-практис...

По мотивам частых историй #все_крутые_компании_так_делают

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

А у вас уже началось годовые планирование и бюджетирование?

Самое забавное конечно, это сравнивать то, что планировали в прошлом году, с тем, что делали.
Или как быстро закончились выделенные квоты на инфраструктурные ресурсы для разработки (типа стендов).

🤣 о, в прошлом году меня чуть позже бомбило.

#байки

Про "забагованность"

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

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

Хороший рассказ, вылез недавно в напоминалках

"Ignite the Fire - How Managers Can Spark New Leaders"

"Leaders and management are going to act in an organization in fundamentally different ways... Leadership is working with goals and vision, management is working with objectives"

#management

Делал несколько заходов, хотел написать красиво…
Тьфу, это ж телега, много букоф никто читать не будет. Поэтому просто выгружаю мысли.
Был в комментах вопрос про то, как можно “мерять” качество. Оставив при этом за рамками определение “качества” (я тут немного пробовал потоптаться, но там с ним бесконечная история).

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

Нельзя посмотреть на циферки и сказать “теперь мы качественные”. Но можно взять некоторые циферки и начать размышлять, глядя на них.

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

В комментах упоминали DORA-метрики. Очень правильные метрики: ибо, имхо, например, скорость фикса (включая скорость его поставки) важнее 100% покрытия.

Редко анализируемая штука: стабильность автотестов.
Автотест грустные новости приносящий - это не гонец, которого надо убить (выключить из прогонов). Это повод к разбору, потому что “автотест моргают = в проде все будет моргать”. Хотя бы, потому что если мы не можем диагностировать проблему в тестовом окружении, то ровно то же самое будет и в проде. Шансы на то, что проблема в написании проверок, а не в продакшен коде, конечно есть. Но часто реальность может быть суровее.
Вообще писал когда-то про "что делать, когда автотесты зеленые". Но так как стабильные тесты - это фантастика, никто и не страдает этим вопросом 😂

Но это все про условно техничку и процессы. А что в реальном мире?

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

Качество для пользователя - это деньги 🙂
Зарабатывает продукт деньги - значит он достаточно качественный. Не зарабатывает - проблема может быть не только в его качестве.

#quality #ваши_вопросы

Про то, как число Данбара (Dunbar's number) можно учитывать в работе и даже в фичах своих продуктов.

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

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

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

PS еще один пост в копилку менеджерской нумерологии.

#management

Про жуков и их подсчеты
Очередным утром, собрав в баночку с бензином очередную порцию колорадских жуков с картофельной делянки, дед Григорич открыл свой ноутбук “Правда” и обнаружил в новостях статью про то, как одна известная компания, занимается учетом жуков, которых сначала разводят, а потом отлавливают. А так как бизнес требует учета и оценки эффективности тех, кто жуков разводит, и тех, кто жуков потом отлавливает, то компания предложила свой вариант того, как этот учет можно вести.
"И тут жуки… ' - с усмешкой подумал Григорич, наливая чашечку утреннего кофея.

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

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

Но мы отвлеклись, вернемся к нашему рассказу. Так вот, открыл Григорич свою “Правду“ за утренним кофеем, а там статья про ненавистный ему учет жуков…

“Тьфу, качество они меряют…Картошка целая должна быть, а не 100500 жуков собрано” - с философским сожалением подумал дед. Отодвинул чашечку, подвинул ноут ближе, зашел в соцсеть “НаЗавалинке” и решил побухтеть.

Продолжение когда-то следует…

#григорич

Иногда спрашивают, что я делаю на работе.
Обычно как-то так...

И да, со стороны это смешнее, чем на самом деле.
#it_memes

И еще про метрики
"Missed Targets / sometimes the best things aren't bright and shiny"

You’re on a team that is absolutely crushing the four key metrics. Lead time is measured in days, you’re deploying several times a day, failures in production are rare, and when there are failures, they are fixed quickly. Your manager brags to his peers constantly about how the team is “elite”.

But the metrics are lying, and the team is dying.

Your lead time is in days because you don’t start tracking items until they’re almost done. You’re deploying several times a day, but only minor or superficial changes, as everything else is in long-running branches. You don’t have errors in production because the team is afraid to report errors in production - instead they patch them quietly when needed. But hey - you’ve nailed the metrics.

Мда, где ж та грань между "вот вам гора показателей, контролируйте... о-п-па проблемка наблюдается" и "просто думаешь мозгами перед тем, как делаешь"... Или нет этой грани?

#metrics

- Кто зафакапил сроки и релиз?
- Тестировщики долго тестировали!
- У нас нет тестировщиков.
- Чёрт, такая хорошая отмазка, а не прокатывает!

Из архивов древних интернетов (с) Табличка “Сарказм” (glorphindale из завалинки X-твиттер)

Большие разрывы между релизами, отсутствие удобной возможности доставлять обновления/патчи/фиксы, нежелание заказчиков делать это обновление возможным - шикарное поле для бесконечной деятельности называемой "тестированием".
Которое, как и ремонт, нельзя закончить, можно только прекратить.

ЗЫ а, еще "сертификацию" забыл, тоже очень творческое мероприятие: из-за которой ищем все что можем найти и даже больше, ибо фиксы - очень дорого

#байки #мысли_вслух

Если поменять "product" на "feature" тоже неплохая (хотя до безобразия банальная) шпаргалка получается.
А то иногда сначала делаем, потом думаем "зачем".

Product pitches should be delivered like a three course meal

плюсую...

#it_memes

How We Can Stop Confusing Long Term Goals with Short Term Plans

Several of my clients want to plan the product roadmap and then “work to the plan.” They think the roadmap is the long-term goal.
But roadmaps aren't goals. Instead, they are tactics for achieving a long-term goal.

...effective strategy is never really “done.”

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

#развитие #стратегия

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

“Картошка жареная, отварная, пюре, картофель фри, картофель пай. Картофельные пирожки с мясом, с грибами и так далее. Картофельные оладьи, картофельная запеканка…” - бурчал Григорич, читая статью и попутно комментируя каждую из метрик в “НаЗавалинке”.

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

Ниже бурчание Григорича и ответы ему от Сергеича.

Метрика: "Количество заведенных и закрытых дефектов" - без понимания того, какой объем кода появился/изменился или какие задачи решали, бесполезная метрика. Но хороший маркер "обсудить".

Дед Сергеич: - Это про то фиксят или нет, объем кода вторичен тут. Хорошо стреляет на командах которые регулярно делают бизнес-рывочек.
Григорич: - Ну 10 багов на 100 строк и 10 багов на 1000 - это разные 10 багов. Не?
Сергеич: - Неа. Потому что модульность/микросервисы/кафка-мать-её-в-сраку и вот это вот все. Плотность багов на единицу строк кода тогда и сейчас - это арифметически одно и то же , а по природе разные вещи.

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

Сергеич: - Это ещё один маркер того, что команда тонет в бизнесовых задачах или успевает выгребать тех долг
Григорич: - или просто код херовый пишет :)

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

"Коэффициент ошибок, пропущенных на прод" - вот кажется, что полезна. А на самом деле скорее для ЧСВ тестировщиков. А польза зависит от модели использования: для SaaS (того софта, что сами менеджерим в проде) важнее скорость обнаружения/отката/зачинки. А вот для On-Premise (разворачивание в среде и силами заказчика) может быть интересна: скорость и возможность применения фикса ограничены.

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

Ответ Сергеича "Оно работает в паре - если ты на проде вылавливает больше Critical и Blocker чем на тесте - значит у тебя уже есть проблема."

"Распределение дефектов по категориям для теста и прода" - самая полезная метрика, но самая затратная: требует доп.усилий по классификации категорий, компонентов, коду и установки этого в самом дефекте. Будут просто забиывать, а если установка поля будет форсится, то ставить дефолт в джире или “от балды”.

"Время жизни дефектов, найденных на проде, по приоритетам" - норм

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

"Количество Acceptance Bug на задачу" - подсвечивает проблемные задачи: с точки зрения проработки и технического качества кода. Маркер для "обсудить"
__________________

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

Ну и не надо называть это “качеством” - пробурчал напоследок Григорич, закрыл ноут, снова взял баночку для жуков и пошел оглядывать картофельную делянку, которую не посмотрел с утра.
#григорич #качество #metrics

я гриб - релиз на проде погиб...

Пятничная #it_memes считалочка

Code coverage vs Code Quality

Покрытие кода - "сколько продакшен кода вызывается, когда запускаются автоматические тесты", очень популярная метрика, которой пытаются измерить качество кода, а скорее тестов, которые его покрывают.
Но давайте простой пример.
Есть функция, которая что-то делает и есть тесты, которые вызывают каждую строчку этой функции, что дает нам 100% покрытия.
Качественный код/тесты? А неизвестно.
Потому что в целом нам важно не только то, что функция сейчас делает, но и ответ на вопрос, а что она должна делать.

Передали, например, в нее NULL, который никак не обрабатывается и finita la commedia нашему 100% покрытию.

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

Итого:
• мерять полезно, работает в комплексе, используется для анализа изменений одного и того же кода/тестов на временном отрезке.
• сравнивать эту метрику для 2х команд между собой - херня.
• 100% покрытия не говорит ни о чем
• но, хорошее дополнение в комментариях, для динамических языков большой процент покрытия дает больше уверенности в том, что косяков меньше, чем могло бы быть
• покрытие кода даст вам количество, когда вам нужно качество

#quality #metrics