Двигаемся дальше, завершаю знакомство со всеми ключевыми ролями и практиками SAFe и это еще не конец.

обновил список литературы по экономике разработки ПО, если кому надо.

Сегодня вышло мое полное интервью о современной роли архитектора.

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

В общем, интервью аж на час!

https://m.youtube.com/watch?v=h3KgPzgVR3A

Не судите строго, это мой первый опыт большого интервью. Приходилось много работать с волнением.

YouTube

СТЕЙКХОЛДЕРЫ с Ярославом Павловым. Гость: Роман Пионтик

Шоу "Стейкхолдеры", где ректор ИМИСП, Ярослав Павлов, берет интервью у слушателей и выпускников бизнес-школы. Этот сезон посвящен слушателям программы DBA. Герой нового выпуска- Роман Пионтик, исполнительный директор департамента корпоративной архитектуры…

За что отвечает архитектура?

1. За выявление наиболее существенных требований и за разрешение противоречивых (конфликтующих или обратно-коррелирующих требований).

2. За устранение напряжения между требованиями и конструкцией (это когда то, что хотим, - не можем, а то, что можем, - не хотим).

3. За выбор способа разрешения неопределенности требований путем выбора соответствующей SDLC-модели разработки. Т.е. за выбор соотношения предиктивного и адаптивного способов разрешения неопределенности.

4. В случае выбора адаптивного способа обработки неопределенности (итеративная SDLC-модель разработки и её производные) - за достижение Quality Attribute Modifiability. Т.е. за максимизацию количества открытых решений, где открытость определяется стоимостью изменения решения. Т.е. за опеспечение постоянства скорости (стоимости) разработки по мере роста размера системы. На практике график роста стоимости разработки обычно обретает характер роста близкий к логарифмическому, и задача архитектуры - предотвратить экспоненциальный рост. Достигается это путем минимизации когнитивной нагрузки, т.е. путем управления сложностью, и локализацией изменений. Если этого не сделать, то адаптивный способ разрешения неопределенности утратит экономическую целесообразность, поскольку стоимость реализации решения будет существенно зависеть от момента принятия решения.

5. В случае выбора многокомандной инкрементальной SDLC-модели разработки и её производных (Scaled Agile) - за обеспечение постоянства скорости разработки по мере увеличения количества команд разработки, т.е. за решение Проблемы Брукса. Достигается это путем минимизации коммуникативной нагрузки на команды разработки за счет выявления правильных границ Bounded Contexts.

Это те функции, для осуществления которых нанимается архитектор.

Теперь подойдем к часто обсуждаемому в профессиональных сообществах вопросу.

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

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

https://devcrowd.ru/pm24/

Исследование рынка продактов, 2024

Исследование рынка продактов, 2024 — ​​

DevCrowd вместе с Яндексом провели исследование продактов 2024

?‍?Плейбук для развертывания инструментов разработчика

После переустановки Linux решил наконец собрать скрипт для установки тулинга на свежую ОС. Надоело красноглазить?

Вылилась эта затея в Ansible Playbook с Golang, Python, Docker, K8s, Helm, Git, VS Code с плагинами, ZSH.

Установка в одну команду?.

Выложил на Github, чекайте, если вам интересна тема рабочего тулинга и Ansible?

https://github.com/abstractart/local-machine-playbook

GitHub

GitHub - abstractart/local-machine-playbook: 👨‍💻Prepare your laptop for Development in one shell command. Includes Golang, Python…

***👨‍💻***Prepare your laptop for Development in one shell command. Includes Golang, Python, VS Code, Docker and tools for it! - abstractart/local-machine-playbook

В этой же книге: ? Когда два сотрудника друг другу в курилке жалуются на начальство: «Блин, опять переезд в новый офис. Сколько можно? Третий раз за год! Заколебали уже…» – это не вполне конструктивно. Потому что, если есть проблема с переездами, они вряд…

В этой же книге:

? Когда два сотрудника друг другу в курилке жалуются на начальство: «Блин, опять переезд в новый офис. Сколько можно? Третий раз за год! Заколебали уже…» – это не вполне конструктивно. Потому что, если есть проблема с переездами, они вряд ли решат ее между собой в курилке.
Вот если кто-то после этого разговора пойдет к начальствувыяснять, что и как с переездами, то произойдет переключение в конструктив.

Тут я с автором второй раз не соглашусь, что, правда, не уменьшает ценность книги. Те, кто знаком с теорией управления изменениями, знают, что иногда бо‌льшего совокупного эффекта можно достигнуть, если позволить кризису назреть, нежели пытаться его компенсировать. Сейчас уже не вспомню, кто автор этого подхода, кажется John P. Kotter (поправьте, пожалуйста, если я ошибаюсь).

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

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

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

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

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

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

Telegram

emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

***💬*** Пример из жизни. На одном из тренингов на этапе сбора ожиданий мы обычно спрашиваем всех участников, чего они ждут от этих двух дней и какие вопросы хотят разобрать. Доходит очередь до инженера лет тридцати с очень уставшим видом: – Я хотел бы научиться…

Вышел BIZBOK v13, пойду полистаю. Анонс был такой:
The Business Architecture Guild®****, a global community of business architecture practitioners, announced today that A Guide to the Business Architecture Body of Knowledge® (BIZBOK® Guide) v13 is now available.  
The BIZBOK is a comprehensive collection of industry best practices that established and continue to serve as the basis for the business architecture discipline and the engine behind end-to-end strategy execution. Updated annually, BIZBOK v13 includes new and enhanced industry reference models, product mapping enhancements, and a wide variety of updates targeted at enhancing industry best practices and adoption.

New this year is the addition of the International Development Organization (IDO) Reference Model.

This new business architecture baseline helps mission-based organizations, like the United Nations and non-governmental organizations like Oxfam, achieve their primary goal of addressing economic, social, and political development in countries and communities around the world.

A second notable enhancement expands the use of product entitlements to optimize customer service delivery across products and product lines. The quality of an organization's customer service delivery can make the difference between long-term success or failure. These latest product mapping enhancements address the customer service optimization challenge directly.

Additional enhancements include refreshed industry reference models for financial services, government, healthcare provider, insurance, manufacturing, telecommunications, and transportation. Cyclical updates include practice-driven strategy, capability, organization, value stream, information, initiative, and stakeholder mapping improvements along with business model alignment, performance metrics, service-oriented architecture, and metamodel enhancements.

Групповое поведение в организации. https://xn--80aabdcpejeebhqo2afglbd3b9w.xn--p1ai/%D0%BC%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D1%8B/160/525