Есть такой способ передачи знаний, очень популярный в IT: фольклорный...

пятничные #it_memes

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

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

"...
Test Automation in 2024
Short story - it still sucks. In the last ten years, I’ve worked with a lot of development teams on improving velocity, and in every single case I’ve found that developers owning all test automation results in better tests, more testable code, faster deliver, and higher overall quality. Some of these teams don’t have dedicated testers, but on teams with dedicated testers, those folks do not write automated tests. They write tools to assist in testing or debugging, or work with the development team in order to improve testing knowledge across the team.
..."

(с) The "A" Word...revisited Alan Page

PS мои пару слов (10-летней давности) про The "A" Word

#test_automation #holywar

А кто-то у себя использует Zero Bug Policy?
Отличный подход, который позволяет сохранить беклог и голову в порядке. Меньше страданий от постоянно растущего количества багов, которые никто не фиксит, но которые постоянно фигурируют в отчетности, как "показатель зрелости продукта".

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

А ведь там все просто: если баг есть и мы оценили его как критичный - значит мы его берем и чиним, а не маринуем в беклоге. Если некритичный (или кажется таковым в настоящее время) - значит просто фиксируем проблему, обозначаем его как “won’t fix” и забываем про него до того момента, когда его критичность меняется (похожий запрос от клиента, новый сценарий эксплуатации проблемы и тдтп).

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

Статья по этой теме с рекомендациями по переходу на ZBP

#testing #процессы

А давайте еще про "законы/закономерности/принципы" в IT.

Самый популярный - это закон Конвея (Conway's law):

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

Иногда звучит в такой интерпретации:

"Don’t ship the org chart!"

Похоже на то, что у вас?

Подробнее по теме:
• The Most Powerful Law in Software
• Conway’s Law in Team Topolgies: Did you really get it? (кстати, там упоминается прикольный "лайфхак": "we should design our teams (not the software yet) to “match” the required software architecture. That means reconfiguring the team intercommunications before the software is finished.")

#it_философия

Продолжая тему "менеджер и техника".

Еще несколько советов оставаться в технике будучи менеджером: Should you Stay Technical as an Engineering Manager?

PS жаль, что мои самые любимые - самые неэффективные 😒
PS2 кстати, вопросы поддержания необходимого тонуса в технике касаются не только менеджеров 😉

#management #развитие

IT Global Meetup #16
23 марта в Питере. Молодцы, оживили.
Даже интересно, сколько участников будет.
PS я тот еще социофобушек теперь, но все может быть...

Философское пятничное #it_memes ное от Макса Дорофеева

#it_философия

Пересмотрел еще раз спустя 9 лет.
Он все так же хорош. Но тогда был прямо в ❤️
Очень рекомендую.

Вадим Макишвили, доклад "36"

Следующий его доклад ("42") мне не так хорошо зашел, но думаю и он нашел свою аудиторию.

#it_философия

Лидерство - это искусство разочаровывать людей с такой скоростью, которую они могут выдержать.

(с) "кому только не приписывают"

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

И еще один доклад Вадима "55", для руководителей.

Почему-то вспомнил про эту книгу "Общаться с ребенком. Как?"
Мысли пересекаются.

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

#management

What's a distributed system?
It's not microservices exchanging messages and storing data in a DB.

Небольшая шпаргалка-затравка по теме распределенных систем. Скорее просто для того, чтобы оценить масштаб бедствия в голове по этой теме перед столь любимыми многими компаниями собесом по System Design.
#tech_read

Девиз "успешных" людей в пятничных #it_memes

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

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

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

Я застал те времена, когда тестировщики в резюме писали "инженер по тестированию" и в вакансиях писали ровно это же.
Потом какие-то умники, глядя на "как там" начали активно форсить тему с QC, почти мгновенно переключившись на использование букв QA.

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

Потом та же история повторилась с DevOps (которые сначала просто админы с большими ЗП, а потом СИАЙ-админы и админа в КУБЕ). И снова раскрутка через вакансии и отражение в резюме.

Теперь вот та же фигня с цифрами по результатам в резюме, которая 100% пришла из резюме сейлзов/маркетологов и прочих продаванов.
Все рекрутеры теперь их ждут в резюме инженеров (и уж тем более инженерных менеджеров) и предлагают всем это использовать.
И все будут писать вот такую фигню, типа "разработал и успешно внедрил новую систему рекомендаций для e-commerce проекта, используя Python (Scikit-learn, NumPy, SciPy, PyTorch, Surprise), PostgreSQL, что позволило увеличить продажи на 15% за первые три месяца после запуска".

Что не так с такими циферками в резюме?
Есть риск попасть в анекдот "Это ребята курили. Я просто рядом стоял"
1. Если вы не знаете, как именно ваша работа повлияла на эти циферки - не надо это писать
2. Если вы не знаете, как эти циферки меряются - не надо это писать
3. Если вы не можете рассказать, сколько времени занял рост до этих циферок, сколько людей и как в этом участвовало - не надо это писать

И чем больше была команда - тем меньше вероятность, что это надо писать...

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

Примеры:
- обучил 100500 падаванов
- проработал изменение архитектуры, которое привело к ускорению (циферка), повышению RPS, повышение производительности и тдтп
- затащил новый подход к написанию тестов и скорость написания тестов увеличилась с X до Y
- ускорение выполнения тестов с N до M
- протащил проект изменений через X команд
- провел X собесов из них Y прошли испытательный срок (или заонбордил 100 чуваков)
- запустил 300 новых команд

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

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

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

Для тех, у кого могут быть вопросы, зачем такое в резюме в принципе.
Числа про деньги интересны с точки зрения:
1) косвенно показывают, что инженер знает про то, как меняются бизнес-метрики его продукта
2) можно предположить, что насколько человек вовлечен в культуру product engineering

