Подкаст "Письма Лиды Таймовой". Выпуск №1: Оценивать или не оценивать

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

#Software #Engineering #Processes #Project #Management

Улучшение процессов разработки программного обеспечения (Рубрика #Management)

Сегодня в 18.00 по Москве я закрываю трек по "Архитектуре, надежности и качеству" на IT пикнике в Москве с вышеуказанным докладом.
Расшифровку доклада можно уже почитать в статье, а ниже приведены материалы для более глубокого изучения.

4 основные книги, из которых родилась идея доклада
- The Phoenix Project (2013 год) - книга написана в жанре производственного романа и похожа на книгу "Цель" ("Goal") или "Критическая цепь" ("Critical Chain") Голдратта.
- The DevOps Handbook (2016 год) - книга с популяризацией devops подхода
- Accelerate (2018 год) - книга, где приводятся крутые выводы о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент.
- The Unicorn Project (2019 год) - эта книга написана Gene Kim как продолжение предыдущей книги Проект Феникс

Связанные книги
- Team Topologies - книга про Team-First подход при проектировании архитектуры программных систем, так и организации.
- Learning Domain Driven Design - эта книга содержит много рекомендаций о том, как бороться со сложностью при проектировании софта.
- A philosophy of sotfware design - книга посвященная борьбе со сложностью и тому, как практиковать стратегический подход к разработке.
- Making Work Visible - простая книга про улучшение процессов разработки с использованием kanban подходов
- SRE Book - крутая книга целиком посвященная тому, как делать надежные системы и строить процессы вокруг них
- "Lean Software Development" - книга про lean практики в разработке

Исследования и whitepapers на тему доклада
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)
- The SPACE of Developer Productivity - интересный фреймворк для оценивания продуктивности разработчиков (состоит из 5 составляющих: saatisfaction & well being, performance, activity, communication & collaboration, efficiency and flow)
- DevEx: What Actually Drives Productivity - продолжение предыдущего исследования, но теперь про опыт разработчика (feedback loops, cognitive load, flow state), который можно мерить по поведению системы и процессам, а также по восприятию разработчиков

Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
- Эволюция подходов к развитию мобильного банка Тинькофф
- Эволюция web Tinkoff на ArchDays

#Processes #Management #Architecture #Conference #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SoftwareArchitecture

Как развиваться, если ты уже Senior System Analyst

Завтра рассказываю этот доклад в 13:15 в онлайне на конференции Flow для системных аналитиков.
Рассказа будет посвящен карьерным трекам системных аналитиков. Ведь когда-то и они дорастают до ведущих и оказываются перед развилкой. Рассмотрим все варианты роста - от типовых до эзотерических:
-Становление лидером профессии аналитиков;
- Рост в тимлида в кросс-функциональной команде;
-Переход в технический продакт-менеджеры;
- Переход в архитектуру.

Завтра я опубликую расшифровку доклада, а потом через некоторое время появится и его запись:)

P.S.
Изначально я планировал выступить на оффлайн части конференции, но потом планы поменялись, так как в даты конференции я буду не в Москве.
Поэтому выступление перенеслось на 10 дней пораньше и сместилось в онлайн.

#Management #Career #Analyst #Software #SoftwareDevelopment

Публичное интервью по troubleshooting для SRE-инженеров на Devoops

Сегодня у меня целых два выступления на разных конференциях. Вечером будет публичное интервью по troubleshooting на Devoops, а днем я расскажу про пути развития senior аналитиков на Flow. Изначально я не планировал такой нагрузки, но выступление на Flow пришлось тоже подвинуть в онлайн:)
Если же возвращаться к интервью на Devoops, то оно посвящено тому как выглядит одно из интервью для SRE инженеров. А выглядит оно как работа в рамках инцидента, где сценарий приблизительно таков:
1. По легенде кандидат и интервьюер работают совместно в SRE-команде. Кандидат исполняет роль Lead, а интервьюер — Junior.
2. Собственно, по той же легенде Lead уезжает на конференцию, а Junior остается дежурить.
3. Дальше происходит инцидент, который они вместе распутывают, так как junior сразу использует "звонок другу" и дальше под руководством лида пытается со всем справиться:)

На публичном интервью я буду выступать в качестве интервьюера, а выступить в качестве собеседуемого согласился Салих Фахрутдинов - Senior SRE в Tinkoff Origination Platform.
Спасибо Салиху и надеюсь, что у нас получится интересно:)

#Engineering #SRE #Career #Interview #Processes #Postmortem #Management

Материалы к докладу на конференции Flow "Как развиваться, если ты уже Senior System Analyst"

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

- Доклад "'Канал. Продукт. Платформа' или эволюция подходов к развитию мобильного банка Тинькофф"
 - Краткий обзор "Team topologies" в трех частях 
 - - Teams as means of Delivery
