Sviluppo S / W adattivo - Guida rapida

Cos'è Agile?

In termini letterari, la parola "agile" significa qualcuno che può muoversi rapidamente e facilmente o qualcuno che può pensare e agire rapidamente e chiaramente. Negli affari, "agile" viene utilizzato per descrivere i modi di pianificare e svolgere il lavoro in cui si comprende che apportare le modifiche necessarie è una parte importante del lavoro. "Agilità" aziendale significa che un'azienda è sempre in grado di tenere conto dei cambiamenti del mercato.

Nello sviluppo del software, il termine "agile" è adattato per significare "la capacità di rispondere ai cambiamenti - cambiamenti da Requisiti, Tecnologia e Persone".

Manifesto Agile

L'Agile Manifesto è stato pubblicato da un team di sviluppatori di software nel 2001, sottolineando l'importanza del team di sviluppo, adattandosi alle mutevoli esigenze e al coinvolgimento dei clienti.

Il Manifesto Agile è:

Stiamo scoprendo modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro, siamo arrivati ​​a valorizzare -

• Individui e interazioni su processi e strumenti.
• Software funzionante su documentazione completa.
• Collaborazione con il cliente nella negoziazione del contratto.
• Rispondere al cambiamento piuttosto che seguire un piano.

Cioè, mentre c'è valore negli elementi a destra, diamo più valore agli elementi a sinistra.

Caratteristiche dell'agilità

Di seguito sono riportate le caratteristiche di Agility:

• Agility in Agile Software Development si concentra sulla cultura dell'intero team con team multidisciplinari e interfunzionali dotati di poteri e auto-organizzazione.

• Promuove responsabilità e responsabilità condivise.

• Facilita una comunicazione efficace e una collaborazione continua.

• L'approccio a tutto il team evita ritardi e tempi di attesa.

• Consegne frequenti e continue garantiscono un feedback rapido che a sua volta consente al team di allinearsi ai requisiti.

• La collaborazione facilita la combinazione tempestiva di diverse prospettive nell'implementazione, nella correzione dei difetti e nell'adattamento dei cambiamenti.

• Il progresso è costante, sostenibile e prevedibile, enfatizzando la trasparenza.

Metodologie agili

Le prime implementazioni dei metodi Agile includono Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development e Dynamic Systems Development Method (DSDM). Queste sono ora denominate collettivamente metodologie Agile, dopo che il manifesto Agile è stato pubblicato nel 2001.

In questo tutorial impareremo la Metodologia Agile - Adaptive Software Development.

Che cos'è lo sviluppo software adattivo?

Lo sviluppo di software adattivo è un passaggio verso pratiche adattive, lasciando le pratiche deterministiche nel contesto di sistemi complessi e ambienti complessi. Adaptive Software Development si concentra sulla collaborazione e l'apprendimento come tecnica per costruire sistemi complessi. Si è evoluto dalle migliori pratiche di RAD (Rapid Application Development) e Evolutionary Life Cycles. Lo sviluppo di software adattivo è stato quindi esteso per includere approcci adattivi per la gestione, con la speculazione che sostituisce la pianificazione.

Jim Highsmith ha pubblicato un libro su Adaptive Software Development nel 2000. Nelle parole di Highsmith:

“Lo sviluppo di software adattivo è ciclico come il modello evolutivo, con i nomi delle fasi Speculare, collaborare, apprendere che riflettono il regno imprevedibile di sistemi sempre più complessi. Lo sviluppo adattivo va oltre la sua eredità evolutiva in due modi chiave. Primo, sostituisce esplicitamente il determinismo con l'emergenza. In secondo luogo, va oltre un cambiamento nel ciclo di vita per un cambiamento più profondo nello stile di gestione ".

Un modello SDLC (Software Development Life Cycle) è un framework che descrive le attività svolte in ogni fase di un progetto di sviluppo software.

In un ciclo di vita dello sviluppo software, le attività vengono eseguite in cinque fasi:

• Requirements Gathering- Vengono raccolti i requisiti per un software da sviluppare. Questi requisiti saranno in una lingua compresa dal cliente / utente. Si consiglia la terminologia specifica del dominio.

• Analysis - I requisiti raccolti vengono analizzati dal punto di vista dell'implementazione e le specifiche del software vengono scritte per coprire sia i requisiti funzionali che i requisiti non funzionali.

• Design - Questa fase prevede l'arrivo all'architettura software e alle specifiche di implementazione basate sulla tecnologia scelta per lo sviluppo.

• Construction - In questa fase, il codice viene sviluppato, unit test, integrato, integrato testato e viene prodotta la build.

• Testing- In questa fase viene eseguito il test funzionale del software costruito. Ciò include anche la verifica dei requisiti non funzionali.

Esistono due approcci per eseguire queste attività:

• Prescriptive - I modelli SDLC che ti forniranno le modalità per eseguire le attività in modo prescritto, come definito dal framework.

• Adaptive- I modelli SDLC che ti daranno flessibilità nello svolgimento delle attività, con alcune regole che devono essere seguite. I metodi agili seguono principalmente questo approccio, ognuno con le sue regole. Tuttavia, seguire un approccio adattivo o agile non significa che il software sia sviluppato senza seguire alcuna disciplina. Ciò porterebbe a un caos.

Devi capire che non possiamo dire che un modello SDLC specifico sia buono o cattivo. Ognuno di loro ha i suoi punti di forza e di debolezza e quindi sono adatti in determinati contesti.

Quando scegli un modello SDLC per il tuo progetto, devi capire:

• Il contesto della tua organizzazione
• Il tuo contesto tecnologico
• La composizione della tua squadra
• Il contesto del tuo cliente

Ad esempio, se lo sviluppo del software è prevedibile, è possibile utilizzare un approccio prescrittivo. D'altra parte, se lo sviluppo del software è imprevedibile, ovvero i requisiti non sono del tutto noti o il team di sviluppo non ha una precedente esposizione al dominio o alla tecnologia corrente, ecc., L'approccio adattivo è la scelta migliore.

Nelle sezioni seguenti verranno illustrati i modelli SDLC più diffusi che si sono evoluti durante l'esecuzione di progetti di sviluppo software nel settore. Imparerai anche i punti di forza e di debolezza di ciascuno di essi e in quali contesti sono adatti.

Il modello Waterfall è un modello SDLC classico ampiamente conosciuto, compreso e comunemente utilizzato. È stato introdotto da Royce nel 1970 ed è tuttora seguito come approccio comune per lo sviluppo del software in varie organizzazioni del settore.