#собеседования #про_резюме

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

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

"Roast Beef and Legos" by Alan Page

#it_философия

Лет 5 назад подсмотрел у Киры Кузьменко 2 лайфхака на тот случай, когда "текст никак не пишется” (она в свою очередь тоже откуда-то взяла, но те ссылки уже "мертвые"):

1. "...если не пишется и страх чистого листа. С 2008 года практикую: надо просто начать с "ну бля, короче..." — и дальше текст сам выстраивается без воды и вот этого всего."
2. Тексты не пишутся по вдохновению, да и дождаться его иногда месяцами невозможно. (...) Трудно, как говорят редакторы, только первые двадцать минут. Правда, эти двадцать минут приходится переживать несколько раз в день.

Моему блогу уже больше 12 лет, почти 250 заметок. По лайфхакам: оба рабочие. Но мне всегда нужен какой-то триггер, а самое главное: глобальная цель, типа нафига это все.
Многие рекомендуют писать по расписанию, типа дисциплинирует. Но у меня такой вариант только в телеге работает, и то, только потому, что я достаточно часто просто закидываю ссылки без своих букв.
#байки

В статье Алана есть интересная аббревиатура: TTWWADI.
А явной расшифровки нет, пришлось гуглить.
That’s the way we’ve always done it - вот что это значит.
И понятно, что это проблема не только IT.

#it_философия

"20% теории управления достаточно для 80% результатов. Если конечно принцип Парето работает" Ryan Lilly

Вся мякотка в том, что далеко не все менеджеры знают и 5% этой теории. А если и знают, то не используют.

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

Есть ложь, наглая ложь и "тут всего пара строчек, оценю задачу в половину сторипоинта" (байки из интернетов)

#metrics #байки

Результат #codereview на 50 строк vs 100500 строк

Сделал дело и идешь смотреть пятничные #it_memes

В четверг в комментах обещал побухтеть про оценку.
Мое определение оценки:
“Процесс в рамках которого, мы разбираемся, что от нас ждут, что нам для этого надо сделать и в каких частях нашего приложения, какие у нас зависимости, готовы ли они к нашим задачам, какие риски и тдтп. А "оценка времени" - это лишь один из артефактов процесса оценки.”

Я тут не хочу писать подробности про сторипойнты (попугаев, слоников, чашки кофе, размеры маек), планинг-покер и тд. Очень много инфы по этой теме.

Тут будут просто советы, а завтра про собственно процесс, как я его вижу.

