pianifica la conformità e mantiene i supporti tecnici e risolve i problemi

Questo non è qualcosa che il mio team fa oggi ma è un cambiamento proposto al nostro processo che ho fluttuato da altre persone per un po '(e sono curioso di sapere cosa ne pensa la comunità, quindi tutti i commenti sono benvenuti ) ...

Hai detto che la tua squadra sta già facendo mischia e ha un arretrato di lavoro rappresentato da carte. Per uno sviluppatore che lavora su una nuova funzionalità (nuovo sviluppo) e per farlo funzionare, è molto simile a lavorare su una funzionalità rotta esistente (bug fixing) e farlo funzionare. Il lavoro è lavoro.

Tu, in qualità di proprietario del prodotto, puoi trattare la risoluzione dei bug nello stesso modo in cui tratti le nuove attività di sviluppo e assegna loro la priorità nello stesso backlog. Alcuni bug (o richieste di funzionalità) possono attendere, altri devono essere corretti. Alcuni sono molto importanti, alcuni possono essere risolti in seguito. Puoi decidere su questi fattori e metterli nella posizione appropriata nel backlog e decidere se devono essere in versione corrente o ritardati fino al prossimo.

In questo modo, finché il tuo team mantiene la velocità del punto, dovresti essere in grado di avere un'idea approssimativa di quando il rilascio sarà completato. Tutto quello che devi fare è tracciare un grafico con due linee che interpolano i seguenti set di dati:

1. Il completamento della storia della tua squadra - quanti punti cumulativi sono completati ogni iterazione
2. Scorrimento del raggio d'azione del tuo team - numero totale di punti che fanno parte del rilascio. questo numero salirà ovviamente quando aggiungerete bug per far parte del rilascio, ma questo è solo un riflesso della realtà.

In un punto temporale in cui le due linee si intersecano è la tua data di rilascio stimata.

Sono d'accordo con i tuoi sviluppatori sul fatto che spaccare la squadra non è l'ideale. Personalmente, odio essere isolato nella terra di manutenzione, mentre l'altra parte della mia squadra ha guidato l'architettura e le principali decisioni di progettazione senza di me. Allo stesso tempo, se ritieni che gli sviluppatori 2/5 debbano dedicarsi alla risoluzione dei bug, che cosa significa semplicemente richiedere che il 40% del tempo (né più né meno) in una determinata iterazione sia dedicato esclusivamente ai bug, ma l'intera squadra sarebbe coinvolto?

Oltre a capire il problema della programmazione, come menzionato in altri, anche voi come team dovreste capire la causa principale di tanti bug in arrivo che stanno influenzando la pianificazione. Non cercare te stesso una soluzione, invece organizza una serie di incontri retrospettivi e lascia che il team guidi la discussione. Lavora insieme per stabilire obiettivi / obiettivi di qualità ragionevole e poi chiedi loro idee su come raggiungerli.

Non so se la tua squadra stia facendo uno di questi oggi, ma ecco alcune idee:

1. Revisioni del design - prima di entrare nel mondo del lavoro, fai una rapida revisione da parte dei colleghi del lavoro che ti aspetta. Questo dà la possibilità di un secondo set di occhi per individuare potenziali problemi prima che entrino nel codice, che è molto più costoso da risolvere.
2. Revisione del codice - Con l'aiuto degli strumenti di revisione del codice (alcuni sono open source), il processo di revisione del codice può essere eseguito in modo molto efficace. Ti aiuterà a condividere le conoscenze e identificare potenziali aree problematiche prima ancora di entrare nel codice di produzione.
3. QA: hai un team di test dedicato o gli sviluppatori eseguono i propri test? Trovo che gli sviluppatori tendono ad essere condizionati o "abituati" a come il software funziona e iniziano a trascurare i problemi di usabilità. Una nuova serie di occhi dalla prospettiva dell'utente finale può trovare ogni genere di cose.
4. TDD / Test delle unità automatizzate - questo non è facile e molti team hanno provato e fallito. Ma se fatto bene, ti permetterà di consegnare componenti che sarebbero molto più solidi e non richiederebbero ai tuoi ragazzi di tornare da loro mese dopo mese. Anche per alcuni ingegneri, che non sono così dettagliati, il TDD può fare miracoli. Ho lavorato con alcuni ragazzi che scrivono codice decente e producono funzionalità, ma mancano costantemente i confini e i casi ipotetici. Direi che spendere tempo in anticipo per scrivere il codice di prova sarebbe un grande investimento rispetto al tempo trascorso dopo che uno di questi casi limite è stato riscontrato dal cliente e richiede una correzione dopo il rilascio. Con TDD, è un'altra occasione per verificare gli scenari dei casi d'uso e quindi semplicemente lasciare liberi gli sviluppatori. Al termine dei test, sarai molto più a tuo agio che stai pubblicando qualcosa di qualità.

