Книжный куб

Ну и картинка для иллюстрации поста

CAP Theorem Знаменитой CAP теореме исполнилось 25 лет, поэтому хотелось что это такое, зачем она и как появилась. Про это есть отличная статья от Eric Brewer, автора теоремы, который написал ее больше 10 лет назад, которую хотелось вспомнить, так как она хороша:) Начнем с самого утверждения теоремы (цитата из статьи выше)

The CAP theorem states that any networked shared-data system can have at most two of three desirable properties: - consistency (C) equivalent to having a single up-to-date copy of the data; - high availability (A) of that data (for updates); and - tolerance to network partitions (P).

Дальше надо вспомнить про ее появление - 25 лет назад, осенью 1998 года была сформулирована CAP теорема - в 1999 году она была опубликована в статье "Harvest, Yield, and Scalable Tolerant Systems" в ACM - в 2000 представлена на Симпоузиуме "Symposium on Principles of Distributed Computing" (презентация здесь) - в 2002 доказана формально (где консистентность из теоремы превратилась в линеаризуемость) Потом теорема пошла в массы и превратилась в условные "выберите 2 свойства из трех: C, A, P", что является сильным упрощением по трем причинам, что указывает Эрик в уже упоминавшейся статье: 1. Из-за редкости partition нет смысла выбирать между C и A (про это подробнее в следующий раз при обсуждении PACELC Theorem) 2. Решение о C или A принимается не единоразово для всех компонентов и всех данных, а на другом уровне гранулярности и может зависеть от типа операции или данных 3. C, A, P - это не бинарные свойства, а скорее непрерывные - availability от 0 до 100%, уровни консистентности тоже бывают разные и даже partitions имеют нюансы:) В итоге, Эрик говорит о том, что в отсутствии разделения системы мы можем выбирать A или C, а во время проблем у нас должен быть понятный алгоритм - определения, что случился partition - перехода в явный partition режим, в котором часть операций может быть лимитирована - запуска процесса восстановления консистентности и компенсации ошибок, что возможно были в рамках partition Потом Эрик рассказывает про связь акронимов ACID, BASE и CAP - BASE расшифровывается как Basic Availability, Soft state и Eventually consistency. Первые два из свойств помогают достигать доступности при разделении системы на части - ACID расшифровывается как Atomicity, Consistency, Isolation, Durability. Этот акроним знают многие, кто работал с реляционными базами данных, но как я писал выше Consistency из CAP и из ACID - это про разное и это добавляет сложности в понимании:) Следом идет часть про latency, которая отсутствует в классической формулировке, но неявно присутствует. Ведь выполняя операцию в разделенной системе, мы в какой-то момент должны принять решение - отменить операцию и уменьшить доступность - продолжить операцию, но принять риск неконсистентности данных Конечно можно попробовать повторно выполнить операцию (retries), но это просто откладывает принятие решение на некоторое время. Таким образом, с прагматической точки зрения разделение — это ограничение по времени (таймаут), который мы закладываем в свое общение. А из этого следует несколько последствий 1. Не существует глобального понятия partition, поскольку некоторые узлы могут обнаружить partition, а другие — нет. 2. Те узлы, что обнаружили partition входят в режим partition-mode, собственно ту часть, где нам надо выбирать между C и A В итоге, проектировщики системы выставляют time bounds так, чтобы соответствовать целевым скоростям ответа системы на запросы, а чем жестче эти time bounds, тем выше вероятность попадания в partition mode, причем даже просто при медленной сети, но без реального ее разделения. В приведенной выше статье есть еще много интересных мыслей про scope консистентности и как это соотносится с датацентрами, как явно управлять процессами перехода в partition mode и восстанавливаться после partition. Очень рекомендую ее к прочтению. #Software #Architecture #DistributedSystems #SystemDesign

