Самая известная структура компании (модель масштабирования) имени компании: Spotify model.
Многие до сих пор пытаются внедрить то, что рассказывал Книберг в 2014 не особо вдаваясь в детали, причины и подноготную этого устройства. А между тем в Spotify уже давно все не так, как все привыкли себе представлять. И сложности ровно такие же, как у нас всех: менеджмент, синхронизация команд, развитие людей.
И неважно как у вас называются команды, их менеджеры, как команды объединены, важно как в работе учитываются эти моменты:
•Поставка ценности – все улучшения системы следует проверять, задавая вопрос: помогает ли это улучшение/эксперимент нам обеспечить ценность?
•Обеспечение ценности продукта – требует проведения экспериментов и выяснения того, что работает для реальных конечных пользователей.
•Автономия важнее управления и контроля – без автономии невозможно обучение, совершенствование, инновации или способность адаптироваться к меняющимся обстоятельствам.
•Синхронизация — вместо того, чтобы указывать людям, что делать как с функциями продукта, так и с архитектурой продукта, сосредоточьтесь на том, чтобы команды согласовывали свои планы с общей целью продукта.
•Кросс-функциональные продуктово-ориентированные команды (фиче-тимы) — вместо функциональных команд (база данных, бизнес-логика, пользовательский интерфейс).
•Инженерная культура, ориентированная на обеспечение качества и простоты: создайте конвейер непрерывной поставки, который позволит командам создавать ценность независимо друг от друга. По сравнению с конвейером, который требует ожидания, пока команда DevOps выполнит развертывание. Во многих организациях DevOps — это команда, следующая за функциональной командой, которая развертывает приложение. Это известный антипаттерн.
•Психологическая безопасность – ключевым элементом дружелюбности к эксперименту является создание среды, в которой мы можем признать, что рискуем и извлекаем уроки из этого процесса. Причудливое название этого явления – «психологическая безопасность».
•Постоянное совершенствование как особенность системы: команды никогда не перестают совершенствоваться. Нам необходимо создать культуру, которая будет способствовать такому мышлению.
•Моральный дух – готовность и настойчивость членов команды работать ради общего блага.
•Улучшение потока работы через систему — инструменты включают ограничение незавершенной работы, перекрестную профессиональную переподготовку и устранение узких мест. Вы можете измерить успех этого как с помощью Cycle Time и Lead Time.
Что еще почитать:
Spotify doesn’t use “the Spotify model” and neither should you.

#процессы

Если вы хотите быстро улучшить результаты тестирования, замените «проверить X» на «ищите проблемы, связанные с X» М.Болтон
#мысли_вслух #testing

Период активного внедрения Agile/Scrum (для многих это до сих пор синонимы) в работу IT-команд совпал с моим становлением, как менеджера. И уже тогда у меня были вопросы “нафига нужен Scrum Master, если есть лид?” Ну то есть, чтобы что? Почему лид не может делать то, что ожидается от SM?
Версий было много, правильного ответа до сих пор нет (у меня нет, у теоретиков наверное есть). Есть только предположение, что далеко не каждый человек получивший менеджерские лычки и соответствующие полномочия сможет выстраивать в команде процессы, самоорганизацию и тп без подключения “дубинки” полномочий. А у SM какие полномочия? Только тру лидершип (чистое лидерство). И каждый вертится, как умеет...

И вот, не прошло и 20 лет, ты-дынц “Вашим следующим Scrum Master должен стать ваш менеджер”.

#management #процессы #байки

В этот раз тег #holywar сразу в заголовке: можем ли мерять продуктивность?
Один из моих любимых вопросов на собесе: в чем разница между производительностью и продуктивностью. Обычно обширное поле для рассуждений.
А эта короткая старая статья в свое время похоже заложила фундамент того, что я сейчас понимаю под эффективной работой и сеньорностью. Это понимаешь только спустя годы :)
There's No Such Thing As Software Productivity
Тезисы:
• Разработка ПО не является деятельностью, которая обязательно производит что-либо
• То что делают хорошие разработчики - они устраняют проблемы
• Ты не можешь измерить разницу продуктивности между хорошим и плохим разработчиком потому что там нет ничего, что можно измерить
• Если мы смогли решить проблему, вообще ничего не создавая, то все, что мы на самом деле производим - деньги на ветер

PS рубрика "листая дневничок": это я наткнулся на свою запись в блоге про эту статью.
PS2 А хорошо, до сих пор хорошо: "Добавить нечего. Надо просто вбить себе это directly в мозг! Лучше гвоздями." (с) Шульга

#metrics #it_философия

Тестовые окружения для слабаков. Пацаны тестируют в проде
#it_memes #testing #тесты_в_проде

Закон Парето (он же принцип 80/20):
80% результатов возникают из 20% причин, а 80% результатов возникают из 20% усилий.
Примеры из IT:
• 80% пользователей используют только 20% фичей
• 80% багов находятся в 20% кода
• 90% падений происходит из-за 10% ошибок
• 80% времени на фикс багов приходится на 20% от всех багов
• 80% изменений делается в 20% кода
• 80% кода пишется за 20% времени, оставшиеся 20% кода пишутся за оставшиеся 80% времени
Подробнее со ссылками на пояснения (не все уже открывается по ссылкам из статьи, но гуглится, при желании)

80% постов читают только 20% подписчиков 😃
#it_философия

"На каждом проекте, как ты его ни планируй, рано или поздно наступает фаза «Херачим!»" (c) чье-то из интернетов 2014
#мысли_вслух #it_философия

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

Немного рефлексии.
Что такое стратегия?
Посмотреть интернеты, доклады, книги - везде все вроде похоже, но понимание у всех все равно разное.

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

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

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

