Tutti gli sviluppatori di un team hanno lo stesso ruolo / responsabilità nella scrittura e nell'aggiornamento dei documenti di progettazione del software

Question

Tutti gli sviluppatori di un team hanno lo stesso ruolo / responsabilità nella scrittura e nell'aggiornamento dei documenti di progettazione del software

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

7

Ho fatto una domanda molto simile qualche giorno fa, ma poiché presentavo troppa situazione attuale della mia azienda, la maggior parte delle risposte si concentrava completamente su qualcosa a cui non stavo cercando di rispondere. Quindi volevo riprovare ...

Dato praticamente qualsiasi team agile, hai sempre persone con varie a) conoscenza del prodotto b) esperienza nella produzione di disegni e c) livello generale di competenza.

Quindi diciamo che si prende una squadra agile e usando i fattori (a), (b) e (c) sopra si ottiene un punteggio complessivo per ogni ingegnere (solo esercizio mentale). Ora li ordiniamo in ordine crescente e otteniamo uno spettro continuo.

Quindi la domanda che volevo porre è questa: Ogni singola persona su questo spettro deve avere la stessa responsabilità di scrivere / aggiornare le specifiche di progettazione del software?

Non sto parlando di design del software, in team agili che vengono solitamente eseguiti da più di una persona in un ambiente più collaborativo. Ma alla fine della giornata, qualcuno deve tornare alla sua scrivania per aprire il suo editor di documenti preferito (e approvato dalla società / squadra) e digitare tutto.

La ragione per cui pongo questa domanda è perché sembra che le persone di fascia alta dello spettro tendano a produrre documenti che siano più leggibili, concisi ma che abbiano esattamente le informazioni che vorrai in una specifica di progettazione in modo che le persone future che lo leggono abbiano molto più beneficio. Le persone sul lato opposto dello spettro tendono a produrre documenti che non sono altrettanto utili o chiari e molte volte, anche con diverse iterazioni di revisioni del design, il loro lavoro non sembra altrettanto utile (quindi le specifiche che producono diventano scritte solo dumping che nessuno legge o si fida a causa del modo in cui sono scritti).

Non sto proponendo che la squadra agile sia segregata e solo certe persone hanno determinati ruoli che non cambieranno mai. Sto chiedendo... 1) cosa fai nei tuoi team con persone che hanno punteggi molto diversi (a) x (b) x (c) 2) Ha senso non dare la stessa responsabilità a tutti. Invece, dare solo attività di aggiornamento più piccole (o nessuna) a quelle nella parte bassa dello spettro. Ma poi lavora con questi individui identificando (a), (b) e (c) i fattori che dovrebbero migliorare e man mano che questi vengono migliorati, dà loro più responsabilità.

Personalmente, non sono venduto in un modo o nell'altro, sono solo curioso di sapere come gli altri team si occupano di questo.

agile team documentation

posta DXM 09.10.2011 - 07:40

fonte

4 risposte

Leggi altre domande sui tag agile team documentation

Quale struttura dati posso usare per modellare una rete di nodi e spigoli? Alternative a * documenti * nello SDLC?

score 4 · Answer 1

Si

Permettetemi di rispondere con una contro-domanda: se esistesse un componente del sistema particolarmente adatto allo skillset di uno sviluppatore, la preferenza del team dovrebbe essere che lei è l'unica che lavora su di esso? In una squadra agile, quasi certamente no. Uno degli obiettivi del "processo agile" è condividere e distribuire conoscenze. Se quelli che non sono bravi a scrivere i documenti di progettazione non ottengono pratica e feedback, come miglioreranno?

Costruire manutenzione, scrivere codice, compilare, progettare documenti, eseguire il debug, testare sono tutte parti del ruolo di sviluppatore software in quasi tutte le organizzazioni. Se hai un interesse a lungo termine nell'investire nei membri della tua squadra, allora dovresti cercare di migliorare le abilità più deboli, possibilmente abbinandole a un mentore con una forza in quell'abilità. È difficile migliorare senza fare pratica.

Se i documenti di progettazione sono importanti o meno per un team agile, oltre al punto. Se uno sviluppatore non può comunicare bene un progetto, allora non può comunicare bene. Ho lavorato su team in cui i membri del team non potevano usare svn. Ho lavorato su team in cui solo una persona sapeva come formattare un file di configurazione. Personalmente ritengo che Microsoft Word sia intenzionalmente progettato per funzionare in diretta opposizione al modo in cui penso a scrivere documenti. Non importa. Se questo è lo strumento che usa il mio team, allora devo adattarmi a quell'ambiente per lavorare efficacemente in una squadra. (Questo non vuol dire che non ci sono modi per cambiare l'ambiente, ma questa è una discussione diversa).

score 3 · Answer 2

Scrivere la documentazione è un compito condiviso come tutto il resto di un team agile.

Inizia chiedendo al tuo team di che tipo di documentazione hanno realmente bisogno, quanto di esso e quanto spesso deve essere aggiornato. Quindi guidali attraverso quella discussione tenendo presenti i valori agili. Alla fine dovrebbero essere d'accordo e impegnarsi in qualcosa, e qualsiasi cosa loro escano è probabilmente la risposta corretta nel tuo caso. Non è il tuo posto per dire loro come dovrebbero farlo.

Spesso risulta che la documentazione non è utilizzata nella pratica e esiste solo a causa delle politiche aziendali. Se scopri che non hai bisogno di tutto questo, la maggior parte del problema con la documentazione scritta va via. Ad esempio, ricavare conoscenze dal codice usando commenti, codice pulito e test di unità come le specifiche aiuta molto.

score 1 · Answer 3

È una buona cosa che tu stia considerando di documentare le specifiche di progettazione. Come hai detto tu, se la scrittura viene lasciata ai singoli individui, otterrai vari livelli di qualità. Un modo per aumentare la qualità e il valore di questo tipo di documentazione è progettare modelli di ciò che dovrebbe essere documentato e buoni esempi di cosa includere e non includere. Quindi, 1 persona anziana esamina l'output (molto simile a una revisione del codice ma con un numero massimo fisso di iterazioni). È difficile ottenere un output omogeneo senza farlo.

Inoltre, tieni presente che alcune persone tecniche non sono affatto abili nello scrivere. Assicurati di non premere quelle persone per l'esecuzione di tali compiti. Se si dispone di un sistema con un numero elevato di componenti, la maggior parte delle persone deve aiutare con la documentazione. Incaricare solo pochi esperti renderà il loro output di sviluppo a soffrire.

score 0 · Answer 4

Non esiste una ricetta fissa per la documentazione; come tutto il resto, dipende molto dalle persone in una squadra e dalle loro personalità e abilità. Ognuno può fare la propria parte o una persona può assumersi l'incarico. Va tutto bene, davvero. Ho ottenuto buoni risultati con il tester che scrive la maggior parte della documentazione, ma è forse il migliore quando un architetto / capo di progetto fa la documentazione. Anche ogni programmatore che fa la sua parte può funzionare, ma alcuni programmatori sono davvero cattivi in questo.

La domanda che dovresti porci è qual è il modo migliore per affrontare il problema con la tua squadra, non come dovrebbe essere fatto in un mondo ideale. Usa i punti di forza delle persone o rafforza le capacità delle persone se sono cattive in qualcosa o, ancora meglio, fai entrambe le cose quando puoi.