Текущий состав Комитета РОО "Объединение ИТ-Архитекторов" на ArchDays'22:
@emacsway , @elukianov , @GKruglov , @sergey486 .

Надеюсь, что с 10 декабря этот состав расширится.

@elukianov и @GKruglov выступили с докладами. Свою рецензию на один из них я приводил в предыдущем посте. После официальной части последовала неофициальная.

О важности понимания драйверов. Вот в Agile возвращаются проектные практики - это противоречит Agile? Кое-кто считает, что да, и даже выдумывает всякие уничижительные обзывательства типа "Wagile".

Возьмем, к примеру, набившую оскомину многим архитекторам Agile-ценность "Individuals and interactions over processes and tools" of "Agile Manifesto".

Давайте осуществим трассировку к драйверам, о которых лучше все повествуют, разумеется, первоисточники.

Сперва выявим цель этой ценности:

💬 "The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker."
—"History: The Agile Manifesto"

Итак, цель заключалась в "restore credibility" & "restore a balance".

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

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

💬 "For example, I think that ultimately, Extreme Programming has mushroomed in use and interest, not because of pair-programming or refactoring, but because, taken as a whole, the practices define a developer community freed from the baggage of Dilbertesque corporations. Kent Beck tells the story of an early job in which he estimated a programming effort of six weeks for two people. After his manager reassigned the other programmer at the beginning of the project, he completed the project in twelve weeks—and felt terrible about himself! The boss—of course—harangued Kent about how slow he was throughout the second six weeks. Kent, somewhat despondent because he was such a "failure" as a programmer, finally realized that his original estimate of 6 weeks was extremely accurate—for 2 people—and that his "failure" was really the manager's failure, indeed, the failure of the standard "fixed" process mindset that so frequently plagues our industry.

This type of situation goes on every day—marketing, or management, or external customers, internal customers, and, yes, even developers — don't want to make hard trade-off decisions, so they impose irrational demands through the imposition of corporate power structures. This isn't merely a software development problem, it runs throughout Dilbertesque organizations.

