Correzione di bug generati da un'altra squadra

Per cosa stai cercando di ottimizzare?

1. Qualità del codice: questa è la tua occasione per capire in che modo questo bug è sfuggito dal laboratorio in primo luogo. A seconda del tempo che vuoi dedicare a questo, puoi esaminare una revisione del codice con tutto il team o l'analisi delle cause principali.

   • Non basta guardare il codice ma tutto ciò che riguarda il processo di sviluppo e test

     • Perché non è stato trovato nei test? Stai usando prima il test, giusto? Prendi in considerazione tutti i quadranti ?
     • Perché non hai addestrato i membri del tuo team in questa zona?
     • Hai interrotto processi che hanno causato questo difetto o permesso di essere creato e non trovato?

2. Conoscenza / apprendimento del team: accoppia un esperto del team che ha creato il bug (esperto in questo settore, non solo qualcuno di quel team) con qualcun altro che non conosce quell'area, la sua conoscenza si diffonderà e tu avrà più esperti in questo settore.

3. Felicità del team: cerca di trovare la soluzione di cui tutti, o la maggior parte della gente, sono soddisfatti, discuti il problema in modo aperto e non giudicante con i team e raggiungi un consenso.

4. Velocità: assegna il bug a chiunque abbia la larghezza di banda su cui lavorare adesso . Questo può essere difficile da ottimizzare, chi lo farà il più veloce, chi può iniziare a lavorarci adesso, è meglio iniziare o aspettare qualcun altro. Attenzione a questo , anche se ottimizzato in modo efficiente, oltre a possibilmente avere un effetto negativo su tutti gli altri parametri qui menzionati, può portare a un aumento del debito tecnico ancora maggiore. Ricorda: più fretta, meno velocità.

bugs must be fixed by the ones who made them

I programmatori cercano una specie di giusto e sbagliato nel mondo e non trovano giustizia: dov'è Batman quando hai bisogno di lui! Non c'è motivo di sconvolgere le persone senza una ragione, quindi vediamo se ci sono alcuni benefici "aziendali" generali.

1. Carico del lavoro di squadra - a volte una squadra diventerà più affollata di un'altra. Ciò accade a causa di membri che lasciano o prendono tempo libero. Possono avere meno talento. È possibile che la loro parte sia solo più difficile.
2. Responsabilità - Questo deve essere considerato a livello di squadra. Sono pigri e creano bug perché possono lasciare l'altro ragazzo. Non darei per scontato che stia succedendo. Un giorno, potrebbero dover correggere i bug.
3. Uso inefficiente del tempo - Richiede più tempo per correggere bug non familiari. Vedi # 1 per determinare se una squadra può ancora farlo più velocemente dell'altro. Solo se riesci a dimostrare che una quantità sproporzionata di tempo è spesa per correggere gli altri bug del team e nel lungo periodo rallenta l'intero progetto, hai un vero argomento.
4. Non è divertente. - È vero, ma non farei questo argomento. Puoi affermare che la tua squadra si sente meno importante essendo obbligata a fare più di questo tipo di lavoro.

Scopri chi ha deciso di farlo per qualsiasi motivo. Quindi puoi considerare i pro e i contro. Fai sapere loro che ti infastidisce, ma devi confrontare le squadre oltraggiate per i benefici per il cliente e il cliente dovrebbe vincere a meno che non siano completamente distorti. Condividere il padrone di mischia tra due squadre potrebbe essere il problema. Un SM dedicato può essere più territoriale e protettivo a causa dell'impatto negativo sulla squadra.

Con gli altri suggerimenti su ciò è una buona possibilità per una revisione del codice. Sarebbe fattibile per la persona a cui è stato assegnato l'errore di accoppiarsi con qualcuno dell'altro team per risolverlo. La combinazione di persone di ogni team contribuirà ad ampliare la conoscenza della base di codice e a dare un'idea di come funziona l'altra squadra.

Riesco a vedere che ciò accade in due situazioni e in quelle situazioni sono necessari diversi modi per risolvere il problema.

1. I due team lavorano su diverse aree dell'intera applicazione, hanno diverse aree di competenza e i bug vengono assegnati alla squadra sbagliata perché il problema sembra a prima vista appartenere a quel gruppo.
   In tal caso, benvenuto nel mondo dello sviluppo di software su larga scala.

   In questo caso il problema può essere affrontato in modo relativamente semplice. Se ti rendi conto che, dopo aver analizzato il bug, non si trova nella tua area di competenza, hai riassegnato il bug alla giusta squadra / persona.
   Se accade molto spesso, potresti pensare di creare un piccolo team con persone di entrambe le squadre "A" e "B" per pre-analizzare i problemi in arrivo e assicurarsi che vengano assegnati al team giusto.

2. I team lavorano sulle stesse parti dell'intera applicazione e hanno aree di competenza che si sovrappongono.
   In questo caso, dovrebbero essere considerati come una grande squadra e il problema principale sembra essere che i membri del team non la vedono come tale. In questa situazione, la soluzione dovrebbe essere cercata di più nell'area in cui le squadre "A" e "B" devono considerarsi membri di una squadra più grande.

Lo vedo come un'opportunità per codificare casualmente la posizione del bug e i suoi dintorni, quindi non sono mai stato troppo preoccupato quando mi è successo.

Forse potrebbe essere usato come una terza possibilità; tratta i bug come tempo di revisione del codice o tempo di debug peer. Ciò ti consente anche di farti un'idea del lato economico con cui l'altro team sta lavorando; dal momento che una squadra sembra dipendere dall'altra, è sempre utile condividere questa conoscenza.

Idealmente ciò avrebbe bisogno di evolvere organicamente, lasciando emergere dalla discussione i problemi più dolorosi; Credo fermamente che questo dovrebbe non essere richiesto dalla direzione:)