Come scusarsi quando hai rotto la costruzione notturna [chiuso]

Il mio primo impegno nel mio progetto ha comportato la rottura del build notturno e le persone sono su di me mentre ci stiamo avvicinando al rilascio. Voglio inviare un'e-mail di scuse che dovrebbe sembrare sincera e allo stesso tempo suggerire che questo è stato il mio primo impegno e che non si sarebbe più ripetuto.

Essendo un madrelingua inglese, ho difficoltà a trovare le parole giuste. Qualcuno può aiutarmi per favore?

Non scusarti!

• Rompere la build una volta su una luna blu non è un grosso problema e non dovrebbe mai essere un ostacolo allo spettacolo.
• È colpa del tuo manager per non aver configurato build automatiche continue.

Inoltre, scommetto che la tua squadra fallisce il "Joel Test" e non può fare un build in un solo passaggio.

Se è così, questa sarebbe un'altra cosa per cui non dovresti scusarti. In effetti, è un anti-modello di squadra.

Bagel. Ciambelle. Ecc. In una società per cui ho lavorato in passato, controllare il codice non funzionante o causare in altro modo l'interruzione del collega viene generalmente risolto introducendo alimenti di scuse il giorno successivo.

Un giorno abbiamo avuto un ragazzo che ha spazzato via un database di produzione, causando un forte panico e una notte tarda per tutto il team. Il giorno dopo ha grigliato hamburger per pranzo.

Adoro le scuse dei colleghi. Scuse gustose e gustose.

Due citazioni per te:

L'uomo che non commette errori di solito non fa nulla .-- William Connor Magee

Chiunque non commetta errori non si sta impegnando abbastanza .-- Wess Roberts

Sono d'accordo con Jim G. , non scusarti ma impara da esso e non commettere più lo stesso errore ... tienilo a SECCO;)

Non scusarti, basta FIX IT il prima possibile. Va bene però, tutti rompono la costruzione almeno una volta, nella mia ultima compagnia è stato qualcosa di un rituale di iniziazione. Quando un membro del team ha rotto la build, abbiamo messo un papero di gomma sulla sua scrivania la mattina prima che entrasse, questo gli ha fatto sapere che ha rotto la build e lo avrebbe riparato.

L'abbiamo chiamato Duckie per l'integrazione continua e quando lo facevi per il giorno in cui le persone ti prendevano in giro, ma era tutto divertente, nulla di tutto ciò doveva essere di cattivo umore.

Abbiamo preso qualcosa come una build rotta e l'abbiamo trasformata in un esercizio di team building.

"Scusa colpa mia!" è come mi scuso di solito quando ho rotto la build. Succede. Ma come altri hanno già detto, questa è un'opportunità per migliorare i tuoi sistemi in modo che una persona non possa rompere così facilmente la costruzione per tutti gli altri.

Non vorrei scusarmi formalmente in queste circostanze, ma se in realtà ritieni che un'apologia più formale sia appropriata, le tue scuse dovrebbero fare queste cose:

• Esprimi rammarico.
• Esporre il problema.
• Assumersi la responsabilità.
• Fare ammenda.
• Salva la faccia.

Cioè, "Mi dispiace [EXPRESS REGRET] di averti disturbato [ASSUMI LA RESPONSABILITÀ] accidentalmente [SAVE FACE] rompendo la costruzione [STATE THE PROBLEM]. Le ciambelle sono con me domani. [MAKE AMENDS]"

Ogni parte è necessaria con scuse adeguate; se non si afferma il problema, non è chiaro. Se non esprimi rammarico, assumiti la responsabilità e fai ammenda, le persone si sentono come se fossi sincero. La parte salvavita è la parte più trascurata delle scuse; la parte salvavita è ciò che ricorda alla persona lesa che sei un collega di valore che a volte commette errori e non un idiota (o un sabotatore!)

Infine, alcuni pensieri sulla rottura della build:

