Prendi in considerazione un approccio agile. Voglio dire, se hai le risorse di tempo e le eccellenti capacità di scrittura per annotare ogni decisione di progettazione che prendi insieme alle loro motivazioni, documenta tutto. Realisticamente parlando, presumo che tu non sia in una tale posizione. Un approccio agile può aiutare con una sfida chiave per la documentazione dei razionali: spesso non si sa quali razionali erano quelli importanti fino a dopo.
Affrontiamo il problema da un punto di vista olistico. Ragazzi avete delle motivazioni per la vostra decisione. Sono intrappolati in Squishyware in questo momento, il cervello della squadra. Nonostante la quantità di documentazione relativa al credito, l'archiviazione di razionali in sqishyware non è poi così male. Siamo davvero bravi come specie a ricordare le cose importanti. È per questo che ogni grande corporazione ha "conoscenza tribale", anche quando quelle corporazioni cercano di documentare tutta quella conoscenza tribale.
Ora hai un problema. Stai scoprendo che lo sqiushyware non tiene abbastanza bene le motivazioni. Bene per te per aver capito che c'è un problema e per identificare che deve essere risolto! Non è sempre un passo facile! Quindi siamo abbastanza sicuri che la soluzione sia scaricare parte di tale logica nella documentazione. Tuttavia, non è abbastanza. Non possiamo mai dimenticare la seconda metà del puzzle, che sta ricaricando la logica nello squishyware quando è necessario prendere una decisione. Ho visto un sacco di squadre che documentano tutto come un matto, ma il contenuto non è in realtà organizzato per aiutare a prendere buone decisioni, quindi finiscono per dimenticare le motivazioni anche se sono scritte .
Quindi hai un processo in due fasi. Devi estrarre la logica dallo squishyware e documentarlo. Quindi devi assicurarti che la documentazione sia organizzata abbastanza bene da riportare il razionale in squishyware quando ne hai bisogno! Ora penso che abbiamo abbastanza di una dichiarazione di problema per renderci conto di dove piaceranno le sfide. Quando stai documentando, in genere non sai chi lo guarderà in seguito, o cosa stanno cercando. Allo stesso modo, quando guardi indietro alla documentazione, in genere non sai cosa stai cercando (nella migliore delle ipotesi potresti sapere quando).
Quindi una grande azienda potrebbe provare a gestirla in due grandi blocchi. Per prima cosa possono andare a sviluppare requisiti basati su ciò di cui le persone hanno bisogno quando ricercano la documentazione. Quindi usano questi requisiti per costruire un processo per lo sviluppo di detta documentazione. E, se oso dirlo, allora tutti si lamentano perché quasi nessuno sa esattamente come dovrebbe essere la documentazione il primo giorno. La documentazione è sempre incompleta e gli sviluppatori lamentano sempre che il processo è troppo oneroso.
È ora di andare agili.
Il mio consiglio sarebbe di avviare uno sforzo agile per migliorare il processo di documentazione: i nove metri interi da squishyware a documentazione e ritorno a squishyware. Riconosci subito che perderai alcune informazioni perché il tuo processo non è perfetto, ma va bene perché stai ancora cercando di capire il processo! Ti mancherebbe di più se provassi a creare una soluzione adatta a tutte le dimensioni.
Qualche bocconcino in particolare guarderei: * Esplora la documentazione informale. La documentazione formale è ottima, ma richiede molto tempo. Uno degli scopi della documentazione è di rilasciare informazioni dallo sviluppatore squishyware e metterle su carta. La documentazione informale riduce al minimo i costi per farlo.
- Accetta formati di documentazione non affidabili. Nulla andrà bene la prima volta. È meglio ottenere i dati e capire come renderli affidabili in seguito. Ad esempio, potresti documentare le tue motivazioni in un blocco <rationale> </rationale> o qualcosa di simile, il che renderebbe più semplice raccogliere quei dati in un secondo momento. Memorizzare le motivazioni in una user story, per ora, va bene!
- Non dimenticare mai il valore dell'organizzazione. Scopri come a te, come squadra, piace cercare razionali nella documentazione e provare a documentare ciò. Ogni squadra avrà un processo diverso. In una delle mie squadre, non siamo mai riusciti a trovare subito il biglietto con la motivazione. Quello che potremmo fare è trovare una riga di codice che conta, fare un
svn blameper scoprire quando è cambiato e perché, quindi andare a vedere i biglietti. Una volta che eravamo lì, in genere mettevamo tutta la logica di cui avevamo bisogno proprio sul biglietto. Ha funzionato per noi, scopri cosa funziona per te.
- La documentazione organica può crescere nel tempo. È raro che gli sviluppatori sappiano quali razionali sono più importanti il giorno in cui hanno bisogno di scriverlo. Di solito scopriamo quali erano importanti in seguito. Se si dispone di un processo di preparazione della documentazione che consente agli sviluppatori di gestire il proprio piccolo giardino di razionali, quelli importanti emergeranno in superficie. Ancora più importante, i razionali possono cambiare. Potresti capire che due diversi cambiamenti, con due razionali diversi, sono stati descritti al meglio da un'unica logica che funziona per entrambi. Ora c'è meno contenuto tra te e le decisioni!