migrazione del prodotto e del team dalla gara di avvio allo sviluppo della qualità [duplicato]

3

Questo è l'anno 3 e il prodotto sta vendendo abbastanza bene. Ora abbiamo bisogno di applicare buone pratiche di sviluppo del software. L'obiettivo è monitorare i report dei bug in entrata e ridurli, consentire funzionalità infinite e prepararsi per il ridimensionamento 10x. Le frasi "test-driven-development" e "continuous-integration" non sono nemmeno comprese dalla squadra, perché erano tutte nella prima gara di prodotto di 2 anni. Le dimensioni del team tecnico sono 5.

La domanda è

  1. come vendere / convincere team e management su TDD / test di unità / standard di codifica / documentazione - con economia.
  2. allenare il team a fare qualcosa di più della semplice funzionalità di codifica e di iniziare a scrivere unità di test - il che sembra più lavoro, significa avere più tempo!
  3. come pianificare la creazione di unità per tutto il codice di produzione del backlog
posta thevikas 28.11.2011 - 10:24
fonte

3 risposte

4

Devi farlo in modo incrementale. Un approccio "big bang" causerà più disagi e potenziali problemi rispetto alla soluzione (test TDD / unità, ecc.) Che è stato progettato per risolvere.

Prendi un problema alla volta e affrontalo. Se è troppo grande, suddividilo in una serie di problemi minori.

Devi mostrare ai tuoi colleghi e al management che il problema è reale e sta costando denaro all'azienda - sia direttamente sia in tempi di sviluppo più elevati. Quindi è necessario dimostrare che la soluzione risolverà questo problema e, altrettanto importante, non causerà ulteriori problemi lungo il percorso.

In questo modo otterrai il supporto di tutti e, si spera, avrai la proprietà della soluzione. Questo dovrebbe renderli più disposti a provarlo in primo luogo e ad andare avanti anche se non mostra miglioramenti immediati.

I tuoi colleghi probabilmente hanno individuato questi problemi da soli e (si spera) stanno facendo lo stesso di te - chiedendosi come possono essere risolti. Anche il semplice atto di parlarne può fare molto.

    
risposta data 28.11.2011 - 10:35
fonte
1

This is year 3 and product is selling good enough. Now we need to enforce good software development practices.

Non sei sicuro della qualità dei processi e del prodotto e continua a vendere? Fortunato! No. Non volevo davvero criticarti, ma il mio punto è che, il fatto che il tuo prodotto stia andando bene sul mercato, è un segnale positivo. Non buttare via ancora le cose!

Ciò di cui tu, in realtà, devi veramente fare le cose lentamente. A mio parere, non è importante fare il miglior adattamento rispetto ad alcuni processi standard; piuttosto devi usare quello che fa al caso tuo.

Io non sono molto consapevole di quanto la maturità avete in alcune di queste, ma lo rendono veramente lavorare per la squadra. Prima di tutto, devi assicurare 4 cose essenziali: a. Controllo della versione, b. Bug tracking e c. gestione efficace del rilascio. d. Costruisci il seme dei test di regressione.

Nel risposta qui - ho enumerato alcune pratiche buone e semplici, se seguita costruisce buon ritmo nelle persone e aiuta a portare il codice affidabile come il fuoco chiave.

Gli stessi piccoli criteri di miglioramento passo-passo si applica se si vuole automatizzare il processo di test e procedere verso l'integrazione continua - iniziare con quello che la maggior parte delle persone concordano sul fatto che può essere banalmente e affidabile automatizzati (dopo un po 'la gente comincerà a pensare , perché lo abbiamo mai fatto manualmente).

Infine, sulla documentazione e sul processo di revisione del codice. Immagino che la maggior parte dei programmatori voglia fare un buon lavoro in questo; Il problema è che non c'è consenso, la cosa migliore è cercare di portare un approccio peer-driven a una domanda più ampia: che cosa tutti noi pensiamo sia un buon codice e documentazione! (read questo ) Mentre ti evolvi, di nuovo le persone si trasformeranno lentamente in una responsabilità personale più che politica che schiva l'attività.

Questa verità è, non ci sono grandi alternative al modo "small-step-by-step" di evoluzione codice. Chiamalo TDD, agile, iterativo o altro; questi passaggi sono ciò che rende possibile che la squadra possa capire l'evoluzione del codice e, con ogni probabilità, cercare di accelerare alla loro velocità massima.

Una volta, le persone vedono il successo in questi piccoli passi e trovano la proprietà, il loro più grande impegno per apprendere le migliori pratiche e migliorare ancora di più rapidamente, lasciandoli con questa proprietà e vedrai meraviglie!

    
risposta data 28.11.2011 - 11:38
fonte
1

Il link potrebbe aiutarti molto in questa situazione. Non aiuta esattamente a vendere l'idea di TDD / agile (dovresti usare altre fonti che spieghino i suoi vantaggi come un costo quasi costante, un basso costo di modifica, una paura ridotta del cambiamento, ecc. Per questo userò la "Extreme Programming" di Kent Beck: Explained "), ma aiuta esattamente con il processo di spostare il codice legacy nel processo agile - isolando parti del codice, trasformandole in un modulo, unitamente a testimoniallo, quindi riscrivibile in modo peupibile alla nuova versione sviluppata da TDD e sostituendo il vecchio con il nuovo - questo è ciò di cui tratta il libro.

    
risposta data 28.11.2011 - 12:13
fonte