Nel modello Waterfall, ogni fase del ciclo di vita può iniziare solo dopo il completamento della fase precedente del ciclo di vita. Quindi, è un modello lineare senza loop di feedback.

Modello a cascata - Punti di forza

I punti di forza del modello Waterfall sono:

• Facile da capire, facile da usare.
• Fornisce struttura al team di sviluppo inesperto.
• Le pietre miliari sono ben comprese.
• Imposta la stabilità dei requisiti.
• Ideale per il controllo di gestione (pianificazione, monitoraggio, reporting).
• Funziona bene quando la qualità è più importante del costo o della pianificazione.

Modello a cascata - Punti deboli

I punti deboli o gli svantaggi del modello Waterfall sono:

• Idealizzato: non corrisponde bene alla realtà.

• Non realistico: non è possibile aspettarsi requisiti precisi all'inizio del progetto.

• Non riflette la natura iterativa dello sviluppo esplorativo che è più comune.

• Difficile e costoso apportare modifiche.

• Il software viene consegnato solo alla fine del progetto. A causa di questo -

  • Ritarda la scoperta di difetti gravi.

  • Possibilità di consegna di requisiti obsoleti.

• Significativo sovraccarico di gestione, che può essere costoso per piccoli team e progetti.

• Richiede risorse esperte in ogni fase: analisti, designer, sviluppatori, tester.

• Il test inizia solo dopo che lo sviluppo è stato completato e i tester non sono coinvolti in nessuna delle fasi precedenti.

• La competenza dei team interfunzionali non è condivisa poiché ogni fase viene eseguita in silos.

Quando utilizzare il modello a cascata?

Puoi usare il modello Waterfall se:

• I requisiti sono ben noti.

• La definizione del prodotto è stabile.

• La tecnologia è ben compresa.

• Nuova versione di un prodotto esistente.

• Portare un prodotto esistente su una nuova piattaforma.

• Grande organizzazione con team interfunzionali strutturati.

• I canali di comunicazione sono ben consolidati all'interno dell'organizzazione e anche con il cliente.

Modello di prototipazione evolutiva

Nello sviluppo del software utilizzando il modello di prototipazione evolutiva, gli sviluppatori costruiscono un prototipo durante la fase dei requisiti. Gli utenti finali valutano quindi il prototipo e forniscono un feedback. Il feedback può essere correzioni al prototipo o funzionalità aggiuntive. Sulla base del feedback, gli sviluppatori perfezionano ulteriormente il prototipo.

Pertanto, il prodotto si evolve attraverso Prototype → Feedback → Refined Prototype Cycles e da qui il nome Evolutionary Prototyping. Quando l'utente è soddisfatto della funzionalità e del funzionamento del prodotto, il codice del prototipo viene portato agli standard richiesti per la consegna del prodotto finale.

Modello di prototipazione evolutiva - Punti di forza

I punti di forza oi vantaggi di un modello di prototipazione evolutiva sono:

• I clienti / utenti finali possono visualizzare i requisiti di sistema man mano che vengono raccolti guardando il prototipo.

• Gli sviluppatori imparano dai clienti e quindi nessuna ambiguità riguardo al dominio o all'ambiente di produzione.

• Consente progettazione e sviluppo flessibili.

• L'interazione con il prototipo stimola la consapevolezza delle funzionalità aggiuntive necessarie.

• I requisiti imprevisti e le modifiche dei requisiti vengono facilmente adattati.

• Vengono prodotti segni di progresso costanti e visibili.

• Consegna di un prodotto finale accurato e manutenibile.

Modello di prototipazione evolutiva - Punti deboli

I punti deboli o gli svantaggi del modello di prototipazione evolutiva sono i seguenti:

• Tendenza ad abbandonare lo sviluppo strutturato nello sviluppo code-and-fix, sebbene non sia ciò che è prescritto dal modello.

• Questo modello ha ricevuto una cattiva reputazione per i metodi rapidi e sporchi.

• La manutenibilità complessiva può forse essere trascurata.

• Il cliente può eventualmente chiedere la consegna del prototipo come finale, non dando la possibilità agli sviluppatori di eseguire la fase finale, ovvero la standardizzazione del prodotto finale.

• Il progetto può continuare all'infinito (con un continuo scivolamento dell'ambito) e la direzione potrebbe non apprezzarlo.

Quando utilizzare il modello di prototipazione evolutiva?

Puoi utilizzare il modello di prototipazione evolutiva -

• Quando i requisiti sono instabili o devono essere chiariti
• Come fase di chiarimento dei requisiti di un modello a cascata
• Sviluppare interfacce utente
• Per dimostrazioni di breve durata
• Per sviluppo nuovo o originale
• Per implementare una nuova tecnologia

In un modello incrementale iterativo, inizialmente, viene costruita un'implementazione parziale di un sistema totale in modo che sia in uno stato deliverable. Viene aggiunta una maggiore funzionalità. I difetti, se presenti, dalla consegna precedente vengono risolti e il prodotto funzionante viene consegnato. Il processo viene ripetuto fino al completamento dell'intero sviluppo del prodotto. Le ripetizioni di questi processi sono chiamate iterazioni. Alla fine di ogni iterazione, viene consegnato un incremento del prodotto.

Modello incrementale iterativo - Punti di forza

I vantaggi o i punti di forza del modello incrementale iterativo sono:

• È possibile sviluppare prima i requisiti prioritari.

• La consegna iniziale del prodotto è più veloce.

• I clienti ottengono presto funzionalità importanti.

• Riduce il costo di consegna iniziale.

• Ogni versione è un incremento del prodotto, in modo che il cliente abbia sempre a portata di mano un prodotto funzionante.

• Il cliente può fornire un feedback ad ogni incremento di prodotto, evitando così sorprese alla fine dello sviluppo.

• Le modifiche ai requisiti possono essere facilmente adattate.

Modello incrementale iterativo - Debolezze

Gli svantaggi del modello incrementale iterativo sono:

• Richiede una pianificazione efficace delle iterazioni.

• Richiede una progettazione efficiente per garantire l'inclusione della funzionalità richiesta e la fornitura di modifiche successive.

• Richiede la definizione anticipata di un sistema completo e perfettamente funzionante per consentire la definizione degli incrementi.

• Sono necessarie interfacce di modulo ben definite, poiché alcune vengono sviluppate molto prima che altre vengano sviluppate.

• Il costo totale del sistema completo non è inferiore.

Quando utilizzare il modello incrementale iterativo?

Il modello incrementale iterativo può essere utilizzato quando:

