Краткая выжимка моих ответов из обсуждения этой темы.

Определения:
PBI - элемент беклога (очередь задач на выполнение).
У каждого PBI должна быть бизнес-ценность, а элементы беклога выстраиваются в порядке максимизации бизнес-ценности.

Обсуждение началось с понятия «техническая таска», которыми могут быть enabler, spike, acceptance criteria.

Важно отметить, что:
Enabler всегда привязан к story/epic, он enabler для этого PBI, поэтому наследует бизнес-ценность этого PBI.
Acceptance criteria - это свойство pbi, определяется как часть pbi, у которого определена бизнес-ценность.
Spike - это предусловие для pbi и наследует бизнес-ценность pbi.

Не важно что за pbi рассматривается, - бизнес-ценность должна быть и она должна быть сводимой к некоторой цели, иначе невозможно выставить приоритеты.

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

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

Что делать с техническими задачами вида «настроить CI/CD»?

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

Аналогия с хирургией. В хирургии беклог – это пациенты, ранжированные по степени тяжести состояния. Никто в этот беклог не поместит «кипячение инструмента», «подготовку баллона с кислородом», «дезинфекцию операционной», «покупку новой лампы». Если эти важные, инфраструктурные процессы будут проседать, – инструмент закончится, пациенты будут умирать от заражений, не будут дожидаться своей очереди и так далее, это как раз и есть проблема сопуствующих, поддерживающих процессов.

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

В Team Topologies предложили решение, которое мы практикуем уже лет 20 даже на моей памяти, они его скорее формализовали, – enabling team. Ты должен уметь пользоваться инструментом, но следить за его работоспособностью будут другие люди. Тебе поставят, развернут и настроят CI/CD, но ты обязан уметь пользоваться этим инструментарием, это твой условный скальпель.

Другой класс задач – это архитектурные изменения. Например, в компании перепиливается архитектура, чтобы обеспечить надежность в пять девяток и сделать публичной статистику uptime. Технических изменений много, но они все несут бизнес-ценность, а бизнес-ценность в том, чтобы изменить свою конкурентную позицию на рынке, – брать клиентов высокой надежностью. Это рациональное, взвешанное бизнес-решение, на текущий момент уже год идут изменения и каждый архитектор, PO и разработчик понимает какие конкретно это несет выгоды для бизнеса и почему это важно именно сейчас.

//продолжение

Далее Иван справедливо заметил: «если есть enabling/platform team, то ряд вопросов обретает совсем другой окрас.».
Конечно, Ваня полностью прав, ну а если нет такой enabling/platform team, то у тебя одна физическая команда поделена на две логические и это тот еще ад. Тот самый условный хирург еще и инструмент моет, пол моет, закупами медикаментов занимается, каталку катает и так далее. Аналогия один-в-один.

Можно накидать в беклог задач, вроде:
- заплатить налоги
- заплатить пенсионные взносы
- подготовить договор с заказчиком
- подготовить закрывающие документы
- арендовать землю под подстройку второго офиса
- починить принтер
…

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

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

Через минуту стартуем митап
«Тернистый путь инструмента цифрового проектирования».

Спикер: Виктор Выскребенцев — Исполнительный директор в ПАО Сбербанк.


Yotube-трансляция: https://www.youtube.com/live/jP_AROux7Fs?feature=shared

(запись доступна по этой же ссылке)

Нашел у себя план архитектурного кикофа (совместное формирование первичного видения архитектуры), Last edit was about 8 years ago 🙂

Зачем мы здесь собрались?
Просто и четко опишите проблему, которую намереваетесь решить.

Каково видение?
Опишите, как предлагаемый продукт решает ранее описанную проблему.

В чем ценность?
Опишите бизнес-ценности продукта.

Каков скоуп?
Перечислите наиболее приоритетные из уже известных функциональные требования. Обычно — это must have фичи.
Перечислите то, что не входит в скоуп.
Какие фичи могут повлиять на архитектурное решение?

Кто ключевые заинтересованные лица?
Перечислите заинтересованных лиц и их основной интерес

