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

На изображении из книги "Extreme Programming Explained" 1st edition by Kent Beck приводится типичный график роста стоимости изменения кода в зависимости от момента принятия решения, характерный для времён до 1990 года. Из данного графика возникает экономическая целесообразность принимать решения как можно раньше, стремясь к моменту наименьшей стоимости их реализации. Это создает экономическую целесообразность заблаговременной обработки неопределенности, вплоть до BDUF, который, как известно, является моментом наименьшей информированности:
https://t.iss.one/ru_arc/50

#SDLC #Agile

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

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

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

Как можно разрешить этот "Catch-22"? Согласно "Первому закону диалектики", противоречие должно привести к синтезу, т.е. к качественному изменению.

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

Однако, согласно "Второму закону диалектики", качественные изменения происходят в результате количественных изменений.

Скачкообразное изменение состояния называется в философии "революцией" (коренной смысл этого термина далек от политики), и именно на это намекает заголовок статьи "The Winter Getaway That Turned the Software World Upside Down" By Caroline Mimbs Nyce - одного из участников встречи 2001 года по Agile Manifesto.

Осталось отыскать эти количественные изменения, что станет темой следующего поста.

#SDLC #Agile

Пообщались на Flow Live про архитекторов и архитектуру. Целевая аудитория стрима – аналитики, соответственно и спич с этой позиции.

Область системного анализа довольно близка к разработке архитектуры. Случается, что роль архитектора выполняет разработчик или лид системный аналитик. А бывает и наоборот. На проекте нет штатного архитектора. Или он есть, но настолько занят, что его как бы и нет. И вот в этом случае как раз и пригодятся знания о том, как разрабатывать архитектуру, как предусматривать такие моменты развития системы, про которые разработчик и системный аналитик никогда не задумывались. В этом подкасте разговариваем про архитектуры и почему в них важно разбираться системному аналитику. А также про то, кто такие архитекторы.

https://www.youtube.com/watch?v=Ur1hui3gmSg

FIGURE 3.8 Historical cost of exploration.

-- "Essential Scrum: A Practical Guide to the Most Popular Agile Process" by Kenneth Rubin, "Chapter 3 Agile Principles :: Prediction and Adaptation"

График демонстрирует те самые "количественные изменения", которые привели к изменениям качественным.

Обрели массовость высокоуровневые объектно-ориентированные языки с уклоном на управление сложностью, появились шаблоны и принципы проектирования, методики управления сложностью (ROM, POSA, GOF, OOAD, SOLID, Use Case Driven Approach, Object-Oriented Software Construction etc.), появились TDD, Refactoring и т.п.

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

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

#SDLC #Agile

🔷 "Layers, Onions, Ports, Adapters: it's all the same" by Mark Seemann

Статья не нова, но отвечает на частые вопросы.
#DDD #SoftwareDesign

Делюсь презентацией из доклада с ArchDays 2022.
#SAGA #ArchDays

В прошлую пятницу прошла конференция ArchDays.

На мой взгляд конференция прошла отлично. Выступения интересные и глубокие.

Мы постарались максимально обыграть онлайн участие, отстроить звук, поставили экраны покрупнее, закупили попкорн и колу 🙂

Все презентации доступны по ссылке: https://archdays.ru/program/

Начинаем монтаж видео и изучение анкет обратной связи. Все видео в публичном доступе будут через 2 месяца, отдельные начнем выкладывать чуть раньше.

Огромная благодарность спикерам, участникам, нас было 250 человек очно и 270 человек онлайн.

Вот такой график роста стоимости изменения кода удалось достигнуть в 90-х годах. Изображение из книги "Extreme Programming Explained" 1st edition by Kent Beck.

При таком графике, близком к константному, стоимость реализации решения уже не зависит от момента принятия решения, что позволяет откладывать принятие решения до момента наибольшей информированности:
https://t.iss.one/ru_arc/50

Это создает экономическую целесообразность разрешения неопределенности эмпирическим способом.

#SDLC #Agile

💬 "Сделайте изменение легким, а потом делай легко изменение.
Make the change easy then make the easy change."
—Kent Beck, "Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 2020"

#SDLC #Agile

Более развернутый вариант предыдущей фразы:

💬 "At the core of understanding this argument is the software change curve. The change curve says that as the project runs, it becomes exponentially more expensive to make changes. The change curve is usually expressed in terms of phases "a change made in analysis for $1 would cost thousands to fix in production". This is ironic as most projects still work in an ad-hoc process that doesn't have an analysis phase, but the exponentiation is still there. The exponential change curve means that evolutionary design cannot possibly work. It also conveys why planned design must be done carefully because any mistakes in planned design face the same exponentiation.

The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work. This flattening is both enabled by XP and exploited by XP. This is part of the coupling of the XP practices: specifically you can't do those parts of XP that exploit the flattened curve without doing those things that enable the flattening. This is a common source of the controversy over XP. Many people criticize the exploitation without understanding the enabling. Often the criticisms stem from critics' own experience where they didn't do the enabling practices that allow the exploiting practices to work. As a result they got burned and when they see XP they remember the fire."
—"Is Design Dead?" by M.Fowler

#SDLC #Agile

Roadmap развития системного аналитика. Может пригодится кому-то из архитекторов...

🔷 "Что нужно знать системному аналитику уровня Middle и Senior: план развития Hard Skills" by
AlexeyChijov

#Career

Текущий состав Комитета РОО "Объединение ИТ-Архитекторов" на 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