Come convalidare la necessità di documentazione?

3

Una volta ero in un progetto in cui un manager non tecnico aveva trascorso metà della squadra a documentare ciò che avevano appena fatto in modo che qualcuno con una comprensione zero della tecnologia sarebbe stato in grado di capire la tecnologia. Personalmente, ho pensato che fosse uno spreco enorme, ma non c'era modo di convalidare che questo fosse o non fosse uno spreco.

C'è un mezzo leggero per convalidare la necessità di documentazione prima di impegnarsi a produrre la documentazione?

Esempio 1: Supponiamo che il team stia utilizzando un software off-the-self senza personalizzazione. Il test potrebbe pubblicare una descrizione del lavoro su base mensile per accedere alla probabilità che un esperto nel software possa essere trovato a un livello di costo accettabile.

Esempio 2: richiama automaticamente variabili, funzioni, ecc. dal codice e due settimane dopo la scrittura del codice, generando domande che valutano automaticamente la conoscenza del proprio codice da parte degli sviluppatori senza accesso al codice. Se lo sviluppatore non è in grado di rispondere alle domande, deve spiegare il codice a un altro sviluppatore e lo sviluppatore decide se deve essere prodotta la documentazione.

Esempio 3: Un altro modo sarebbe quello di prendere la probabilità che il codice venga utilizzato in base all'analisi runtime e fare un riferimento incrociato sia con la volatilità di input / output sia con la probabilità storica di errori / bug riportato da quella sezione di codice e / o richieste basate sul cliente per aggiornare il codice.

Onestamente, non credo che questi siano grandi esempi, ma sono più che altro un tentativo di dare l'essenza generale di quello che sto cercando, e che l'obiettivo è il metodo più utile per le barebone per farlo.

    
posta blunders 06.09.2013 - 14:56
fonte

2 risposte

3

Misura il tempo necessario ai nuovi membri del team per essere produttivi. Confrontalo con altre risorse disponibili per aumentare. Ad esempio, se hai (che chiamerò collettivamente materiale di rampa):

  • Esercitazioni
  • Documenti (ad esempio documenti della guida in linea)
  • Documentazione (cioè intestazioni di funzioni API ecc.)
  • Documenti in cui è possibile effettuare ricerche con Wiki / OneNote condivisi

Quindi dovresti essere in grado di far funzionare qualsiasi sviluppatore competente a piena capacità produttiva entro 3-6 mesi (a seconda della complessità del software). Se è necessario che i nuovi sviluppatori inviino un numero arbitrario di miglioramenti o aggiunte utili ai documenti e / o ai tutorial, sono sempre aggiornati e in miglioramento.

Bonus: tutorial / documenti possono essere resi disponibili per i clienti e diventare parte del prodotto.

Quindi, se i nuovi sviluppatori (continuamente) non stanno aumentando sufficientemente in quel momento, allora la qualità del tuo materiale ramp-up non è in linea con la complessità del tuo prodotto o dell'ambiente di lavoro, e deve essere aumentato o migliorato.

    
risposta data 06.09.2013 - 20:33
fonte
1

Hai alcune opzioni:

  1. Programmazione abbinata. Hanno le persone che non capiscono la coppia di tecnologia con le persone che lo fanno. Potrebbe rallentare un po 'la velocità, ma è più efficace della scrittura di risme di documentazione.
  2. Consulta il proprietario del prodotto, quali sono i criteri di accettazione stabiliti dal proprietario del prodotto. Forse il proprietario del prodotto non sa che questa persona sta spendendo cicli di progetti su questo.
  3. Scrivi buoni test per x-unit. Test ben scritti dovrebbero fornire un'ampia documentazione per il sistema in fase di scrittura.
  4. Fornisci loro l'url di Stack Exchange;)

La documentazione che è veramente necessaria emerge, non è il risultato di uno sforzo forzato forzato.

Cheers!

    
risposta data 07.09.2013 - 02:21
fonte

Leggi altre domande sui tag