In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers (you can't use the word 'shit' in a professional paper) out of traditionalists. Quite frankly, the Agile approaches scare corporate bureaucrats — at least those that are happy pushing process for process' sake versus trying to do the best for the "customer" and deliver something timely and tangible and "as promised" — because they run out of places to hide."
—"History: The Agile Manifesto"

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

Спустя 10 лет, в своем докладе "Kent Beck talks beyond Agile Programming @ Startup Lessons Learned Conference 2010" Kent Beck скажет, что к ценности "Individuals and interactions over processes and tools" of "Agile Manifesto" стоило бы добавить еще и "Team vision and discipline".

#SDLC #Agile

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

💬 ...people and how they work together is the primary factor in software development, and that processes are a secondary factor. This is reflected in the first value of the agile manifesto "Individuals and interactions over processes and tools"...
<...>
An important consequence of these values and principles is that a team should choose its own process - one that suits the people and context in which they work. Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.
<...>
This notion of a process made to fit the team (and not the other way around) is a necessary condition for agile methods, but clearly isn't sufficient. A team may choose a totally waterfall, un-agile process. In that case, clearly the process is no more agile than apples taste of strawberries. But agile methods aren't the best for all situations, and personally I'd rather have a team work in a non-agile manner they chose themselves than have my favorite agile practices imposed upon them.
<...>
imposition isn't as clear cut as it can sound, but the fundamental point remains - imposing agile methods introduces a conflict with the values and principles that underlie agile methods.
—"Agile Imposition" by Martin Fowler

#SDLC #Agile

Возможно вы пропустили, но вышел новый отчет State of Devops 🙂 https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf

Несколько интересных фрагментов
«Надежные (Dependable) команды обеспечивают надежный(Dependable) сервис: творческая командная культура ведет к большей надежности».

Мы видим, что люди с меньшим опытом в целом имеют худшие результаты при использовании trunk based development. (Что и не мудрено. Вы попробуйте trunk based, когда, скажем у вас тестов нет. прим stringconcat)
Хотя она оказывает положительное влияние на общую эффективность организации» (есть предположение о том, что этот результат является неожиданностью, и возможные причины включают гораздо более неопытных участников, чем в предыдущие годы)

«Исследование этого года показало, что loosely-coupled architecture (слабосвязанная архитектура) может способствовать выгоранию команд.
Это удивительное открытие, которое противоречит результатам предыдущих лет. Наш анализ показывает, что стабильно
команды, в которых используется loosely-coupled architecture, имеют более низкий уровень выгорания. Генеративная культура Westrum и стабильность команды поддерживают слабосвязанную архитектуру и снижают выгорание, так что это явно противоречит друг другу. Необходимы дополнительные исследования, прежде чем мы сможем сделать окончательные выводы».

«Самый важный фактор, который мы обнаружили, был вовсе не техническим, а скорее культурным: организации, наиболее близкие к «генеративной» культурной группе Westrum, значительно чаще говорили, что у них широко распространены методы обеспечения безопасности, как это определено в рамках SLSA».

Матрица скиллов архитектора:
- https://t.iss.one/ru_arc_chat/7769
- https://t.iss.one/ru_arc_chat/7777

🔷 "Обязан ли разработчик развиваться?" - статья на Хабре полностью подтверждает актуальность целей нашего объединения архитекторов.

Мы уже не раз обсуждали в чате сообщества @ru_arc_chat о том, что требуются новые способы разрешения противоречия между трудоемкостью освоения перегруженной области знаний и стесненностью ресурсов времени практикующего специалиста.

Именно этим фактором вызван взрывной рост интереса на рынке к reference applications/architectures, которые, по сути, решают одну проблему - быструю навигацию на основе схожести решаемой проблемы и демонстрацию решения на основе примера. Это позволяет легко отыскивать решения в условиях недостаточной полноты знаний. Но еще большего результата могут дать графы принятия решений и СППР.

Мы также обращали внимание на огромное количество когнитивных искажений, действующих в процессе собеседования, которые, по сути, превращают его в лотерею.

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

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

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

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

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

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

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

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

А еще - объединяться в организованную силу, способную изменять и улучшать профессиональную среду специалиста на рынке. Эта организованная сила и есть то самое, что отличает практическое применение знания от пустого мечтательства.

#Goal

Коллеги, у нас в группе @ru_arc_chat возникло небольшое обсуждение механизмов резольва конфликтов слияния веток системы контроля версий с архитектурными моделями. Ознакомиться можно начиная с этого сообщения:
- https://t.iss.one/ru_arc_chat/7804

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

В Archi мержить приходится на уровне текстовых файлов, благо, благодаря GRAFICO это несложно сделать, но не стоит этого ожидать от каждого программиста, который решит актуализировать доку.

В Papyrus пошли дальше этого, и сделали графический резольвер:
- https://youtu.be/NSCfYAukYgk?t=1685

Реализован он плагином Papyrus Compare, основанном на EMF Compare.

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

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

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

Ценность Archi заключается в том, что он:
1) Open Source, что снижает зависимость от геополитических рисков;
2) on-premise, что позволяет чувствительной архитектурной информации не покидать периметр безопасности;
3) имеет широкие возможности по интеграции, что позволяет генерировать исходный код микросервисов по EventStorming диаграммам, подобно тому, как это делает сервис domorobo.to + XOOM-Designer, либо же автоматизировать сверку программного кода с диаграммами (с моделью);
4) позволяет вести моделирование коллективно, посредством плагина coArchi;
5) нотация (т.е. цвета) Event Storming практически идентична нотации Archimate "C.1.10 Business Process Cooperation Viewpoint";
6) в отличии от EventStorming на стикерах/Miro, где нет модели, Archi имеет модель, что позволяет определять не только границы Bounded Contexts, но еще и определять наилучшие контуры границы микросервисов с математической точностью;
7) с помощью плагина jArchi поиск контуров границ микросервисов можно автоматизировать с простотой и легкостью jQuery;
8) позволяет строить C4Model диаграммы, интегрированные в единую модель;
9) позволяет создавать Context Map, интегрированную в единую модель;
10) достаточный для полноценного документирования Agile Architecture (копия);

🔷 Конспект по книге Greg Young "Versioning in an Event Sourced System":
- https://github.com/luque/Notes--Versioning-Event-Sourced-System

#DDD #EventSourcing

🔷 Краткие пересказы некоторых популярных книг по IT:
- https://yoan-thirion.gitbook.io/knowledge-base/

#SoftwareArchitecture #Career #SoftwareConstruction