В комментах хорошая картинка про хорошую/плохую стратегии.

Продолжение следует...
#it_философия #байки #стратегия

Сегодня тоже про стратегию, но нескучно, потому что автор не я.
"В жизни каждой организации неизбежно наступает период когда менеджеры в ней превращаются в стратегов.
Менеджер становится стратегом не сразу, не в один день.
Менеджер делает какое-то дело, его люди делают это дело.
Дело даже получается, так может повторится даже несколько раз.
Люди у менеджера учатся, проявляют инициативу.
И в какой-то момент менеджер понимает, что ему больше не нужно делать менеджерскую рутину. Что он может подумать о ней… о стратегии.
Стратегия, сука, непонятная.
Она вроде бы и есть, а вроде бы и нет. Вот с тактикой все просто - взял кусок работы, нарезал на спринты, ходишь на стендапы, решаешь проблемы команды, получаешь результаты и обратную связь.
А со стратегией все сложно - ты ее подумал, обсудил, проговорил с людьми. Может быть даже записал на бумажку и придал ей официальный статус.
Но ее нет. Физически ее нет.
Поэтому стратегу нужно, конечно, подумать эту вот самую стратегию, обсудить ее, проговорить ее и ... идти выполнять. Самому.
И тут собственно и наступает тот самый критичный для менеджера момент - кто-то может отвернуться (пусть и на время) от этой бездны стратегии, и пойти обратно в окопы, а кого-то засасывает эта метафизическая бездна.
Это конечно идеализированная картина мира, где только черное и белое, но (!!!)- конченых стратегов нужно отстреливать!" (с) Никита Макаров
#it_философия #стратегия

Ну и стратегично-пятничное, знаменитый анекдот про стратегов
#it_memes #it_философия #стратегия

Закончим страт-рефлексию одной из лучших подборок материалов по технической стратегии.
Если уж кому повезет ею заниматься, будьте готовы.
https://lethain.com/strategy-notes/
Ну а дальше, весьма традиционно: "пни вперед - комбинация придет".
#management #стратегия

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

Аншлаговые были статьи с точки зрения трафика. HR-ы (не мои) рассылали своим сотрудникам, для планирований 😄

А сейчас сдув пыль, можно посмотреть, какие они были эти конференции 10 лет назад...
Летопись конференц-движения 😂

#байки

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

Принципы Modern Testing 2.0 (бета):
• Наш приоритет – развитие бизнеса.
• Мы используем такие модели, как бережливое мышление (Lean Thinking) и теорию ограничений (Theory of Constraints), которые помогают выявить, расставить приоритеты и устранить узкие места в системе.
• Мы являемся движущей силой постоянного совершенствования, адаптируем и оптимизируем наши практики, чтобы добиться успеха, вместо того, чтобы быть системой для выявления наших неудач.
• Мы глубоко заботимся о культуре качества в нашей команде: обучаем, руководим и воспитываем друг друга в направлении более зрелой культуры качества.
• Мы считаем, что только клиент может судить и оценивать качество нашего продукта.
• Мы активно используем данные, чтобы глубже понять, как клиенты используют наш продукт, а затем устранить разрыв между гипотезами о продукте и влиянием на бизнес.
• Мы расширяем возможности и экспертизу всей команды; понимая при этом, что эти действия могут уменьшить (или даже устранить) потребность в специализированных специалистах.
Тут можно почитать про принципы подробнее.
Еще интересно: Alan Page on Testing: From Past to Future

#testing #it_философия

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

Му-Му — говорит коровка.
Гав-Гав — говорит собачка.
Еще два дня и релизим — говорят разработчики третий месяц.

А потом на ретро релиза...

Картинка (с) Maxim Dorofeev, ей недавно исполнилось 10 лет...
#it_memes

"The Definitive Guide to API Test Automation With Playwright"
Большой цикл статей про автоматизацию тестирования API с помощью Playwright.
#test_automation #tech_read

"Интересно, сколько раз это должно повториться, прежде чем мы наконец запомним, что «сделано» от разработчика может означать «работа только начинается». Надо чаще с ними общаться" (с) чье-то из древних интернетов
#мысли_вслух

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

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

Идеально на эту тему от Никиты Сергеевича.

Или вот лекция Сергея Мартыненко по этому вопросу (академический подход).

#test_automation

"Программисты — оптимисты.
Поговорка «хороший инженер – параноик» только объясняет, почему программист — не инженер. С опытом прогрессирует паранойя и уходит вера в магию — поэтому старых программистов мало.
В России их практически нет. Любой HR знает, что программист «за 35», не ушедший в бизнес, менеджмент, или тестирование — или бракованный, или и так нарасхват." (с) Стас Фомин "Ищу Программиста" 2016
#it_философия

Ко вчерашнему посту про возраст, нарасхват и "бракованных" программистов.
ЗЫ хочу в понедельник что-то про возраст еще добавить :)
#it_memes

И еще немного про возраст
“Is software development really a dead-end job after age 35-40?”

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

Некоторые соглашаются, что после 45+ тяжело кодить, потом что медленно соображают. Я не знаю, в 45 я уже не кодил :)
Но знаю, что многие отличнейшим образом справляются.

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

Итого: Каким-то “молодым” тяжело с "возрастными", каким-то “возрастным” тяжело с "молодыми".
Что такое “молодой” и “возрастной”? Без контекста - вопрос без ответа. Многим людям просто с другими людьми тяжело работать в принципе, постоянно.

Когда-то давно написал бу-бу-бу про “как это работать с коллегами возраста твоих детей”, в чем его вывод - да фиг знает.
Кажется, что основное, что надо держать в голове - это то, что раньше или позже все там будут 🙂.
И к этому надо быть готовым.
#it_философия #байки