Scrum agile - Importanza della raccolta dei requisiti e documentazione e suggerimenti per migliorare

Is this acceptable in agile scrum?

Definisci "accettabile". In alcuni ambienti, va bene. In più, è proibitivamente problematico.

Il problema è che la maggior parte degli analisti aziendali è orribile . Anche quando capiscono bene il prodotto, e anche quando possono definire e implementare le funzionalità, raramente comprendono gran parte delle implicazioni della funzione nel codice base. Quindi, anche se non è fantastico avere richieste di funzioni mal definite, è improbabile che tu possa ripararle.

So how much documentation is essential?

Nessuno.

Sono forse in minoranza qui, ma trovo che la documentazione, soprattutto a lungo termine, sia meno che inutile. La documentazione è un metodo di comunicazione scadente. Molte persone sono cattive nel farlo. Non ti consente di adattare il tuo messaggio a diversi target di pubblico. Non consente l'interazione per chiarire le idee.

Peggio, è invariabilmente non corretto / non aggiornato. Quindi non solo hai dedicato un sacco di tempo e sforzi alla realizzazione di questi documenti, ma stai mentendo attivamente al tuo staff.

In this case, is it the responsibility of the BA to give proper acceptance criteria or the scrum team's(BA is also part of our scrum team) responsibility to navigate through such difficulties?

Varia. Per me, i BA (e le altre parti interessate) non sono in grado di dettare ciò che viene fatto in uno sprint. Si tratta di un accordo tra il team e gli stakeholder realizzati durante lo sprint kickoff. Quella riunione di kickoff dovrebbe essere "hey, vorrei caratteristica XYZ". "Okay, cosa significa? Hai bisogno di Foo?" una specie di "avanti e indietro" finché tutti possono essere d'accordo sul lavoro che verrà svolto nello sprint, solitamente sotto forma di "In 2 settimane, Bob sarà in grado di aprire l'app e ordinare una Pina Colada".

We also have to spare additional capacity for the bugs, customer cases. So at the end of it, it is usually the developers and QA who have to put extra hours to meet all the commitments.

Perché?

Stai negoziando con le parti interessate durante lo sprint kickoff sugli impegni che stai assumendo, giusto?

Se ti impegni troppo, è quello che ottieni. Se ti viene detto che stai facendo questo sprint, allora forse dovresti fare agile .

Penso che quello che stai cercando sia extreme programming .

Most of the times if we are unable to complete the work in a given release

Il triangolo di tempo / ambito / costo ti consente di aumentarne uno se ne riduci un altro, non solo di forzare tutti e tre per migliorare, questo fa sì che la quarta variabile nascosta subisca un colpo di qualità.

additional teams are brought in to complete the work and this complicates it further

Aggiungere più sviluppatori software a un progetto software già in ritardo non fa finire prima, vedi Brooks - Mythical Man Month . La parte difficile della creazione di software non consiste nel digitare la soluzione nel computer, ma nelle persone che circondano lo spazio del problema.

When a team member leaves the company, he takes away the knowledge and due to little or no documentation, the new team member (BA) has no where to refer to, and due to this the entire team suffers

Con la programmazione delle coppie puoi diffondere la conoscenza attorno al tuo team. L'idea è di avere specialisti, che sono esperti in un campo, ma non ruoli, in cui le persone sono costrette a rimanere all'interno delle loro aree designate.

In this case, is it the responsibility of the BA to give proper acceptance criteria or the scrum team's responsibility to navigate through such difficulties?

È responsabilità di tutti i membri del team assumere collettivamente la responsabilità di risolvere il problema. Sembra che il Product Owner non stia facendo un buon lavoro abbattendo i requisiti dei clienti nelle storie degli utenti, ma questo potrebbe significare che devi solo aiutarli a capire meglio la tua tecnologia.

The developers and the QAs are always in a time crunch due to the discovery process involved during the sprint. The quality also suffers due to this.

Naturalmente la qualità soffre, questa non è scienza missilistica. XP ha una settimana lavorativa di 40 ore. A volte è necessario uno scricchiolio, anche se molto meno di quello che pensa la maggior parte degli MBA degli anni '80, quando si muove una scadenza esterna. Ma la maggior parte delle volte, se vieni costretto a una crisi, i tuoi analisti aziendali non stanno facendo il loro lavoro correttamente e stanno cercando di aiutarli a coprirli e questo si tradurrà in sviluppatori bruciati che producono codice peggiore e sono meno produttivi a lungo termine.