Nikita Pinchuk professional channel: IT / EA / BA / Architecture

Читал эту книжку давно, но вот сегодня упоминал о ней на одном вебинаре о комплексном взгляде на проектирование иб продуктов. О принципах, бизнес модели, ну и об архитектуре, конечно же. Platform Ecosystems: Aligning Architecture, Governance, and Strategy https://a.co/d/0dn2YWo

Петли положительной или отрицательной обратной связи[9] и отложенные эффекты – тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов – учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте. Таким образом, группа разработки входит в самоусиливающуюся нисходящую спираль – последовательность петель положительной обратной связи, где каждая петля усиливает последующую. К счастью, этот нисходящий тренд ограничен бюджетом. Попробуйте… увидеть в системе петли положительной обратной связи. По мере того как уходит все больше крутых разработчиков, которые могли бы создавать отличный код и обучать других, у слабых разработчиков становится все меньше возможностей для обучения. Процент слабых разработчиков растет, а качество кода и производительность падают все ниже. Код становится все более грязным, запутанным, с большим количеством повторений, что снижает способность группы быстро реализовывать новую функциональность. Падение скорости реализации новой функциональности вынуждает нанимать еще больше дешевых разработчиков. Короче, в системе создается множество самоусиливающихся петель положительной обратной связи. -- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева

Свежая картинка по продуктам с открытым кодом в области дата инженерии. Подробнее о ней в блоге её автора на Substack [1]. А я скажу что такие картинки хороши когда надо синхронизировать картинку в голове с изменениями за год, правда, мне лично, вот такой иконостас иконок всегда казался не наглядным и куда практичнее были обзоры по наиболее интересным развивающимся и новым продуктам. Вот в этой картинке, например, нет SODA для data quality, в платформе метаданных зачем-то CKAN, хотя он про другое. Я, кстати, несколько по другому систематизирую инструменты с открытым кодом. Когда-то просто стал делать закладки в Github по категориям [2] и там много их, больше 30 списков. А заодно для тех кто интересуется разного рода экзотическим открытым кодом. Markdowndb [3] наглядная реализация принципов "всё таблица" и "всё SQL". Это фреймворк превращающий документы с разметкой Markdown в SQL базу данных к которой можно делать запросы к содержимому этих файлов с фильтрацией по тэгам, файлам и тд. Внутри используют Sqlite, в гайдах рассказывают как заменить статические файлы на эту базу в статических сайтах. Ссылки: [1] https://practicaldataengineering.substack.com/p/open-source-data-engineering-landscape [2] https://github.com/ivbeg?tab=stars [3] https://markdowndb.com #opensource #data #dataengineering #datatools

#techdebt

Распределение функций между командой и Product Owner работает только тогда, когда когда достигается цель - поддержание постоянства скорости разработки по мере роста размеров системы. Иными словами, когда команда достаточно грамотна в Software Design. Именно об этом говорит принцип Agile Manifesto: 🔷 "Continuous attention to technical excellence and good design enhances agility." Именно поэтому, на Snowbird Meeting присутствовал весь архитектурный бомонд того времени. Именно поэтому Agile был создан архитекторами. Что произойдет, если команда недостаточно подготовлена по Software Design? Кодовая база будет загнивать, темпы разработки будут деградировать, команда утратит доверие со стороны Product Owner, и Product Owner начнет возводить защитные стены от команды, затягивая в свою зону ответственности все решения по системному инкременту. Иными словами, он начнет указывать команде не только то, "что" нужно сделать в User Story, но и "как" команда должна это реализовать. Т.е. возникнет ситуация, описанная в начале предыдущего поста. Звучать это будет примерно так: "давайте пока поставим костыль, а потом исправим". Естественно, это "потом" никогда не наступит. Команда тоже начнет возводить свою защитную стену, и начнет твердить, что все нужно сжечь и переписать. И возможно, команда даже уговорит Product Owner, и он выделит ресурсы, но через пару месяцев все снова сгниет. Потому что код или самоочищается, если команда знает Software Design, или загнивает. Каждая сторона отгородилась от другой стороны непробиваемой стеной. Ключевая цель Agile утрачена. Agile больше не выполняет своих функций. В моем списке литературы приводятся 5 книг, без которых остается мало шансов организовать эффективную разработку и завоевать доверие Product Owner. Молодые специалисты часто думают, что они придут в компанию, и их научат работать. В подавляющем большинстве случаев их научат тому, как не нужно строить системы. Практически все известные мне крутые специалисты сформировались не благодаря условиям работы, а вопреки им.