- - Team Topologies that work for flow
- - Evolving team interactions for innovation and rapid delivery
- Статья "Про performance review в командах разработки"
- Обзор white paper "DevEx: What Actually Drives Productivity"
 - Доклад "Современные подходы к разработке программного обеспечения"
 - Доклад "SOLID'ный тимлид, или основы менеджмента для технарей"
 - Доклад "Как нанимать технических руководителей"
 - Доклад "Как и куда развиваться, если ты уже Senior Software Engineer"
 - Доклад "Варианты роста инженера, если он уже Senior"
 - Доклады про system design interview
 - - в общем про system design в Тинькофф
 - - больше про то, как мы оцениваем прохождение собеседования
 - - как подготовиться к собеседованию
 - -пример на C++ Russia 2022 про проектирование ленты в сервисе видео
- - пример на ArchDays 2022 про проектирование букинга номеров в отелях
 - - пример на C++ Russia 2023 про проектирование умных парковок

#Career #SystemDesign #Software #SoftwareArchitecture #Architecture #Engineering

Как RnD (Research and Development) появляется в крупных ИТ-компаниях

На TeamLead Conf++ 2023 я расскажу доработанный доклад про RnD, который я уже рассказывал на нашем дне открытых дверей в Ереване, но записи которого не велось.

В докладе я попробую ответить на вопросы:
— Зачем крупным ИТ-компаниям заниматься RnD
— В какой момент RnD может появляться и как может выглядеть
— Какие задачи могут стоять перед RnD-направлением
— Как может происходить внедрение инноваций и как сделать этот процесс эффективным

P.S.
Для доклада я возьму другие Bigtech компании, которых нет в статье приведенной выше, а также попробую посмотреть как это происходит в российских компаниях, включая Тинькофф.

#RnD #SoftwareDevelopment #Software #Conference

Practical Magic: The Resilience Potion & Security Chaos Engineering • Kelly Shortridge • GOTO 2023

Интересное выступление от Kelly Shortridge, Senior Principal at Fastly, про Security Chaos Engineering, про которую она написала одноименную книгу.
В самом докладе автор рассказывает про 5 составляющих устойчивость (resilience) системы:

1. Define the system’s critical functions
Зная что относится к критическому функционалу, легко понять что в него не входит, а это позволяет более осознанно действовать как при разработке, так и во время инцидентов. Например, ясно где стоит использовать скучные, но предсказуемые технологии:) Новые и модные технологии стоит использовать там, где это выступает для бизнес-проблем в качестве market differentiator. Здесь же идет речь про важность стандартизации: языков, бибилиотек и tooling, memory safety. Дальше автор переходит к важности понимания своих зависимостей, а также работе с данными, где надо ограничивать доступ к чувствительной информации.

2. Define the system’s safe boundaries
Здесь автор выдает такую фразу "A lot of getting security “right” is just solid engineering. Security is a facet of quality", которая позволяет аргументировать внедрение хороших инженерных практик не только с точки зрения оптимизации темпа разработки или улучшения качества, но и с точки зрения рисков (как любят строить аргументы security специалисты). В этом же разделе автор говорит о том, что надо предвидеть масштабирование системы и думать о том, как она будет себя чувствовать при изменившихся условиях. Нам надо предвидеть потребность в реакции на инциденты наших ops/SRE команд. Дальше здесь опять идет речь про стандартизацию, но на этот раз паттернов и инструментов. Автор предлагает не создавать самим middleware, но предоставить командам список проверенных библиотек и сервис провайдеров, которые им стоит использовать. Плюс команды опять же должны знать про свои зависимости и понимать какие там могут быть ошибки. Если думать про уязвимости, то их надо классифицировать по тому, насколько атаку легко автоматизировать и масштабировать, а также насколько атака далека от целей атакующего. И с учетом этого можно приоритизировать устранение уязвимостей.

3. Observe system interactions across spacetime
Для построения безопасных и устойчивых систем нам нужна observability как с точки зрения топологии систем, так и с точки зрения изменений во времени. Дальше идет речь про ментальные модели, которые мы строим для понимания системы, а также про тестирование как систем, так и наших ментальных моделей. Автор топит за integration tests и ругает unit tests, но это кажется последствия профессиональной деформации. Дальше заходит речь про chaos engineering (например, есть такая книга), а потом про то, как это переходит в security chaos engineering. Автор рассказывает про стандартный цикл: постановку гипотезы, проведение экспериментов, анализ результатов и постановку задач на улучшение.

4. Feedback loops and a learning culture
Здесь автор говорит про важность обратных связей и обучения для улучшения ситуации. И тут на сцену выходит distributing tracing, который нам просто необходим:) Про тему с распределенным трейсингом можно прочитать отдельную книгу "Distributed Tracing in Practice"

5. Flexibility and willingness to change
В общем и целом, без желания меняться и менять систему не построить устойчивую систему. Это про адаптацию и про рефакторинг, про изменение кода наших систем и про простоту внесения изменений. Дальше автор рассказывает про статическую типизацию кода как помощь при рефакторинге:) Дальше автор переходит к модульности и появляются отсылки к coupling и тому, что модули формируют локальные границы. Причем isolation - это ключевое свойство, которое поддерживает system resilience. Дальше автор рассказывает про использование sandbox для исполнения опасного кода. Напоследок автор рассказывает как менять систему, используя паттерн "Strangler Fig", про которую рассказывал неплохо Мартин Фаулер почти 20 лет назад.

#Chaos #Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software