• La maggior parte dei requisiti è nota in anticipo, ma si prevede che evolverà nel tempo.

• I requisiti hanno la priorità.

• È necessario che le funzionalità di base vengano fornite rapidamente.

• Un progetto ha tempi di sviluppo lunghi.

• Un progetto ha una nuova tecnologia.

• Il dominio è nuovo per il team.

Il modello RAD (Rapid Application Development) prevede le seguenti fasi:

• Requirements Planning phase - Nella fase di pianificazione dei requisiti, è necessario condurre un workshop per discutere i problemi aziendali in modo strutturato.

• User Description phase - Nella fase di descrizione dell'utente, vengono utilizzati strumenti automatici per acquisire informazioni dagli utenti.

• Construction phase - Nella fase di costruzione, gli strumenti di produttività, come generatori di codice, generatori di schermate, ecc. Vengono utilizzati all'interno di un time-box, con un approccio "Do until Done".

• Cut Over phase - Nella fase Cut over, vengono eseguiti l'installazione del sistema, i test di accettazione degli utenti e la formazione degli utenti.

Modello di sviluppo rapido delle applicazioni - Punti di forza

I vantaggi o punti di forza del modello di sviluppo rapido delle applicazioni sono i seguenti:

• Tempi di ciclo ridotti e una maggiore produttività con meno membri del team significherebbero costi inferiori.

• Il coinvolgimento del cliente durante l'intero ciclo riduce al minimo il rischio di non raggiungere la soddisfazione del cliente e il valore aziendale.

• L'attenzione si sposta sul codice in una modalità ciò che vedi è ciò che ottieni (WYSIWYG). Questo porta chiarezza su ciò che si sta costruendo è la cosa giusta.

• Utilizza concetti di modellazione per acquisire informazioni su business, dati e processi.

Modello di sviluppo rapido delle applicazioni - Punti deboli

Gli svantaggi o punti di forza del modello di sviluppo rapido delle applicazioni sono i seguenti:

• Il processo di sviluppo accelerato deve fornire risposte rapide all'utente.

• Rischio di non arrivare mai alla chiusura.

• Difficile da usare con i sistemi legacy.

• Sviluppatori e clienti devono essere impegnati in attività a fuoco rapido in un lasso di tempo abbreviato.

Quando utilizzare il modello di sviluppo rapido delle applicazioni?

Il modello di sviluppo rapido dell'applicazione può essere utilizzato quando:

• L'utente può essere coinvolto durante tutto il ciclo di vita.
• Il progetto può essere time-boxed.
• La funzionalità può essere fornita in incrementi.

Sebbene i punti di forza del modello di sviluppo rapido delle applicazioni siano apprezzati, è usato con parsimonia nel settore.

Il modello a spirale aggiunge l'analisi dei rischi e la prototipazione RAD al modello Waterfall. Ogni ciclo prevede la stessa sequenza di passaggi del modello Waterfall.

Il modello a spirale ha quattro quadranti. Cerchiamo di discuterli in dettaglio.

Quadrante 1 - Determina obiettivi, alternative e vincoli

• Objectives - Funzionalità, prestazioni, interfaccia hardware / software, fattori critici di successo, ecc.

• Alternatives - Costruire, riutilizzare, acquistare, subappaltare, ecc.

• Constraints - Costo, pianificazione, interfaccia, ecc.

Quadrante 2 - Valuta le alternative, identifica e risolvi i rischi

• Studiare le alternative relative agli obiettivi e ai vincoli determinati.

• Identifica i rischi come la mancanza di esperienza, nuove tecnologie, tempi stretti, ecc.

• Risolvere i rischi identificati valutando il loro impatto sul progetto, identificando i piani di mitigazione e di emergenza necessari e implementandoli. I rischi devono essere sempre monitorati.

Quadrante 3: sviluppo di un prodotto di livello superiore

Le attività tipiche includono:

• Crea un design
• Rivedi il design
• Sviluppa codice
• Controlla il codice
• Prodotto di prova

Quadrante 4 - Pianificare la fase successiva

Le attività tipiche includono:

• Sviluppa il piano del progetto
• Sviluppare un piano di gestione della configurazione
• Sviluppa un piano di test
• Sviluppa un piano di installazione

Modello a spirale - punti di forza

I vantaggi o punti di forza del metodo Spiral sono:

• Fornisce un'indicazione tempestiva dei rischi, senza comportare molti costi.
• Gli utenti possono visualizzare il sistema in anticipo grazie agli strumenti di prototipazione rapida.
• Le funzioni critiche ad alto rischio vengono sviluppate per prime.
• Il design non deve essere perfetto.
• Gli utenti possono essere coinvolti da vicino in tutte le fasi del ciclo di vita.
• Feedback precoce e frequente da parte degli utenti.
• Costi cumulativi valutati frequentemente.

Modello a spirale - Debolezze

Gli svantaggi o i punti deboli del metodo Spiral sono:

• Può essere difficile definire obiettivi, pietre miliari verificabili che indicano la disponibilità a procedere con l'iterazione successiva.

• Il tempo speso nella pianificazione, nel ripristino degli obiettivi, nell'analisi dei rischi e nella prototipazione può essere un sovraccarico.

• Il tempo speso per valutare i rischi può essere troppo grande per progetti piccoli oa basso rischio.

• Il modello a spirale è complesso da comprendere per i nuovi membri del team.

• È richiesta esperienza nella valutazione del rischio.

• La spirale può continuare indefinitamente.

• Gli sviluppatori devono essere riassegnati durante le attività della fase non di sviluppo.

Quando utilizzare il modello a spirale?

Il modello Spiral può essere utilizzato quando:

• La creazione di un prototipo è appropriata.
• La valutazione del rischio è importante.
• Un progetto è a rischio medio-alto.
• Gli utenti non sono sicuri delle loro esigenze.
• I requisiti sono complessi.
• La linea di prodotti è nuova.
• Si prevedono cambiamenti significativi durante l'esplorazione.
• Impegno del progetto a lungo termine imprudente a causa di potenziali cambiamenti aziendali.

I metodi Agile si basano sul manifesto Agile e sono di natura adattiva. I metodi agili garantiscono:

• Collaborazione in team.
• Collaborazione con i clienti.
• Comunicazione costante e continua.
• Risposta ai cambiamenti.
• Prontezza di un prodotto funzionante.

Sono nati diversi metodi Agile, promuovendo lo sviluppo iterativo e incrementale con iterazioni time-boxed. Sebbene i metodi Agile siano adattivi, le regole del metodo specifico non possono essere ignorate e quindi richiedono un'implementazione disciplinata.

