Per visualizzare l'articolo in inglese, selezionare la casella di controllo Inglese. È possibile anche visualizzare il testo inglese in una finestra popup posizionando il puntatore del mouse sopra il testo.
Traduzione
Inglese

Principi e valori di Agile di Jeff Sutherland

Jeff Sutherland ha inventato la metodologia Scrum nel 1993 e ha collaborato con Ken Schwaber per formalizzarla all'OOPSLA'95. Insieme hanno esteso e migliorato Scrum in molte società di software ed hanno contribuito alla scrittura del Manifesto Agile. Nel blog di Jeff Sutherland, all'indirizzo http://scrum.jeffsutherland.com, vengono esaminate le origini e le procedure consigliate della metodologia Scrum.

Lo sviluppo Agile è un termine derivato dall'Agile Manifesto, scritto nel 2001 da un gruppo di cui facevano parte gli autori di Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) e Crystal, un rappresentante dello sviluppo basato su funzionalità e molti altri guru nel settore del software. L'Agile Manifesto ha definito un set comune di valori e principi generali per tutte le singole metodologie Agile dell'epoca. I dettagli del manifesto quattro valori fondamentali per la creazione di team ad alte prestazioni.

  • Individui e reciproche interazioni

  • Distribuzione di software funzionante

  • Collaborazione del cliente

  • Risposta al cambiamento

Questi valori fondamentali sono supportati da dodici principi che è possibile reperire presso il sito Web seguente: Manifesto for Agile Software Development (informazioni in lingua inglese).

Questi valori non sono stati semplicemente approvati a parole dagli autori dell'Agile Manifesto per essere subito dopo dimenticati. Si tratta di valori operanti. L'approccio di ogni singola metodologia Agile a questi valori è leggermente diverso, ma tutte le metodologie dispongono di processi e pratiche specifici per la promozione di uno o più di questi valori.

Gli individui e le interazioni sono essenziali per la creazione di team ad alte prestazioni. Studi sulla "saturazione della comunicazione" durante un progetto hanno evidenziato che, quando non esistono problemi di comunicazione, i team sono 50 volte più produttivi rispetto alla media del settore. Per semplificare la comunicazione, le metodologie agile si basano su cicli frequenti di controllo e adattamento. La frequenza di questi cicli può variare da pochi minuti con programmazione di coppia, a poche ore con integrazione continua, fino ad ogni giorno con riunione giornaliera e a ogni iterazione con revisione e analisi retrospettiva.

Commenti e comunicazione più frequenti non sono tuttavia sufficienti per eliminare i problemi di comunicazione. Questi cicli di controllo e adattamento funzionano solo in presenza di diversi comportamenti principali da parte dei membri del team, quali:

  • rispetto per il valore di ogni persona;

  • sincerità nel corso delle comunicazioni;

  • trasparenza di tutti i dati, azioni e decisioni;

  • fiducia che ogni persona supporterà il team;

  • impegno nei confronti del team e dei suoi obiettivi.

Perché questi tipi di comportamento possano svilupparsi, è necessario che la gestione Agile fornisca un ambiente d'appoggio, il responsabile del team faciliti la loro inclusione e i membri del team li esibiscano. Solo allora i team saranno in grado di realizzare il loro potenziale completo.

Per i team raggiungere questi tipi di comportamento è più difficile di venga visualizzato. La maggior parte dei team evita di fare affidamento su sincerità, trasparenza e fiducia a causa di norme culturali o per esperienze negative pregresse di conflitto generato da comunicazioni oneste. Per contrastare queste tendenze è necessario che la leadership e i membri del team facilitino un conflitto positivo. Quando i team avviano conflitto positivo, non solo promuovono il comportamento più produttivo, ma funziona per ottenere vantaggi:

  • Il miglioramento del processo dipende dalla capacità del team di generare un elenco di impedimenti o problemi nell'organizzazione, affrontarli in modo diretto ed eliminarli sistematicamente in ordine di priorità.

  • L'innovazione si realizza solo lo libero scambio delle idee in conflitto, come hanno studiato e documentato stato da Hirotaka Takeuchi e da Ikujiro Nonaka, fondatori di scrum.

  • La risoluzione degli ordini del giorno in conflitto si verifica quando i team sono allineati intorno agli obiettivi comuni e vengono generate le problematiche e conflitti potenziali.

  • L'impegno collaborativo si verifica solo quando le persone sono d'accordo sugli obiettivi comuni e cercano di migliorare sia a livello personale che come team.

