I documenti di progettazione di alto livello e di basso livello sono necessari per seguire il processo di sviluppo Agile?

No, Agile non richiede la necessità di documenti HLD (o SRS, requisiti aziendali) o LLD (o specifiche tecniche) da associare alle User Story. Tuttavia, questi documenti sarebbero altamente incoraggiati per il processo Waterfall.

Semplicemente perché Agile non richiede questo non significa che non dovrebbe esistere però. Non si escludono a vicenda. Si può teoricamente gestire un progetto Agile e richiedere ancora documenti HLD e LLD, tuttavia il caso dovrebbe essere fatto se questi documenti portano valore agli stakeholder .

In Agile è altamente incoraggiato a svolgere solo compiti che diano valore allo stakeholder e molti sostengono che questi documenti non lo fanno. Possono portare valore agli architetti o allo sviluppatore, ma gli utenti e gli altri stakeholder probabilmente non si preoccupano di queste cose a meno che non richiedano specificamente tali documenti come deliverable.

Risposta breve no. Agile non dice molto su cosa devi o non devi fare. È principalmente un insieme di valori e un modo di pensare.

Tuttavia, i requisiti tipicamente scritti sono piuttosto leggeri nei processi agili. I tuoi documenti HLD e LLD sembrano più pesanti di quelli che potrebbero essere comuni.

Tipicamente i backlog sono pieni di storie, le storie sono per lo più inviti ad avere una discussione sul design. Dopo una discussione, alcune note potrebbero essere annotate, alcuni criteri di accettazione hanno funzionato. Ma è tutto abbastanza informale sulla necessità di avere una base.

Credo che dipenda da alcuni fattori come:

1. Il dominio aziendale del progetto se stiamo parlando di applicazioni mediche o simili, vorresti sicuramente tenere traccia di questo tipo di documentazione per FDA o approvazione equivalente.

2. Durata prevista del progetto da rilasciare se si prevede un intervallo di 2 ~ 3 anni, quindi è meglio mantenere il livello minimo ed efficace di documentazione possibile per tenere traccia dei cambiamenti critici nel corso della vita del progetto.

E credo che ci possano essere più fattori che possono influenzare tale decisione, quindi è meglio definire i pro e i contro della creazione di & mantenere tale tipo di documentazione mantenuta e rispettata.

La risposta è che dovremmo usare la documentazione quando pensiamo di averne bisogno, piuttosto che vietarla del tutto. Una persona ha suggerito se un progetto è lungo, quindi potrebbe essere utile conservare un documento originale che indichi quali fossero gli obiettivi e gli obiettivi in quel momento. Molto prima che ci fosse Agile, ho usato questo approccio di buon senso. Mi è stato svelato un paio di volte di aver preso interi paragrafi da strategie e piani di test perché non erano utili nel contesto di ciò che stavo facendo, piuttosto che completarli per rispettare semplicemente uno standard. Se un piano di test può essere scritto su una singola pagina, lo faccio perché nel tempo è facile girovagare lungo il percorso sbagliato, soprattutto se non c'è affatto altra documentazione nel progetto. La sua non è una brutta cosa, a meno che l'informazione in esso sia sbagliata o irrilevante o semplicemente non utile. Quando è utile, fallo quando non lo è. Questo per me è "agile"

Se ti interessi di queste cose (a seconda dell'ambiente / progetto che potresti volere molto bene), le tratti come attività e pianifichi poi come qualsiasi altra attività. Se vuoi rendere questi documenti o meno è indipendente dal tuo processo di agile / scrum.