В IT чудес не бывает

Когда на неделе уже 2ая пятница, нельзя не напомнить важное в #it_memes

Да просто чек-бокс не работает. Минорчик.
Починим в следующей версии.

Про "думать".

Всегда гордился умением все (ну ок, почти все) запоминать, быстро потом сопоставлять факты и тдтп.
Но “мыслетопливо” со временем похоже стало заканчиваться быстрее, чем накапливаться и приходится чаще записывать. Особенно, когда речь идет про одновременно идущие и долгоиграющие проекты, неважно в работе или в личной жизни.
Некоторые “бурчалки из метро” так и не появились тут в канале только потому, что я их не успел записать. Или записал тезисами в виде аналогии, типа такой “способы достижения качества - способы приготовления мяса - щуп для температуры”. Офигел потом, когда прочитал этот тезис… (но потом все же вспомнил, про что была мысль).
#мысли_вслух

Планируем и оцениваем лишь для того, чтобы потом было что “резать”.
Всегда умиляла история “вы сначала оцените, потом будем думать, будем это делать или нет”.
Какой смысл точно оценивать то, на что потом точно не дадут времени/денег/людей/инфры?
А если вдруг дадут, то почему сейчас не дают на то, что нужно вот прямо сейчас на другие задачи…
Эмоционально-риторические вопросы про #оценка

If you're thinking without writing, you only think you're thinking.
(с) Leslie Lamport

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

Трекинг и #оценка задач в часах:

1 час - "хорошо декомпозированная задача"
2 часа - "хорошо декомпозированная задача" + кофе + партия в кикер
3 часа - "хорошо декомпозированная задача" + кофе + партия в кикер + обед
4 часа - "че ж я такое делал сегодня? А, вот эту задачу"
8 часов - "от рассвета до заката что-то делал 2 дня, но задача в беклоге одна. Просто у нас встреч много"

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

Хотя на самом деле, что часы, что сторипойнты, что майки, что слоники - важна дисциплина в том, как ты подходишь к оценке при планировании и трекингу текущего прогресса.

PS смотри больше постов про оценку по хештегу #оценка

Чем больше думаю про качество и над вопросом, как его пощупать (кроме денег), тем больше прихожу к мысли, что мем “нормально делай - нормально будет” вполне себе дает подход с хорошим качеством на выходе.

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

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

Все остальное от лукавого. Скучно.

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

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

PS2 болеть плохо, всем читателям крепкого здоровья

Code coverage vs Code Quality

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

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

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

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

#quality #metrics

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.”

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

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

плюсую...

#it_memes

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

Product pitches should be delivered like a three course meal

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

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

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

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

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

И еще про метрики
"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

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

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

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

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

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

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

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

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

#григорич

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

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

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

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

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

#management

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

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

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

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

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

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

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

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

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

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