Lavoro nel team di compilatori C # / Visual Basic. Ovviamente oggi Visual Studio è un progetto così imponente che ha un team tutto suo solo per gestire le infrastrutture di costruzione e una stanza enorme con un proprio sistema di climatizzazione dedicato. A metà degli anni '90, quando ho iniziato come stagista, il team di compilazione di Visual Basic era un tirocinante - io - e un armadio pieno di macchine. I tempi sono cambiati!

In quei giorni prima della continua integrazione e dei forti processi di check-in, i team avrebbero avuto una serie di penalità per aver rotto la build. In alcune squadre la penalità era che se hai rotto la build, dovevi indossare un cappello divertente ogni giorno al lavoro fino a quando qualcun altro ha rotto la build. In alcune squadre, se indossavi quel cappello, eri responsabile di verificare che la costruzione notturna fosse corretta.

Quest'ultimo bit sembra forse crudele, ma in realtà ha avuto uno scopo prezioso. Poiché quasi tutti hanno rotto la build in un momento o nell'altro, alla fine l'intero team avrebbe imparato i processi per verificare la build notturna.

Non scusarti. Sono i tuoi colleghi che hanno la colpa di non rivedere il tuo primo commit e di non avere un sistema di feedback rapido per build come un server di integrazione continua.

Nel mio attuale lavoro abbiamo una regola informale secondo cui qualcuno che commette furtivamente poco prima di lasciare il lavoro e si scopre di rompere la costruzione deve portare caramelle / torte / bevande per l'intera squadra il giorno successivo. Ma abbiamo una continua integrazione che ci avvisa di una build rotta durante il giorno. E la regola probabilmente non si applica al primo commit di qualcuno.

Comunque, una posta formale di scuse è probabilmente un po 'troppo.

Una regola fondamentale - quando ti sbagli, ADMIT IT: - | Non devi scusarti per scusarti. Tutti fanno degli errori. I professionisti lo ammettono. Questo è il lavoro di squadra. Gli altri membri del team dovrebbero riunirsi per aiutarti. In caso contrario, chiedi aiuto. Il massimo da dire in seguito è: cosa possiamo imparare da esso?

Dicono che un matrimonio riuscito si basi su tre piccole parole: "Ho sbagliato".

Se qualcuno non commette un errore occasionale, non sta lavorando, ma un errore da cui non si impara sono due errori.

Le migliori scuse stanno risolvendo rapidamente la pausa

Se la tua azienda ha già un modo per testare le modifiche della tua build, allora (A) le tue modifiche non sono riuscite (ma le hai comunque verificate) o (B) sono riuscite (e devi creare un nuovo caso di prova).

Se i tuoi colleghi testano con cautela le loro modifiche e si aspettano di trovare interruzioni nella build notturna, allora (C) hai un processo fragile (e devi introdurre test come quello trovato in Extreme Programming).

È possibile che (D) le tue modifiche abbiano causato cambiamenti imprevisti nel codice di Bill che erano già in atto o modificati nella stessa build del tuo.

A seconda di come testerete voi e la vostra azienda, mi scuserei caso per caso:

• (A) Ho fallito il test di compilazione ma ho verificato le mie modifiche. Mi dispiace, sto cambiando il mio processo, quindi non lo farò più.
• (B) Ho superato il test di build e ho aggiunto il test JUnit XYZtest.java per ridurre le possibilità di ricorrenza.
• (C) Dato che non abbiamo un processo di test di compilazione, ne sto creando uno per le mie modifiche. Vorrei condividere con te come possiamo migliorare il nostro processo di creazione.
• (D) Lavorerò con Bill per scrivere un test di JUnit XYZtest.java per ridurre le possibilità di ricorrenza.

Sono sicuro che c'è una (E) a cui non ho pensato.

Si noti che sto dicendo "per ridurre la possibilità di ricorrenza" piuttosto che "in modo che non accada più". Accadrà di nuovo. Ma puoi migliorare il tuo processo per ridurre tale possibilità. Questo, penso, è uno dei segni di un programmatore vincente.