Как выглядит наиболее просто решение?
Скетч номинальной архитектуры. Это может быть неформальная диаграмма.

Каковы ключевые риски?
Перечислить топ ключевых рисков.

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

Каковы ожидания по компромиссам?
Обсудите ключевые компромиссы прежде чем переходить к принятию сложных решений. Обсудите большую четверку: стоимость, скоуп, сроки и качество. Обсудите важные атрибуты качества.

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

Еще из старого:

«Bounded Context» как решение проблем с аморфными терминами через контекстные границы доменных моделей

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

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

Объемная статья про практики распределенной трассировки.

https://www.zerok.ai/post/distributed-tracing-best-practices

А админ-то прав 🙂

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

Во-первых, в такой ситуации важно не накопить критическую массу отказов, при которой вся система умрет.

Во-вторых, в таких системах точно известно, что отказы неизбежны, но неизвестно что конкретно и когда откажет.

Вот поэтому и нужно уметь поднимать быстро :)

У подлодки очередной движ, неделя баз данных:

https://podlodka.io/javacrew

В 19:00 Иван Волынкин (OneCell) расскажет как предоставить команде возможность работать на разных dev окружениях с разными ветками и всегда знать, где что задеплоено.

Подключайтесь по ссылке на эфир и задавайте вопросы спикеру: https://www.youtube.com/live/sViiClT1t-M?feature=shared

Ваня пилит достаточно классный и удобный open source инструмент: https://github.com/jonasasx/envrouter 🙂

В видео Ваня показал envrouter в действии, демка пока даже доступна публично https://demo.envrouter.ru (как я понял 1-2 дня будет доступна)

Кому интересно попробовать или поконтрибьютить, чат проекта:
https://tttttt.me/envrouter_ru

♻️ Виды потерь, через призму которых можно посмотреть и на процессы, относящиеся к работе с архитектурой

Неэффективная верификация
Неэффективное тестирование, прототипирование, подтверждение; например — поддержка тестов стоит дороже, чем тем риски, которые они митигируют

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

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

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

Недостаток в требуемых компетенциях
Недостаток навыков или знаний, требуемых для выполнения задачи; например: неэффективное использование IT-инструментов из-за недостаточных навыков

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

Перегрузка информацией
Большие размеры партий работы (batch size), распространение и хранение ненужной информации; например: слишком большое количество информации усложняет процесс поиска релевантной информации

Нечеткие ответственности
Нечеткие ожидания в отношении производительности и организационных ролей; например: наложение компетенций и ролей

Недостаточные коммуникации
Коммуникации требуют значительного времени и усилий, при этом не добавляя ценности; например: недостаточная коммуникация ведет к исправлению неверной выполненной работы (rework)

Множественная интерпретация информации
Форма представления информации ведет к возможности множественной интерпретации; пример: отсутствие стандарта документирования

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

Недоутилизация
Использование навыков и компетенций не самым эффективным способом

Оверинжинирнг
Добавление фич, которые не добавляют ценности клиенту; пример: возросшая стоимость разработки и поддержки как результат избыточных требований

Ненужное преобразование данных
Перевод данных из одного формата в другой из-за использования неподходящих инструментов и недостатка в стандартизации; пример: переформатирование или повторный ввод данных

Недостаток в распространении знаний
Отсутствие обмена информацией, экспертизой и навыками; пример: старт новых проект не использует опыт, полученный при старте прошлых проектов

Обработка ошибочной информации
Обработка информации, основанной на правильных потребностях, но потребности не полностью удовлетворены; пример: при обработке информации не выявлена ее дефектность, что влияет на другие процессы

Изменение требований
Внутреннее или внешнее изменение требований; пример: изменения могут привести к rework, особенно если они произошли в конце процесса

Барьеры в кооперации
Нежелания взаимодействия; пример: недостаточное владение ведет к снижению мотивации

🧩 Виды прототипов в связке с архитектурой

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

Spike
Цель – лучше понять проблемную область. Сохраняется только результат исследования, код уничтожается.

