О лидерстве на удалёнке:
https://www.theseus.fi/bitstream/handle/10024/794439/Abbasi_Kalim.pdf

Вот таким должен быть архитектор. Я уже говорил ранее, что архитектор выполняет хищнические функции. И подобно этому орлу, он так же гордо должен расправляться с legacy и с несоответствующими решениями.

Узнал, что Taskjuggler есть web-based UI:
https://www.project-open.com/en/integration-taskjuggler

Автор книги в представлении не нуждается:
https://www.tgoop.com/nikitapinchuk/309

Именно. На всякий случай краткая борьба с мифами - Dr Cookie and Mr Token - Web Session Implementations and How to Live with Them (https://www.dais.unive.it/~calzavara/papers/itasec18.pdf)

Очень интересное обсуждение получилось в чате @ru_arc_chat на тему организации аутентификации в распределенной среде с использованием IAM и BFF/API-Gateway.

"Исследование компании / процесса / продукта …", Сергей Баранов

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

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

Основная специализация ребят: MSA, DDD, CQRS/ES, Clean Architecture, IoT, распределенные системы, системная архитектура, управление SDLC процессами разработки, антикризисное управление. Есть немного AI/ML.

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

У группы есть тг-бот @krew_solutions_bot , через который участникам группы можно напрямую написать запрос на услуги Consulting, Enabling, Audit, Outstuff, Outsource, Part-time.

Это не сервер трудоустройства, поэтому, пожалуйста, не нужно никого хантить на Full-time.

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

https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html - прекрасная статья чтобы помочь определиться со статус-кодом "как мы обычно делаем".

по-прежнему ищу статьи про "всегда 200".

💬 Одной из проблем при найме разработчиков является заблуждение о небольшом разбросе в их квалификации – ошибочное мнение, будто программисты не слишком отличаются друг от друга (с точки зрения производительности, качества кода и т. д.). Но исследования показывают, что верхний квартиль по уровню квалификации способен работать примерно вчетверо быстрее, чем нижний [Prechelt00]. Довольно большая разница, согласитесь. Кроме того, модель COCOMO, основанная на многолетних масштабных исследованиях, показывает, что уровень квалификации группы разработчиков – наиболее важный из всех факторов, влияющих на ее производительность [Boehm00]. Наконец, очень слабые программисты в среднем создают код худшего качества (с плохим дизайном) и с бо‌льшим количеством дефектов, что дополнительно тормозит всю систему.

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

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

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

-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева

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

Таким образом, группа разработки входит в самоусиливающуюся нисходящую спираль – последовательность петель положительной обратной связи, где каждая петля усиливает последующую. К счастью, этот нисходящий тренд ограничен бюджетом.

Попробуйте… увидеть в системе петли положительной обратной связи.

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

-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева

"Чтобы жизнь тебя устраивала, сначала устрой её. Иначе она устроит тебя не туда, куда тебя устраивает." — Стас Янковский

Невероятно меткое определение ключевой сути деятельности ИТ-специалиста. Как говорится, если Вы не занимаетесь архитектурой, то архитектура займется вами.

На каждом новом проекте в течении всей своей практики я начинал с того, что создавал себе (и другим) условия работы.

Вначале я научился писать высокоэффективный код. Это когда код качественный и пишется быстро.

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

Потом я понял, что нужно уметь формировать над командой защитный зонтик, чтоб они умели применять навыки в реальных условиях давления бизнеса. Бизнесу нужно быстро, команде нужно качественно, что означает тоже быстро, но завтра. Но бизнес это не всегда понимает. Найти баланс помогла книга "Extreme Programming Explained" 1st edition by Kent Beck.

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

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

В принципе, я уже излагал эту историю здесь.

Чем отличается 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 Architecture 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"

Подробнее здесь.

Но тут есть еще один нюанс, о котором - в следующем посте.

Распределение функций между командой и 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.

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

Кто голосует за вариант 2, тот признает, что интеграционное событие должно находиться исключительно в инфраструктурном слое приложения. Соответственно, политика (Domain Event Hadler), создающая интеграционное событие, является адаптером, и тоже должна находиться в инфраструктурном слое. Соответственно, демонстрационное приложение от Microsoft содержало ошибку.