Metodi Agili - Punti di forza

I vantaggi o punti di forza del metodo Agile sono:

• Rilasci precoci e frequenti.
• Sistemazione delle mutevoli esigenze.
• Comunicazione quotidiana tra cliente e sviluppatori.
• Progetti costruiti attorno a individui motivati.
• Squadre auto-organizzate.
• Semplicità, concentrandosi su ciò che viene immediatamente richiesto.
• Nessun edificio per il futuro o sovraccarico del codice.
• Riflessione regolare per regolare il comportamento per migliorare l'efficacia.

Metodi Agili - Debolezze

Gli svantaggi o i punti deboli del metodo Spiral sono:

• La disponibilità del cliente potrebbe non essere possibile.

• Le squadre dovrebbero essere esperte nel seguire le regole del metodo.

• È necessaria una pianificazione appropriata per decidere rapidamente la funzionalità che deve essere fornita in un'iterazione.

• Ci si aspetta che il team abbia capacità di stima e capacità di negoziazione.

• Il team dovrebbe avere capacità di comunicazione efficaci.

• Le nuove squadre potrebbero non essere in grado di organizzarsi.

• Richiede disciplina per svilupparsi e fornire in iterazioni time-boxed.

• La progettazione deve essere mantenuta semplice e gestibile, richiedendo quindi capacità di progettazione efficaci.

Quando utilizzare i metodi Agile?

I metodi Agile possono essere utilizzati quando:

• L'applicazione è critica in termini di tempo.

• L'ambito è limitato e meno formale (è in corso il ridimensionamento dei metodi agili a progetti più grandi, con alcune estensioni ad alcuni dei metodi agili).

• L'organizzazione utilizza metodi disciplinati.

I primi modelli SDLC sono più orientati alle pratiche di stabilità, prevedibilità e rendimenti decrescenti. Il settore, come le piattaforme Internet, si è mosso per aumentare gli ambienti di ritorno, approcci imprevedibili, non lineari e rapidi.

Adaptive Software Development (ASD) si è evoluto per affrontare questi problemi. Si concentra sull'emergenza come fattore più importante dal punto di vista del management, per migliorare la capacità di gestire lo sviluppo del prodotto.

Nelle parole di Jim Highsmith, "Il framework Adaptive Software Development si basa su anni di esperienza con metodologie di sviluppo software tradizionali, consulenza, pratica e scrittura di tecniche di sviluppo rapido di applicazioni (RAD) e collaborazione con società di software ad alta tecnologia per la gestione dello sviluppo del prodotto pratiche ”.

Il modello a cascata è caratterizzato da linearità e prevedibilità, con scarso feedback. Può essere visto come una sequenza diPlan → Build → Implement.

I modelli del ciclo di vita evolutivo come il modello Spiral hanno spostato l'approccio deterministico a quello adattivo, con Plan → Build → Revise Cycles.

Tuttavia, la mentalità dei professionisti è rimasta deterministica con la prevedibilità a lungo termine che si rivolge alla prevedibilità a breve termine. Le pratiche dei modelli del ciclo di vita evolutivo come RAD si sono rivelate meno deterministiche.

Il ciclo di vita adattivo

Il modello Adaptive è costruito da un punto di vista diverso. Sebbene ciclici come il modello evolutivo, i nomi della fase riflettono la natura imprevedibile di sistemi sempre più complessi.

Lo sviluppo adattivo va oltre la sua eredità evolutiva in due modi chiave:

• Sostituisce esplicitamente il determinismo con l'emergenza.

• Va oltre un cambiamento nel ciclo di vita per un cambiamento più profondo nello stile di gestione.

Le tre fasi del ciclo di vita dello sviluppo software adattivo sono:

• Speculate - Speculare sostituisce la parola deterministica pianificazione, pianificazione delle specifiche del prodotto o pianificazione delle attività di gestione del progetto.

• Collaborate - Collaborare rappresenta il tracciamento di un equilibrio tra

  • Gestire nel senso tradizionale della gestione del progetto e

  • Creare e mantenere l'ambiente collaborativo necessario per l'emergenza.

Le attività di collaborazione creano prodotti, tenendo il passo dei cambiamenti nell'ambiente.

• Learn - Learn mira sia agli sviluppatori che ai clienti a utilizzare i risultati di ogni ciclo di sviluppo per apprendere la direzione del successivo.

In questo capitolo, comprenderemo i vari concetti di Adaptive Software Development.

Teoria dei sistemi adattivi complessi (CAS)

Brian Arthur e i suoi colleghi, presso l'istituto di Santa Fe, hanno utilizzato la teoria dei sistemi adattivi complessi (CAS) per rivoluzionare la comprensione di fisica, biologia, evoluzione ed economia.

Brian Arthur ha culminato i suoi oltre due decenni di tentativi di convincere gli economisti tradizionali che la loro visione, dominata da presupposti fondamentali di rendimenti decrescenti, equilibrio e dinamiche deterministiche, non era più sufficiente per comprendere la realtà. Il nuovo mondo è caratterizzato da rendimenti crescenti, instabilità e incapacità di determinare causa ed effetto.

I due mondi differiscono per comportamento, stile e cultura. Chiedono -

• Diverse tecniche di gestione
• Strategie diverse
• Comprensione diversa

Sviluppo software complesso

Con l'esplosione della portata delle applicazioni software, anche le organizzazioni di sviluppo software stanno accumulando contraddizioni simili a quelle menzionate sopra.

• One World è rappresentato dallo sviluppo deterministico, derivato da pratiche di gestione che affondano le loro radici nelle basi di stabilità e prevedibilità (che in termini di Arthur significa rendimenti decrescenti)

• Il secondo mondo è rappresentato dalle industrie che passano da ambienti in diminuzione a rendimenti crescenti che sono imprevedibili, non lineari e veloci.

Per affrontare i problemi di questo secondo mondo, Jig Highsmith ha offerto un framework, Adaptive Software Development, diverso dal Deterministic Software Development.

Lo sviluppo di software adattivo si concentra sull'affrontare i sistemi complessi:

• Sviluppo di software adattivo per il ciclo di vita dello sviluppo.

• Tecniche di gestione adattiva che richiedono una mentalità diversa da quella delle pratiche di gestione dei progetti tradizionali.

In questo tutorial, puoi comprendere entrambe queste implementazioni.

Adaptive Software Development (ASD) si basa su due prospettive:

