Forwarded from Блог Сергея Баранова
С какой роли вы перешли на роль архитектора?
Anonymous Poll
37%
Разработчик
1%
Тестировщик
12%
Аналитик
4%
DevOps-инженер/админ
4%
Менеджер
2%
Другое (напишу в комментарии)
40%
Посмотреть ответы
Крис Ричардсон опубликовал ссылку на весьма примечательное исследование.
Цитирую его:
"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
Цитирую его:
"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
ResearchGate
(PDF) Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases
PDF | Code quality remains an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code... | Find, read and cite all the research you need on ResearchGate
👍16
Russian Association of Software Architects
"Нам некогда делать DDD..." "Нам некогда писать тесты..." Наверное, каждый из нас слышал подобные утверждения. Но, странное дело, практические эксперименты показывают, что, хотя мы и пишем больше кода, разработка продвигается быстрее. Разве не должна была…
О качестве кода - был у нас такой тематический месячник (можно посмотреть отсюда), в котором, правда, образовалась пауза. Кажется, пришло время вернуться к пропущенным вопросам.
Коротко напомню о том, что такое 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
Коротко напомню о том, что такое 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
Telegram
Russian Association of Software Architects
Друзья, спасибо за ответы. Честно говоря, было неожиданно наблюдать лидерство DDD под конец опроса. И все-таки, в конце "Принципы качественного кода" отыграли свое и сравняли счет. С них мы и начнем. Посвятим принципам качественного кода июль месяц.
Напомню…
Напомню…
🤯2🔥1
Forwarded from Блог Сергея Баранова
Я проектировал/видел/лично знаю архитектурные решения (хотя бы одно) в которых использовалась хореография и это было обоснованным и оправданным
Anonymous Poll
16%
Да
32%
Нет
52%
Посмотреть ответы
Russian Association of Software Architects
О качестве кода - был у нас такой тематический месячник (можно посмотреть отсюда), в котором, правда, образовалась пауза. Кажется, пришло время вернуться к пропущенным вопросам. Коротко напомню о том, что такое Agile SDLC-model - это итеративно-инкрементальная…
Эмпирический способ разрешения неопределенности подразумевает, что не только требования влияют на реализацию, но и реализация влияет на требования. Поскольку сама реализация становится источником новых знаний (и требований), экономическая целесообразность такого метода определяется стоимостью реализации решения в зависимости от момента принятия решения.
На изображении из книги "Extreme Programming Explained" 1st edition by Kent Beck приводится типичный график роста стоимости изменения кода в зависимости от момента принятия решения, характерный для времён до 1990 года. Из данного графика возникает экономическая целесообразность принимать решения как можно раньше, стремясь к моменту наименьшей стоимости их реализации. Это создает экономическую целесообразность заблаговременной обработки неопределенности, вплоть до BDUF, который, как известно, является моментом наименьшей информированности:
https://t.iss.one/ru_arc/50
#SDLC #Agile
На изображении из книги "Extreme Programming Explained" 1st edition by Kent Beck приводится типичный график роста стоимости изменения кода в зависимости от момента принятия решения, характерный для времён до 1990 года. Из данного графика возникает экономическая целесообразность принимать решения как можно раньше, стремясь к моменту наименьшей стоимости их реализации. Это создает экономическую целесообразность заблаговременной обработки неопределенности, вплоть до BDUF, который, как известно, является моментом наименьшей информированности:
https://t.iss.one/ru_arc/50
#SDLC #Agile
👍5🤬1
Russian Association of Software Architects
Эмпирический способ разрешения неопределенности подразумевает, что не только требования влияют на реализацию, но и реализация влияет на требования. Поскольку сама реализация становится источником новых знаний (и требований), экономическая целесообразность…
В предыдущем посте просматривается противоречие, которое заключается в том, что для того, чтобы снизить стоимость разработки, нам необходимо повысить точность прогнозирования (повысить полноту требований), но повышение точности прогнозирования, в свою очередь, повышает стоимость разработки (возникает отрицательная обратная связь).
Причем, как уже упоминалось ранее, повышает её экспоненциально, в то время как бизнес-выгоды от этой точности возрастают логарифмически.
Мы не можем повышать точность прогнозирования, т.к. она превысит предел экономической целесообразности, но мы вынуждены её повысить для того, чтобы принимать решения в момент наименьшей стоимости их реализации.
Как можно разрешить этот "Catch-22"? Согласно "Первому закону диалектики", противоречие должно привести к синтезу, т.е. к качественному изменению.
И решение этого противоречия схоже с решением противоречия "Закона Брукса", в виде автономных команд. Или же с решением в виде Bounded Context, которое разрешает противоречие, заключающееся в том, что при стремлении выровнять язык по всей модели, он стремится к противоречивости (и неоднозначности). Т.е. стремление следовать предметной области вынуждает отступать от неё. В нашем случае решение так же заключается в разбиении целого (процесса разработки) на части (итерации), только вместо согласованности единого языка здесь критерием разделения выступает достаточность полноты требований.
Однако, согласно "Второму закону диалектики", качественные изменения происходят в результате количественных изменений.
Скачкообразное изменение состояния называется в философии "революцией" (коренной смысл этого термина далек от политики), и именно на это намекает заголовок статьи "The Winter Getaway That Turned the Software World Upside Down" By Caroline Mimbs Nyce - одного из участников встречи 2001 года по Agile Manifesto.
Осталось отыскать эти количественные изменения, что станет темой следующего поста.
#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
Telegram
Russian Association of Software Architects
Сегодня Big Design Up Front (BDUF) даже в проектах средней величины практически не применяется. Обрабатывать неопределенность заблаговременно (Prediction), путем логического вывода - это очень дорогая задача, стоимость которой может достигать экспоненциального…
👍11🔥3
Пообщались на Flow Live про архитекторов и архитектуру. Целевая аудитория стрима – аналитики, соответственно и спич с этой позиции.
Область системного анализа довольно близка к разработке архитектуры. Случается, что роль архитектора выполняет разработчик или лид системный аналитик. А бывает и наоборот. На проекте нет штатного архитектора. Или он есть, но настолько занят, что его как бы и нет. И вот в этом случае как раз и пригодятся знания о том, как разрабатывать архитектуру, как предусматривать такие моменты развития системы, про которые разработчик и системный аналитик никогда не задумывались. В этом подкасте разговариваем про архитектуры и почему в них важно разбираться системному аналитику. А также про то, кто такие архитекторы.
https://www.youtube.com/watch?v=Ur1hui3gmSg
Область системного анализа довольно близка к разработке архитектуры. Случается, что роль архитектора выполняет разработчик или лид системный аналитик. А бывает и наоборот. На проекте нет штатного архитектора. Или он есть, но настолько занят, что его как бы и нет. И вот в этом случае как раз и пригодятся знания о том, как разрабатывать архитектуру, как предусматривать такие моменты развития системы, про которые разработчик и системный аналитик никогда не задумывались. В этом подкасте разговариваем про архитектуры и почему в них важно разбираться системному аналитику. А также про то, кто такие архитекторы.
https://www.youtube.com/watch?v=Ur1hui3gmSg
YouTube
[Flow Live] Про архитектуры и архитекторов для системных аналитиков
Подробнее о конференции Flow: https://jrg.su/1TyzrD
— —
Область системного анализа довольно близка к разработке архитектуры. Случается, что роль архитектора выполняет разработчик или лид системный аналитик. А бывает и наоборот. На проекте нет штатного архитектора.…
— —
Область системного анализа довольно близка к разработке архитектуры. Случается, что роль архитектора выполняет разработчик или лид системный аналитик. А бывает и наоборот. На проекте нет штатного архитектора.…
👍10👌2
Russian Association of Software Architects
В предыдущем посте просматривается противоречие, которое заключается в том, что для того, чтобы снизить стоимость разработки, нам необходимо повысить точность прогнозирования (повысить полноту требований), но повышение точности прогнозирования, в свою очередь…
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
-- "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
👌6👎1
🔷 "Layers, Onions, Ports, Adapters: it's all the same" by Mark Seemann
Статья не нова, но отвечает на частые вопросы.
#DDD #SoftwareDesign
Статья не нова, но отвечает на частые вопросы.
#DDD #SoftwareDesign
ploeh blog
Layers, Onions, Ports, Adapters: it's all the same
If you apply the Dependency Inversion Principle to Layered Architecture, you end up with Ports and Adapters.
👍5👌2
Forwarded from Блог Сергея Баранова
В прошлую пятницу прошла конференция ArchDays.
На мой взгляд конференция прошла отлично. Выступения интересные и глубокие.
Мы постарались максимально обыграть онлайн участие, отстроить звук, поставили экраны покрупнее, закупили попкорн и колу 🙂
Все презентации доступны по ссылке: https://archdays.ru/program/
Начинаем монтаж видео и изучение анкет обратной связи. Все видео в публичном доступе будут через 2 месяца, отдельные начнем выкладывать чуть раньше.
Огромная благодарность спикерам, участникам, нас было 250 человек очно и 270 человек онлайн.
На мой взгляд конференция прошла отлично. Выступения интересные и глубокие.
Мы постарались максимально обыграть онлайн участие, отстроить звук, поставили экраны покрупнее, закупили попкорн и колу 🙂
Все презентации доступны по ссылке: https://archdays.ru/program/
Начинаем монтаж видео и изучение анкет обратной связи. Все видео в публичном доступе будут через 2 месяца, отдельные начнем выкладывать чуть раньше.
Огромная благодарность спикерам, участникам, нас было 250 человек очно и 270 человек онлайн.
🔥30👍1
Russian Association of Software Architects
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" График демонстрирует те самые "количественные изменения", которые…
Вот такой график роста стоимости изменения кода удалось достигнуть в 90-х годах. Изображение из книги "Extreme Programming Explained" 1st edition by Kent Beck.
При таком графике, близком к константному, стоимость реализации решения уже не зависит от момента принятия решения, что позволяет откладывать принятие решения до момента наибольшей информированности:
https://t.iss.one/ru_arc/50
Это создает экономическую целесообразность разрешения неопределенности эмпирическим способом.
#SDLC #Agile
При таком графике, близком к константному, стоимость реализации решения уже не зависит от момента принятия решения, что позволяет откладывать принятие решения до момента наибольшей информированности:
https://t.iss.one/ru_arc/50
Это создает экономическую целесообразность разрешения неопределенности эмпирическим способом.
#SDLC #Agile
🔥1🤔1
Russian Association of Software Architects
Вот такой график роста стоимости изменения кода удалось достигнуть в 90-х годах. Изображение из книги "Extreme Programming Explained" 1st edition by Kent Beck. При таком графике, близком к константному, стоимость реализации решения уже не зависит от момента…
💬 "Сделайте изменение легким, а потом делай легко изменение.
Make the change easy then make the easy change."
—Kent Beck, "Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 2020"
#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
YouTube
Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 2020
Domain-Driven Design Europe 2020 - Organised by Aardling (https://aardling.eu/)
About Kent Beck:
Kent consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated…
About Kent Beck:
Kent consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated…
🔥3
Russian Association of Software Architects
💬 "Сделайте изменение легким, а потом делай легко изменение. 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
💬 "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
martinfowler.com
Is Design Dead?
The rise of agile methods (particularly XP) makes some people wonder if there's any role left for software design. I argue that this change shifts from planned to evolutionary design.
👍3🔥1
Forwarded from emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
🔷 "SAGA — эволюция и новые смыслы" / Геннадий Круглов @GKruglov:
- https://t.iss.one/ru_arc/165
Хочу оставить свою рецензию.
Что такое архитектурное решение? Его суть сводится к тому, чтобы бесконечно большое множество вариантов реализации сократить до одного единственного варианта. Иными словами, архитектура - это о том, как не надо делать. И здесь важно не многообразие вариантов само по себе, а те критерии, по которым их количество можно сократить.
Если не понимать решаемой проблемы, тогда никакое решение не будет правильным. Непонимание причинно-следственной связи называется в индустрии Карго-культом, а утрата семантических отношений - "Синдромом коллекционера".
Лучше всего драйверы описываются первоисточниками - уж они-то точно знают, какую проблему они решали. Они дают понимание релевантности этой проблемы решаемой проблеме.
Вот об этом доклад Гены.
Какую проблему решала SAGA? А транзакция? А атомарность? А SAGA - это транзакция? А SAGA атомарна? Почему?
Вот Sam Newman утверждает, что SAGA неатомарна, а Chris Richardson - наоборот, что она атомарна. Вероятно, кто-то из них не стал утруждаться исследованием вопроса, но кто же из них прав?
Гена зацепил довольно сложную тему, сложность понимания которой привело к такому бардаку вокруг этой темы. Каких только заблуждений по этой теме мне не приходилось слышать: и то, что SAGA - это stateless, в отличии от Process Manager, и то, что она обязана иметь компенсации, и т.д.
Была проделана колоссальная исследовательская работа по выявлению драйверов, причин, восстановлению исторического контекста и его актуализации. И много работы еще предстоит.
Материал презентации содержит сотни человеко-дней исследовательской работы, и стал возможным исключительно благодаря консолидации опыта специалистов сообщества. И мой вклад тоже отражен в этом докладе, но особенно ценным оказался вклад @beer_Roman .
Вот только малая часть агрегации информации по этому вопросу из чата @ru_arc_chat :
- https://t.iss.one/ru_arc/112
Особое значение этого доклада заключается не в его содержимом, а в том, что он заложил тот самый хребет, на котором может нарастать плоть исследовательской работы, суть которой сводится к конвергенции существующего зоопарка понятий.
Конечно, хотелось бы вместить больше в этот доклад, и есть что в нем улучшить.
Но этот доклад - только первый шаг, который удалось осуществить в условиях жесточайшего дефицита времени ресурсами одного человека.
Гена зацепил еще одну, не менее важную проблему - вопрос эволюции явления. Изменяется исторический контекст. Старые понятия утрачивают историческую актуальность. На их основе возникают новые понятия. Должны ли мы наделять старые термины новым пониманием? Вот в Agile начали возвращаться проектные практики, в силу изменения исторического контекста, - он перестал быть Agile? Вот SAGA стала решать проблемы распределенных систем, а не LLT - она перестала быть SAGA? А если она стала хореографической - она остается быть SAGA? Вот появились уровни зрелости CQRS - нужно ли изменить его определение, чтобы включить в него CQS?
Кажется, первый луч света в этом тумане неразберихи начал уже пробиваться.
- https://t.iss.one/ru_arc/165
Хочу оставить свою рецензию.
Что такое архитектурное решение? Его суть сводится к тому, чтобы бесконечно большое множество вариантов реализации сократить до одного единственного варианта. Иными словами, архитектура - это о том, как не надо делать. И здесь важно не многообразие вариантов само по себе, а те критерии, по которым их количество можно сократить.
Если не понимать решаемой проблемы, тогда никакое решение не будет правильным. Непонимание причинно-следственной связи называется в индустрии Карго-культом, а утрата семантических отношений - "Синдромом коллекционера".
Лучше всего драйверы описываются первоисточниками - уж они-то точно знают, какую проблему они решали. Они дают понимание релевантности этой проблемы решаемой проблеме.
Вот об этом доклад Гены.
Какую проблему решала SAGA? А транзакция? А атомарность? А SAGA - это транзакция? А SAGA атомарна? Почему?
Вот Sam Newman утверждает, что SAGA неатомарна, а Chris Richardson - наоборот, что она атомарна. Вероятно, кто-то из них не стал утруждаться исследованием вопроса, но кто же из них прав?
Гена зацепил довольно сложную тему, сложность понимания которой привело к такому бардаку вокруг этой темы. Каких только заблуждений по этой теме мне не приходилось слышать: и то, что SAGA - это stateless, в отличии от Process Manager, и то, что она обязана иметь компенсации, и т.д.
Была проделана колоссальная исследовательская работа по выявлению драйверов, причин, восстановлению исторического контекста и его актуализации. И много работы еще предстоит.
Материал презентации содержит сотни человеко-дней исследовательской работы, и стал возможным исключительно благодаря консолидации опыта специалистов сообщества. И мой вклад тоже отражен в этом докладе, но особенно ценным оказался вклад @beer_Roman .
Вот только малая часть агрегации информации по этому вопросу из чата @ru_arc_chat :
- https://t.iss.one/ru_arc/112
Особое значение этого доклада заключается не в его содержимом, а в том, что он заложил тот самый хребет, на котором может нарастать плоть исследовательской работы, суть которой сводится к конвергенции существующего зоопарка понятий.
Конечно, хотелось бы вместить больше в этот доклад, и есть что в нем улучшить.
Но этот доклад - только первый шаг, который удалось осуществить в условиях жесточайшего дефицита времени ресурсами одного человека.
Гена зацепил еще одну, не менее важную проблему - вопрос эволюции явления. Изменяется исторический контекст. Старые понятия утрачивают историческую актуальность. На их основе возникают новые понятия. Должны ли мы наделять старые термины новым пониманием? Вот в Agile начали возвращаться проектные практики, в силу изменения исторического контекста, - он перестал быть Agile? Вот SAGA стала решать проблемы распределенных систем, а не LLT - она перестала быть SAGA? А если она стала хореографической - она остается быть SAGA? Вот появились уровни зрелости CQRS - нужно ли изменить его определение, чтобы включить в него CQS?
Кажется, первый луч света в этом тумане неразберихи начал уже пробиваться.
Telegram
Russian Association of Software Architects
Делюсь презентацией из доклада с ArchDays 2022.
#SAGA #ArchDays
#SAGA #ArchDays
🔥11❤2👍2🤨1
Roadmap развития системного аналитика. Может пригодится кому-то из архитекторов...
🔷 "Что нужно знать системному аналитику уровня Middle и Senior: план развития Hard Skills" by
AlexeyChijov
#Career
🔷 "Что нужно знать системному аналитику уровня Middle и Senior: план развития Hard Skills" by
AlexeyChijov
#Career
Хабр
Что нужно знать системному аналитику уровня Middle и Senior: план развития Hard Skills
Решил составить для себя план развития (я в IT с 2007, как аналитик - с 2017). Что получилось: некий чек-лист с перечислением 13 блоков (от работы с требованиям до безопасности) с описанием, что...
❤4👍1👌1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
🔷 "SAGA — эволюция и новые смыслы" / Геннадий Круглов @GKruglov: - https://t.iss.one/ru_arc/165 Хочу оставить свою рецензию. Что такое архитектурное решение? Его суть сводится к тому, чтобы бесконечно большое множество вариантов реализации сократить до одного…
Текущий состав Комитета РОО "Объединение ИТ-Архитекторов" на ArchDays'22:
@emacsway , @elukianov , @GKruglov , @sergey486 .
Надеюсь, что с 10 декабря этот состав расширится.
@elukianov и @GKruglov выступили с докладами. Свою рецензию на один из них я приводил в предыдущем посте. После официальной части последовала неофициальная.
@emacsway , @elukianov , @GKruglov , @sergey486 .
Надеюсь, что с 10 декабря этот состав расширится.
@elukianov и @GKruglov выступили с докладами. Свою рецензию на один из них я приводил в предыдущем посте. После официальной части последовала неофициальная.
🔥14🎉5❤1😁1
Russian Association of Software Architects
Более развернутый вариант предыдущей фразы: 💬 "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…
О важности понимания драйверов. Вот в 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-ценность "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
Telegram
Ivan Zakrevsky in RASA Chat
Из тех тем, что я слышал за последнюю неделю, можно на онлайн встрече обсудить:
1. Является ли SAFe возвратом в Waterfall? В последнее время вышло несколько статей с таким утверждением, и здесь есть что проанализировать:
- https://medium.com/agileinsider/the…
1. Является ли SAFe возвратом в Waterfall? В последнее время вышло несколько статей с таким утверждением, и здесь есть что проанализировать:
- https://medium.com/agileinsider/the…
🔥7👍1🤯1
Russian Association of Software Architects
О важности понимания драйверов. Вот в Agile возвращаются проектные практики - это противоречит Agile? Кое-кто считает, что да, и даже выдумывает всякие уничижительные обзывательства типа "Wagile". Возьмем, к примеру, набившую оскомину многим архитекторам…
Когда 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
💬 ...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
martinfowler.com
bliki: Agile Imposition
Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception.
👍5🔥3🤨1
Forwarded from emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
EventStorming для документирования архитектуры нередко применяется даже в литературе, но теперь с этой целью вполне можно использовать PlantUML Activity Diagram (Beta):
- https://plantuml.com/en/activity-diagram-beta
Подробнее о нотации:
- https://www.uml-diagrams.org/activity-diagrams.html
- https://www.uml-diagrams.org/activity-diagrams-reference.html
- https://www.uml-diagrams.org/activity-diagrams-examples.html
- https://www.uml-diagrams.org/activity-diagrams-controls.html
P.S. Я уже говорил в сообществе, что предпочитаю для этих целей ArchiMate "C.1.10 Business Process Cooperation Viewpoint", нотация которого практически 1:1 совпадает с EventStorming, хотя в C4Model для подобных целей предусмотрена "Dynamic diagram".
C4Model + EventStorming удачно сочетаются в документировании Agile Architecture средствами Archi.
#EventStorming #UML #Documenting
- https://plantuml.com/en/activity-diagram-beta
Подробнее о нотации:
- https://www.uml-diagrams.org/activity-diagrams.html
- https://www.uml-diagrams.org/activity-diagrams-reference.html
- https://www.uml-diagrams.org/activity-diagrams-examples.html
- https://www.uml-diagrams.org/activity-diagrams-controls.html
P.S. Я уже говорил в сообществе, что предпочитаю для этих целей ArchiMate "C.1.10 Business Process Cooperation Viewpoint", нотация которого практически 1:1 совпадает с EventStorming, хотя в C4Model для подобных целей предусмотрена "Dynamic diagram".
C4Model + EventStorming удачно сочетаются в документировании Agile Architecture средствами Archi.
#EventStorming #UML #Documenting
PlantUML.com
New Activity Diagram Beta syntax and features
The new syntax is more consistent. You can have start, stop, labels, conditions, while loops, repeat loops, notes, partitions. Changing fonts and colors is also possible.
🔥7👍2
Forwarded from StringConcat - разработка без боли и сожалений (Sergey Bukharov)
Возможно вы пропустили, но вышел новый отчет 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».
Несколько интересных фрагментов
«Надежные (Dependable) команды обеспечивают надежный(Dependable) сервис: творческая командная культура ведет к большей надежности».
Мы видим, что люди с меньшим опытом в целом имеют худшие результаты при использовании trunk based development. (Что и не мудрено. Вы попробуйте trunk based, когда, скажем у вас тестов нет. прим stringconcat)
Хотя она оказывает положительное влияние на общую эффективность организации» (есть предположение о том, что этот результат является неожиданностью, и возможные причины включают гораздо более неопытных участников, чем в предыдущие годы)
«Исследование этого года показало, что loosely-coupled architecture (слабосвязанная архитектура) может способствовать выгоранию команд.
Это удивительное открытие, которое противоречит результатам предыдущих лет. Наш анализ показывает, что стабильно
команды, в которых используется loosely-coupled architecture, имеют более низкий уровень выгорания. Генеративная культура Westrum и стабильность команды поддерживают слабосвязанную архитектуру и снижают выгорание, так что это явно противоречит друг другу. Необходимы дополнительные исследования, прежде чем мы сможем сделать окончательные выводы».
«Самый важный фактор, который мы обнаружили, был вовсе не техническим, а скорее культурным: организации, наиболее близкие к «генеративной» культурной группе Westrum, значительно чаще говорили, что у них широко распространены методы обеспечения безопасности, как это определено в рамках SLSA».
🔥6👌2