Dove inserire elementi del backlog come "Come sviluppatore, ..."?

Alla fine della giornata, l'agilità riguarda la consegna di un prodotto all'utente finale. Se mettere storie di questo tipo aiuta il tuo team a farlo, dovresti farlo.

Detto questo, queste sono storie terribili. Non hanno criteri di accettazione, non sono qualcosa che può essere fatto in un singolo sprint. Quello che hai scritto è tradizionalmente considerato parte del definizione di fatto . Sono regole che la tua squadra ha deciso di seguire per aiutare a rispondere alla domanda "questa storia è stata fatta?".

Se vuoi mettere il debito tecnico in una storia, personalmente penso che sia OK. Anche se non siete utenti finali del prodotto che state costruendo, siete effettivamente utenti degli strumenti e delle pratiche che utilizzate per consegnare il prodotto, e presumibilmente, questo debito tecnico aggiunge un qualche valore aziendale (rendendovi più produttivi , o rendendo possibile fornire software di qualità superiore, ecc.).

Ricorda: la visibilità è uno degli obiettivi dell'essere agili. Se c'è un lavoro che deve essere svolto dal team, indipendentemente da chi sia, deve essere visibile e giustificato. Assicurati solo che questo lavoro funzioni effettivamente con validi criteri di accettazione e una chiara descrizione del business case per la storia.

Questa non dovrebbe essere una storia utente di alcun tipo. Se stai usando Scrum o metodologie agili simili, questo sarebbe parte della tua Definizione di fatto . Questo avrà spesso una lista di controllo degli aspetti che sono necessari per una user story da considerare come recensioni di codici, QA, unit test creati, ecc.

Idealmente, dovresti automatizzare gli aspetti che puoi in modo da non doverli incorporare in un processo manuale. Ad esempio, i test di integrazione continui possono essere attivati quando si tenta di eseguire il commit e, in caso di errore, il commit viene rifiutato. Ci sarà sicuramente un sacco di cose che non possono essere automatizzate. Identificazione di artefatti chiari per il loro completamento, ad es. un commit che aggiunge test, note da una revisione del codice, log di test CI riusciti, può aiutare a garantire obiettività e responsabilità. Idealmente, puoi acquisire queste cose con un intervento manuale minimo o nullo, ad es. le note di una recensione possono essere un registro di chat o commenti in un bug / bug tracker.

Una definizione di comportamento desiderabile, non del prodotto finale ma di qualche risorsa produttiva, non è considerata una storia in senso Scrum. Le storie di Scrum dovrebbero seguire il formato "cosa, perché, per chi". Quello che dovrebbe essere un risultato concreto, misurabile, non una visione vaga.

Potresti riscrivere il tuo primo esempio:

Come team di sviluppo vogliamo che la persona X segua il corso di formazione Y per consentirgli di eseguire l'attività Z.

E poi qualcuno potrebbe obiettare che non si tratta né di una caratteristica del prodotto né di una user story, quindi non sarà ammessa. Quello che succede dopo dipende dal proprietario del tuo prodotto.