Deep Learning от MIT Press Эта книга John D. Kelleher вышла в серии Essential Knowledge Series и содержит интересное введение в deep learning. Я уже рассказывал про другую книгу "Data Science" из этой же серии, в которой он выступал в качестве соавтора. В этой книге автор рассказывает про нейронные сети на пальцах и только в одной главе (про backpropagation) он погружается немного в математику. И хоть с издания книги в 2019 году утекло много воды, но она мне кажется до сих пор неплохим обзором deep learning для людей далеких от ml. Сама книга состоит из 7 глав 1. Introduction to deep learning - введение начинается с того, что deep learning помогает принимать решения на основе данных. Автор вспоминает про тройку терминов AI (artificial intelligence), ML (machine learning), deep learning и показывает их вложенность друг в друга: deep learning ⊂ ML ⊂ AI. Дальше приводится пример с простым dataset, функцией как детерминированным маппингом входных значений в выходные, а дальше перехода от детерминизма к угадыванию функции по доступным в датасете inputs и outputs (объяснение ml на пальцах). Конечно угадать точно можно не всегда и многое зависит от доступного датасета. Дальше на пальцах разбирается обучение с учителем, без него, а также reinforcement learning. А к концу главы автор рассказывает про причины успешности deep learning: что нам не приходится самим заниматься выделением значимых фич (feature engineering), также это хорошо работает в домене с большим количеством фич (размерность задачи) и большим объемом данных (добавлю от себя про важность большого количества GPU). Кстати, в этом тексте упоминается AlphaGo, про которая есть крутая документалка. 2. Conceptual foundations - здесь рассказывается про то, что такое модель, как можно подобрать параметры модели с использованием доступных данных, как комбинируя простые модели можно получить комплексную модель 3. Neural networks: the building blocks of deep learning - краткое объяснение нейронных сетей, того как они работают и откуда появилось название глубоких нейронных сетей (от наличия hidden layers, которые расположены между input и output layers) 4. A Brief history of deep learning - здесь автор дает выжимку из истории развития нейронных сетей, причем фокус здесь как на концептуальных, так и на практических прорывах. Это описание истории показалось мне меньше biased, чем в книге "Антология машинного обучения" ("The Deep Learning Revolution"), про которую я писал раньше. Отдельно автор рассказывает почему deep learning стало так развивается в последнее время - тут работает цикл из трех элементов, что усиливают друг друга: big data, улучшение алгоритмов, улучшение железа 5. Convolutional and recurrent neural networks - здесь описывается работы сверточных и рекуррентных нейронных сетей, где первые отлично подходят для работы с изображениями, а вторые лучше для работы с текстом. Причем описание нейронных сетей дается буквально на пальцах (мне кажется, что его поймут и люди, что далеки от математики) 6. Learning functions - эта глава самая математическая из всех и здесь идет речь про градиентный спуск и backpropagation algorithm. Первый алгоритм абсолютно стандартен для задач поиска минимума/максимума функции, а вот алгоритм обратного распространения ошибки в 80х годах сильно продвинул глубокие нейронные сети в популярности, так как этот способ позволял определять как менять веса hidden layers в нейронной сети при обучении. Собственно, именно при рассмотрении backpropagation надо немного знать про частные производные 7. The future of deep learning - здесь автор описывает светлое будущее deep learning, которое за 4 прошедших года кажется наступило в виде пришествия LLM (large language models) В общем, книга достаточно легко читается и классно подойдет для первоначального знакомства с этой областью на уровне научпоп литературы:) #ML #Data #Learning #DataScience #Software #PopularScience

Industry Myth Busting • Joris Kuipers • GOTO 2023 Забавное выступление в стиле разрушителей легенд, в котором автор говорит про - развитие технологий и какая зеленая трава и голубое небо было раньше - микросервисы и монолиты - feature branches vs trunk based development - подходы к тестированию, юнит тесты, пирамиды тестирования, перевернутой пирамиды и honeycomb (наверное есть и дргуие фигуры) Через все эти примеры сквозит мысль про то, что перед тем как выбирать лучший способ действий, стоит сначала определиться со своими целями, а дальше уже появятся критерии оценки конкретных решений:) В конце автор подвешивает вопросы, которые он мог бы еще обсудить, но не хватило времени - интерфейсы и конкретные классы - сервисы и serverless - the right programming language - и в будущем обсуждение что лучше: писать код руками или при помощи AI #Conference #Engineering #Software #SoftwareDevelopment

