Серия статей про полезные практики и подходы в тестировании микросервисов https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/
#testing #tech_read

Вчера обещал про календарь разработчика.
Спойлер: тут без чудес, рекомендации те же, что и менеджерам.

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

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

Что туда может входить?
- всеми любимые Scrum-активности (независимо от реальности, все свои процессы в 99% называют Scrum, так принято, не будем нарушать традицию) по некоторым оценкам могут занимать суммарно от 2х дней в 2 недели
- встречи для обсуждения технических моментов со смежными командами (тут частота зависит от степени желания что-то обсуждать, некоторым "проще" потом переделывать)
- собесы (кому не везет у тех по 3-4 собеса в неделю, по 1-1.5ч каждый)
- если повезет, то будут 1:1 с лидом/менеджером (если совсем повезет, то раз в 2 недели)
- партия в кикер или плойка
В итоге, иногда, на собственно работу (написание/ревью кода, прогон тест-кейсов и тд) может оставаться по 3-4 часа в день.

Много это или мало? Тут как посмотреть: иногда качественно проведенная встреча с другой командой может привести к тому, что вам и кодить/тестить ничего не придется.
Scrum-активности тоже могут занимать немного времени, если просто начать там делать ровно то, ради чего они придуманы. К примеру Daily Scrum (как правильно называется то, что часто называют standup) может заканчиваться за 5 мин, если фокус не на перечислении каждой задачи, а на обсуждении проблем достижения цели спринта. Ну и тд.

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

The Architect’s Blueprint: Understanding Software Styles and Patterns with Cheatsheet
https://medium.com/bytebytego-system-design-alliance/the-architects-blueprint-understanding-software-styles-and-patterns-with-cheatsheet-5c1f5fd55bbd
#tech_read

И еще немного про встречи из анналов истории :)
#it_memes

Рубрика "Вопросы из зала"
Как взращивать инициативу?
Инициатива это про самостоятельность, вовлеченность и в какой-то степени ответственность. Поэтому:
- в команду должны входить цели, а не то, как их достигать
- слушать людей (про то, что они должны хотеть вам что-то говорить, про доверие, можно обсудить отдельно)
- давать им возможность реализовывать свои идеи (с вас время, ресурсы)
- давать ошибаться (цена ошибки регулируется вами, в этом сложность, но без этого никак) Ну и если вы приняли/одобрили решение, то и отвечать за ошибку надо самому
- можно обсудить условия, при которых команда самостоятельно принимает решения, без привлечения "высших" сил (больше самостоятельности + см.коммент про ошибку)
- искать увлеченных и поддерживать культуру вовлеченности. Вообще это заразительно, главное поддерживать энтузиастов
- собеседование новичков должно включать в себя оценку этого скила
- оценка инициативности должна стать одним из пунктов перформанс-ревью, если оно проводится
- ваши ожидания от людей должны быть для них прозрачными, но не должны остаться лишь словами
- делитесь с ними проблемами (с фильтром конечно) - это расширяет контекст и "провоцирует" на активность мысли
- хакатоны и тп подобные мероприятия скорее помогают, но я не фанат этого действа, хотя по сути это возможность направить часть нерастраченной креативной энергии, если на рабочих проектах "легаси", "жесткие сроки" и тому подобная реальность. Но кажется, что это лукавство со стороны компании ;)

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

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

#ваши_вопросы #management
Интересующие вас вопросы можно задать в комментах под сообщениями или в личку. "Редакция" всегда рада поделиться опытом или поразмышлять над возможными ответами, если такого опыта еще не было :)

С Днем знаний всех.
Знания - это то, чего постоянно не хватает, это то, что нужно постоянно наращивать. И да пребудет с нами сила.

Интересный вопрос (часто возникает в той или иной формулировке):
"Качество ПО - это ответственность команды". Но почему-то разработчики не хотят тестировать продукт (когда надо)? И писать автотесты (когда надо)?

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

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

Что происходит в реальной жизни?
Разработчиков не учат тестированию. Более того, популярно мнение, что это вредно. Я однажды уже комментировал это . (Уже стесняюсь писать про то, сколько лет назад это было, но мало что менялось с тех пор).

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

