La pressione dello sprint causa problemi di qualità? [chiuso]

Il grafico di burn down non visualizza una scadenza. Mostra i tuoi progressi verso l'impegno della tua squadra. Penso che sia una nota importante.

Se qualcuno sta utilizzando il tuo sprint per far rispettare una scadenza, allora non stai facendo realmente mischia. Stai solo lavorando in sprint, che è un problema molto comune quando i team iniziano ad adattare la mischia.

Quando il grafico di burndown rappresenta il burn-down delle attività committed , è più nelle mani del tuo team. Se il tuo lavoro sta soffrendo, è perché ti sei impegnato a fare più di quanto tu possa realizzare. Durante il prossimo sprint, la tua squadra dovrebbe naturalmente accettare di impegnarsi a meno lavoro per fornire un prodotto di qualità superiore.

Quello che stai descrivendo è un problema mentale più di ogni altra cosa. Non pensare alla tabella di burndown come misurare il progresso verso una scadenza. Invece, pensa di misurare i progressi verso il tuo obiettivo stimato per questo sprint. Invece del tuo sviluppatore che pensa "Ho XYZ da completare e deve essere fatto entro la data di fine dello sprint", il tuo sviluppatore dovrebbe pensare "Ho XYZ completo e in base alla quantità di tempo che ho, dovrei essere in grado di finire entro la data di fine dello sprint ".

Se il tuo grafico non brucia del 100% significa semplicemente che il tuo obiettivo stimato non corrisponde a quello che il tuo team è stato in grado di produrre nel periodo di sprint. È sempre utile scoprire perché. Non hai assegnato lo sforzo corretto durante la tua sessione di pianificazione? I tuoi sviluppatori giocavano a Counterstrike invece di fare il loro lavoro? I membri del tuo team hanno incontrato impedimenti? C'è stato un bug critico che ha allontanato le risorse chiave dal loro lavoro?

Questi tipi di discussioni dovrebbero svolgersi in parte durante gli stand up quotidiani e, per lo meno, dovrebbero essere riportati nella retrospettiva dello sprint. Questo feedback dovrebbe essere preso in considerazione e applicato per contribuire a migliorare le stime in futuro.

La qualità delle riparazioni si riduce alla tua squadra che acquista la nozione che non ci sono ripercussioni per aver dovuto urtare qualcosa nel prossimo sprint, a condizione che il motivo sia valido.

Per come la vedo io, lo scopo del grafico di burn down è:

1. Permettere al team di abbandonare gli impegni di sprint presto piuttosto che tardi se non ce la farà. L'idea è che è meglio finire lo sprint con una storia fatta anziché due metà e che l'OP preferirebbe sapere che questa funzione non verrà eseguita entro venerdì, piuttosto che durante la riunione di accettazione.
2. Fornire dati che consentano al team di ottenere stime migliori e una velocità più veloce più veloce: un grafico di burn down di buona qualità dovrebbe significare che la squadra ha il loro atto insieme (non necessariamente che ottengono molto da fare). Un grafico che sembra troppo buono di solito significa che è stato diagnosticato ed è inutile.

Se la squadra fa qualcosa per far sembrare buono il grafico di burn down, sconfigge lo scopo. Ricorda: la misura principale del progresso è il funzionamento (alta qualità) del software. Non una tabella di burn down di bell'aspetto o impegni irrealistici.

Se c'è una pressione esterna sulla squadra in tal senso, ti consiglio di interrompere la comunicazione del grafico di burn down al di fuori del team. È uno strumento prezioso, ma può essere danneggiato troppo facilmente.

(Per essere chiari: è normale che l'overcommitment avvenga occasionalmente, ma se accade regolarmente, la squadra non sta imparando: una velocità stabile, stime realistiche e una buona comunicazione su quale sia un obiettivo di allungamento e cosa dovrebbe essere promesso dovrebbe mantenere sprint di massima alla baia)

Con il software, in genere hai le seguenti metriche:

• Scala temporale. Hai l'iterazione.
• Scope. Hai corretto l'ambito.
• Risorse. Hai i membri del team.
• Qualità. La qualità deve essere al 100%

Quando la pressione è attiva, quale sacrifichi? Ti aspetti che il team crei più scadenze lavorando straordinariamente? Ti cadono storie? Gli sviluppatori aggiuntivi probabilmente non si aggiorneranno abbastanza velocemente? o semplicemente testare le basi e incrociare le dita?

Ciò che ho visto accadere in tutti i team di mischia con cui ho lavorato è che sono sotto pressione per aumentare continuamente lo "scopo" come misura di quanto sia buona la squadra, che per portare avanti tutto ciò, le squadre oltre il lavoro le loro ore, e tale qualità viene schiacciata, poiché gli sviluppatori consegnano in ritardo e la scadenza finale non può essere spostata.

Ciò che Scrum intendeva fornire era:

Scala temporale: esaminiamo lo stato di avanzamento del prodotto in occasioni periodiche fisse che ci assicurano che stiamo offrendo le funzionalità di cui il cliente ha bisogno.

Risorse: abbiamo chiarezza su chi sta lavorando nel team per l'iterazione. gli sviluppatori non sono portati a fare interruzioni di contesto dolorose.

Qualità: apprezziamo soprattutto la qualità. Ci assicuriamo che tutto ciò che produciamo sia debitamente testato e, se non lo abbiamo testato al 100%, non è ancora stato fatto.

Ambito: stiamo dando visibilità al business su ciò che ci aspettiamo di fornire alla fine di questa iterazione, basata sulle nostre esperienze passate.

In questo ambiente, quando la pressione è attiva, la sua portata viene sacrificata.

Come far funzionare Scrum?

Questa è la domanda sbagliata. La domanda giusta è quale tipo di output ha bisogno l'azienda dal team di sviluppo? Hanno bisogno di un prodotto di qualità? o hanno bisogno di rilasciare il software a una scadenza?

Quando sono venuti a patti con questo, saranno in grado di organizzare l'ambiente appropriato per i loro sviluppatori. Scrum, kanban, XP possono farlo tutti, ma sono tutti dipendenti dall'ambiente.