Generative AI Overview for Project Managers Нашел интересные документы на сайте PMI, которые были посвящены введению в ChatGPT для проджект менеджеров. Они состояли из двух документов (приложил их к посту) - Suggested GenAI Tools for Project Work v1.1 - ChatGPT Prompt Engineering Guide В первом ребята говорили про инструменты, которые полезны для руководителей проектов, среди которых интересны следующие - Для планирования: плагин "Show Me Diagrams" в GPTStore - может помочь рисовать диаграммы Ганта и network diagrams, визуализации прогресса - Для создания прототипов: Autodesk Fusion 360, Catia, Ansys Discovery - Для time и cost management: Smartsheet - Для мониторинга и отслеживания движения по проекту: плагин "WebPilot" в GPTStore - Для риск менеджмента: "ChatGPT AI Assistant for Jira" - Для управления workflow и автоматизации: ClickUp - Для генерации кода, текстов и изображений: MidJourney, Azure AI, GitHub Copilot, Microsoft 365 Copilot, Google Bard, ChatGPT by OpenAI Во втором документе показаны примеры промтов, которые могут быть полезны проджект менеджерам, например: - Провести cost-management analysis проекта и помочь принять решение - Помочь описать бизнес кейс и убедить стейкхолдеров о старте проекта по лояльности - Создать устав проекта (project charter) - Обработать расползание работ по проекту (scope creep) с использованием traceability matrix - Провести расчеты в рамках EVM (Earned Value Management) и так далее Мне показалось интересным, что обычно неповоротливый институт выпустил достаточно актуальные документы по AI, которые позволяют увеличить эффективность менеджеров проектов, сняв с них часть рутинной работы и переложив на ботов:) #Management #Project #AI #ML #Processes

Creating Local-First Collaboration Software with Automerge • Martin Kleppmann • GOTO 2023 Интересное выступление Мартина Клеппмана, который еще в 2017 году написал уже классическую книгу с кабанчиком (Designing Data-Intensive Applications). Уже в момент издания DDIA Мартин был скорее исследователем распределенных систем, чем промышленным разработчиком. А в конце своей книги он рассказывал про использование CRDT (Conflict-free Replicated Data Type) для решения проблем синхронизации изменений на разных нодах распределенной системы. Мартин долго работал в этом направлении и в этом докладе рассказывает о том 1) как его библиотека automerge прошла путь от версии 0.1 в 2017 году до версии 2.1 в 2023 году 2) и почему нам есть до этого дело Доклад состоял из следующих частей - Мартин рассказал для начала о том, как мы сейчас делаем распределенные системы в вебе - круто выглядит картинка из 6 разных представлений состояния приложения (HTML DOM, JS app state, JSON REST API, model objects, database, persistent layer) - Дальше Мартин предложил альтернативу в виде local-first software, которая напоминает старые добрые десктопные приложения ... но к ним добавляется библиотека automerge - Эта библиотека дает JSON like интерфейс для работы с данными, работа с которыми напоминает git, но уже не для исходного кода, а для данных наших приложений - Суть в том, чтобы хранить не просто конечный state данных, а некоторый набор изменений (в git это коммиты), а дальше при параллельном изменении уметь автоматически объединять эти изменения (отсюда название automerge) - При таком подходе приложения работают в local-first формате со своими данными, используя библиотеку automerge, плюс эта библиотека забирает на себя сложности распространения и синхронизации изменений по разным нодам - Мартин отметил, что этот подход не универсален и не во всех типах приложений стоит его использовать, но для создания коллаборативных сервисов это может быть удобно - например, для того, чтобы сделать свои версии сервисов навроде Google Docs, Miro, Slack, ... - Напоследок Мартин рассказал про текущую работу над алгоритмом для работы с rich текстом, который нужен для коллаборативного инструмента для редактирования текста (как раз Google Docs). Здесь Мартин на пальцах объяснил сложность и показал как они планируют ее преодолеть В общем, это интересный доклад от интересного спикера, мысли которого повлияли на большое количество инженеров. Приятно видеть, что Мартин умеет не только хорошо писать код и книги, но и выступать на сцене:) #DistirbutedSystems #Architecture #SoftwareDevelopment #SoftwareArchitecture #SystemDesign #RnD

