RT
Эти ваши скрам команды оказались на практике такими же siloes, только в другой проекции.
Size: a a a
2019 October 10
АЕ
не отслеживаю бизнес-метрику и не слежу за спринтами, этим занимаются руководители проектов
EI
Эти ваши скрам команды оказались на практике такими же siloes, только в другой проекции.
Это, как говорится, depends on.
Бывает и по-другому
Бывает и по-другому
PD
На самом деле, командный дух тоже способствует "силосности", а скрам поощряет замыкание команды на саму себя.
EI
На самом деле, командный дух тоже способствует "силосности", а скрам поощряет замыкание команды на саму себя.
Прямо как и написано во втором Agile-манифесте - http://beyondagilemanifesto.org/
Кент Бек писал его не от радости, что всё работает ка нужно.
Кент Бек писал его не от радости, что всё работает ка нужно.
EI
Правильно понимаю, что нужен новый манифест?
RT
На самом деле, командный дух тоже способствует "силосности", а скрам поощряет замыкание команды на саму себя.
Вот-вот. А собирать работу команд в общую сверх задачу приходится архитектору
PD
Правильно понимаю, что нужен новый манифест?
Каждому продукту нужен свой манифест.
Я почти серьезно.
Я почти серьезно.
PD
Вот-вот. А собирать работу команд в общую сверх задачу приходится архитектору
Ну, иногда архитектору, иногда PM, иногда еще кому-нибудь
Там разные сценарии...
Там разные сценарии...
EI
Каждому продукту нужен свой манифест.
Я почти серьезно.
Я почти серьезно.
Да, поддерживаю.
OS
Правильно понимаю, что нужен новый манифест?
Недавно люди в твиттере стали считать новые манифесты... На цифре 35 перестали
PD
Ну, а зачем их считать. Их надо рефлексировать и понимать, а что нужно в данном конкретном месте.
EN
Нужен архитектор манифестов для начала
EI
Недавно люди в твиттере стали считать новые манифесты... На цифре 35 перестали
Я с 1840 года по 1920 насобирал штук 30. Нужно было.
Манифест - это способ работы, и не нужно его стесняться :)
Манифест - это способ работы, и не нужно его стесняться :)
PO
Я с 1840 года по 1920 насобирал штук 30. Нужно было.
Манифест - это способ работы, и не нужно его стесняться :)
Манифест - это способ работы, и не нужно его стесняться :)
Кажется, манифест это не только способ работы...
AL
Кажется, манифест это не только способ работы...
Манифест - заявление о намерении. Может быть источником требований.
Почему вы его приравняли к "способу работы" б
Почему вы его приравняли к "способу работы" б
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
Есть у кого отклик на этот текст? Или своё понимание роли "владелец продуктовой архитектуры"?
RT
На мой взгляд не стоит связывать архитектуру с командой, архитектор должен быть вне контекста команд, так и тллько так его взгляд на вещи будет полон и объективен
EI
На мой взгляд не стоит связывать архитектуру с командой, архитектор должен быть вне контекста команд, так и тллько так его взгляд на вещи будет полон и объективен
Архитектор как человек, или как роль?
Я выше писал, что я за третий вариант - за командную роль Продуктового Архитектора.
Если брать второй вариант - в каждый продукт по "живому архитектору навсегда" - то да, это трата времени и людей.
Я выше писал, что я за третий вариант - за командную роль Продуктового Архитектора.
Если брать второй вариант - в каждый продукт по "живому архитектору навсегда" - то да, это трата времени и людей.
EI
В том, какой мотив и какая рамка удержания целостности.
Или ты снаружи продукта, и консультируешь
Или ты внутри продуктов, и живёшь в продуктовом подходе
Или ты передаёшь Архитектуру как роль команде, и помогаешь в сложные минуты
Или ты снаружи продукта, и консультируешь
Или ты внутри продуктов, и живёшь в продуктовом подходе
Или ты передаёшь Архитектуру как роль команде, и помогаешь в сложные минуты
+