Deconfigurazione del ruolo di Solution Architect e Product Owner

Question

Deconfigurazione del ruolo di Solution Architect e Product Owner

#1 da (3 voti)

-1

Attualmente lavoro come Solution Architect all'interno di un'organizzazione Scaled Agile. Abbiamo anche proprietari di prodotti che sono in termini di società "di grado superiore" rispetto al gruppo di supervisione tecnica a cui appartiene l'architetto della soluzione. Il gruppo di supervisione tecnica stabilisce gli standard e esamina le idee di miglioramento dei processi. Occasionalmente, ci imbattiamo in situazioni mentre i processi, l'architettura, ecc. Si scontrano con ciò che il Product Owner vuole e fa sì che il Product Owner sostituisca il Solution Architect's anche con un RAA stabilito per la società, questo si verifica ancora.

All'interno di un framework Scaled Agile, i proprietari dei prodotti intendono avere il loro ruolo progettato in questo modo poiché sono i "proprietari"?

project-management agile scaled-agile-framework

posta Solution Architect 04.09.2018 - 16:06

fonte

1 risposta

Leggi altre domande sui tag project-management agile scaled-agile-framework

Creazione di un programma simile a CMD (Command Line Parser) Qual è esattamente il significato di "nodo" in Document Object Model (DOM)?

score 3 · Answer 1

In né Scrum né SAFe il proprietario del prodotto ha il controllo sui dettagli di implementazione della soluzione. Rappresentano le esigenze del cliente e possiedono il backlog di capacità che devono essere costruite da un punto di vista del prodotto.

Il team dovrebbe avere una definizione di fatto che stabilisca le aspettative di qualità per l'implementazione. Il team promette di soddisfare tutti gli elementi applicabili su tale DoD per qualsiasi articolo arretrato che assumono e i Proprietari del prodotto promettono di dare loro il tempo di farlo.

È vero che è nella loro proprietà declassificare gli elementi di miglioramento architettonico complessivo, il debito tecnico e altre preoccupazioni. Nella mia esperienza, non è mai nel loro interesse in quanto erode la fiducia della squadra e il successo a lungo termine del prodotto. In particolare, ciò comporta un debito tecnico che rende le funzionalità successive molto più costose da implementare.

Dovrebbe esserci una salutare tensione tra i ruoli. Tuttavia, come in una partita di tiro alla fune, se entrambe le parti sono troppo forti o troppo deboli, tutto cade. Se il Product Owner utilizza l'autorità organizzativa per dettare "come" il team implementa il lavoro, stanno lavorando contro l'intento di Scrum e SAFe e probabilmente stanno creando una serie di effetti collaterali negativi nel processo.

Se vuoi saperne di più sull'implementazione prevista, darei un'occhiata alla Guida di Scrum ' s guida sui ruoli nello Scrum Team. SAFe attinge da questo.