Чем отличается User Story от Task? Написать пост на эту тему меня потдолкнула недавно опубликованная ссылка на статью о техдолге в чате канала, а именно эти строки: 💬 "Doubtful developers may say, “But what if management deprioritizes or discards the technical debt subitems?”" В целом статья неплохая, но есть нюанс. Как говорил человек, который создал роль Product Owner и Scrum-Master: 💬 "So I split the role in two, giving the Scrum Master the how and the Product Owner the what. <...> The Scrum Master and the team are responsible for how fast they're going and how much faster they can get. The Product Owner is accountable for translating the team's productivity into value." —"Scrum: The Art of Doing Twice the Work in Half the Time" by Jeffrey Sutherland Именно команда ответственна за скорость разработки. А скорость разработки напрямую зависит от внутреннего качества программы, т.е. за Software Design. Говоря архитектурным языком, команда отвечает за Quality Attribute Modifiability. Product Owner описывает в User Story функциональный инкремент, в то время как команда декомпозирует его на Tasks, которые описывают системный инкремент. Одна и та же функция может поддерживаться различными вариантами конструкций. В качестве подкпорки под дверь можно использовать конструкцию в виде камня, а можно и в виде книги. И, наоборот, одна и та же конструкция может выполнять разные функции. Например, тот же камень можно использовать в качестве функции якоря, или орехи им колоть. Это т.н. дихотомия функции и конструкции. Конструкция может совпадать с функцией, а может не совпадать. Как и Bounded Context (Solution Space) может совпадать с Subdomain (Problem Space), а может не совпадать. На простом примере: у ножниц два функциональных компонента, один - чтоб держать, а другой - чтоб резать. Но конструктивно ножницы состоят их двух половинок и гвоздика. Иногда конструктивный элемент иногда называют модулем, а функциональный - компонентом. Но вернемся к User Story. Поясню на примере. Камень сам по себе бесполезен для разжигания костра. Два камня бесполезны сами по себе. Но два камня во взаимодействии могут высекать искру. У них появилось новое, emergent свойство, т.е. они образовали систему. Система обладает свойствами, которыми её элементы по отдельности не обладают. Так вот, Product Owner пишет "нужна искра". Это функциональный инкремент, добавляющий новую, видимую функциональность в систему, которую можно протестировать приёмочными тестами уровня компонентных или сквозных тестов. Отдельно взятый камень протестировать на уровне компонента или системы нельзя, т.к. он сам по себе не обладает emergent свойствами. Они появятся только тогда, когда будут завершены все необходимые системные инкременты, которые образуют систему. Product Owner не пишет в User Story "взять один камень, взять другой камень". Это пишет команда в Tasks, на которые декомпозируется User Story. Product Owner отвечат за функцию, а команда - за конструкцию. Это нерушимое правило, нарушение которого приводит к накоплению техдолга и к деградации темпов разработки, что, в свою очередь, приводит к утрате экономической целесообразности итеративной разработки, поскольку внесение изменений становится дороже заблаговременного проектирования. На эту тему есть у меня хороший Long Read. Команда не должна согласовывать с Product Owner системный инкремент. Вот что по этому поводу говорит Open Agile Standard: 💬 Fowler would strongly promote the view that code refactoring requires no justification; rather it is part of a developer's "day job". This does not mean that we have to take on a massive code restructuring exercise for a legacy codebase; on the contrary, there may be no reason whatsoever to restructure the code for a stable legacy project. However, that said, developers should refactor their code when the opportunity arises. —"Open Agile Architecture™" by The Open Group, Chapter "6.5.1. Justifying Ongoing Investment in Architectural Refactoring" Подробнее здесь. Но тут есть еще один нюанс, о котором - в следующем посте.

В продолжение предыдущих ссылок на bmm и строгую метамодель - добавлю вот это: https://4brain.ru/blog/%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0-%D1%81%D0%B5%D0%BF%D0%B8%D1%80%D0%B0-%D1%83%D0%BE%D1%80%D1%84%D0%B0/

“Using the ArchiMate® Modeling Language with BMMTM Representing the Concepts of the Business Motivation Model (BMM) using the ArchiMate 3.0 Specification A White Paper by: Ed Walters and Antonio Plais” https://www.tud.ttu.ee/im/Enn.Ounapuu/W179.PDF

Несправедливо недооцененная техника. Business motivation model. https://www.omg.org/spec/BMM/1.3/About-BMM https://youtu.be/XQ2WMqz4QCA?si=ZrMG3-q21_8OE4Do

Тут подборка литературы по оцениванию и планированию.