Questo ultimo punto in merito all'impegno è particolarmente importante. Solo quando sono impegnati, gli individui e i team coinvolti nello sviluppo del software si sentono responsabili del risultato finale, ovvero della distribuzione di valore elevato. Le metodologie agile facilitano l'impegno eauto-organizzazione dai membri del team incoraggianti per il raggiungimento di elementi da un elenco classificato in ordine di priorità di lavoro, gestire il proprio lavoro e stato attivo sul miglioramento delle pratiche di lavoro. Queste procedure costituiscono la base dell'auto-organizzazione, la forza propulsiva per in un team Agile.

Per creare team ad alte prestazioni, le metodologie Agile valutano utenti e interazioni in relazione a processi e strumenti. Da un punto di vista pratico, tutte le metodologie Agile cercano di accrescere il livello di comunicazione e collaborazione tramite cicli frequenti di controllo e adattamento. Questi cicli sono tuttavia utili solo quando i leader Agile incoraggiano il conflitto positivo necessario per lo sviluppo di una base solida di sincerità, trasparenza, fiducia, rispetto e impegno nei team Agile.

Il software funzionante costituisce una delle grandi differenze apportate dallo sviluppo Agile. Tutte le metodologie Agile rappresentate nell'Agile Manifesto enfatizzano la distribuzione al cliente di piccole parti di software funzionante a intervalli predefiniti.

Tutti i team Agile devono stabilire il loro significato di "software funzionante", spesso noto come "definizione di risultato". A un livello elevato, una parte di funzionalità può essere definita completa solo quando le sue caratteristiche superano tutti i test e possono essere utilizzate da un utente finale. A un livello minimo, è necessario che i team superino il livello degli unit test ed eseguano i test a livello di sistema. Nella definizione dello scopo da perseguire con una parte di funzionalità, i migliori team includono anche i test di integrazione, prestazioni e accettazione da parte del cliente.

CMMI una società di Livello 5, che dispone già di una delle frequenze di errore più bassa il mondo, è indicato con notevoli dati in molti progetti vantaggi delle procedure agile. In particolare, erano sistematicamente la doppia velocità in grado di produzione e riducono i difetti del 40 utilizzando le azioni seguenti:. Ciò da una società.

  • Definire i test di accettazione quando si definisce la funzionalità.

  • Implementare le funzionalità in serie e in ordine di priorità.

  • Eseguire i test di accettazione per ogni funzionalità non appena vengono implementate.

  • Correggere i bug ai quali è stata assegnata la più alta priorità il più presto possibile.

Nell'Agile Manifesto si consiglia ai team di distribuire software funzionante a intervalli predefiniti. L'accordo in gruppo di successo significa è uno dei modi pratici che i team agile producono le prestazioni e la qualità elevate necessarie per conseguire questo obiettivo.

Negli ultimi venti anni, la percentuale di riuscita dei progetti è più che raddoppiata in tutto il mondo. Questi miglioramenti si sono verificati in conseguenza di progetti più piccoli e di fornire più frequenti, che clienti consentiti per fornire feedback su software funzionante a intervalli regolari. Gli autori del manifesto non sbagliavano quando enfatizzavano che il coinvolgimento del cliente nel processo di sviluppo del software è essenziale per la riuscita del progetto.

Le metodologie Agile promuovono questo valore consentendo ai clienti di sostenere il lavoro in collaborazione con il team di sviluppo. Il primo team Scrum aveva ad esempio migliaia di clienti. Poiché non era possibile da includerli tutti nello sviluppo del prodotto, hanno selezionato un procuratore del cliente, denominato proprietario del prodotto. Il proprietario del prodotto rappresentato non solo tutti i clienti nel campo, ma anche la gestione, le vendite, il supporto, i servizi client e altre parti interessate. Il proprietario del prodotto era responsabile per l'aggiornamento dell'elenco di requisiti ogni quattro settimane quando il team rilasciava il software funzionante, in considerazione della realtà corrente e dei commenti effettivi dei clienti e delle parti interessate. Il cliente ha aiutato attivamente a dare forma al software che è stato creato.

Il primo team XP fu avviato per un progetto IT interno Il team XP è possibile avere un utente finale della società sul lavoro tra gruppi con essi giornaliera. 10 Circa di tempo, i consulenti e i team interni riescono a trovare un utente che può collaborare quotidianamente con il team. Nell'altro 90% dei casi devono nominare un procuratore. Questo procuratore del cliente, che i team XP definiscono "cliente", collabora con gli utenti finali per fornire un elenco chiaro, classificato in ordine di priorità, delle funzionalità che gli sviluppatori devono implementare.

È attraverso la collaborazione giornaliera cliente o (cliente immesso) che i dati di settore mostrano che i progetti agile dispongono di più di due volte l'indice di riuscita dei progetti tradizionali su mondiale centrale. Poiché le metodologie agile supportano il valore dell'impegno del cliente, viene creato un punto nei team di sviluppo che è specificamente per il rappresentante del cliente.