Questo è un problema comune e impegnativo. Molte questioni relative ai clienti sono progetti di ricerca davvero lunghi, e finché non vengono pienamente compresi, non è possibile stimare lo sforzo necessario per risolverli.

Una soluzione è quella di dedicare due sviluppatori alla volta strettamente per la risoluzione, ruotando l'assegnazione a un altro paio di sviluppatori ogni tre o quattro settimane.

Vedo alcuni problemi qui:

• Il tuo software sembra eccessivamente bacato se i tuoi sviluppatori vengono sommersi da segnalazioni di bug. Devi dare un'occhiata (Root Cause Analysis) ai bug che si stanno verificando e vedere perché si verificano. Se non lo fai ti imbatterai semplicemente negli stessi problemi ad ogni versione.

• Misura il processo di correzione dei bug. Registrare la data in cui è stato sollevato il bug, la data in cui è iniziata l'indagine, la data in cui è stata trovata una soluzione suggerita. Vedi se ci sono bloccanti qui.

• La tua documentazione è cattiva? Le tue interfacce utente non sono intuitive?

• Sembra che tu non abbia le risorse per supportare più di una versione del tuo prodotto. Arriva il momento in cui smetti di mantenere vecchie versioni di prodotti a meno che non ci siano circostanze eccezionali (bug critici / ostili) e se un cliente vuole qualcosa in un vecchio prodotto devi sapere quando dirgli No / Non vale la pena aggiustarlo. / p>

• Sei il capo, se vuoi che i tuoi dipendenti lavorino in un modo nuovo che dovrebbero. Ascolta le loro proteste, ma spiega loro perché le cose devono cambiare e chiedi loro se possono vedere alternative.

Se hai troppi bug nella tua versione attuale, dedicare risorse alla prossima versione (prima di ridurre il numero di bug) aggiungerà solo altri bug.

Lo renderei una priorità

1. assegna la priorità ai bug esistenti
2. trova e corregge quelli ad alta priorità
3. eseguire un'analisi delle cause di root per capire perché stai ricevendo così tanti bug

Dì ai tuoi sviluppatori di RALLENTARE. Scrivere velocemente il codice buggy è più dannoso che scrivere codice stabile lentamente.

Lo scenario è:

• Il tuo team è composto da quattordici persone, con cinque sviluppatori.
• Sei un aiuto privato e senza debiti.
• Il tuo cliente ama il tuo prodotto abbastanza da interagire con te invece di andare da qualcun altro.
• Hai un'attività tecnica e una persona non tecnica non può supportare il prodotto.
• I tuoi sviluppatori hanno bisogno di concentrarsi su funzionalità e correzioni di bug.
• I tuoi sviluppatori non vogliono alternare lo sviluppo di funzionalità e correzioni di bug.
• Sei impegnato a sviluppare, ma non hai avuto versioni recenti per i clienti.
• Hai favorito la creazione di funzionalità per la correzione dei difetti, forse per un po 'di tempo.

La risposta è semplice, ma a seconda che la tua squadra abbia un atteggiamento maturo, spiacevole.

• Devi pagare il debito tecnico per correggere i bug.
• Devi supportare i clienti che utilizzano membri del team.

Il tuo istinto originale era probabilmente corretto. Alcuni membri del team devono lavorare con funzionalità e alcuni bug, alternando periodicamente. Se si è passati attraverso il database dei bug e tracciato il difetto al suo autore, questo sarebbe un modo per assegnare i bug e forse determinare la durata della rotazione di ogni persona. Tuttavia, a volte, il bug esiste perché la persona che scrive il particolare codice non ha l'abilità di scriverlo. Questo potrebbe essere il caso in cui la tua distinzione tra i membri junior e senior possa essere di beneficio.

Supporto clienti WRT, ti consiglio di ruotare anche quella funzione. Se un piccolo numero di persone lavora con l'assistenza clienti, sentirà le stesse domande e fornirà le stesse risposte, potenzialmente creando un database di domande frequenti. Una volta che hai scritto delle garanzie per il supporto, puoi usare meno persone tecniche per condividerle con i clienti. Esistono molti sistemi per l'assistenza clienti automatizzata, tra cui Right Now Web che potrebbe essere troppo costoso, ma forse può aiutarti a trovare indizi a un'alternativa open source. Non tutti nel tuo team avranno i talenti necessari per lavorare con i clienti, quindi potresti scoprire che hai bisogno di mordere il proiettile e se hai le capacità, fallo da solo. Almeno per un po '.