Можно долго мусолить тему "разрабов в тестировании", но реальность такова, что только руководитель разрабов определяет, участвуют они в тестировании или нет, а если участвуют, то как именно.
Поэтому если вы, как тестировщик, имеете вопрос "почему разрабы не тестируют", то задайте его их руководителю. Что делать, если этот вопрос возникает у руководителя, мы обсудим позже, хотя кажется, что ответ очевиден.
#testing #holywar

Софт-скилы под давлением временем только твердеют и замещают собой старые хард-скилы, которые превращаются в песок - путь менеджера
#мысли_вслух

Мне очень нравятся DORA метрики. Это хороший инструмент для оценки качества DevOps-процессов. И хотя изначально (в лоб) он больше подходит для тех проектов, которые можно обозначить, как "self-coded + self-hosted", все метрики можно замапить на любые типы проектов и типы релизов. Вот пример того, как это можно сделать для мобилок.
PS грустный факт: я нечасто участвовал в собеседованиях DevOps-ов, но за все время не могу вспомнить, чтобы кто-то из них знал эти 4 буквы DORA.
#metrics

"...давать ошибаться..."
Кстати, про ошибки.
Все делают ошибки. Ошибка - это нормально, это в целом даже ожидаемо. Ненормально ничего не делать после того, как ошибка произошла, считая что "ошибка - это нормально".
И под “делать” я тут понимаю не “кару небесную”, а нормальную работу над ошибками: понять причину, неочевидные следствия и шаги по их устранению, а также нужные исправления для того, чтобы уменьшить шанс на повторение ошибки и/или снизить ее цену.
#мысли_вслух

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

А если мы говорим о менти, который хочет получить совет, то лучшее по этой теме было тут "Instead of looking for a mentor, just find somebody who can answer some questions you have. Then, if you think they can answer some more, ask them again. In reality, a mentor is mostly just somebody that answers questions more than once."

Ну а я постоянно следую этому совету
"If you want a mentee - get good at something and make yourself available to answer questions about it"

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

#развитие

Тут вчера в тви меня по касательной зацепило бурным обсуждением на тему тим/тех-лидов (ссылка не на оригинальное сообщение, а фактически на начало треда). Изначально все началось с того, сколько времени тимлид тратит на кодирование, а ушло в спираль рассуждений про сам концепт тимлидства.
Как это часто бывает в интернетах, "рубилово" было достойным, но немного грустным от того, что оба автора были в чем-то правы, но не могли услышать друг друга :)
При этом я полностью солидарен с тем, что если тимлид успевает тратить 80% своего времени на код, то скорее всего он не тимлид.
Но фишка в том, что ожидания от лидов везде разные. И, не зная этих ожиданий и контекста их применения, сложно выносить однозначный вердикт.

Как я для себя формулирую ожидания от Team Lead / Tech Lead:

Team Lead:
• фокусировать
• вдохновлять
• растить
• коммуницировать
• воспитывать
• поддерживать
• оценивать производительность команды
• выявлять внутренние проблемы в команде на ранних стадиях
• решать конфликтные ситуации
• контролировать внутренние процессы разработки
• организация ретроспективы

+ добавляется то, что обычно делает или Tech lead, или эти активности размазываются по другим людям в команде:
• разработка (программирование или тестирование)
• соблюдение регламентов
• декомпозиция задач
• code review
• техническое воспитание новичков
• принятие решений в рамках тех технологических решений и стандартов, что есть в компании
• участие в архитектурной(-ых) группе(-ах)
• контролировать технический долг
• участвовать в отборе кандидатов, включая собеседование
• изучение индустрии

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

Чем Team Lead в этом случае отличается от Engineering Manager?
Распоряжением бюджета (планирование/расход).

Чем Team Lead отличается от Scrum Master (правда ведь весьма похоже по ожиданиям?). У SM фокус на скраме, поддержанием его культуры, ценностей и тп. Но, если коротко, далеко не везде у нас есть скрам, уволить сотрудника скрам-мастер не может (хотя тимлид тоже не всегда 😉) и за работу команды в итоге отвечает Team Lead.

Вообще вопрос не нов. И у меня тоже есть немного букв про эту таинственную роль с полезными ссылками по теме внутри.
#процессы #management