0b111 лет в Тинькофф Семь - это красивое число, что помещается в три бита:) А еще ровно столько лет назад я вышел на новую работу в Тинькофф. Я пришел на позицию engineering manager заниматься проектами привлечения. Моим руководителем был Кирилл Бобров, наш VP of Acquisition в то время. У Кирилла были наполеоновские планы и я точно знал, что скучно мне не будет. Но 7 лет назад я и не предполагал, что задержусь в компании на 7 лет. Проблема была в том, что с самого детства мне было важно, чтобы мне было интересно - я глотал книги пачками, занимался шахматами, участвовал в олимпиадах по всем предметам, ближе к концу школы учился в ЗФТШ при Физтехе, ... в общем, делал все, чтобы не было скучно. Еще в универе я пошел работать и обычно получалось так, что работу в среднем до Тинькофф я менял раз в 2 года. В Тинькофф я попал в период роста и моя зона ответственности постоянно менялась. Я чувствовал себя не просто engineering менеджером, а скорее менеджером непрерывных изменений с девизом "пересобери себя и свою команду или умри"... Но как только я справлялся с новым вызовом, то получал следующий. Это происходило примерно каждые полтора-два года. В итоге, я сейчас технический директор большого подразделение, но что важнее, я до сих пор с интересом хожу на работу и именно это держит меня в Тинькофф - мне просто хочется узнать на что мы способны в целом как компания и какой вклад я смогу внести в эти результаты. #Management #SelfDevelopment #Engineering #Processes #Software

Обзор книги "Как делать полезные заметки" ("How to take smart notes, Zettelkasten") Эта книга Зонке Аренса, преподавателя философии образования, посвящена методу Zettelkasten, который позволяет строить свою базу знаний из заметок, создаваемых с использованием этой системы придуманной Никласом Луманом. В предисловии книги автор напоминает нам про важность письма в жизни человека, но отмечает, что большинство материалов на этот счет посвящены написанию эссе, книг, ну в крайнем случае рабочей переписке. А он предлагает читателям научиться конспектировать свои небольшие идеи и озарения, из которых потом и собираются более крупные произведения как из кубиков:) А это в свою очередь помогает победить страх чистого листа бумаги. Именно поэтому мне понравилась эта книга и я решил написать краткий обзор на нее, который сначала был тут в 4 частях, а потом я объединил все части в статью в рамках своего блога TellMeAbout.Tech:) P.S. Думаю, что я дальше именно так и буду собирать статьи - эксперимент показал, что так мне проще писать их по частям в этот канал, а потом собирать воедино на Medium:) #SelfDevelopment #Writing #Brain #Processes #SystemThinking #Thinking

Citizen Developer На выходных я занимался самообучением с использованием информации от PMI и наткнулся на информацию про Citizen Developer, которой решил поделиться с читателями. И начать стоит определения, которое можно найти на сайте Gartner A citizen developer is an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units. A citizen developer is a persona, not a title or targeted role. They report to a business unit or function other than IT. All citizen developers are business technologists. However, all business technologists are not necessarily citizen developers. There is no required designation of proficiency or time allocation for citizen developers but they must be legal employees of an organization. Если переводить с возвышенного языка техно-маркетинга специалистов Gartner на русский матерный, то под термином citizen developer, который я перевел как гражданский разработчик, кроется человек, который может нашмалять на no-code/low-code платформе что-то под потребности бизнеса. Так что возрадуйтесь пользователи Tilda, Bubble, аналитики Camunda и другие ребята, что умеют пользоваться UI - теперь достаточно уметь тыкать кнопки в вашем любимым no-code решении, чтобы войти в IT в роли разработчика, хоть и с уточнением citizen. Для повышения уровня абсурда упомяну, что этот термин я услышал в рамках вводного курса CDBA (Citizen Developer Business Architect), в котором рассказывали что для Citizen Developer нужен свой архитектор, который придумает чем им стоит заниматься и организует такую группу конфигураторов, которая будет собирать из говна и палок решения для бизнеса. В общем, демократизация разработки происходит прямо на глазах ... и стартует с навешивания названий, которые размывают границы профессии. P.S. Tсли у нас появились гражданские разработчики, то как теперь надо называть обычного software development engineer? #SoftwareDevelopment #Software #Engineering #LowCode #NoCode #Architecture