Non scusarti. Sei umano e commetterai errori. Ognuno interromperà la build di tanto in tanto, la chiave è semplicemente risolverlo rapidamente.

Per quanto riguarda le persone che ti saltano addosso ... beh, sono curioso di sapere se hanno mai scritto in un bug.

Come affrontare questo dipende dall'atmosfera nel tuo gruppo. Se è una cultura della colpa, starei molto attento a scusarti e a come lo fai. Se si tratta di un'atmosfera collaborativa e positiva, allora sì, qualcosa del tipo "Ho sbagliato, mi dispiace. Come possiamo evitarlo in futuro?" è probabilmente una buona idea.

In ogni caso, uno scherzo come questo dovrebbe essere accompagnato da una sorta di post-mortem per a) scoprire come è successo eb) come ridurre al minimo le possibilità che accada di nuovo.

Non ho familiarità con la tua struttura (lavoro in un ambiente molto diverso) ma alla fine la realtà è che occasionalmente le persone commettono errori e le cose si rompono. Impari dall'esperienza e vai avanti.

Nel mio ambiente se rompessi la costruzione otterresti una buona nervatura nervosa e un comico spiritoso. Non sono sicuro in quale paese di lingua inglese tu sia, ma potrebbe essere che come madrelingua inglese non stai ricevendo la natura sottolineata dei commenti.

Essendo dall'altra parte come sviluppatore senior, una volta ho commentato una revisione del codice che un modo di fare x "succhiato" non perché il codice era cattivo ma lo fa per la struttura del progetto. Per me è stato più un commento che ho bisogno di risolvere il problema strutturale. Solo più tardi ho scoperto che il Jr Dev era molto arrabbiato con lui a causa del mio impreciso discorso irriverente.

Um. Ottieni il token build rotto . Passa la rabbia al prossimo fortunato destinatario. Succede tutte le volte. La qualità è importante, ma gli errori sono inevitabili. Aggiustali. Vai avanti. Peccato per il prossimo povero ragazzo.

Come regola generale, direi:

Se il tuo checkin provoca un errore del compilatore che ti saresti sorpreso se avessi fatto un "get latest" prima del check-in, un semplice "whoops, my bad" è in ordine. (soprattutto se si cammina alle 10 del mattino successivo, mentre tutti stanno decidendo a quale gruppo di modifiche tornare)

Se il tuo check-in provoca comportamenti imprevisti generali, anche errori di runtime, non credo che dovrebbe essere tenuto contro di te. Viene con il territorio. Fino a quando tutti "ottengono" tutti generalmente passano i loro compilatori, le persone non dovrebbero davvero lanciarsi in una crisi (con un paio di eccezioni come l'eliminazione di un database, l'eliminazione della copia del server del progetto e tutti i changeset, o qualsiasi altra cosa sia così stupido che le persone debbano assumere intenti maliziosi).

Il TEAM è fallito.

La tua azienda ha bisogno di più revisioni del codice su uno sviluppatore che esegue una prima creazione.

Semplicemente non vedo come una squadra permetta che ciò continui senza che facciano una revisione e offrano alcune garanzie lungo il modo in cui stai facendo le cose correttamente.

Essere vicini al tempo di rilascio non è una scusa, ma un motivo migliore per ricontrollare il nuovo codice.

Se la tua versione non può essere facilmente annullata, ci sono problemi ancora maggiori con questo gruppo.

Non capisco perché le persone siano dappertutto. Se il sistema è configurato correttamente, dovrebbero essere in grado di prendere in giro le modifiche / risolverle molto rapidamente.

Ma ancora una volta, se sei uno di quei ragazzi che hanno rotto la costruzione di Windows, allora ... Non posso fare a meno. (È incredibilmente difficile da fare - prima che qualcuno metta in discussione le filosofie della SM, ma di tanto in tanto qualcuno lo fa - e l'intero QA dell'azienda si ferma per un giorno).

