Sviluppo di software adattivo - Pratiche

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 allo scopo 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. I test dovrebbero essere 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 presto 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 di 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 deve 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.
  • Cosa deve fare il Team di meno.

Lo stato del progetto

La revisione dello stato del progetto aiuta a pianificare ulteriori lavori. Nei progetti di sviluppo di 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?"