1. У всех, кто участвует в процессе, должно быть одинаковое понимание того, что именно они оценивают и с какой точностью эта оценка делается (подробнее смотри совет 1 отсюда )
2. Важно понимать, что ошибки оценки все равно будут. И поэтому должны быть:
• процесс работы над этими ошибками (расширяем базу знаний и подходы для следующих оценок) с тем, чтобы в следующий раз оценка была точнее
• процесс информирования о возникающих из-за этого рисках (не тянем до последнего)
3. При запуске/перестройке процесса оценки очень помогают эталонные (референтные) задачи, сравнивая с которыми мы пытаемся оценить наши текущие задачи
4. Оценка в сторипойнтах - это в том числе способ избежать необходимости точной оценки: когда оценивается, например, в часах, сразу возникает ситуация, когда было запланировано например 3 часа, а задача сделана за 3.5.
Это хорошая оценка или продолб? А 4 часа? А как это время измерялось и что в него входило?
5. Не бывает “копеечных” задач. Вообще не используйте это обозначение. Оно мешает запускать в голове комплексный процесс оценки задачи, зато помогает забыть про важные вещи.
6. БОльшая декомпозиция помогает точности оценки
7. Постепенный уход в сторону простого кол-ва задач, тогда можно просто считать кол-во задач и меньше думать про их оценивание.

Кстати, в очередной раз “эффект инфополя”: пишу заметку, а в рассылке в пятницу пришла хорошая статья по теме оценки.

И еще тут у меня было про этой теме.

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

#процессы #оценка

Если оценку задач делает не "специально обученный быть крайним человек" лид, а решение принимается на командной встрече, то предлагаю такой вполне рабочий процесс:

Работу над оценкой задач на следующий спринт начинаем в текущем спринте.
Встреча 1 (30-45 мин):
• смотрим на ожидаемый список историй/задач (формирует PO исходя из целей спринта, но возможно участие команды, особенно по техническим задачам)
• определяем задачи, по которым недостаточно информации для их оценки (по остальным сразу делаем оценку)
• у каждой такой задачи появляется ответственный, который до проведения следующей встречи собирает нужную для оценки информацию (корректность проработки, место(-а) в коде, которые надо изменить/дописать, синхронизация со смежной командой и тд) и делает на базе этого предварительную оценку* (см дальше пояснения)

Встреча 2 (30-45 мин), лучше через неделю после первой:
• каждый ответственный рассказывает про свою задачу
• информация обсуждается
• делаются итоговые оценки
• обсуждаются вновь прилетевшие (с момента встречи 1) задачи, которые хочется затащить в спринт. Если нужно, то по ним тоже запускается работа по их оценке

Встреча планирования спринта (15 мин**):
• если за время после 2й встречи ничего нового не прилетело, то в спринт просто берутся задачи согласно текущей “скорости прожевывания сторипойнтов” (ака velocity) и их приоритетов
• если что-то прилетело и оно важно, то это обсуждается уже на планировании. Но лучше бы конечно это все же сделать предварительно, иначе оценка будет скорее “пальцем в небо”.

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

*По опыту, самая холиварная тема - это “а как я буду что-то ресечить, если у меня куча задач по текущему спринту?”. Все просто - время на ресеч “закладывается” при планировании через анализ текущей скорости прожевывания сторипойнтов командой. Речь не про то, что этим надо заниматься по ночам. Для трепетно относящихся к учету времени для такие ресечей на оценку можно заводить задачи с фиксированными значениям сторипойнтов.
** вторая по популярности тема "это ж нафига столько встреч?"
Ну, во-первых, суммарно по времени получается не больше, чем одна большая встреча планинга (где большей частью все "играют в покер", а не планируют). Во-вторых, обычно в этом случае мы получаем более осознанную и точную оценку, часто выясняются неочевидные вещи, требующие дополнительного ресеча и задача в этом случае просто не берется в работу в текущий спринт. Что, в конечном итоге, тоже экономит время. Ну и в третьих, первую встречу вполне можно проводить "заочно" и асинхронно.

Почему такой процесс редко можно встретить в реале? :)
Да фиг его знает, я ставлю на "лень-матушка раньше нас родилась...". Всегда ведь проще погадать на планинге не делая предварительного исследования.

#процессы #оценка