Programming's Greatest Mistakes • Mark Rendle • GOTO 2023 Превосходный стендап на тему ошибок в разработке софта, от которого я действительно смеялся. Суть в том, что автор - опытный разработчик софта, который всю дорогу рассказывает про факапы, причем начинает со своего, а дальше раскручивает спираль дальше и упоминает многие известные истории. Давайте я кратко опишу факапы, которые обсуждаются - The med file Unf*cker - факап автора, где он для устранения бага в повреждении сохраненных файлов сделал софт для их исправления (с интересным неймингом) - Y2K - проблема 2000 года, когда год должен был помещаться в YY, но в 2000 году надо было перейти к YYYY. И дальше весь софт надо было доработать под эти изменения - The Kennel club "Dog 38" - забавный пример с хранением чисел в римском формате - Agile в enterprise в виде SAFe, AutoScrum 1.1 от Accenture и The Agile Landscape v3 от Deloitte - по картинкам видно, что Agile в корпорациях тут зашел куда-то не туда:) - The Pentium FPU - проблема с плавающей точкой в процессорах Intel, эту ситацию прикольно описал Энди Гроув в книге "Выживают только параноики", про которую я уже писал - Null - история про появление nullable значений и как там поучаствовал Tony Hoare, который это назвал "Null References: The Billion Dollar Mistake" - Hartford Center - история про то, что спроектированное в CAD не всегда хорошо чувствует себя в реалььности (тут про обрушение здания из-за снега) - Knight Capital - эпичная история про high frequency trading и как экстренное обновление программного обеспечения с багом и отключенной защитой от дурака обанкротило за несколько часов большой хедж фонд - Mariner1 - про баг в формуле, которую транслировали в Fortran, что привело к крушению - Mars Climate Orbiter - про имперскую и метрическую системы (дюймы и футы) и как из-за этого космический аппарат для исследования Марса вместо того, чтобы исследовать его с орбиты, решил примарсится:) - Ariane 5 - про то, как при миграции софта с Ariane4 на Ariane5 в 16 битное float поле положили 64 битное значение и к чему это привело - The Big Rewrite - про факап самого автора - Javascript - язык, который собрали за 10 дней, а дальше он стал супер-популярным и настолько же неконсистентным:) - Лейтенант Станислав Петров - как советский офицер предотвратил 26 сентября 1983 года потенциальную ядерную войну после ложного срабатывания системы предупреждения о ракетном нападении со стороны США. #Fackup #Humor #Reliability #SRE

Как делать полезные заметки (How to take smart notes, Zettelkasten) - IV Заканчивая рассказ про Zettelkasten, я хотел бы рассказать про три шага к успешному письму, которыми завершается книга (предыстория в постах 1, 2 и 3) 12. Развивайте идеи Делать заметки конечно хорошо, но классно их связывать между собой, потому что "заметки ценны настолько, насколько ценна сеть записей и взаимосвязей, в которую они включены". Так как ящик для заметок - это не энциклопедия, то не стоит беспокоиться о полноте информации, то есть мы можем писать только те заметки, что помогают нам в мышлении. Только собирая заметки в статью, мы задумаемся о том, как заполнить лакуны смысла. Дальше автор дает семь советов - Разрабатывайте темы - размечайте заметки ключевыми словами, по которым легко можно было собрать все связанные заметки на определенную тему - Создавайте умные связи - используйте 2 вида ссылок: 1) ссылки на заметки, которые дают вам обзор темы (как точка входа в тему) и 2) ссылки одной заметки на другую (это позволяет собрать сеть и увидеть неявные взаимосвязи через транзитивные ссылки) - Сравнивайте, исправляйте и делайте различия - сопоставляйте старые и новые заметки. Это позволит найти противоречия и парадоксы, которые помогут лучше понять тему. Такие сопоставление обеспечат continuous improvement важных для нас идей - Соберите свой инструментарий для мышления - наша способность воспринимать информацию и интерпретировать смыслы зависит от широты наших знаний. Именно поэтому получение широкого набора теоретических инструментов (ментальных моделей) позволяет избежать ситуации человека с молотком, который везде видит гвозди:) Рекомендую почитать книги "The Model Thinker" и "Great Mental Models". Основной посыл не в том, чтобы все знать, а в том, чтобы иметь возможность разобраться, опираясь на обширный ресурс ментальных моделей - Используйте ящик как двигатель творчества - ящик является тем местом, где разные заметки сплавляются воедино в новые знания через поиск небольших отличий и разрешения этих конфликтов - Думайте внутри ящика заметок - делая заметки, мы проверяем свое понимание текста, который прочитали и хотим суммировать, мы фокусируемся на сути и задаем себе хорошие вопросы, когда сортируем и уточняем уже существующие заметки - Развивайте творчество с помощью ограничений - ограничение на размер и формат заметки на самом деле не ограничивают нас, а заставляют проявить свою креативность 13. Делитесь своими инсайтами Когда у нас есть ящик для заметок, мы можем заглянуть в него, чтобы собрать статью, вытягивая заметки и собирая их в ожерелье аргументов, которые нам надо связать общей нитью и превратить в линейное повествование без белых пятен. Дальше автор дает советы - Содержимое ящика уже дает нам хорошую стартовую площадку - у нас есть множество идей, объединенные в темы - Составляя заметки мы шли снизу вверх, а собирая статью мы можем пойти сверху вниз, имея перед собой общую картину, разработанной темы - Причем мы можем добиться просто следуя за своими интересами (помните, в заметки попадают только интересные нам мысли) - Для успеха сбора статьи надо визуально структурировать проект - и если линейная структура не получается, то можно писать параллельно несколько статей - Опять автор напоминает, что стоит отказаться от планирования и сначала стать экспертом - Ну и для завершения проекта пригодится фраза Антуана де Сент-Экзюпери "Как видно, совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять" (у меня самого с этим бывают трудности) 14. Заведите себе полезную привычку В этой главе говорится про силу привычек как полезных, так и вредных. Автор предлагает превратить записывание своих мыслей в привычки, а дальше превратить их в постоянные заметки, которые начать потом складывать в ящик. Так пошагово можно дойти до Zettelkasten. #SelfDevelopment #Writing #Brain #Processes #SystemThinking #Thinking

