Come lo sviluppo agile della documentazione minima è compatibile con il requisito che i processi aziendali debbano essere documentati?

Questa è un'interpretazione piuttosto insolita del valore di "Software di lavoro su una documentazione completa". Questo valore del manifesto Agile è stato creato come reazione ai progetti in cui la documentazione consisteva di centinaia o migliaia di pagine di documentazione che nessuno avrebbe voluto leggere; l'obiettivo era quello di sostituire quei manuali enormi ed estremamente inutili che raccolgono polvere su uno scaffale da qualcosa di più vicino agli sviluppatori, qualcosa di più accessibile, più leggibile.

Naturalmente, parte della documentazione può essere sostituita da user story e test automatizzati, oltre a clean code e clean architecture -due aspetti critici che non hai menzionato.

Detto questo, c'è ancora una documentazione da fare, se il progetto usa o meno metodologie Agile. Alcuni progetti richiederebbero solo poche pagine che descrivono come installarli e usarli, così come la loro architettura. Altri avrebbero ancora bisogno di molto di documentazione, perché gli sviluppatori originali hanno scelto scelte di progettazione non intuitive ma necessarie, perché il progetto si basa su alcuni capricci di un sistema di terze parti, ecc.

Quindi:

• Documentare accuratamente.

• Non scrivere documentazione per scrivere documentazione.

• Scegli con cura il formato migliore per documentare un'informazione. A volte sarebbe un test. A volte potrebbe essere un diagramma UML. A volte, sarebbe un nome di variabile migliore. Se altri sviluppatori leggono la tua documentazione, ci sei riuscita. Se raccoglie la polvere su uno scaffale, hai fatto una scelta sbagliata.

La documentazione di processo deve essere scritta solo una volta. Se questo è un requisito per fare affari sia all'interno della vostra azienda o con il vostro cliente, allora quel lavoro è parte dello sprint 0 (cioè il primo sprint). Sono già stato in quella posizione e sono riuscito a mappare i processi agili in CMMI livello 3 senza documenti di tracciamento che avremmo altrimenti dovuto creare abitualmente.

Agile non si tratta di sostituire i requisiti per fare business, è un approccio per stringere il ciclo di feedback per essere in grado di correggere i problemi all'inizio mentre sono ancora piccoli. È un approccio che incoraggia la sperimentazione in modo che tu possa trovare gli approcci che rendono più felice il tuo cliente.

C'è sempre un disadattamento di impedenza quando devi adattarti agilmente all'interno di un processo a cascata più ampio nello spazio del tuo cliente. È lì che devi impostare i firewall per dove finisce e l'altro inizia. Questo tipo di ambiente si presta a un dev-and-hand-over-to-op piuttosto che a un approccio DevOps diretto. È anche in particolare questo tipo di cose che è necessario documentare nel processo di scrittura. Ciò consente al tuo team di sapere che se il cliente desidera qualcosa entro una certa data, sai esattamente quale sprint devi avere un pacchetto completamente sbloccabile per passare attraverso il processo più ampio.

La maggior parte delle persone ha a che fare con situazioni non ottimali. Anche se Agile è in giro da un paio di decenni, è ancora vista come il giovane processo di upstart. L'obiettivo nel documentare il tuo processo è quello di rendere qualsiasi artefatto che le persone che ti richiedono scrivano il tuo processo vogliono vedere un sottoprodotto naturale di seguire il processo. Ad esempio, legare ogni commit a un fabbisogno o una segnalazione di bug è facile poiché la maggior parte dei sistemi di tracciamento dei problemi gestiscono ciò per te, purché tu faccia riferimento al numero di problema nel tuo messaggio di commit. Ottenere una relazione su ciò che è fatto e quanto sei vicino è una questione di avere lo strumento per generare grafici, ecc.

Siamo sinceri, se hai un requisito per la documentazione esaustiva di stile dei documenti di parole non è così. Domanda il requisito.

Ma! Oltre ad essere un passo indietro rispetto allo sviluppo di software per grandi cascate, ricorda anche che agile è un passo avanti rispetto allo sviluppo del caos no-process. Se i documenti sono un requisito, inserirli nel backlog, stabilire le priorità, stimare e programmare normalmente. Il costo diventa quindi visibile al cliente.