dove traccia le decisioni del team [chiuso]

Question

dove traccia le decisioni del team [chiuso]

#1 da (6 voti)
#2 da (4 voti)
#3 da (1 voti)
#4 da (1 voti)

6

Sono stato in molti team di sviluppo e man mano che il team matura le decisioni sulla direzione vengono prese. Queste decisioni spesso vengono ripetute più e più volte. Come perché non riempiamo questo campo perché non abbiamo usato memcache su una soluzione personalizzata. Queste decisioni si sommano nel tempo e diventano una parte significativa delle guide di stile che codificano standard e test unitari.

La mia domanda è che non ho mai imbattuto in un buon modo per tenere traccia di queste decisioni o della scoperta che è stata fatta per realizzarle. Qualcuno ha una buona pratica.

development-process configuration-management

posta rerun 23.10.2013 - 18:44

fonte

4 risposte

Leggi altre domande sui tag development-process configuration-management

Complessità ciclica con due IF: perché è 3? Ci sono guide di stile standard per PHP? [chiuso]

score 6 · Answer 1

(nella mia esperienza)

Le decisioni importanti (in particolare quelle relative ai proprietari dei prodotti) appartengono ai documenti di progettazione.

Le decisioni tecniche banali (perché è un campo vuoto?) appartengono a un commento proprio accanto al campo.

Tra una sorta di decisioni sono dispari. Tendo a pensare che la conoscenza comune non documentata sia la migliore, poiché la documentazione di una decisione è inutile se nessuno la segue e queste decisioni medie sono spesso cose che tutti devono seguire. Ho visto i wiki usati per questo con scarso successo. Soprattutto per le guide di stile, averlo in codice è spesso "abbastanza buono" per consentire alle persone di seguire il flusso.

score 4 · Answer 2

La metodologia di sviluppo software agile affronta queste decisioni di sviluppo in modo molto efficiente. Alla fine di ogni iterazione, possiamo avere una sessione retrospettiva. Annotiamo le nostre lezioni che abbiamo appreso in un periodo di tempo e le esaminiamo prima di iniziare la prossima iterazione per il miglioramento.

Suggerirei di guardare in Uso di Retrospettive Agile di grandi dimensioni per migliorare i progetti

score 1 · Answer 3

Ho familiarità con il problema. Una buona soluzione di cui ho sentito parlare (ma che non ho provato io stesso) è stata una squadra agile che ha fatto Kanban correttamente (con una vera scheda fisica) e ha aggiunto un'area "principi" in cui decisioni come questa - o almeno si strusciavano su punti ricorrenti di dolore - potrebbe essere scritto ("usa X se stai facendo Y", "non dimenticare W", "le nostre cose ora devono lavorare con Z"). Sul tabellone fisico avrebbero una buona possibilità di essere visti da qualcuno che spostasse la propria story card su una colonna "attiva" o "conclusa" e facendo jogging nella loro memoria che è qualcosa che devono tenere a mente / fare qualcosa.

Ovviamente si tratta di rendimenti decrescenti se ne possiedi troppi, ma la roba deriverebbe dall'area dei principi alla cultura / alle conoscenze comunali / abitudini del team e lo spazio della scheda potrebbe quindi essere aggiornato per essere qualcosa di diverso ora pensato che causi più problemi.

Un buon esempio di "radiatore di informazioni" in azione credo.

score 1 · Answer 4

Le registrazioni delle decisioni prese, sotto forma di documenti di progettazione o trascrizioni di riunioni, devono essere archiviate in semplici file di testo UTF-8 all'interno del sistema di controllo della versione, nello stesso repository del codice sorgente dell'organizzazione, in modo da poter mantenere tracciabilità tra quando è stata presa una decisione e quando è stata implementata.

Idealmente, le decisioni / minuti e amp; altri documenti di progettazione dovrebbero fare uso di convenzioni leggibili a macchina come YAML o Markdown in modo che i report possano essere generati in qualsiasi formato di file richiesto (HTML, PDF, DOC), consentendo anche l'uso di strumenti di controllo della versione come diff, merge e blame .