Per i team di creare i prodotti che soddisfaranno i clienti e forniranno il valore aziendale, i team devono rispondere a modifiche. I dati di settore mostrano che durante lo sviluppo del software oltre il 60% di requisiti del prodotto o del progetto subiscono modifiche. Anche quando i progetti tradizionali vengono completati puntualmente all'interno del budget e contengono tutte le funzionalità pianificate, i clienti spesso non sono soddisfatti perché il risultato ottenuto non corrisponde esattamente a quanto desideravano. legge di Humphrey", i clienti non sanno mai cosa desiderano fin quando non vedono il software funzionante. Se i clienti non vedono il software funzionante fino alla fine di un progetto, sarà troppo tardi per incorporare i loro suggerimenti. Le metodologie agile perseguono i commenti del cliente in qualsiasi progetto in modo da poter includere i team feedback e nuove informazioni durante lo sviluppo del prodotto.

Tutte le metodologie Agile dispongono di processi incorporati per modificare i piani a intervalli regolari in base ai commenti forniti dal cliente o dal suo procuratore. I piani vengono progettati per fornire sempre innanzitutto il valore aziendale più elevato. Poiché l'80% del valore risiede nel 20% delle funzionalità, i progetti Agile eseguiti correttamente tendono a terminare velocemente, laddove la maggior parte dei progetti tradizionali vengono completati in ritardo. Di conseguenza, i clienti sono più soddisfatti e gli sviluppatori lavorano con maggiore piacere. Le metodologie Agile sono basate sulla consapevolezza che, per riuscire, è necessario pianificare il cambiamento. Per questo motivo, hanno stabilito processi, quali revisioni e analisi retrospettive, specificatamente progettati per modificare periodicamente le priorità in base ai commenti dei clienti e al valore aziendale.

Lo sviluppo Agile non è di per sé una metodologia. Si tratta piuttosto di un termine generico che descrive diverse metodologie Agile. Al momento della sottoscrizione dell'Agile Manifesto nel 2001, tali metodologie includevano Scrum, XP, Crystal, FDD e DSDM. Da allora, come utile metodologia Agile sono emerse anche le pratiche Lean, che vengono pertanto incluse sotto il termine generico di sviluppo Agile nell'illustrazione riportata più avanti in questo argomento.

Come molti linguaggi di programmazione manifestano le funzionalità principali della programmazione orientata agli oggetti in modi diversi, ugualmente ogni metodologia Agile dispone di un approccio leggermente diverso per l'implementazione dei valori principali dell'Agile Manifesto. In base ai dati di un recente sondaggio, il 50% circa dei professionisti Agile si avvale della metodologia Scrum nei team. Un altro 20% utilizza Scrum con componenti XP e un ulteriore 12% utilizza solo XP. Poiché le implementazioni Agile sono Scrum o XP per oltre l'80% in tutto il mondo, MSF for Agile Software Development v5.0 si concentra sui processi e sulle pratiche principali di Scrum e XP.

Ombrello Agile

Scrum è un framework per i processi di sviluppo Agile, che non include procedure di progettazione specifiche. Viceversa, XP si concentra sulle procedure di progettazione ma non include un framework generale dei processi di sviluppo. Ciò non vuol dire che Scrum non consigli determinate procedure di progettazione o che XP non disponga di processi. Nel primo progetto Scrum ad esempio erano implementate tutte le procedure di progettazione ora note come XP. Il framework Scrum per lo sviluppo del software era tuttavia progettato in modo che un team venisse avviato in due o tre giorni, laddove le procedure di progettazione spesso richiedono molti mesi per l'implementazione. La decisione di quando, e se, implementare procedure specifiche era pertanto demandata a ogni team. I creatori di Scrum, Jeff Sutherland e Ken Schwaber, consigliano di avviare i team Scrum immediatamente e di creare un elenco di impedimenti e un piano di miglioramento del processo. Quando procedure di progettazione vengono identificate come impedimenti, i team devono utilizzare le procedure XP come una modalità di miglioramento. I migliori team eseguono la metodologia Scrum integrata con le procedure XP. Scrum consente l'escalation a XP e XP consente l'esecuzione efficace di Scrum.

Nella tabella riportata di seguito viene illustrato come è possibile scambiare i termini principali nelle metodologia Scrum e XP.

Scrum

XP

proprietario del prodotto

cliente

scrum master

coach XP

team

team

sprint

iterazione

riunione pianificazione sprint

gioco di pianificazione

Aggiunte alla community

Mostra: