mvp orizzontale  psm1 small  certified disciplined agilist mini  sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

  • Categoria: ALM
  • Scritto da Felice Pescatore
  • Visite: 1059

DevOps e l’[Operational] Product Owner

Nel post “Product-Centric approach” abbiamo evidenziato come DevOps richieda di guardare all’intero Prodotto e non soffermarsi al singolo progetto, abbracciando in modo completo “The Three Ways”.

In questo scenario di trasformazione, i ruoli che ereditiamo dal contesto corrente, in special modo da quello Agile, devono trovare la loro giusta collocazione ed evoluzione. In particolare, parlando di Prodotto, viene subito in mente il ruolo del Product Owner, che come sappiamo è focalizzato sulla creazione di Valore per il cliente e, quindi, sulla realizzazione delle feature di prodotto e sulla relativa pianificazione in chiave Product Backlog.

Cosa accade se guardiamo al mondo DevOps? Beh, se il Product Owner viene considerato come il “responsabile del prodotto”, dovrebbe essere colui che si occupa sia della realizzazione delle feature sia della messa in esercizio, sovraintendendo quindi anche gli aspetti di Operation e non solo quelli di Dev.

Questo però tende a far spostare il focus del Product Owner da business-oriented, tipico nell’accezione Agile, a technical-oriented, implicando anche una conoscenza più approfondita delle tematiche inerenti la fase di delivery e deployment. È un po’ come se l’Agile Product Owner si fondesse con il Service Delivery Manager (ITIL), complementari e indispensabili entrambi.

In realtà questo doppio aspetto è difficilmente assolvibile da una sola persona, perché richiede competenze ed approcci spesso in contrasto tra loro e comunque troppo ampi da essere gestiti agevolmente da una sola persona. Si tratta di un aspetto già noto nello @Scaling ed esplicitamente contemplato da SAFe che individua il Product Manager ed il Product Owner in modo distinto e ben preciso.

pm po

 

Il primo è business-oriented (posizionato del Program Level e spesso noto anche come Chief Product Owner) e si occupa primariamente di aspetti legati al successo dell’iniziativa di business annessa e della governance del Program Backlog:

  • Market/customer facing;
  • Collocated with, and reports into marketing/business;
  • Owns Vision, pricing, licensing, ROI, and Program Backlog;
  • Drives release content via prioritized Features;
  • Establishes feature acceptance criteria.

Il SAFe Product Owner (collocato a livello di Team Level) è invece più technical-oriented, dedicato al team ed impegnato negli aspetti di delivery del prodotto:

  • Solution/technology/team facing;
  • Collocated with, and reports into development;
  • Contributes to Vision and Program Backlog;
  • Own steam backlog and implementation;
  • Drives sprint content via prioritized Stories;
  • Establishes story acceptance criteria, accepts stories into the baseline.

Con questo approccio è possibile estendere il ruolo del Product Owner anche in chiave Ops, andando a seguire una parte specifica delle attività del Program Backlog, raccolte in uno specifico Team Backlog nel quale possono trovare posto anche gli Operational Requirement. Si aggiungono così le seguenti responsabilità:

  • Embrace “System Thinking” and focus on the “Product Lifecycle” not just projects or features;
  • Understand the “Operational Requirements”;
  • Ensure that the “Operational Requirements” are seen as important as the “Functional Requirements” in the Product roadmap and champion their implementation.

In tal modo si preserva, inoltre, l’univocità del ruolo del Product Owner che resta l’unico responsabile di tutte le attività di delivery dello specifico Team.

Tagged under: scaling,,