Code of Architecture - Continuous Architecture in Practice - I Завтра в 18:00 по Москве мы начнем новый сезон Code of Architecture, в котором мы в четырех частях обсудим книгу Continuous Architecture in Practice. В первой серии речь пойдет про первые две главы, в которых обсуждаются следующие темы: 1. Why software architecture is more important than ever - здесь в основном про архитектуру в мире agile, архитектуру в облаке, роль архитектора как не добавляющего ценность. Дальше дается определение continuous architecture и набор принципов, про которые я писал уже ранее, а в конце главы приводится описание сквозного Case Study, над которым авторы работают в каждой главе 2. Architecture in practice: essential activities - про принятие и governing архитектурных решений, про атрибуты качества, технический долг, про циклы обратной связи (фитнес функции, continuous testing), модели и нотации для описания архитектуры, паттерны проектирования и архитектурные стили, концепцию архитектуры как потока принятия решений. Гостем стрима будет Максим Смирнов — ИТ-архитектор и автор «Архитектура ИТ-решений». В прошлом главный архитектор Билайна, Банка России и Бинбанк Диджитал. P.S. Я уже писал про интервью Eoin Woods, одного из авторов, про книгу. Плюс я как-то разбирал одну из глав этой книги, которая посвящена resilience как архитектурной характеристики. В итоге, мне эта книга нравится сильно больше, чем Evolutionary Architecture, которая вроде как тоже посвящена непрерывному изменению архитектуры во времени. Подключайтесь завтра в 18:00 к нашей трансляции. #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management

Немного картинок из введения в Disciplined Agile, про которое я писал в посте