• Prospettiva concettuale basata sulla teoria dei sistemi adattivi complessi (CAS), come indicato nella prima sezione di questo capitolo.

• Prospettiva pratica basata su

  • Anni di esperienza con metodologie di sviluppo software deterministiche.

  • Consulenza, pratica e scrittura di tecniche RAD (Rapid Application Development); e collaborando con società di software ad alta tecnologia per la gestione dello sviluppo del prodotto.

In questo capitolo, comprenderete la prospettiva concettuale di Adaptive Software Development.

Concetti di sistemi adattivi complessi (CAS)

La teoria dei sistemi adattivi complessi (CAS) ha molti concetti. Lo sviluppo di software adattivo si basa su due di questi concetti:

• Emergence
• Complexity

Emergenza

Nei complessi progetti di sviluppo di prodotti software, i risultati sono intrinsecamente imprevedibili. Tuttavia, i prodotti di successo emergono continuamente da tali ambienti.

Ciò può accadere tramite Emergence, come illustrato nella teoria CAS (Complex Adaptive Systems). Può essere compreso con un semplice esempio, il comportamento di floccaggio degli uccelli.

Quando osservi uno stormo di uccelli, noti che:

• Ogni uccello ci prova

  • Mantenere una distanza minima da altri oggetti nell'ambiente, inclusi altri uccelli.

  • Abbina le velocità con gli uccelli nelle vicinanze.

  • Spostati verso il centro di massa percepito degli uccelli nelle vicinanze.

• Non ci sono regole di comportamento per il gruppo. Le uniche regole riguardano il comportamento dei singoli uccelli.

• Tuttavia, esiste un comportamento emergente, lo stormo di uccelli. Quando gli uccelli erranti si precipitano a raggiungere, lo stormo si divide intorno agli ostacoli e si riforma dall'altra parte.

Ciò mostra i requisiti dei più difficili cambiamenti del modello mentale nello sviluppo adattivo: dai modi di gestire e organizzare quella libertà individuale alla nozione che un nuovo ordine creativo emerge in modo imprevedibile dall'autoorganizzazione spontanea.

Oltre allo sviluppo, l'emergenza è il concetto più importante anche dal punto di vista del management.

Complessità

Nel contesto dello sviluppo software, la complessità riguarda:

• Gli individui di un team come gli sviluppatori, i clienti, i fornitori, i concorrenti e gli azionisti, i loro numeri e la loro velocità.

• Dimensioni e complessità tecnologica.

Pratiche di sviluppo software adattivo

Adaptive Software Development offre una prospettiva diversa sulle pratiche di gestione del software. Nelle sezioni seguenti, è possibile comprendere le due pratiche importanti: Qualità e RAD, entrambe con ramificazioni per la raccolta dei requisiti.

È possibile trovare i dettagli di tutte le pratiche nel capitolo Pratiche di sviluppo software adattivo in questo tutorial.

Qualità

In un ambiente complesso, l'antica pratica del "Fallo bene la prima volta" non funziona poiché non puoi prevedere cosa è giusto all'inizio. Devi avere l'obiettivo di produrre il giusto valore. Tuttavia, in un ambiente complesso, le combinazioni e le permutazioni di componenti di valore come l'ambito (caratteristiche, prestazioni, livelli di difetto), la pianificazione e le risorse sono così vaste che non può mai esserci un valore ottimale. Pertanto, l'obiettivo è quello di spostarsi per offrire il miglior valore nel mercato competitivo.

Pratiche RAD

Le pratiche RAD generalmente comportano una combinazione di quanto segue:

• Ciclo di vita evolutivo
• Focus group dei clienti, sessioni JAD, revisioni tecniche
• Gestione del progetto con tempistiche
• Ingegneria del software continua
• Squadre dedicate con stanze di guerra

I progetti RAD hanno un intrinseco sapore adattivo ed emergente. Molte organizzazioni IT sono contrarie a RAD. Tuttavia, Microsoft e altri hanno prodotto software incredibilmente ampio e complesso utilizzando tecniche paragonabili a RAD perché solleva interrogativi sulla loro visione fondamentale del mondo.

Le pratiche RAD e il processo Microsoft sono entrambi esempi di sviluppo adattivo in azione. Dare loro un'etichetta (cioè, Sviluppo adattivo) e rendersi conto che c'è un crescente corpo di conoscenza scientifica (cioè, teoria CAS) spiega perché funzionano. Ciò dovrebbe fornire una base per un uso più ampio di queste pratiche.

Lo sviluppo di software adattivo si è evoluto dalle pratiche RAD. Anche gli aspetti del team sono stati aggiunti a queste pratiche. Le aziende dalla Nuova Zelanda al Canada, per un'ampia gamma di tipi di progetti e prodotti, hanno utilizzato lo sviluppo software adattivo.

Jim Highsmith ha pubblicato Adaptive Software Development nel 2000.

Le pratiche di sviluppo software adattivo forniscono la capacità di accogliere il cambiamento e sono adattabili in ambienti turbolenti con prodotti che si evolvono con poca pianificazione e apprendimento.

Fasi del ciclo di vita dell'ASD

Lo sviluppo di software adattivo è ciclico come il modello evolutivo, con i nomi delle fasi che riflettono l'imprevedibilità nei sistemi complessi. Le fasi del ciclo di vita dello sviluppo adattivo sono:

• Speculate
• Collaborate
• Learn

Queste tre fasi riflettono la natura dinamica dello sviluppo di software adattivo. Lo sviluppo adattivo sostituisce esplicitamente il determinismo con l'emergenza. Va oltre un semplice cambiamento nel ciclo di vita per un cambiamento più profondo nello stile di gestione. Adaptive Software Development ha un ciclo di vita dinamico Speculate-Collaborate-Learn.

Il ciclo di vita dello sviluppo software adattivo si concentra sui risultati, non sulle attività, ei risultati vengono identificati come funzionalità dell'applicazione.

Ipotizzare

Il termine piano è troppo deterministico e indica un grado di certezza ragionevolmente alto sul risultato desiderato. L'obiettivo implicito ed esplicito della conformità al piano, limita la capacità del manager di guidare il progetto in direzioni innovative.

In Adaptive Software Development, il termine piano è sostituito dal termine speculare. Mentre specula, il team non abbandona la pianificazione, ma riconosce la realtà dell'incertezza nei problemi complessi. La speculazione incoraggia l'esplorazione e la sperimentazione. Le iterazioni con cicli brevi sono incoraggiate.

Collaborare

