Lavoro come parte di un team Agile simile a una mischia e qualche tempo fa, una cosa che abbiamo identificato che il team dovrebbe fare è mantenere un buon set di documenti di progettazione per la nostra base di codice. Poiché siamo agili e disponiamo di una buona quantità di discussioni e comunicazioni, i nostri progetti sono mantenuti ad un livello elevato e sono generalmente utilizzati per descrivere il layout generale dei moduli, comprese le classi principali e alcune delle loro interazioni e. Inoltre li abbiamo trovati utili per la discussione di punti di partenza e anche per ricordare alle persone che la progettazione deve essere presa in considerazione prima di passare al codice.
Finora, ci si aspettava che tutti aggiornassero le specifiche di progettazione in base alle necessità. I lead di progettazione per ogni team sono responsabili di dare consigli alle persone sul design in generale, su cosa aggiornare nelle SDS e anche per rivedere le specifiche per assicurarsi che tutto rimanga coerente.
Il problema che sto vedendo è che mentre tutti, specialmente i nuovi membri, trovano le specifiche di progettazione molto utili quando imparano nuovi componenti o addirittura tornano a componenti che non hanno toccato per un po ', la maggior parte delle persone aggiorna solo i documenti per il bene di aggiornarli (ad esempio, gli viene detto che devono farlo e così lo fanno). In modo che ci ritroviamo con descrizioni one-liner che a volte non sono nemmeno frasi complete e quando dico loro che questo deve essere aggiornato e compilato, aggiungono di più, ma di nuovo, solo perché vengono dette. Così ora gli one-liner diventano 1,5 righe e non c'è ancora nulla di utile scritto.
Ovviamente le diverse abilità / punti di forza dei membri del team saranno diverse. Quindi la domanda è: alcuni membri del team su una squadra agile non sono semplicemente responsabili della progettazione e si riducono a un programmatore? Oppure dovrebbe essere il ruolo di lead nel design di tornare a quei membri del team e farli riscrivere le specifiche quante volte necessario (e questo sta diventando davvero doloroso) fino a quando non acquisiscono abbastanza abilità per produrre ciò che ci si aspetta?
Le mie linee guida di base che suggerisco a tutti: se eri seduto in una riunione o facevi una presentazione sul diagramma di classe X, cosa diresti se il tuo pubblico avesse bisogno di sapere come funziona il tuo codice. Invece, la metà delle volte si limita a ripetere ciò che posso già vedere nel diagramma delle classi. "Classe X implementa l'interfaccia Y". Questa sarebbe tutta la descrizione della classe.
Modifica Lavoro per una grande azienda con un appetito molto salutare per l'outsourcing / appalto. La squadra in cui lavoro ha membri permanenti, ha anche membri permanenti che sono molto nuovi per il team (dalla recente fusione). E abbiamo appaltatori dall'India e dalla Polonia che molto probabilmente saranno riassegnati ad altri progetti dopo l'attuale rilascio. Quindi diversi membri hanno un buy-in diverso a questo punto. La documentazione è sicuramente importante per quelli di noi che sono stati sul progetto nell'ultima versione e saranno sul progetto nella prossima versione.