E sì, non scusarti. Basta fare una chiacchierata con il tuo manager e fargli capire che hai imparato da quello che hai fatto.

Le build si rompono continuamente. Bug ed errori sono un dato di fatto, ed è per questo che dovresti avere un processo che minimizzi gli effetti di bug ed errori.

Se una rottura del build è un grosso problema, significa che il tuo processo è rotto.

Dovresti fare build continue, non build notturne.

Meglio una risposta tardiva che mai ...

Come molti altri hanno già detto, non scusarti per aver rotto la build. Ammetti semplicemente che eri tu e vai avanti con il lavoro. Questa roba accadrebbe se tu fossi lì o no, e nessuno merita di essere trattato male a causa sua. Le persone reagiscono male sotto pressione, quindi se sei in grado di rimanere calmo e semplicemente andare avanti con il lavoro, ti distinguerai quando è importante. Il mio consiglio per quando le persone ti mettono in difficoltà è semplicemente quello di evitare di essere difensivo, disinnescare la situazione facendo sapere alle persone che stai affrontando il problema o sei pronto a chiedere consigli se scopri di essere bloccato.

Personalmente, vedo una build rotta come un'opportunità.

• Se la build si interrompe e puoi dimostrare che è colpa tua, è probabile che dimostri che l'integrazione continua e i processi di build stanno facendo il loro lavoro. Questa è una buona cosa, poiché convalida i tuoi processi. Se la build non si rompe mai, mi preoccuperei che ci fosse qualcosa di sbagliato.
• Se hai rotto la build in un modo abbastanza comune, e capita spesso di rompersi in questo modo, forse qualcosa manca nel processo CI. Questa è un'opportunità per migliorare i tuoi processi in modo che gli scenari di errore comuni possano essere gestiti meglio.
• Se hai superato il dovere e hai incasinato davvero la build con un problema oscuro, allora hai l'opportunità di conoscere qualcosa di nuovo che potrebbe essere abbastanza importante da innescare un avvertimento per il resto della squadra.

Quindi quello che sto dicendo è che rompere la build di tanto in tanto significa che le persone stanno facendo il loro lavoro. Sicuramente potresti aver fatto un errore, ma se lo usi come un'opportunità per imparare, stai facendo il tuo lavoro semplicemente imparando a farlo meglio la prossima volta.

Di 'loro che hanno bisogno di build CI per il check-in. In questo modo non dovresti aspettare fino alla sera per sapere che è rotto. SÌ!!! Di 'loro che è il processo che è sbagliato, nient'altro. Hai appena identificato un gap nel loro sistema.

Ma sì, assicurati di ripararlo. Non un grande affare. Non è in produzione. Solo una notte senza valore.

Una pratica abituale nella mia azienda è:

• Gridando "non sono stato io!" (di solito prove CVS / SVN altrimenti)
• Indossa una maglietta con scritto "my-userlogin ist Schuld!" (sì, il 50% della nostra maglietta del nostro sviluppatore)
• Affermando che funziona nella casella di posta locale e tutti i test sono andati bene

La mia azienda ha anche un buon modo di gestire un "incidente" del genere:

• Il lavoratore deve indossare il seguente costume per mezza giornata ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• Non mi scuserei.

• Darei la colpa al lead CI per avermi permesso di eseguire build non funzionanti.

• Dovrebbe essere in atto un processo CI per impedire agli sviluppatori di commettere codice non funzionante.

• Se la compilazione locale non riesce, non dovrebbe essere consentito accedere al server di compilazione.

Mentre penso che possa esserci qualche tipo di scusa, per favore non dire: "Farò in modo che questo non accada di nuovo". Perché lo farà. E se lo fa ti morderà.

Se stai lavorando a un progetto open source,

dì semplicemente "Mi dispiace, ho rotto la build. Forse ero troppo assonnato!"

e aggiungilo come commento github.

È perché molti sviluppatori open source scrivono codice durante la mezzanotte.