Il processo Agile: come e cosa dovrebbe essere documentato?

Qualche tempo fa la società per cui lavoro aveva esternalizzato a terzi un progetto di sviluppo. Hanno impiegato pratiche agili nello sviluppo della soluzione. Tuttavia, quando viene richiesta la documentazione, si dice semplicemente che è necessario in quanto è stato incorporato in una wiki o come parte dei loro sprint.

Sono partiti al completamento del progetto, con tutti tranne uno del team di progetto. Il sito wiki del progetto è stato chiuso una volta scaduto l'abbonamento annuale.

Quando se ne sono andati hanno preso la maggior parte della conoscenza e della comprensione di ciò che è stato sviluppato con loro.

Quindi ho 2 domande principali;

1. È normale per l'agile o solo una scusa per non volerlo scrivere?
2. Quali sono le norme del settore per la documentazione in progetti agili per registrare requisiti di sviluppo, progetti, decisioni chiave e contesto?

È normale per l'agile o solo una scusa per non volerlo scrivere?

La mia teoria è che è per questo che l'agile si è diffuso così velocemente, in particolare la mischia . Ho visto troppi team desiderosi di proteggersi agilmente (anziché l'intera azienda). Il problema è che in molti casi la metodologia viene usata contro di loro dal management (perché vogliono proteggersi anche loro!).

Questo significa che l'agile non funziona affatto? Ovviamente no, questo significa solo che l'agile ti aiuta a risolvere alcuni problemi comuni, ma sei ancora responsabile di tutti gli altri. E in molti casi l'agile non è adatto a quella squadra in quella compagnia.

Quali sono le norme del settore per la documentazione in progetti agili per registrare requisiti di sviluppo, progetti, decisioni chiave e contesto?

Per essere brevi:

Il team dovrebbe definire la quantità di documentazione necessaria

Conoscono il dominio, sono gli esperti e, soprattutto, costruiscono la cosa!

Questo è ciò che significa software di lavoro su documentazione completa nel Manifesto Agile .

Ti hanno lasciato una serie di test TDD, test di accettazione o altri test unitari? Fanno un buon lavoro nel documentare come funziona un'applicazione e dovrebbe funzionare, oltre a fornire un'implementazione di esempio di come utilizzare ciò che è stato sviluppato.

Sebbene non sia affatto un esperto Agile, ecco il mio tentativo di risposta:

1. C'era una storia / un requisito che richiedeva documentazione specifica? In caso contrario, questo fa parte del problema poiché ottieni ciò che è richiesto in una certa misura. È una scusa e potrei chiedermi cosa intendi per "normale" qui. È solo una maggioranza di quelli che seguono i principi Agile che rende qualcosa di normale o fa parte del processo complessivo che dovrebbe essere previsto? Queste sono le due opinioni che ho potuto vedere per questo. EDIT: Dubito che ci sia qualcosa che la maggior parte delle squadre fa lo stesso quando si tratta di documentazione, ma questa è un'ipotesi da parte mia.

2. Un paio di link che potrebbero essere di interesse, sono circa il meglio che potrei fare al riguardo:

   • Best practice per la documentazione Agile / Lean
   • Documentazione tecnica e agile

Agile ha alcuni punti specifici nel manifesto , in cui segnalerei questo insieme alla nota:

Software funzionante su documentazione completa

Cioè, mentre c'è valore negli oggetti a destra, valutiamo di più gli oggetti a sinistra.

Sono semplicemente orribili. Non credo che agile non significhi affatto documentazione. Dovrebbero aver almeno tenuto traccia della descrizione dell'applicazione. Ottenere un'esportazione della loro wiki sarebbe stato bello o avrebbe permesso a qualcun altro di riscuotere il costo del servizio.

Potrebbe non essere così dettagliato come un tentativo. La teoria è, quando in una crisi del tempo, le specifiche non corrispondono più al codice comunque. Quindi hai abbastanza documentazione per scrivere il codice e non provare a definirlo in dettaglio (un po 'come scrivere il codice in un codice pseudo-verbalizzato / diagramma-codice e quindi nel codice effettivo.).

Il tuo problema non ha nulla a che fare con Agile. Avrebbero dovuto produrre la documentazione richiesta. Il progetto è stato gestito male.

Dovrebbe esserci almeno una descrizione delle caratteristiche, delle storie degli utenti e dei casi di test da qualche parte . L'IT potrebbe essere nei file Leggimi nei progetti, potrebbe essere nei commenti del codice sorgente, potrebbe essere nei documenti di progettazione; potrebbe essere tutto quanto sopra ... o potrebbe essere MIA!

Nella mia esperienza ci sono sempre molte persone che richiedono documentazione (sono stato uno di loro) ma in pratica nessuno ha davvero il tempo o il desiderio di crearli. Occasionalmente ci sono sforzi, ma la documentazione creata in genere viene superata molto rapidamente e non si sincronizza con il reale funzionamento del sistema. Questo porta a una situazione in cui anche se si dispone di documentazione nessuno si preoccupa davvero di controllarla perché semplicemente non si fidano della sua precisione.

Per un'accuratezza reale e informazioni affidabili, si riduce praticamente alla capacità di leggere codice e test. Un cliente che desidera (ri) scoprire che cosa fa il suo sistema può sempre intervistare e interrogare un programmatore che può quindi presentare (con qualche indagine) fatti sul sistema.

Creare una buona documentazione non è banale e può essere piuttosto costoso. In secondo luogo, ci si potrebbe chiedere del pubblico, a chi serve la documentazione e che cosa intende fornire?