MVP
Цель – выпустить минимальное жизнеспособное решение относительно самого себя в будущем, но конкурентноспособное относительо рынка.

Ходячий скелет
Форма PoC для основной концепции архитектуры. Специализируется на реализации одной самой простой функциональности, минималистичной реализации end-to-end сценария. Это не точное отражение архитектуры, лишь «скелет», который тем не менее должен быть «ходячим», то есть потенциально мы имеем возможность отгрузить его заказчику. Он должен быть покрыт тестами.

Alistair Cockburn очень точно описал этот феномен (http://alistair.cockburn.us/Walking+skeleton):

A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in working, shippable and testable code. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.

Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A skeleton of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.

Краткая выжимка из ответов на вопрос о распределении данных из чата по микросервисам, показалось важным, так как ситуация распространенная:

Вопрос
Есть два микросервиса: документы и авторизация. Документы реализует всю свою бизнес логику, авторизация свою. В документе есть ссылка на пользователя из авторизационного сервиса. Например я делаю грид с документами, где я должен показать не просто id пользователя а его имя фамилию. В каком месте правильнее переводить ID в имя фамилию? На стороне сервиса документов или на стороне UI?

Ответ
Если подойти к вопросу с позиции предметно-ориентированного проектирования.

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

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

С другой стороны, если это только чтение и никакой логики касательно имени и фамилии нет в предметной области (которая шире кода), то BFF здесь выглядит наиболее рациональным. Да в этом случае это дополнительные накладные расходы, – дополнительный сервис, кодинг, деплой и проч, но зато чистый сервис документов, который ничего не знает о сервисе авторизации и его API + масштабирование выглядит более простым в случае необходимости.

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

Ссылка на оригинальное обсуждение: https://tttttt.me/microservices_ru/26794

Нашел в архиве требования безопасности, уж не помню к какому точно проекту формулировал, еще в 2012-м году, может кому-то будет полезно.

Делайте скидку на то, что это было почти 12 лет назад, появились новые угрозы, но что-то почерпнуть точно можно :)

Почти совсем оффтопик.

Очень давно посмотрел этот ролик и все никак не мог потом найти, – название не запомнил. А запомнился он мне ровно тем, что, казалось бы, 1986-й год, а многие компании работают, продукты разрабатываются и архитектурные решения принимаются ровно так, как описал Михаих Жванецкий.

Кто не видел – не пожалейте времени, всего 6 минут. Это шедевр 🙂

Михаил Жванецкий - Паровоз для машиниста (1986)
https://www.youtube.com/watch?v=srfeL88Oov8

Почитать под вечерний кофе

https://www.infoq.com/news/2023/10/uber-up-cloud-microservices/

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

Оставлю один тут, как опорный, чтобы потом можно было вспомнить и найти :)

If I'm a McAfee user, what are the five things that a user can do? It shouldn't overreach. It should be complete. And you should provide all of that functionality. It's almost like taking these little, itsy, bitsy pieces of things that you can stitch together. And then you think ‘that’s a noun, what does it provide in terms of verbs that can be done to it? 
Or what can it do to other nouns in the system? So that's the domain decomposition, which is the first exercise. 

https://diginomica.com/mcafee-adopts-microservices-using-confluent-cloud-scale-its-architecture-and-services?amp

ArchDays занял столько времени, что подготовить не оказалось времени, а на пикнике не велась запись.

Так что, – надо повторить :)

К концу месяца доработаю выступление, добавив в него деталей и сделаю онлайн выступление.

Скоро анонс, а пока можете написать в комментарии к этому сообщению свои вопросы или идеи (может кто из канала был на выступлении, какие темы были не раскрыты или раскрыты не полностью).

А кто хочет погрузиться глубже, – начинайте с гугления ATAM и CBAM, проверенные годами подходы, а позже я напишу какие с ними проблемы (точнее, – не с ними, с аудируемыми решениями, но сути это не изменит).

Кто использует https://raml.org для API?
Поделитесь впечатлениями.