Disciplined Agile® от PMI Уже 6 лет я являюсь сертифицированным руководителем проектов по версии PMI (Project Management Institute) и я периодически возвращаюсь к их курсам и обучающим материалам, чтобы продлить свой статус, заработав нужное количество PDU. В этот раз проходя обучение, я наткнулся на много материалов по agile подходам под флагом Disciplined Agile® и мне стало интересно - что это такое - откуда появилось - насколько оно полезно - и насколько стандартные agile подходы являются недисциплинированными:) Собственно, начать стоит с того, что это такое и ответ мы можем найти в самом начале страницы с введением в этот вид agile процессов: Disciplined Agile (DA) is an agnostic, hybrid tool kit that harnesses hundreds of Agile, Lean, and traditional strategies to guide you to the best way of working (WoW) for your team or organization. Дальше я заинтересовался откуда это появилось и нашел официальную историю появления и развития этого подхода - В 2012 году Disciplined Agile был создан Scott Ambler и Mark Lines - В 2019 году PMI приобрело Disciplined Agile - Дальше PMI активно начало встраивать в свои материалы по управлению проектами agile подходы в форме disciplined agile Теперь взглянем на интересные моменты DA - это не фреймворк, а тулкит для создания процессов под себя, авторы называют это Way of Working (сразу вспомнился RUP с его глубоким тюнингом) - у этого подхода есть 4 отдельных области: mindset (как подавать основы lean и agile в условиях корпорациях), people (роли, ответственность, структура команд), flow (процессы), practices (техники для того, чтобы ваша команда двигалась к цели) - DA mindset основан на трех китах: принципы (для business agility), promises (соглашения со всеми стейкхолдерами), guidelines (гайды для улучшения WoW) - дальше DA вписывается в корпорацию, которая конечно же Disciplined Agile Enterprise, в которой бизнес функции называются process blades (для каждого подхода важно придумать свой язык:)) - и вся эта DA enterprise опирается на foundation (mindset, people, agile, lean, serial, WoW) - за основанием идет DevOps, но не простой а дисциплинированный - поверх него вводится понятие value streams, а уже сверху громоздится DAE (Disciplined Agile Enterprise) - дальше авторы вспоминают про свободу выбора и презентуют интересный интерактивный справочник, который позволит кастомизировать WoW - но для кастомизации и постоянных улучшений авторы вводят понятие guided continuous improvement (GCI), которые разложены на отдельные уровни: personal improvement, team improvement, multi-team improvement, value stream improvement, organizational improvement В общем, во время изучения базовых основ Disciplined Agile я словил такое ощущение дежавю, что полез изучать историю появления подхода, о которой я написал в начале поста. После этого все стало ясно - PMI надо было добавить себе в портфель менеджерских подходов немного гибкости и они это сделали хоть и довольно топорно:) #Management #Agile #Project #Leadership #SelfDevelopment #Software #Processes

Спектакль «Человек-амфибия» в Театре на Малой Ордынке! Вчера мы были с женой на спектакле по мотивам фантастического романа Александра Беляева «Человек-амфибия», которому в этом году исполнилось 95 лет. Мы достаточно редко выбираемся в театр, но тут у нас выдался субботний вечер без детей и дальше Тинькофф Город помог моей жене выбрать представление, которое нам понравилось по нескольким причинам: - Динамичная история - Яркие персонажи, которые классно отыграны актерами - Красивая хореография и заводная музыка В общем, 2.5 часа пролетели очень быстро и оставили приятное послевкусие, поэтому мы решили сходить на другую постановку в этом же театре. И выбрали мы спектакль “Маленький принц” Антуана де Сент-Экзюпери, причем я недавно перечитывал эту книгу и писал про нее. #SciFi Theatre

CNCF Platforms White Paper - III В окончании рассказа про этот white paper о платформах хочется рассказать про возможности платформ, которые нужны для создания современных приложений (начало в постах 1 и 2). 7. Capabilities of platforms Здесь авторы представляют список возможностей из 12 пунктов, а также приводят список CNCF и CDF проектов, которые по их мнению закрывают эти возможности. Ниже список пунктов, а в приложенных изображениях иллюстрации - Web portals - для получения информации и предоставления продуктов и возможностей - APIs (and CLIs) - для автоматического предоставления продуктов и возможностей - “Golden path” - шаблоны и документация для помощи в оптимальном использовании продуктов - Автоматизация для сборки и тестирования сервисов и продуктов - Автоматизация для доставки и верификации сервисов и продуктов - Среды для разработки - например, локальные IDE и инструменты для удаленного доступа - Инструменты для observability сервисов и продуктов, включая доступ к информации по функционированию сервисов, их производительности и стоимости - Инфраструктурные сервисы, включая compute, storage и сети - Data сервисы, включая базы данных, кеши и объектные хранилища - Messaging and events сервисы, включая брокеры и очереди - Identity и secret management сервисы, например user identity, authorization, certificate and key issuance, and static secret storage - Хранилище артефактов для контейнеров и пакетов, специфичных для языков, кастомных бинарей и самого исходного кода #Kubernetes #SRE #DistributedSystems #PlatformEngineering #SoftwareDevelopment #Software #ProductManagement

