Зачем тогда мы сделали организацию?

Мы сделали её потому, что:

1. Нам нравится развиваться вместе. Мы знаем друг друга уже давно и взаимовыручка стала для нас привычной.

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

2. Нам нравится объединять крутых спецов и вместе достигать вершин квалификации.

За короткое время существования объединения я обрел невероятно качественный и чрезвычайно востребованный инкремент знаний. В одиночку я этого не сделал бы никогда. Никакие платные курсы с этим не могут сравниться.

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

Нам нравится качественно изменять условия своей работы. Мне объединение уже изменило условия моей работы информационно, методически и имиджево. Мы провели совместную конференцию, сделали workshop для программистов по EventStorming, получили ряд первоклассных консультаций известных узкопрофильных специалистов по трудным вопросам, приняли участие в подготовке к печати книги "Learning DDD" - фамилии наших сотрудников отражены на странице Acknowledgments.

4. Нам нравится быть организованной силой, которая стоит на защите наших общих интересов.

5. См. #Goal и уставные цели, которые были сформированы на основе коллегиального анализа проблематики отрасли.

Если вы разделяете нашу позицию, то Закон предусматривает два вида участия в организации:

1. членство и почетное членство;
2. участие и почетное участие.

Членство подразумевает под собой признание уставных целей и принятие на себя прав и обязанностей. Только члены Организации могут определять способы её существования.

Участие подразумевает просто признание уставных целей и способствование их достижению. Никак не оформляется, ни к чему не обязывает, но и прав никаких не дает.

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

Членство в организации возможно только по рекомендации действующего её члена со стажем не менее полугода или с момента учреждения организации. Если рекомендовать некому, то можно обратиться в бот @ru_arc_bot, и в процессе участия в деятельности организации появится возможность заручиться рекомендацией.

Для подписчиков канала скидка 20% на конференцию ArchDays по промокоду ru_arc

https://archconf.ru/welcome_from_sergey

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

О системе квалификационной классификации. Зачем и почему она была создана.

1. Мы не первые, кто осознал в ней необходимость и предпринял попытку реализовать её. Похожая система существует во многих объединениях, например, в проектной ассоциации:
- https://projects.management/infopage.html?Page=vision
- https://projects.management/infopage.html?Page=statuses

Большую популярность набирают социальные токены.

Даже в LinkedIn есть система Endorsement.

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

Насколько нам это удалось - будем смотреть на практике и адаптировать по результату.

Исходный код разрабатываемой системы открыт:
- https://github.com/emacsway/grade

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

3. Еще Gregor Hohpe подсветил ключевую проблему экспертных сообществ - Эффект Даннинга-Крюгера, по причине которого генерируется большое количество информационных помех в сообществе, что повышает когнитивную нагрузку на участников сообщества и демотивирует грамотных экспертов. Система призвана восстановить качество информационного пространства.

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

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

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

5. Система banofbot сообщества очень примитивна и рискованна. Её можно усовершенствовать, если учитывать ценность вклада и экспертность того, кто банит, и того, кого банят. Таким образом можно существенно облегчить бан спамеров и защититься от атак против весомых участников чата.

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

Причиной загнивания кодовой базы являются когнитивные искажения - в очередной раз подтвердил Kent Beck, подчеркнув актуальность и обширность проблемы. Отсюда следует вывод о том, что рациональная аргументация перед лицом, находящимся под их воздействием, работать не будет - требуется организация таких процессов разработки, которая взаимно компенсировала бы когнитивные искажения.

💬 "I’ve always been puzzled why the balance between structure & behavior investment seems so hard to maintain. I’m also puzzled why the balance we see in the wild is so heavily tilted towards behavior changes when as I geek I think it should be more balanced.

If "behavior change = revenue" & "structure change = option", then the struggle for balance makes more sense. It’s not about the personalities of Product versus Engineering. It’s not about short-sighted versus visionary thinking. The struggle is economic—do we make some money now or more money later? The answer is always “both”. We have to make some money now to survive. We want to make more money later. Fear versus greed. No wonder it’s so hard to get time to refactor."

— "Behavior Change = Revenue Versus Structure Change = Option" by Kent Beck

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

Ну и центр притяжения Земли, обеспечивающий орбиту своих спутников - роль которого и должно выполнить наше объединение 🙂))

🔷 "Event Sourcing explained" - The internet contains many confusing articles that mix Event Sourcing with EDA and CQRS. Let’s see what it is and what not.
by Anton Stöckl - автор проекта go-iddd - Golang DDD CQRS/ES Reference Application

#DDD #EDA #CQRS #EventSourcing #SoftwareDesign

🔷 "Using scenarios to reinvigorate your microservice architecture" by Chris Richardson

It sounds dull but good architecture documentation is essential. Especially when you are actively trying to improve your architecture. For example, I spend a lot time helping clients modernize their software architecture. Yet more often than I like, I’m presented with a vague and lifeless collection of boxes and lines. As a result, it’s sometimes difficult to discuss the architecture in a meaningful and productive way.

