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

Le linee guida sono lì per tutti. In una squadra matura, come hai detto, tutti lo stanno facendo, quindi non significa che non ci sia posto per esso. Supponiamo, un nuovo membro si unisce, che non è stato esposto a questa metodologia prima. Avere la struttura in atto, sarebbe vitale per lui. Non avrebbe dovuto disturbare gli altri membri, o non avrebbe "dimenticato" un deliverable.

Secondo me, Elenca tutto, incluso l'ovvio. Forse hai una "short cheat list" per quelli non ovvi se aiuta quelli che vogliono una lista più breve, ma considera il caso dei nuovi membri che saltano su.

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

Solo perché i punti sono palesemente ovvii non significa che le persone li porteranno sempre fuori. Prendiamo 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 dose di educazione ed esperienza tra di loro. Tuttavia, le cose vanno ancora male - i passaggi sono fuori servizio, qualcosa viene dimenticato, qualcosa viene fatto in modo errato. Ho visto un certo numero di fonti che un numero elevato (fino al 70%) di incidenti aerei attribuito a errore del pilota avrebbe potuto essere prevenuto con una lista di controllo . Nel mondo medico, fino al 29% delle denunce per negligenza nei Paesi Bassi avrebbe potuto essere impedito con l'uso di una lista di controllo, secondo i ricercatori . Sebbene queste persone siano state addestrate, e con il senno di poi probabilmente identificheranno facilmente ciò che hanno fatto di sbagliato, è successo qualcosa che li ha fatti decadere. Non l'ho ancora letto, ma Il Manifesto di Checklist dovrebbe essere pertinente. È scritto da una professione medica, ma i vantaggi di rendere una checklist o diagramma di flusso visibile 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 ovvio questo compito sia, se ha bisogno di essere completo perché la storia sia considerata fatta, deve essere in quella lista. L'elenco deve essere visibile da qualche parte al team. Nota che non deve essere niente di originale o formale - forse solo una serie di domande che tutti ha bisogno di chiedersi prima che una storia possa essere chiamata fatta.

Il secondo passo è decidere che cosa va in quella lista di controllo per la definizione di fatto. Tutto ciò che devi fare per completare un'attività deve essere specifico, non ambiguo, accettabile e realistico. Deve anche essere in un contesto di tempo per l'esame del fatto. Ad esempio, non è necessario includere "modifica codice" o "modifica progettazione" in una definizione di fatto - se non fosse necessario modificare un prodotto di lavoro, non era necessario per la storia.

Sospetto che una buona lista di controllo da utilizzare come base per una definizione di fatto sia:

• Have all associated unit, integration, system, and acceptance tests been updated?
• Has the work product been transformed into its releasable form? For example, code built, documentation in the exportable file format, etc.
• Have all associated work products been peer-reviewed? Examples of work products include source code (production and test), comments, design documents, test procedures, and user manuals.
• Have all associated tests (at all levels of testing) been executed and pass?
• Has the code been merged into the integration repository?

Naturalmente, dovrai trovare una buona definizione di fatto che includa qualsiasi altra attività che il tuo team e il tuo cliente sentono di aggiungere valore. Se è sulla checklist, 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:

In our team, we have a similar list, but nobody ever looks at it because those points seem so blatantly obvious

La tua squadra è già "matura" ;-). Ma c'è sempre margine di miglioramento!

Alla tua domanda:

So what are examples of strong definitions of done of a mature team? What kind of points do they include typically?

In cima all'elenco, è possibile 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 tuo commit. Inoltre, è possibile formulare un "fatto: con eccellenza" se qualcuno effettivamente migliora le metriche. Sebbene questo (le metriche stanno migliorando) di solito non fa parte delle fasi di sviluppo (nuove funzionalità) ma delle fasi di refactoring.

In una delle mie società precedenti 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 superare i 15, a meno che tu non abbia una scusa molto, molto buona, come calcoli complicati.)

Lo stesso vale per il tipo di violazione Checkstyle, specialmente se si dispone di un set di regole personalizzate per controllare lo stile del codice del proprio team. Se stai violando lo standard di codifica, non hai ancora finito.

Quindi non solo potevi eseguire UnitTest, puoi misurare la copertura del codice. Se non è coperto almeno il 50%, non hai finito. Anche se questa è una sorta di deficiente definizione di fatto, dal momento che dovresti fare dei test per i metodi core / principali / critici, e non necessariamente per il 100% della tua base di codice.

Oh sì ... e se hai (dovresti) un server CI con integrazione di ramo automatizzata ... sei fatto solo se il tuo commit nel ramo DEV si fonde con il ramo LIVE attuale e non causa neanche errori. (Test delle unità, ecc.)

hmmm ... questo è tutto quello che posso ricordare, so, di aziende / progetti passati, che non sono stati menzionati nella tua lista.

Spero di averti dato alcune idee; -)

Saluti,

Anann

In un ambiente TDD / BDD, la definizione di "done" (tecnicamente "Code Complete", come la definizione di Matt S di "really 'done" "è corretta) è piuttosto semplice:

• Tutti i test automatici passano (i test automatici dovrebbero includere quelli nuovi scritti per la storia in questione per verificare che la funzionalità o il comportamento richiesti esista e funzioni)
• Revisione del codice approvata (almeno uno sviluppatore senior del team si accontenta di lasciare che il tuo lavoro diventi parte della base di codici e che tu non abbia "barato" o "hackerato" la tua strada attraverso la storia)
• Impegna con successo (incluso il bot di compilazione che passa 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 tutto ciò di cui deve preoccuparsi il programmatore di squadra medio. Scritte o non scritte, sono inviolabili in un ambiente TDD. La documentazione, quando i programmatori sono quelli che stanno facendo la documentazione, è un ulteriore punto. Nel mio ultimo team Agile, la documentazione è stata gestita dai BAs / QAs; sapevano cosa voleva il cliente, avevano eseguito gli UAT e quindi erano i migliori in grado di documentare la nuova funzionalità in un modo che fosse significativo per il cliente, quindi la documentazione non faceva parte della definizione del programmatore di "fatto", sebbene fosse parte della definizione della squadra.