CNCF Platforms White Paper - II Продолжу рассказывать про White paper о платформах, про который я начал говорить в первом посте. В документе было всего 7 пунктов, первые четыре из которых мы обсудили раньше, а в этом посте пойдет речь про вызовы при создании платформ, как измерять их успех, а а набор возможностей, что предоставляют платформы мы рассмотрим в последнем посте, в котором даже будут картинки:) 5. Challenges when implementing platforms Платформы обещают многое, но на пути к реализации есть вызовы, которые надо преодолеть. Авторы выделяют следующие - платформенные команды должны относиться к своим платформам как продукту и развивать их вместе с пользователями - платформенные команды должны осторожно выбирать свои приоритеты и изначальные партнерства с командами, отвечающими за приложения - платформенные команды должны искать поддержки от команды лидеров (условно топ-менеджеров) и показывать влияние на value streams Вся эта часть крутится вокруг продуктового подхода, где платформа должна развиваться как customer-facing продукт (хоть и dev2dev) и решать проблемы своих пользователей. Отдельно упоминается про важность наличия продакт менеджеров, которые работают с пользователями собирая ожидания, создают роадмап развития платформ и собирают обратную связь от пользователей. Для adoption платформенных решений очень важно выбрать правильные возможности (capabilities) для старта, например, авторы упоминают pipelines, databases, observability, которые являются фундаментальными и нужны почти всем:) Дальше авторы приводят рекомендации о том, как уменьшить нагрузку на платформенные команды за счет - построения thinnest viable platform поверх услуг провайдеров - использования open source фреймворков, инструментов и шаблонов и объединение их вместе для предоставления app командам - убедиться, что платформенные команды укомплектованы достаточно для сложности их домена и количества клиентов 6. How to measure the success of platforms Здесь авторы приводят категории метрик, по которым можно оценивать успешность работы платформенных команд и их платформ - User satisfaction and productivity - метрики по пользователям (DAU и retention), NPS пользователей, метрики продуктивности (например, фреймворк SPACE, про который я уже рассказывал) - Organizational efficiency - здесь можно оценить скорость предоставления возможностей (например, provisioning базы данных), создание полностью нового сервиса (от репозитория, сборки и деплоя и появления на production), или времени, что требуется новому пользователю, чтобы сделать первые изменения в коде продукта - Product and feature delivery - здесь идет речь про DORA метрики: deployment frequency, lead time for changes, time to restore services after failure, change failure rate (подробнее можно почитать в книге "Accelerate", про которую я уже рассказывал). Основная цель платформенных команд в том, чтобы выровнять IT возможности и value streams компании. В итоге, успех платформ измеряется успехом продуктов и приложений организации, команды которой используют эти платформы. #Kubernetes #SRE #DistributedSystems #PlatformEngineering #SoftwareDevelopment #Software #ProductManagement

Architects, anti-patterns, and organizational fuckery Интересная статья полугодичной давности про архитекторов и инженеров. Я только сегодня дочитал ее до конца и согласен со многими тезисами, например - что это вопрос ответственности за свои решения (архитектор, который принимает решения, а реализацию оставляет команде - это антипаттерн) - что проектирование - это один из основных скиллов разработчиков - что лучшие "архитекторы" вырастают внутри из инженеров - что это staff+ инженеры, которые практикуют разработку и могут проектировать - что это скорее роль, а не должность - что если это должность, то слишком велика вероятность потери навыков инженеров, так как велик соблазн начать "делать архитектуру" и отринуть прошлое инженера в плане написания кода, ревью и траблшутинга - ведь, зарплата архиетктора такова, что этим не рентабельно заниматься ... но это ловушка для карьеры Есть момент, что в некоторых enterprise компаниях архитекторы бывают полезны, но там они скорее не инженеры, а собиратели решений, которые проектируют интеграцию различных вендорских решений между собой. Но для IT компании - это не то, что нужно:) В итоге, я склоняюсь, что вместо должности архитектор и далее должны быть продолжение должностей разработчика до staff, principal и так далее ... с соответвтующими требованиями к инженерным умениям:) P.S. Вот у меня, например, никогда в карьере не было шильдика "архитектор" и сейчас я вообще менеджер, но проектировать вроде умею ... код правда сейчас пишу с трудом ... но тут надо просто надо волевым решением выделить часть рабочего времени на то, чтобы делать какие-то прототипчики на работе или после нее:) #Management #Architecture #Architect