Agile e Business Analysis

Conversazione Strutturata

Conversazione

Un team di sviluppo Agile, per produrre il massimo valore nel minor tempo possibile, deve essere supportato da buone prassi di business analysis.

Una prassi efficace ed efficiente  è la “conversazione strutturata”  utile per prendere decisioni basate sul valore di business e per sviluppare prodotti che integrino la verifica dei requisiti con il coinvolgimento degli stakeholder.
Il primo obiettivo è comprendere come  suddividere i requisiti in dimensioni adatte a cicli di breve durata, sia per il timeboxing di Scrum che  per il flusso di delivery  di Kanban. La scomposizione  dei requisiti  – detta anche: refining, grooming, partitioning o decomposing  – consente al team di sviluppo software di esplorare, valutare ed esporre l’alto valore dei requisiti.
Le necessarie attività di business analysis sono fondamentali, a prescindere dal ruolo o dal titolo di chi assume il ruolo di Business Analyst: conta l’obiettivo e non il ruolo.
Una “conversazione strutturata” consente di ottenere i principali benefici della filosofia Agile: rilasciare velocemente  porzioni di prodotto software funzionante. Per fare un buon lavoro occorre comprendere:

  • Quali metodi usare per determinare il valore di business, osservando i requisiti in modo olistico.
  • Come considerare gli stakeholder partner di decisioni veloci, collaborando.
  • L’importanza del lavoro di business analysis per creare un prodotto di alto valore.

Agile Business Analysis

Ciò che il Business Analyst rilascia deve essere atteso dal cliente, deve essere fattibile e sopportabile e deve rientrare nella strategia dell’organizzazione. Ciò significa che chi svolge l’analisi deve comprendere prima il contesto generale, oltre alle specificità del prodotto da realizzare. Per farlo è indispensabile coinvolgere gli stakeholder, i quali si devono comportare come partner, collaborando in modo costruttivo e trasparente per mettere a fuoco le esigenze del prodotto per fornire risultati  di valore.
Nei progetti Agile, si analizzano i requisiti in piccoli incrementi con molta attenzione alla loro durata, sviluppando quanto basta per produrre valore di business con alta qualità. In questo modo, si riducono i rischi dei requisiti – rischi che affliggono tanti progetti di sviluppo software.
I rischi di requisiti si dividono in due categorie:
  • Sbagliare lo sviluppo del prodotto o
  • Sviluppare il prodotto sbagliato.
Per garantire di sviluppare il prodotto giusto, occorrono criteri di accettazione basati  su prove chiare per ogni incremento di prodotto da pianificare. Tale verifica – parte del processo di analisi iniziale e non finale – è una competenza della business analysis.
Lo sviluppo Agile è caratterizzato da una serie di piccoli rilasci che confermano se il prodotto in sviluppo sta dando il valore atteso.

Concetti di Analisi e Pianificazione del Prodotto

  • Le prassi Agile comprendono un metodo di sviluppo intensivo attraverso continue e costanti attività  interconnesse di scoperte e rilasci, basati su tecniche di sviluppo iterativo e incrementale.
  • Le prassi Lean, invece, puntano a massimizzare il valore per il cliente e  minimizzare gli sprechi. Normalmente con “Agile” si intende anche “Lean”.

Discover <====> Deliver

Essendo la pianificazione Agile guidata dal valore di business, l’attenzione è  più al prodotto ché al progetto, tendendo ad anticipare valore di business per l’organizzazione dell’utente. Gli stakeholder del prodotto si dividono in tre gruppi:
  • Utente – utenti, clienti e consulenti
  • Business – sponsor, Product Owner, fornitori e consulenti esperti della materia
  • Tecnologia – team di sviluppo e consulenti tecnici.
Tutti questi stakeholder – partner eseguono della business analysis a vari livelli.

UTENTE <=> BUSINESS <=>TECNOLOGIA

In collaborazione con il Product Owner, ogni partner fornisce la sua prospettiva sull’evoluzione del prodotto di rilascio in rilascio. Gli stakeholder identificano il valore di business atteso in fase di pianificazione, rivedendolo, poi, in base ai risultati di ogni rilascio. Con la conferma dei risultati, dopo ogni rilascio, i partner consolidano la loro efficienza confermando  il loro apprendimento.
I partner prima concordano su una visione a lungo termine del prodotto, allineata alla strategia dell’organizzazione, poi identificando gli obiettivi che possano aumentare i ricavi o ridurre i costi. Poiché, il prodotto evolve di rilascio in rilascio, l’approccio Agile, nel tempo, deve rispondere a qualsiasi cambiamento di visione, propositi e obiettivi.
Un prodotto comprende opzioni o requisiti espressi come storie, testi descrittivi, interviste, workshop e così via. Ogni opzione presenta benefici e rischi che i partner analizzano per determinarne il valore di business.
La prospettiva dei partner riflette le loro considerazioni del valore. Ad esempio, gli utenti valutano convenienza e costi; i business partner valutano l’allineamento con la visione, il posizionamento nel mercato e le risorse necessarie; i partner delle tecnologie valutano fattibilità, costi del servizio e attributi di qualità.L’analisi  è più efficiente in base all’orizzonte di pianificazione:
  • A lungo termine (idea generale del prodotto)
  • A medio termine (prossimo rilascio)
  • A breve termine (prossima iterazione).
Il team di sviluppo analizza ognuna di 7 opzioni a diverse dimensioni del prodotto, per individuare quella applicabile al progetto:
  1. Utenti – Quali utenti hanno interesse in questo prodotto?
  2. Interfacce – Quali interfacce sono necessarie?
  3. Azioni – Che azioni sono necessarie?
  4. Dati – Su quali dati si agisce?
  5. Controlli – Quali controlli bisogna effettuare?
  6. Ambiente – In quale ambiente opererà il prodotto?
  7. Qualità – Quali vincoli di qualità avrà il prodotto?
 Rispondendo a queste domande, i partner raggiungono una comprensione olistica del prodotto. Si tratta di dimensioni funzionali (utenti, azioni, dati e controlli) e non funzionali (interfacce, ambienti e attributi di qualità).
Queste 7 dimensioni forniscono anche un linguaggio comune tra tutti i partner per la comunicazione riguardo al prodotto.
La conversazione strutturata è uno schema da utilizzare per esplorare, valutare e confermare le opzioni di alto valore del prodotto, in base ad ognuna delle 7 dimensioni del prodotto, applicando prassi di business analysis come elicitazione, analisi e specifiche.
  • Esplorare – indagare sule opzioni possibili
  • Valutare – spezzettare le opzioni in base al valore e le dipendenze, producendo documenti coerenti con l’orizzonte di pianificazione (più vicini al rilascio, più dettagliata dovrà essere la descrizione).
  • Confermare – dimostrare di aver compreso e prepararsi per il rilascio, specificando i criteri che saranno utilizzati per verificare e confermare il requisito.

Conclusione

I principi Agile applicati alla business Analysis possono essere sintetizzati come segue:
I partner interessati al prodotto collaborano continuamente per scoprire e rilasciare il prodotto in evoluzione. I partner esplorano e valutano le opzioni per le 7 dimensioni del prodotto, identificando e confermando parti coerenti delle opzioni di alto valore allocandole per la pianificazione di tutte le viste.
La Business Analysis è essenziale per amplificare i benefici dello sviluppo Agile.
Utilizzando Business Analyst qualificati e competenti aiuta a migliorare la comunicazione, la pianificazione, la crescita professionale e l’efficienza nel tempo. Ci sarà l’evidenza che il prodotto è pronto per l’utilizzo e che ha una documentazione di valore, riducendo l’insidia del rischio di sbagliare lo sviluppo del prodotto  o di sviluppare il prodotto sbagliato.
Agile-BA
Referenze: http://www.discovertodeliver.com/resources/references.php. (principali testi su Discover to Deliver  e raccomandazioni sui concetti  di pianificazione, prodotti, conversazione strutturata e valore).

Promo

PMTSI-Logo