Che aspetto ha una buona "definizione di fatto" per una squadra matura?

Quando si esaminano esempi di definizioni di done in varie fonti, di solito includono punti simili

• codice completato
• vengono eseguiti test unitari
• codice peer-reviewed o accoppiato
• codice registrato
• documentazione aggiornata
• ...

Nel nostro team, abbiamo un elenco simile, ma nessuno lo guarda mai perché quei punti sembrano così palesemente ovvi che a nessuno sarebbe saltato nessuno di questi passaggi. Quindi ci chiedevamo se questo è principalmente uno strumento per i team che passano a un processo agile e se non dovremmo semplicemente liberarcene.

D'altra parte, molta letteratura afferma che tutti i team ad alte prestazioni hanno una forte definizione di fatto. Questo tipo di suggerimenti suggerisce che potremmo perdere l'occasione di migliorare qui.

Quindi quali sono esempi di forti definizioni di fatto di un team maturo? Che tipo di punti includono in genere?

Le linee guida sono lì per tutti. In una squadra matura, come hai detto, tutti lo fanno, quindi non significa che non ci sia posto per questo. Supponiamo che si unisca un nuovo membro, che non è mai stato esposto a questa metodologia prima. Avere la struttura in atto, sarebbe di vitale importanza per lui. Non dovrebbe disturbare gli altri membri o "dimenticare" un risultato.

Secondo me, elenca tutto, incluso l'ovvio. Forse, avere un "breve elenco di cheat" per quelli non ovvi se aiuta chi desidera un elenco più breve, ma considera il caso dei nuovi membri che saltano avanti.

È un processo iterativo, ogni volta che vedi qualcosa che puoi migliorare, aggiungilo nella definizione di done. Straordinariamente, svilupperai un elenco che è rilevante per la tua azienda. Anann ne ha già menzionato alcuni che valgono la pena.

Solo perché i punti sono palesemente ovvi non significa che le persone li eseguiranno sempre. Facciamo altri due esempi: piloti e chirurghi. Una cabina di pilotaggio di un aereo di linea commerciale o una sala operatoria ha più persone, con una buona educazione ed esperienza tra di loro. Tuttavia, le cose vanno ancora male: i passaggi vengono eseguiti in modo anomalo, qualcosa viene dimenticato, qualcosa viene eseguito in modo errato. Ho visto un certo numero di fonti sul sito che un gran numero (fino al 70%) di incidenti aerei attribuiti a un errore pilota avrebbe potuto essere evitato con una lista di controllo . Nel mondo medico , secondo i ricercatori , fino al 29% delle cause legali per negligenza nei Paesi Bassi avrebbe potuto essere evitato con l'uso di una lista di controllo. Sebbene queste persone siano state addestrate, e con il senno di poi probabilmente identificheranno facilmente ciò che hanno fatto di sbagliato, è successo qualcosa che le ha fatte decadere. Non l'ho ancora letto, ma il Manifesto della lista di controllo dovrebbe essere pertinente. È scritto da una professione medica, ma i vantaggi di rendere visibile una checklist o un diagramma di flusso come promemoria di cosa fare sono applicabili a qualsiasi professione.

Quindi, il primo passo sarebbe quello di creare un elenco di cose che fanno parte della tua definizione di fatto e renderlo visibile. Non importa quanto sia ovvio quel compito, se deve essere completo affinché la storia sia considerata fatta, deve essere in quella lista. L'elenco deve essere visibile da qualche parte alla squadra. Nota che non deve essere niente di speciale o formale , forse solo una serie di domande che tutti devono porsi prima che una storia possa essere definita fatta.

Il secondo passo è decidere cosa succede in quella lista di controllo per la tua definizione di fatto. Tutto ciò che devi fare per completare un'attività dovrebbe essere specifico, inequivocabile, accettabile e realistico. Deve anche essere in un contesto di tempo per essere considerato fatto. Ad esempio, non è necessario includere "modifica codice" o "modifica progettazione" in una definizione di fatto: se non è necessario cambiare un prodotto di lavoro, non è necessario per la storia.

Sospetterei che una buona lista di controllo da utilizzare come base per una definizione di fatto sarebbe:

• Tutti i test di unità, integrazione, sistema e accettazione associati sono stati aggiornati?
• Il prodotto di lavoro è stato trasformato nella sua forma rilasciabile? Ad esempio, codice creato, documentazione nel formato di file esportabile, ecc.
• Tutti i prodotti di lavoro associati sono stati sottoposti a revisione inter pares? Esempi di prodotti di lavoro includono codice sorgente (produzione e test), commenti, documenti di progettazione, procedure di test e manuali utente.
• Tutti i test associati (a tutti i livelli di test) sono stati eseguiti e superati?
• Il codice è stato unito nel repository di integrazione?

Ovviamente, dovrai trovare una buona definizione di fatto che includa qualsiasi altra attività che il tuo team e il tuo cliente sentano aggiungere valore. Se è nell'elenco di controllo, dovrebbe essere qualcosa che deve essere fatto per aggiungere valore a qualcuno (il team, il cliente, l'utente). Enumerando chiaramente ciò che fai, puoi anche identificare ed eliminare attività estranee per migliorare il processo.

In realtà sembra che tu sia un ragazzo fortunato:

Nel nostro team abbiamo un elenco simile, ma nessuno lo guarda mai perché quei punti sembrano così palesemente ovvi

La tua squadra è già "matura" ;-). Ma c'è sempre spazio per migliorare!

Alla tua domanda:

Quindi quali sono esempi di forti definizioni di fatto di un team maturo? Che tipo di punti includono in genere?

In cima al tuo elenco, puoi aggiungere:

Varie metriche sulla qualità del codice: - Instabilità, astrazione - LOC vs DLOC (documentato) - ecc ...

La regola empirica potrebbe essere che la metrica non dovrebbe peggiorare con il commit. Inoltre, potresti formulare un "fatto: con Eccellenza" se qualcuno effettivamente migliora le metriche. Anche se questo (metriche migliorate) di solito non fa parte delle fasi di sviluppo (nuove funzionalità) ma delle fasi di refactoring.

In una delle mie aziende passate avevamo una definizione di "fatto" che diceva che le tue metriche devono rimanere al di sotto di determinate soglie, se vai sopra, non hai ancora finito. (La complessità ciclomatica non dovrebbe mai andare oltre i 15, a meno che tu non abbia una scusa molto, molto buona, come calcoli complicati.)

Lo stesso vale per le violazioni del tipo Checkstyle, soprattutto se si dispone di un set di regole personalizzato per verificare lo stile di codice del proprio team. Se stai violando lo standard di codifica, non hai ancora finito.

Quindi non è solo possibile eseguire UnitTest, ma misurare la copertura del codice. Se non è coperto almeno il 50%, non è fatto. Sebbene questa sia una sorta di definizione traballante di done, dal momento che dovresti avere test per i metodi core / main / critical, e non necessariamente per il 100% della tua base di codice.

Oh sì ... e se hai (dovresti) un server CI con integrazione di filiali automatizzata ... hai finito solo se il tuo commit nel ramo DEV si è unito all'attuale filiale LIVE e non causa errori. (Test unitari, ecc.)

hmmm ... questo è tutto ciò che posso ricordare proprio dalle aziende / progetti passati, che non è stato menzionato nella tua lista.

Spero che ti abbia dato alcune idee ;-)

Saluti,

Anann

In un ambiente TDD / BDD, la definizione di "done" (tecnicamente "Code Complete", poiché la definizione di Matt S "realmente" fatto "è corretta) è piuttosto semplice:

• Tutti i test automatizzati superano (tali test automatici dovrebbero includere quelli nuovi scritti per la storia in questione per verificare l'esistenza e il funzionamento del necessario funzionamento o funzionamento)
• Revisione del codice superata (almeno uno sviluppatore senior nel team è contento di lasciare che il tuo lavoro diventi parte della base di codice e che non hai "imbrogliato" o "hackerato" la storia)
• Impegno riuscito (incluso il bot di build che ha superato tutti i test automatici, le metriche di copertura del codice, i controlli di stile, ecc.)

A questo punto, puoi andare avanti. Questi tre punti sono fondamentali, ma sono tutti aspetti che il programmatore di squadra medio deve considerare. Scritte o non scritte, sono inviolabili in un ambiente TDD. La documentazione, quando sono i programmatori che eseguono la documentazione, è un ulteriore punto. Nel mio ultimo team Agile, la documentazione è stata gestita dai BA / QA; sapevano cosa voleva il cliente, avevano eseguito gli UAT e quindi erano in grado di documentare la nuova funzionalità in modo significativo per il client, quindi la documentazione non faceva parte della definizione del programmatore di "fatto", sebbene facesse parte della definizione della squadra.