Le applicazioni complesse non vengono costruite, si evolvono. Le applicazioni complesse richiedono che un grande volume di informazioni venga raccolto, analizzato e applicato al problema. Gli ambienti turbolenti hanno tassi elevati di flusso di informazioni. Pertanto, le applicazioni complesse richiedono che un grande volume di informazioni venga raccolto, analizzato e applicato al problema. Ciò si traduce in diversi requisiti di conoscenza che possono essere gestiti solo dalla collaborazione in team.

Collaborare richiederebbe la capacità di lavorare insieme per produrre risultati, condividere conoscenze o prendere decisioni.

Nel contesto della gestione del progetto, Collaboration rappresenta un equilibrio tra la gestione con tecniche di gestione tradizionali e la creazione e il mantenimento dell'ambiente collaborativo necessario per l'emergenza.

Imparare

La parte Learn del ciclo di vita è vitale per il successo del progetto. Il team deve migliorare costantemente le proprie conoscenze, utilizzando pratiche come:

• Revisioni tecniche
• Retrospettive del progetto
• Focus group sui clienti

Le revisioni dovrebbero essere fatte dopo ogni iterazione. Sia gli sviluppatori che i clienti esaminano le loro ipotesi e utilizzano i risultati di ogni ciclo di sviluppo per apprendere la direzione del successivo. Il team impara:

• Informazioni sulle modifiche al prodotto

• Cambiamenti più fondamentali nelle ipotesi di fondo su come i prodotti vengono sviluppati

Le iterazioni devono essere brevi, in modo che il team possa imparare da piccoli errori piuttosto che da grandi.

Specula - Collabora - Impara il ciclo nel suo insieme

Come osservi dal ciclo Speculate-Collaborate-Learn, dato sopra, è ovvio che le tre fasi non sono lineari e si sovrappongono.

Osserviamo quanto segue da un framework adattivo.

• È difficile collaborare senza imparare o imparare senza collaborare.

• È difficile speculare senza imparare o imparare senza speculare.

• È difficile speculare senza collaborare o collaborare senza speculare.

Adaptive Software Development Lifecycle ha sei caratteristiche di base:

• Missione focalizzata
• Basato sulle funzionalità
• Iterative
• Time-boxed
• Guidato dal rischio
• Cambiamento tollerante

In questo capitolo si comprenderanno queste sei caratteristiche di Adaptive Software Development.

Incentrato sulla missione

Per molti progetti, la missione complessiva che guida il team è ben articolata, sebbene i requisiti possano essere incerti all'inizio del progetto. Le dichiarazioni di missione agiscono come guide che incoraggiano l'esplorazione all'inizio, ma hanno un focus ristretto nel corso di un progetto. Una missione fornisce i confini piuttosto che una destinazione fissa. Le dichiarazioni di missione e le discussioni che si traducono in tali dichiarazioni forniscono indicazioni e criteri per prendere decisioni critiche di compromesso del progetto.

Senza una missione chiara e una pratica costante di perfezionamento della missione, i cicli di vita iterativi diventano cicli di vita oscillanti, oscillanti avanti e indietro senza alcun progresso nello sviluppo.

Basato sulle funzionalità

L'Adaptive Software Development Lifecycle si basa sulle funzionalità dell'applicazione e non sulle attività. Le funzionalità sono le funzionalità sviluppate durante un'iterazione in base alle priorità del cliente.

Le funzionalità possono evolversi in più iterazioni quando i clienti forniscono feedback.

Le funzionalità dell'applicazione che forniscono risultati diretti al cliente dopo l'implementazione sono primarie. Anche un documento orientato al cliente come un manuale utente è considerato una caratteristica. Gli altri documenti come il modello dati, anche se definiti come deliverable, sono sempre secondari.

Iterativo

L'Adaptive Software Development Lifecycle è iterativo e si concentra su rilasci frequenti al fine di ottenere feedback, assimilare l'apprendimento risultante e impostare la giusta direzione per l'ulteriore sviluppo.

Time-boxed

In Adaptive Software Development Lifecycle, le iterazioni sono temporizzate. Tuttavia, si dovrebbe ricordare che il time-boxing nello sviluppo di software adattivo non riguarda le scadenze temporali. Non dovrebbe essere utilizzato per far lavorare il team per lunghe ore sfidando un ambiente collaborativo o per compromettere la qualità dei risultati.

Nello sviluppo di software adattivo, il time-boxing è considerato come una direzione per concentrarsi e forzare decisioni di compromesso difficili come e quando necessario. In un ambiente incerto, in cui i tassi di cambiamento sono elevati, è necessaria una funzione di forzatura periodica come un timebox per portare a termine il lavoro.

Guidato dal rischio

Nello sviluppo di software adattivo, le iterazioni sono guidate dall'identificazione e dalla valutazione dei rischi critici.

Tollerante al cambiamento

Lo sviluppo di software adattivo è tollerante al cambiamento, considera il cambiamento come la capacità di incorporare un vantaggio competitivo, ma non come un problema per lo sviluppo.

Le pratiche di sviluppo del software adattivo sono guidate dalla convinzione nell'adattamento continuo, con il ciclo di vita attrezzato per accettare il cambiamento continuo come norma.

Adaptive Software Development Lifecycle è dedicato a:

• Apprendimento continuo
• Cambia orientamento
• Re-evaluation
• Scrutare in un futuro incerto
• Intensa collaborazione tra sviluppatori, management e clienti

SDLC adattivo

Lo sviluppo di software adattivo combina RAD con le migliori pratiche di ingegneria del software, come:

• Inizio progetto.
• Pianificazione del ciclo adattivo.
• Progettazione di componenti simultanei.
• Controllo della qualità.
• QA finale e rilascio.

Le pratiche di sviluppo software adattivo possono essere illustrate come segue:

Come illustrato sopra, le pratiche di sviluppo software adattivo sono distribuite nelle tre fasi come segue:

• Speculare - Iniziazione e pianificazione

  • Inizio progetto

  • Stabilire un time-box per l'intero progetto

  • Decidi il numero di iterazioni e assegna a ciascuna una casella temporale

  • Sviluppa un tema o un obiettivo per ciascuna delle iterazioni

  • Assegna funzionalità a ciascuna iterazione

• Collaborate - Sviluppo di funzionalità simultanee

  • Collaborazione per team distribuiti

  • Collaborazione per progetti più piccoli

  • Collaborazione per progetti più grandi

• Learn - Revisione della qualità

  • Qualità del risultato dal punto di vista del cliente

  • Qualità del risultato dal punto di vista tecnico

  • Il funzionamento del team di consegna e le pratiche che i membri del team stanno utilizzando

  • Lo stato del progetto

