Il processo Agile: come e cosa dovrebbe essere documentato?

Is this normal for agile or just an excuse for not wanting to write it?

La mia teoria è che è il motivo per cui l'agilità si diffonde così velocemente, specialmente scrum . Ho visto troppi team desiderosi di proteggere se stessi (anziché l'intera azienda). Il problema è che in molti casi la metodologia viene utilizzata contro di loro dalla direzione (perché anche loro vogliono proteggersi!).

Questo significa che l'agile non funziona affatto? Certo che 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 società.

What are the industry norm for documentation in agile projects to record development requirements, designs, key decisions and context?

Per essere brevi:

Il team deve definire la quantità di documentazione di cui ha bisogno

Conoscono il dominio, sono gli esperti e, cosa più importante, creano la cosa!

Questo è ciò che Il software funzionante su una documentazione completa in mezzo alla Manifesto Agile .

Ti hanno lasciato un set di test TDD, test di accettazione o altri test di unità? Fanno un buon lavoro nel documentare come funziona un'applicazione e ci si aspetta che funzioni, oltre a fornire un'implementazione esemplificativa su come utilizzare ciò che è stato sviluppato.

Anche se non sono un esperto Agile in alcun modo, ecco il mio tentativo di risposta:

1. C'è una storia / requisito che richiede una documentazione specifica? Se no, allora questo è parte del problema, in quanto ottieni in qualche misura ciò che è richiesto. È una scusa e potrei chiedermi cosa intendi per "normale" qui. È solo la maggioranza di coloro che seguono i principi Agile che rendono 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 è una supposizione da parte mia.

2. Un paio di link che potrebbero essere di interesse, è il meglio che potrei fare su questo:

   • Best practice per la documentazione agile / snella
   • Documentazione agile e tecnica

Agile ha alcuni punti specifici in il manifesto , dove vorrei sottolineare questo insieme alla nota:

Working software over comprehensive documentation

That is, while there is value in the items on the right, we value the items on the left more.

Sono semplicemente orribili. Non credo che l'agilità significhi alcuna documentazione. Dovrebbero avere almeno tenuto traccia della descrizione dell'applicazione. Ottenere un'esportazione della loro wiki sarebbe stato carino o permesso a qualcun altro di ritirare il costo del servizio.

Potrebbe non essere così dettagliato come qualche tentativo. La teoria è che, in una crisi temporale, le specifiche non corrispondono più al codice. Quindi hai abbastanza documentazione per scrivere il codice e non provare a definirlo in dettaglio (Ordina come scrivere il codice in qualche pseudo-verbalized-testo / diagramma-codice e poi nel codice reale.).

Il tuo problema non ha nulla a che fare con Agile. Dovrebbero aver prodotto la documentazione che hai richiesto. Il progetto è stato mal gestito.

Ci dovrebbe essere una descrizione delle funzionalità, delle storie degli utenti e dei casi di test da qualche parte , come minimo. L'IT potrebbe trovarsi 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 tempo o voglia di crearle. Occasionalmente ci sono degli sforzi, ma la documentazione creata tipicamente diventa obsoleta 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 controllarlo perché semplicemente non si fida della sua accuratezza.

Per la massima accuratezza e informazioni affidabili, si tratta quasi 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 alcune indagini) fatti sul sistema.

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