PD
О, и чем?
Size: a a a
2019 October 10
PD
Т.е. что они ответили такое?
EI
Т.е. что они ответили такое?
Я в ЛС напишу во избежании религиозных споров :)
PD
АЕ
» консультировать команды разработки и руководителей проектов
Позиция архитектора-консультанта очень важна, но я не знаю, как из неё рассказать про продуктовый подход.
Это просто разные дизайны командной работы - консультирование и team
Позиция архитектора-консультанта очень важна, но я не знаю, как из неё рассказать про продуктовый подход.
Это просто разные дизайны командной работы - консультирование и team
Несколько команд разработки реализует большую архитектурную задачу, скажем на 3-6 месяцев, которую я описал как последовательность других задач, зачем мне быть частью каждой из команд и участвовать в их собраниях?
EI
Несколько команд разработки реализует большую архитектурную задачу, скажем на 3-6 месяцев, которую я описал как последовательность других задач, зачем мне быть частью каждой из команд и участвовать в их собраниях?
» большую архитектурную задачу
Можете пояснить?
Можете пояснить?
АЕ
задача с большими изменениями в архитектуре систем и связей между ними
PD
А зачем эта задача? Откуда взялась?
EI
Я перенесу из личного обсуждения пару абзацев:
EI
Кто помогает продукту понять, что изменится, если они перепишут часть приложения X и не будут делать US Y и не будут переходить на асинхронную очередь Z?
EI
Кто помогает продукту понять, что изменится, если они перепишут часть приложения X и не будут делать US Y и не будут переходить на асинхронную очередь Z?
Например, возьмём продукт Abc.
В Biz-домене 240 US и 33 эпика
В App-домене восемь репозиториев (суммарно 178 компонентов)
В Data-домене три базы + 18 витрин из hadoop
В Tech-домене 9 технологий, K8s на 16 контейнеров + внешние базы + сеть + ...
В Biz-домене 240 US и 33 эпика
В App-домене восемь репозиториев (суммарно 178 компонентов)
В Data-домене три базы + 18 витрин из hadoop
В Tech-домене 9 технологий, K8s на 16 контейнеров + внешние базы + сеть + ...
EI
Продукт существует поверх всех четырёх доменов одновременно.
Так?
Так?
EI
Несколько команд разработки реализует большую архитектурную задачу, скажем на 3-6 месяцев, которую я описал как последовательность других задач, зачем мне быть частью каждой из команд и участвовать в их собраниях?
Ответить одновременно из 4 доменов - это, по мне, задача архитектора.
Это возможно, если он находится не в позиции тех.консалтера (или согласователя) относительно продукта - а является неотемлемой частью владения (own) продуктом.
Это возможно, если он находится не в позиции тех.консалтера (или согласователя) относительно продукта - а является неотемлемой частью владения (own) продуктом.
АЕ
Наш "продукт" состоит из нескольких продуктов, у которых есть владельцы продукта, но нет архитекторов в командах разработки. Архитектор определяет за согласованное в техническом плане развитие продуктов.
OS
EI
Наш "продукт" состоит из нескольких продуктов, у которых есть владельцы продукта, но нет архитекторов в командах разработки. Архитектор определяет за согласованное в техническом плане развитие продуктов.
Домен Tech покрыт.
А три другие домена?
А три другие домена?
EI
Например, возьмём продукт Abc.
В Biz-домене 240 US и 33 эпика
В App-домене восемь репозиториев (суммарно 178 компонентов)
В Data-домене три базы + 18 витрин из hadoop
В Tech-домене 9 технологий, K8s на 16 контейнеров + внешние базы + сеть + ...
В Biz-домене 240 US и 33 эпика
В App-домене восемь репозиториев (суммарно 178 компонентов)
В Data-домене три базы + 18 витрин из hadoop
В Tech-домене 9 технологий, K8s на 16 контейнеров + внешние базы + сеть + ...
#Развить(↑→)
Возьмём пять продуктов компании F. Пять внутренних пересечений по 4 доменам + межпродуктовые по 4 доменам.
Возьмём пять продуктов компании F. Пять внутренних пересечений по 4 доменам + межпродуктовые по 4 доменам.
АЕ
А это на каком языке?
EI
А это на каком языке?
Archimate-нотация, Biz+App+Tech + отдельно выделенный Data-домен
EI
Недавно написал такой текст
——-
Основная задача роли "Architecture owner" - вместе с "работающим продуктом" (Agile manifesto, вторая строка) доставлять решение, которое:
1) синхронизировано с процессами/жизненными циклами (ЖЦ) трёх основных продуктовых доменов (Customer, MVP, EA)
2) обеспечивает согласование между пользователями, командой и EA о возможных вариантах нарушения ЖЦ через модель ограничений
3) создаёт предпосылки к такому изменению ЖЦ в доменах Customer/MVP/EA, которое уменьшает их внутренние долги по отношению друг к другу (cross-debt).
Таким образом, есть четыре основных вектора действия роли "Architecture owner":
- Работа с командой над пониманием процессов/жизненных циклов пользователей продукта и их ограничений (домен Customer)
- Работа с командой над пониманием собственных процессов/жизненных циклов и их ограничений (домен MVP)
- Взаимодействие с ролью "Enterprise Architect" над пониманием EA-процессов/жизненных циклов и их ограничений (домен EA)
- Работа по уменьшению cross-debt
——-
Основная задача роли "Architecture owner" - вместе с "работающим продуктом" (Agile manifesto, вторая строка) доставлять решение, которое:
1) синхронизировано с процессами/жизненными циклами (ЖЦ) трёх основных продуктовых доменов (Customer, MVP, EA)
2) обеспечивает согласование между пользователями, командой и EA о возможных вариантах нарушения ЖЦ через модель ограничений
3) создаёт предпосылки к такому изменению ЖЦ в доменах Customer/MVP/EA, которое уменьшает их внутренние долги по отношению друг к другу (cross-debt).
Таким образом, есть четыре основных вектора действия роли "Architecture owner":
- Работа с командой над пониманием процессов/жизненных циклов пользователей продукта и их ограничений (домен Customer)
- Работа с командой над пониманием собственных процессов/жизненных циклов и их ограничений (домен MVP)
- Взаимодействие с ролью "Enterprise Architect" над пониманием EA-процессов/жизненных циклов и их ограничений (домен EA)
- Работа по уменьшению cross-debt