Speculare - Iniziazione e pianificazione

In Adaptive Software Development, la fase di speculazione ha due attività:

• Initiation
• Planning

Speculate ha cinque pratiche che possono essere eseguite ripetutamente durante la fase di iniziazione e pianificazione. Sono -

• Inizio progetto
• Stabilire un time-box per l'intero progetto
• Decidi il numero di iterazioni e assegna a ciascuna una casella temporale
• Sviluppa un tema o un obiettivo per ciascuna delle iterazioni
• Assegna funzionalità a ciascuna iterazione

Inizio progetto

L'avvio del progetto implica:

• Definizione della missione e degli obiettivi del progetto
• Comprensione dei vincoli
• Stabilire l'organizzazione del progetto
• Individuazione e definizione dei requisiti
• Effettuare stime iniziali di dimensioni e ambito
• Identificazione dei rischi chiave del progetto

I dati di avvio del progetto dovrebbero essere raccolti in una sessione JAD preliminare, considerando la velocità come l'aspetto principale. L'iniziazione può essere completata in uno sforzo concentrato da due a cinque giorni per progetti di piccole e medie dimensioni o da due a tre settimane per progetti più grandi.

Durante le sessioni JAD, i requisiti vengono raccolti in modo sufficientemente dettagliato per identificare le caratteristiche e stabilire una panoramica dell'oggetto, dei dati o di un altro modello architettonico.

Stabilire il time-box per l'intero progetto

Dovrebbe essere stabilito il time-box per l'intero progetto, in base all'ambito, ai requisiti del set di funzionalità, alle stime e alla disponibilità di risorse che risultano dal lavoro di avvio del progetto.

Come sapete, speculare non abbandona la stima, ma significa semplicemente accettare che le stime possano andare storte.

Iterazioni e Time-box

Decidi il numero di iterazioni e la durata delle singole iterazioni in base all'ambito generale del progetto e al grado di incertezza.

Per un'applicazione di piccole e medie dimensioni -

• Le iterazioni di solito variano da quattro a otto settimane.
• Alcuni progetti funzionano meglio con iterazioni di due settimane.
• Alcuni progetti potrebbero richiedere più di otto settimane.

Scegli il tempo, in base a ciò che funziona per te. Dopo aver deciso il numero di iterazioni e la durata di ciascuna iterazione, assegna una pianificazione a ciascuna delle iterazioni.

Sviluppa un tema o un obiettivo

I membri del team dovrebbero sviluppare un tema o un obiettivo per ogni iterazione. Questo è qualcosa di simile allo Sprint Goal in Scrum. Ogni iterazione dovrebbe fornire una serie di funzionalità in grado di dimostrare la funzionalità del prodotto rendendolo visibile al cliente per consentire la revisione e il feedback.

All'interno delle iterazioni, le build dovrebbero fornire funzionalità funzionanti preferibilmente su base giornaliera, consentendo il processo di integrazione e rendendo il prodotto visibile al team di sviluppo. Il test dovrebbe essere una parte integrante e continua dello sviluppo delle funzionalità. Non dovrebbe essere ritardato fino alla fine del progetto.

Assegna funzionalità

Sviluppatori e clienti dovrebbero assegnare insieme funzionalità a ciascuna iterazione. Il criterio più importante per questa assegnazione di funzionalità è che ogni iterazione deve fornire al cliente un insieme visibile di funzionalità con funzionalità considerevoli.

Durante l'assegnazione di funzionalità alle iterazioni -

• Il team di sviluppo dovrebbe elaborare stime, rischi e dipendenze delle funzionalità e fornirle al cliente.

• I clienti dovrebbero decidere la priorità delle funzionalità, utilizzando le informazioni fornite dal team di sviluppo.

Pertanto, la pianificazione dell'iterazione è basata sulle funzionalità e viene eseguita in team con sviluppatori e clienti. L'esperienza ha dimostrato che questo tipo di pianificazione fornisce una migliore comprensione del progetto rispetto a una pianificazione basata su attività da parte del project manager. Inoltre, la pianificazione basata sulle funzionalità riflette l'unicità di ogni progetto.

Collaborare ─ Sviluppo di funzionalità simultanee

Durante la fase di collaborazione, il focus è sullo sviluppo. La fase di collaborazione prevede due attività:

• Il team di sviluppo collabora e fornisce software funzionante.

• I project manager facilitano la collaborazione e le attività di sviluppo simultanee.

La collaborazione è un atto di creazione condivisa che comprende il team di sviluppo, i clienti e i manager. La creazione condivisa è favorita dalla fiducia e dal rispetto.

I team dovrebbero collaborare su -

• Problemi tecnici
• Requisiti aziendali
• Processo decisionale rapido

Di seguito sono riportate le pratiche relative alla fase di collaborazione nello sviluppo di software adattivo:

• Collaborazione per team distribuiti
• Collaborazione per progetti più piccoli
• Collaborazione per progetti più grandi

Collaborazione per team distribuiti

Nei progetti che coinvolgono team distribuiti, è necessario considerare quanto segue:

• Diversi partner dell'alleanza
• Conoscenza ampia
• Il modo in cui le persone interagiscono
• Il modo in cui gestiscono le interdipendenze

Collaborazione per progetti più piccoli

Nei progetti più piccoli, quando i membri del team lavorano in prossimità fisica, dovrebbe essere incoraggiata la collaborazione con chat informali nei corridoi e scarabocchi sulla lavagna, in quanto risulta essere efficace.

Collaborazione per progetti più grandi

I progetti più grandi richiedono pratiche aggiuntive, strumenti di collaborazione e interazione con il project manager e dovrebbero essere organizzati su base contestuale.

Impara - Controllo della qualità

Lo sviluppo di software adattivo incoraggia il concetto di "Sperimenta e impara".

Imparare dagli errori e dalla sperimentazione richiede che i membri del team condividano in anticipo il codice parzialmente completato e gli artefatti, al fine di:

• Trova gli errori
• Impara da loro
• Riduci le rilavorazioni trovando piccoli problemi prima che diventino grandi

Alla fine di ogni iterazione di sviluppo, ci sono quattro categorie generali di cose da imparare:

• Qualità del risultato dal punto di vista del cliente
• Qualità del risultato dal punto di vista tecnico
• Il funzionamento del team di consegna e del team delle pratiche
• Lo stato del progetto

Qualità dei risultati dal punto di vista del cliente