In this presentation, I’ll describe techniques for creating minimal yet effective documentation for your application’s microservice architecture. In particular, you will learn how documenting scenarios can bring your architecture to life.

#Microservices #Documenting #SoftwareArchitecture

🔷 "The Process Automation Map" by Bernd Reucker
🔷 "Exploring the Process Automation Map" by Bernd Reucker
Как раз недавно поднимался вопрос по этой теме в чате канала.

#SoftwareArchitecture

🔷 "Concerned about Serverless Lock-in? Consider Patterns!" by Gregor Hohpe

Design patterns have long been a useful tool for designing software. Several decades later, they can do magic for your solutions by not only improving your designs but also by reducing switching costs.

#SoftwareArchitecture #DistributedSystems

🔷 "10 problems that Event Sourcing can help solve for you" by Dennis Doomen

#DDD #CQRS #EventSourcing #SoftwareDesign

Интересное ежегодное исследование от компании Positive Technologies в мире информационной безопасности.
Тренды, аналитика, события. Отвлекитесь и полистайте на выходных =)
https://www.ptsecurity.com/ru-ru/research/analytics/positive-research-2022/

Software engineering and systems engineering - связь этих дисциплин и стандарт The Software Engineering Body of Knowledge

Программная инженерия и системная инженерия — не просто связанные дисциплины; они тесно переплетены. Правильная системная инженерия является ключевым фактором в деле построения качественной разработки программного обеспечения.

"Software engineering and systems engineering are not merely related disciplines; they are intimately intertwined. (See Systems Engineering and Other Disciplines.) Good systems engineering is a key factor in enabling good software engineering.

The SEBoK explicitly recognizes and embraces the intertwining between systems engineering and software engineering, as well as defining the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK) (Bourque, and Fairley 2014)."
https://www.sebokwiki.org/wiki/Systems_Engineering_and_Software_Engineering

SWEBOK - это стандарт
ISO/IEC TR 19759:2015
Software Engineering — Guide to the software engineering body of knowledge (SWEBOK): https://www.iso.org/standard/67604.html

Здесь обзор текущей версии SWEBOK (v3): https://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide#Knowledge_Areas_Characterizing_the_Practice_of_Software_Engineering

А здесь можно скачать SWEBOK v3:
https://www.computer.org/education/bodies-of-knowledge/software-engineering

А вот здесь SWEBOK v3 на русском: https://github.com/ligurio/swebok-2004-in-russian

Драфт новой версии SWEBOK (v4): https://waseda.app.box.com/v/ieee-cs-swebok

Крис Ричардсон опубликовал ссылку на весьма примечательное исследование.

Цитирую его:
"Unsurprisingly, technical debt impacts business outcomes.
Research by @AdamTornhill found that organizations waste up to 42% of their time due to technical debt."
https://www.researchgate.net/publication/359129462_Code_Red_The_Business_Impact_of_Code_Quality_--_A_Quantitative_Study_of_39_Proprietary_Production_Codebases

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

Коротко напомню о том, что такое Agile SDLC-model - это итеративно-инкрементальная модель разработки, на которую наложен ряд филосовско-психологических принципов с целью снизить напряжение между техническими специалистами и представителями бизнеса.

Основой этой филосовско-психологической прослойки стал документ Bill of Rights, который является результатом глубокого аналитического труда Kent Beck в области психологии. Дело в том, что Kent Beck имел превосходную эрудированность в области психологии, философии и менеджмента, а морально-психологический климат в ИТ-индустрии того времени был, мягко говоря, напряженным. Кстати, мы этот документ уже упоминали.

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

Идея Bill of Rights возникла на основе идеи Declaration of Independence (перевод):

💬 "Software development is risky. People involved have many fears of what may go wrong.

To develop effectively we must acknowledge these fears. Why do we need a software process? For the same reason that we need laws, governments, and taxes: fear.

The Declaration of Independence says:

That among these [rights] are life, liberty, and the pursuit of happiness. That to secure these rights, governments are instituted among men, deriving their just powers from the consent of the governed.

Though the profundity of these words may distract us, consider the word secure. We institute governments because we are afraid of losing our rights. By the same token, we institute software processes because we are afraid."
-- "Planning Extreme Programming" by Kent Beck, Martin Fowler

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

В превосходной статье Craig Larman "Iterative and Incremental Development: A Brief History" говорится о том, что цикл PDSA известен еще с 1930 года, в 1957 году впервые была применена инкрементальная модель разработки, а в 1968 году - итеративная.

И вот теперь мы подошли к интересному вопросу, который рассмотрим далее. Почему при столь высокой практической востребованности, эмпирический способ разрешения неопределенности в виде итеративной модели впервые получил практическое применение лишь в 1968 году, а начал обретать массовость лишь в конце 1990-х годов?

#SDLC #Agile

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

На изображении из книги "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