Один из самых неожиданных вопросов, который пришлось услышать на проходивших у меня в прошлом году собесах: "как вы будете мотивировать людей, которые не хотят работать? Они приходят только деньги получать".
Но самое грустное, что это не тренировочный кейс, это то, с чем пришлось бы столкнуться (по словам собеседующих), “потому что, давайте будем честными, хотя вы и можете обеспечить вовлеченность сотрудников, вы не можете замотивировать их. Это происходит изнутри.” (Do Managers Really Have Power Over Employee Motivation?)
А в целом, не демотивируйте, чтобы потом не мотивировать - это самое простое обычно. Это то, с чего стоит начать. Частично, то что может демотировать, мы уже обсуждали.

#байки #management

Сегодня же пятница. Хватит серьезного контента на неделю.
Обещал вчера ролик про то, как это "просто" - научиться писать автотесты.
PS простите, тут все взрослые, а детям закройте глаза на последнем кадре.
#it_memes #тестирование

Немного прагматизма.
Менять людей сложно, иногда проще их поменять, как бы это странно и цинично не звучало. Но если не улучшать процесс собеса и онбординга, то ничего хорошего не получится.
Собеседование - один из важных инструментов взращивания нужной вам инженерной культуры и экспертизы в команде: вы не должны забывать оценивать на собесе то, что вам ценно/важно. И это скорее всего не только харды.
Немного моего творчества про собесы:
• Нетехническое собеседование - зачем, полезные вопросы
• Немного про наём, собеседование и испытательный срок от вашего КО
• "Вкусняшка" для менеджера программистов или лучший момент в работе менеджера
• Обычные и не очень вопросы к собеседованию на позицию Engineering Manager

#management #процессы #собеседования

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

Тема оценки предстоящих работ постоянно в топе инфоленты, потому что все стараются, но мало кто попадает: потому что это сложно или долго.
Estimation Isn’t for Everyone одна из свежих статей на эту тему. Забавно, что там 1:1 повторяются мои мысли про усреднение оценки на периоде времени, что дает возможность перейти просто к количеству выполняемых задач для измерения скорости команды.
А время по оценке каждой задачи в отдельности правильнее тратить на то, чтобы понять, что именно нужно сделать и эксперименты. Поэтому что именно это уменьшает неопределенность и снижает риски.

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

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

Давайте сегодня сдуем пыль со старой статьи-перевода (я начинал вести свой блог делая переводы интересных статей, добавляя свои мысли по ходу).
Кто такой хороший тестировщик?
Статья была какое-то время очень популярна (по статистике). Что изменилось с тех пор? Имхо - ничего. Классика.
ЗЫ Только ссылку на оригинал пришлось поправить, потому что старая умерла.
#testing #классика #развитие

Рубрика "Вопросы из зала"
Как руководителю обучать руководителей?
Disclaimer: реального официального опыта быть менеджером менеджеров у меня нет, дальше просто мои мысли и идеи, подтвержденные лишь по касательной. Короче, как бы делал я. В подписчиках есть большие руководители, надеюсь они дополнят, поправят. И конечно, речь ниже про IT менеджеров.

Когда-то очень давно, когда я стал в первый раз менеджером, один очень близкий мне и мудрый человек сказал "самое тяжелое - это научиться управлять первыми 5 сотрудниками, дальше уже просто." Я тогда удивился, но сейчас понимаю, что это так и есть. Во всяком случае, если все без экзотики с прямым подчинением 40 человек. Был у меня такой опыт.

Итак, как обучать руководителей? Хмм, да кажется проще, чем инженеров, потому что нужно научить тому, что, по идее, уже знаешь и делаешь сам. А если не знаешь - научиться вместе 🙂

Регулярные задачи и активности у подчиненного руководителя сильно пересекаются с твоими текущими или ты ими занимался недавно.
Проведение собесов/отбор, 1:1, формирование команд, планирование и работа с рисками, бюджетирование (😭).
Ты же сам все это уже умеешь? Делись опытом, спрашивай, слушай (больше, чем говоришь сам), направляй в нужную тебе сторону, поддерживай правильные действия.
Если есть сомнения в своих педагогических навыках, организуй обучение на специализированных курсах, посещение конференций. Только важно потом обсуждать увиденное/услышанное/изученное.

Самое сложное, пожалуй, это оценить, как это все применяется твоим сотрудником на практике.
Но это уже тема отдельного разговора.

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

Традиционный пятничный мем.
Картинка 10+ летней давности. Тогда прямо в тему. Сейчас, хочется уже верить, не совсем. Но все равно, улыбает.
PS или все так же? 🫠
#it_memes #тестирование