Il mio primo impegno nel mio progetto ha comportato la rottura della struttura notturna e la gente mi sta sopra mentre ci avviciniamo al rilascio. Voglio inviare un'e-mail di scuse che dovrebbe sembrare sincera e allo stesso tempo suggerisco che questo è stato il mio primo impegno e questo non si sarebbe più ripetuto.
Essendo un madrelingua inglese non nativo, ho difficoltà a trovare le parole corrette. Qualcuno può aiutarmi?
Don't apologize!
Inoltre, scommetto che la tua squadra fallisce "Joel Test" e non può creare una build in una passo.
Se è così, questa sarebbe un'altra cosa di cui non dovresti scusarti. In effetti, è un anti-modello di squadra.
bagel. Ciambelle. Ecc. In una società per la quale ho lavorato in passato, il controllo del codice non funzionante o la conseguente interruzione del collega è in genere risolta con l'introduzione di scuse alimentari il giorno successivo.
Un giorno abbiamo fatto saltare via un database di produzione, causando un panico enorme e una nottata per l'intera squadra. Il giorno dopo ha grigliato gli hamburger per il pranzo.
Adoro le scuse per i colleghi. Scuse gustose e gustose.
Due citazioni per te:
The man who makes no mistakes does not usually make anything.--William Connor Magee
Anyone who doesn't make mistakes isn't trying hard enough.--Wess Roberts
Sono d'accordo con Jim G. , non scusarti ma impara da esso e non fare lo stesso errore di nuovo ... tenerlo ASCIUTTO;)
Non chiedere scusa, basta FISSARLO il prima possibile. Va bene però, tutti rompono la build almeno una volta, nella mia ultima compagnia è stato qualcosa di un rituale di iniziazione. Quando un membro della squadra ha rotto la build, avremmo messo un paperino di gomma sulla sua scrivania la mattina prima che entrasse, questo gli ha fatto sapere che ha rotto la build e che l'avrebbe sistemata.
L'abbiamo chiamato Duckie per l'integrazione continua e quando lo avevi per la giornata la gente ti stuzzicava ma era tutto per divertimento, nessuno di questi doveva essere meschino.
Abbiamo preso qualcosa come una build rotta e l'abbiamo trasformato in un esercizio di team building.
"Mi dispiace, il mio male!" è come di solito mi scuso 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 build per tutti gli altri.
Non vorrei fare scuse formali in queste circostanze, ma se ritieni che sia appropriata un'apologia più formale, allora le tue scuse dovrebbero fare queste cose:
Cioè, "Mi dispiace [ESPRIMI REGRETE] che ti ho disturbato [TAKE RESPONSIBILITY] accidentalmente [SAVE FACE] rompendo la build [STATE THE PROBLEM]. Le ciambelle sono su di me domani. [MAKE AMENDS]"
Ogni parte è necessaria in scuse appropriate; se non si specifica il problema, non è chiaro. Se non esprimi rimpianti, prendi responsabilità e fai ammenda, le persone si sentono insincere. La parte salvavita è la parte più trascurata di una scusa; la parte salvavita è ciò che ricorda alla parte lesa che sei un prezioso collaboratore che a volte commette errori, e non un idiota (o un sabotatore!)
Infine, alcune considerazioni sulla rottura delle build:
Lavoro con il team di compilatori C # / Visual Basic. Ovviamente oggi Visual Studio è un progetto talmente imponente da avere un team tutto suo solo per gestire l'infrastruttura di costruzione e un'enorme sala con il proprio sistema di climatizzazione dedicato. Alla metà degli anni '90, quando ho iniziato come stagista, il team di sviluppo di Visual Basic era uno stagista e un armadio pieno di macchine. I tempi sono cambiati!
Di ritorno in quei giorni prima dell'integrazione continua e dei processi di controllo intensi, i team avrebbero ricevuto una serie di sanzioni per rompere la build. In alcune squadre la penalità era che se hai rotto la build, dovevi indossare un buffo cappello ogni giorno al lavoro fino a quando qualcun altro non 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à è servito a uno scopo prezioso. Poiché quasi tutti hanno rotto la build una volta o l'altra, alla fine l'intero team avrebbe appreso i processi per verificare la build notturna.
Non chiedere scusa. Sono i tuoi colleghi a essere colpevoli di non aver esaminato il tuo primo commit e di non avere un sistema di feedback rapido per build come un server di integrazione continuo.
Al mio attuale lavoro abbiamo una regola informale secondo cui qualcuno che si impegna a malapena prima di lasciare il lavoro e scopre di rompere la build deve portare caramelle / dolci / bevande per l'intera squadra il giorno successivo. Ma abbiamo un'integrazione continua che ci avvisa di una costruzione rotta durante il giorno. E probabilmente la regola non si applica al primo commit di qualcuno.
Ad ogni modo, una mail formale di scuse è probabilmente un po 'troppo.
Una regola fondamentale: quando ti sbagli, AMMETTE: - | Non devi strisciare per scusarti. Tutti fanno degli errori. I professionisti lo ammettono. Questo è il lavoro di squadra. Gli altri membri della squadra dovrebbero stare insieme per aiutarvi. Se non lo fanno, CHIEDETE aiuto. La maggior parte di ciò che dobbiamo dire in seguito è - cosa possiamo imparare da esso?
Dicono che un matrimonio di successo si basa su tre piccole parole: "Ho sbagliato".
Se qualcuno non commette un errore occasionale, non sta funzionando, ma un errore da cui non si impara sono due errori.
Le migliori scuse stanno risolvendo rapidamente l'interruzione
Se la tua azienda ha già un modo per testare le modifiche alla tua build, allora (A) le tue modifiche sono fallite (ma le hai controllate in ogni caso) o (B) sono riuscite (e hai bisogno di costruire un nuovo test case).
Se i tuoi colleghi testano con cautela i loro cambiamenti e si aspettano di trovare interruzioni nella compilazione notturna, allora (C) hai un processo fragile (e devi introdurre test come quelli trovati in Extreme Programming).
È possibile che (D) le tue modifiche abbiano causato cambiamenti imprevisti nel codice di Bill che erano già presenti o modificati nella stessa build della tua.
A seconda di come testate voi e la vostra azienda, vorrei scusarmi caso per caso:
Sono sicuro che c'è un (E) a cui non ho pensato.
Si noti che sto dicendo "per ridurre le possibilità di ripetizione" piuttosto che "quindi non accadrà più". Accadrà di nuovo. Ma potresti migliorare il tuo processo per ridurre questa possibilità. Questo, penso, è uno dei marchi di un programmatore vincente.
Non chiedere scusa. Sei umano e commetterai degli errori. Tutti rompere la build di tanto in tanto, la chiave è quella di ripararlo rapidamente.
Per quanto riguarda la gente che ti salta addosso ... beh, sono curioso di sapere se hanno mai scritto un bug.
Come avvicinarsi a questo dipende dall'atmosfera del tuo gruppo. Se è una cultura della colpa, sarei molto attento a scusarmi e a come lo fai. Se si tratta di un'atmosfera collaborativa e positiva, allora sì, qualcosa sulla falsariga di "Ho incasinato, mi dispiace, come possiamo evitare questo in futuro?" è probabilmente una buona idea.
In ogni caso, uno scherzo del genere dovrebbe essere accompagnato da una sorta di post-mortem per a) scoprire come è successo eb) come minimizzare le possibilità che ciò 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 build avresti delle costole buone e qualche spiritosa cometa. Non sono sicuro di quale sia il tuo paese di lingua inglese, ma potrebbe essere che come madrelingua inglese non stai ricevendo la natura di sottolineatura dei commenti.
Essendo dall'altra parte come sviluppatore senior, una volta ho commentato una revisione del codice che un certo modo di fare x "faceva schifo" non perché il codice fosse cattivo ma facesse parte della struttura del progetto. Era più un commento per me stesso che dovevo risolvere il problema strutturale. Solo più tardi ho scoperto che Jr Dev era molto arrabbiato con lui a causa del mio impreciso discorso.
Um. Ottieni il token di build non funzionante . 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 causa un errore del compilatore, ti saresti accorto se avessi fatto un "get latest" prima di fare il check-in, un semplice "whoops, my bad" è in ordine. (specialmente se passi alle 10 del mattino successivo, mentre tutti decidono su quale gruppo di modifiche tornare indietro)
Se il tuo checkin causa un comportamento inaspettato generale, anche errori di runtime, non penso che dovrebbe essere tenuto contro di te. Viene fornito con il territorio. Fintanto che gli "ultimi" di tutti vengono generalmente passati ai compilatori, le persone non dovrebbero essere in difficoltà (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 talmente stupida che la gente debba assumere intenzioni malevole).
Il TEAM ha avuto esito negativo.
La tua azienda ha bisogno di più revisioni del codice su un dev che fa una prima build.
Semplicemente non vedo come un team permetta a questo di andare avanti senza che facciano una revisione e offra alcune assicurazioni sul 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 ancora più problemi con questo gruppo.
Non capisco perché le persone ti stiano addosso. Se il sistema è configurato bene, dovrebbero essere in grado di mettere a punto le tue modifiche / risolverle molto rapidamente.
Ma di nuovo, se sei uno di quei ragazzi che hanno rotto le finestre, allora ... Non posso aiutarti. (È incredibilmente difficile da fare btw - prima che qualcuno ponga le filosofie di MS, ma a volte qualcuno lo fa - e l'intera azienda QA si ferma per un giorno).
E sì - non scusarti. Parla con il tuo manager e fagli 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 di un edificio è un grosso problema, significa che il tuo processo è rotto.
Dovresti creare build continui, non build notturni.
È meglio una risposta tardiva che mai ...
Come molti altri hanno già detto, non chiedere scusa per aver rotto la build. Ammetti semplicemente che sei stato 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 di ciò. 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 danno un momento difficile è semplicemente evitare di essere sulla difensiva, disinnescare la situazione facendo sapere alla gente che sei o al problema o sei pronto a chiedere consiglio se trovi che sei bloccato.
Personalmente, vedo una build rotta come un'opportunità.
Quindi quello che sto dicendo è che rompere la costruzione di tanto in tanto significa che le persone stanno facendo il loro lavoro. Certo, potresti aver commesso un errore, ma se lo usi come un'opportunità per imparare, stai facendo il tuo lavoro semplicemente imparando a farlo meglio la prossima volta.
Dì loro che hanno bisogno di build CI per ogni check-in. In questo modo non dovrai aspettare la notte per sapere che è rotto. SÌ!!! Dì loro che è il processo che è sbagliato, nient'altro. Hai appena identificato una lacuna nel loro sistema .
Ma sì, assicurati di risolverlo. Non un grande affare. Non è in produzione. Solo una notte senza valore.
Una pratica abituale nella mia azienda è:
La mia azienda ha anche un buon modo di gestire un simile "incidente":
Non mi scuso.
Incolperei la lead CI per avermi permesso di commettere build fallite.
Dovrebbe esserci un processo CI in atto per impedire agli sviluppatori di commettere codice non funzionante.
Se la build locale fallisce, allora non dovrebbe essere permesso di entrare nel build server.
Anche se penso che possa essere in atto 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 su un progetto open source,
Dì solo "Scusa, ho rotto la build." Forse ero troppo assonnato! "
e aggiungilo come commento github.
È perché molti sviluppatori open source scrivono codice durante la mezzanotte.
Leggi altre domande sui tag builds continuous-integration release