Фотки с ArchDays выложили в группу во вконтакте 👀

Вышел очередной, 27-й technology radar от thoughtworks

https://www.thoughtworks.com/radar

Закончил краткий пересказ статьи «Microservices: The Evolution and Extinction of Web Services?» за авторством Luciano Baresi и Martin Garriga 👌

abstract
Еще 20 лет назад SOA и Web Services были на пике популярности. Это был самый настоящий хайп. Особенность хайпа в том, что его применяют ради хайпа, а не для пользы дела, в массе своей даже не разобравшись в сути явления или технологии. Такое положение дел привело к тому, что количество определений и трактовок SOA и Web Services было примерно равно количеству внедрений Это, в свою очередь, приводило к тому, что проблема подгонялась под решение. Сегодня то же самое происходит с микросервисами. Авторы статьи исследуют эволюционный путь от SOA к микросервисам на основе анализа литературы, как академической, так и научно-популярной.

https://agilemindset.ru/история-микросервисов/

Приятного чтения 🧠

🔷 "Handbook of Requirements and Business Analysis" by Bertrand Meyer

28 October 2022, 19:36

Надеюсь, автор в представлении не нуждается.

[UPDATE]: Содержание:
- https://se.inf.ethz.ch/requirements/contents.pdf

#Analysis

По-немногу начинаем выкладывать видео с #ArchDays’22

Как подготовиться и пройти System Design Interview
Александр Поломодов

https://youtu.be/jUbOm0B-eKQ

Подборка ссылок по техдолгу от @inikolski :

Ваня (RASA) прости!

ALL - no comments

Является ли исключение человека из команды проявлением недостаточных Soft Skills руководства команды?

Вот что пишет Kent Beck - человек, обладающий невероятной эрудицией в области психологии и философии, тот самый, благодаря которому принципы коммуникативной психологии стали неотъемлемой частью современных методологий разработки:

💬 "One of the most difficult aspects of managing a galloping shift to XP is deciding that a team member isn't working out. In this situation, you are always better off without them. And you should make the change as soon as you are sure the situation isn't going to get any better."
-- "Extreme Programming Explained" 1st edition by Kent Beck

Во втором издании он не изменил отношения к этому вопросу:

💬 "XP can't have been easy for you. No. At first, a third of the people are skeptical, a third buy in quickly, and a third wait and see. Eventually, 80-90% buy in, 10-20% use XP grudgingly, and 35% never buy in. If programmers won't pair or if they insist on owning code, have the courage to fire them. The rest of the team will bail you out."
-- "Extreme Programming Explained" 2nd edition by Kent Beck

Именно так и поступил Nick Tune.

Звучит немного парадоксально, но сегодняшний уровень внедрения основ коммуникативной психологии в методологии разработки обязан своим существованием именно жестким увольнениям на своей заре. Цель оправдала средства.

Когда человек недотягивает до среднего уровня команды, понижает эффективность команды, и перспектив изменения ситуации не наблюдается, перед руководством возникает вопрос грамотного управления ресурсами для достижения целей, соизмерение баланса затрат и выгод, и, как результат, - изменения качественного состава команды "as soon as you are sure the situation isn't going to get any better". Коммуникативная психология должна способствовать достижению целей, а не противодействовать.

И здесь уже выходит на первое место другое психологическое качество руководителя, которое Kent Beck называет одной из 4-х ценностей XP - Courage.

#SoftSkills

Zero trust. Подборка документации для архитектора.

https://www.redhat.com/architect/what-is-zero-trust

AgileDays Call For Papers! 🧠

Скоро пройдет очередная, 17-я AgileDays и уже 7-й год подряд я курирую на ней инженерный трек.

В разные годы на AgileDays выступали Henrik Kniberg, Jeff Patton, Gojko Adzic, David J. Anderson, Patrick Kua, Kent Beck.

Когда-то трек был очень технический, прям хардкор, затем выступления смягчались и сейчас трек называется «Tech for Non-Tech»
«Процессы, практики и инструменты разработки и поставки продуктов. Повышение гибкости через постоянное внимание к техническому совершенству.»

Для нас это отличная возможность рассказать простым, доступным языком о современных тенденциях и наработках в области разработки, DevOps и архитектуры.

Ссылка на конференцию: https://agiledays.ru

Заявки на выступления принимаем до 7 января.