Nei progetti di sviluppo software adattivo, ottenere feedback dai clienti è la prima priorità. La pratica consigliata per questo è un focus group sul cliente. Queste sessioni sono progettate per esplorare un modello di lavoro dell'applicazione e registrare le richieste di modifica del cliente.

Le sessioni di focus group del cliente sono sessioni facilitate, simili alle sessioni jad, ma piuttosto che generare requisiti o definire piani di progetto, sono progettate per rivedere l'applicazione stessa. I clienti forniscono feedback sul software funzionante risultante da un'iterazione.

Qualità dei risultati da una prospettiva tecnica

Nei progetti di sviluppo software adattivo, dovrebbe essere data importanza alla revisione periodica degli artefatti tecnici. Le revisioni del codice dovrebbero essere eseguite su base continua. Le revisioni di altri artefatti tecnici, come l'architettura tecnica, possono essere condotte settimanalmente o alla fine di un'iterazione.

Nei progetti di sviluppo software adattivo, il team dovrebbe monitorare periodicamente le proprie prestazioni. Le retrospettive incoraggiano i team a conoscere se stessi e il proprio lavoro, insieme come una squadra.

Le retrospettive di fine iterazione facilitano l'auto-revisione periodica delle prestazioni del team come:

• Determina cosa non funziona.
• Cosa deve fare di più il team.
• Ciò che il team deve fare di meno.

Lo stato del progetto

La revisione dello stato del progetto aiuta a pianificare ulteriori lavori. Nei progetti di sviluppo software adattivo, determinare lo stato del progetto è un approccio basato sulle funzionalità, la fine di ogni iterazione contrassegnata dalle funzionalità completate che danno come risultato il software funzionante.

La revisione dello stato del progetto dovrebbe includere:

• Dov'è il progetto?
• Dov'è il progetto rispetto ai piani?
• Dove dovrebbe essere il progetto?

Poiché i piani nei progetti di sviluppo software adattivo sono speculativi, più della domanda 2 sopra, la domanda 3 è importante. Cioè, il team di progetto e i clienti devono chiedersi continuamente: "Cosa abbiamo imparato finora e questo cambia la nostra prospettiva su dove dobbiamo andare?"

Di seguito è riportato un diagramma di flusso della gestione del software tradizionale.

La gestione tradizionale del software è stata caratterizzata dal termine comando-controllo.

Molte organizzazioni sono immerse in una tradizione di ottimizzazione, efficienza, prevedibilità, controllo, rigore e miglioramento dei processi. Tuttavia, l'emergente economia dell'era dell'informazione richiede adattabilità, velocità, collaborazione, improvvisazione, flessibilità, innovazione e flessibilità.

I libri di revisione aziendale e di gestione di Harvard hanno elaborato termini come empowerment, gestione partecipativa, organizzazione dell'apprendimento, gestione centrata sull'uomo, ecc., Ma nessuno di questi viene inserito nella gestione delle organizzazioni moderne.

Nel contesto dello sviluppo di software adattivo, il divario sembra molto più ampio ed è necessario considerare le tecniche di gestione adattiva che si sono dimostrate efficaci in altri campi.

Gestione adattiva

La gestione adattiva si è dimostrata efficace negli ambienti in cui i gestori delle risorse hanno lavorato insieme alle parti interessate e agli scienziati come un team, con i seguenti obiettivi:

• Imparare come i sistemi gestiti rispondono agli interventi umani.

• Per migliorare le politiche e le pratiche sulle risorse in futuro.

Il principio alla base della gestione adattiva è che molte attività di gestione delle risorse sono esperimenti poiché i loro risultati non possono essere previsti in modo affidabile in anticipo. Questi esperimenti vengono quindi utilizzati come opportunità di apprendimento per i miglioramenti futuri.

La gestione adattiva ha lo scopo di aumentare la capacità di rispondere tempestivamente di fronte a nuove informazioni e in un contesto di diversi obiettivi e preferenze degli stakeholder. Incoraggia le parti interessate a delimitare le controversie e discuterle in modo ordinato mentre le incertezze ambientali vengono indagate e meglio comprese.

La gestione adattiva aiuta gli stakeholder, i manager e altri decisori a riconoscere i limiti della conoscenza e la necessità di agire su informazioni imperfette.

La gestione adattiva aiuta a cambiare le decisioni prese chiarendo che:

• Le decisioni sono provvisorie.
• La decisione di una direzione non deve essere sempre giusta.
• Sono previste modifiche.

Esistono due tipi di approcci alla gestione adattiva:

• Gestione adattiva passiva.
• Gestione adattiva attiva.

Gestione adattiva passiva

La gestione adattiva mira a migliorare la conoscenza scientifica e quindi a ridurre le incertezze.

All'interno della gestione adattiva passiva, viene selezionata una singola linea d'azione preferita, basata sulle informazioni e sulla comprensione esistenti. I risultati delle azioni di gestione vengono monitorati e le decisioni successive vengono adattate in base ai risultati.

Questo approccio contribuisce all'apprendimento e alla gestione efficace. Tuttavia, è limitato nella sua capacità di migliorare le capacità scientifiche e gestionali per condizioni che vanno oltre il corso dell'azione selezionato.

Gestione adattiva attiva

Un approccio di gestione adattivo attivo rivede le informazioni prima che vengano intraprese le azioni di gestione.

Viene quindi sviluppata una gamma di modelli di sistema alternativi competitivi dell'ecosistema e delle relative risposte (ad esempio, cambiamenti demografici; usi ricreativi), piuttosto che un singolo modello. Le opzioni di gestione vengono scelte in base alle valutazioni di questi modelli alternativi.

Leadership-Collaboration Management

La gestione adattiva è ciò che è più adatto per lo sviluppo di software adattivo. L'approccio richiede i gestori delle risorse, cioè i manager che possono lavorare con le persone, consentire interventi umani e creare un ambiente amichevole.

Nello sviluppo del software, i leader spesso si assumono queste responsabilità. Abbiamo bisogno di leader più dei comandanti. I leader sono collaboratori e lavorano a fianco del team. La leadership collaborativa è la pratica più ricercata nello sviluppo adattivo.

I leader hanno le seguenti qualità:

• Afferra e imposta la direzione.

• Influenzare le persone coinvolte e fornire indicazioni.

• Collabora, facilita e gestisci macro il team.

• Fornire indicazioni.

• Crea ambienti in cui le persone di talento possono essere innovative, creative e prendere decisioni efficaci.

• Comprendi che a volte hanno bisogno di comandare, ma non è il loro stile predominante.