Concetto: Bilanciamento delle priorità in competizione degli stakeholder
Questo principio articola l'importanza dell'equilibrio delle esigenze dello stakeholder.
Descrizione principale

Introduzione

Questo principio articola l'importanza di bilanciare le esigenze di business e dello stakeholder spesso in conflitto, oltre ad equilibrare lo sviluppo personalizzato di contro al riutilizzo delle risorse, soddisfando tali esigenze.

    
Vantaggi
  • Allineamento delle applicazioni con le esigenze di business e dell'utente
  • Riduzione dello sviluppo personalizzato
  • Ottimizzazione del valore di business
Pattern
  1. Definire, comprendere ed assegnare una priorità alle esigenze di business e dell'utente
  2. Assegnare le priorità ai progetti ed ai requisiti ed associare le esigenze alle capacità del software;
  3. Capire quale risorsa può essere potenziata;
  4. Bilanciare il riutilizzo di risorse con le esigenze dell'utente
Anti-pattern
  • Documentare in modo approfondito i requisiti precisi all'inizio del progetto, forzare l'accettazione dei requisiti da parte dello stakeholder
    • Negoziare le modifiche ai requisiti, dove ogni modifica può aumentare il costo o la durata del progetto,
    • Bloccare i requisiti in anticipo, riducendo quindi la possibilità di potenziare le risorse esistenti,
    • Eseguire principalmente uno sviluppo personalizzato.
  • Strutturare un sistema solo per soddisfare le esigenze degli stakeholder che si fanno sentire di più.

Discussione

Ad esempio, la maggior parte degli stakeholder preferisce disporre di un'applicazione che esegue esattamente quello si desidera debba svolgere, minimizzando il costo di sviluppo dell'applicazione ed i tempi di realizzazione. Tuttavia queste priorità sono spesso in conflitto. Un altro esempio è che se si potenzia un'applicazione in pacchetto, si potrebbe essere in grado di distribuire una soluzione più rapidamente e ad un costo inferiore, ma scendendo a compromessi con molti requisiti. Se invece si decide di creare un'applicazione da zero, questa potrebbe sì occuparsi di ogni requisito desiderato, ma il budget e la data di completamento potrebbero entrambi andare oltre i loro limiti fattibili.

L'utilizzo di un componente può radicalmente ridurre i costi ed i tempi di distribuzione di un determinato insieme di funzionalità. In molti casi è necessario effettuare un compromesso su alcuni requisiti funzionali o tecnici, ad esempio il supporto piattaforme, le prestazioni o l'impronta fisica (la dimensione fisica dell'applicazione).

Per essere in una posizione di equilibrio fra le esigenze, è necessario prima gestire i requisiti in modo efficace, come descritto in  Materiale di supporto: gestione dei requisiti. Invece di proiettare i team di programmazione su ogni elemento dell'elenco di requisiti, è necessario comprendere ed assegnare una priorità alle esigenze di business e degli stakeholder. Questo significa catturare i processi di business e collegarli ai progetti e alle capacità software, che consentono di assegnare in modo efficace una priorità ai progetti e ai requisiti, e di modificare le priorità man mano che aumenta la comprensione dell'applicazione ed evolvono le esigenze degli stakeholder. Significa anche che è necessario coinvolgere nel progetto il cliente o una sua rappresentanza, per essere certi di comprendere le sue esigenze.

Allo stesso tempo è necessario incentrare le attività di sviluppo intorno alle esigenze degli stakeholder. Ad esempio, potenziando lo sviluppo guidato dai casi d'uso e la progettazione incentrata sull'utente, il processo di sviluppo può accogliere l'evoluzione delle esigenze degli stakeholder nel corso del progetto, come con una funzione di modifica del business e con una maggiore comprensione delle capacità realmente importanti per il business e gli utenti finali. 

Infine, è necessario capire quali risorse sono disponibili e bilanciare il riutilizzo di risorse con le esigenze degli stakeholder. Esempi di risorse sono le applicazioni preesistenti, i servizi, i componenti riutilizzabili ed i pattern. Il riutilizzo delle risorse può, in molti casi, portare alla riduzione dei costi del progetto. Riutilizzare delle risorse comprovate spesso significa una maggiore qualità nelle nuove applicazioni. Lo svantaggio è che spesso è necessario giungere ad un compromesso fra il riutilizzo delle risorse e la soddisfazione completa delle esigenze dell'utente. Il riutilizzo di un componente può abbassare i costi di sviluppo di una funzione dell'80%, ma quel componente potrebbe risolvere solo il 75% dei requisiti. Quindi un efficace riutilizzo richiede un costante bilanciamento fra il riutilizzo delle risorse e l'evoluzione delle esigenze degli stakeholder.