Comment s'excuser lorsque vous avez rompu la construction nocturne
Mon premier engagement dans mon projet a entraîné la rupture de la construction nocturne et les gens sont partout autour de moi alors que nous approchons de la sortie. Je veux envoyer un e-mail d'excuses qui devrait sembler sincère et en même temps laisser entendre que c'était mon premier commit et que cela ne se répéterait plus.
Étant un anglophone non natif, j'ai du mal à trouver des mots corrects. Puis-je avoir une aide s'il vous plait?
Ne vous excusez pas !
- Briser la construction une fois dans une lune bleue n'est pas un gros problème et ne devrait jamais être un spectacle.
- C'est la faute de votre manager pour ne pas avoir configuré de builds automatisés continus.
De plus, je parie que votre équipe échoue au 'Joel Test' et ne peut pas faire de build en une seule étape.
Si c'est le cas, ce serait une autre chose pour laquelle vous ne devriez pas vous excuser. En effet, c'est un anti-pattern d'équipe.
Bagels. Donuts. Etc. Dans une entreprise pour laquelle j'ai travaillé dans le passé, la vérification du code cassé ou toute autre perturbation causée par un collègue est généralement résolue par l'introduction de denrées alimentaires d'excuses le lendemain.
Un jour, un type a fait exploser une base de données de production, provoquant une panique massive et une nuit tardive pour toute l'équipe. Le lendemain, il a grillé des hamburgers pour le déjeuner.
J'adore les excuses de mes collègues. Des excuses savoureuses et savoureuses.
Deux citations pour vous:
L'homme qui ne fait aucune erreur ne fait généralement rien .-- William Connor Magee
Quiconque ne commet pas d'erreurs n'essaie pas assez fort .-- Wess Roberts
Je suis d'accord avec Jim G. , ne vous excusez pas mais apprenez-en et ne faites plus la même erreur ... gardez-le DRY;)
Ne vous excusez pas, réparez-le dès que possible. C'est bien, cependant, tout le monde brise la construction au moins une fois, dans ma dernière entreprise, c'était quelque chose d'un rituel d'initiation. Lorsqu'un membre de l'équipe cassait la construction, nous mettions un canard en caoutchouc sur son bureau le matin avant son arrivée, cela lui faisait savoir qu'il avait rompu la construction et qu'il le réparerait.
Nous l'avons appelé le canard d'intégration continue et quand vous l'avez eu pour la journée, les gens vous taquinaient, mais tout était amusant, rien n'était censé être méchant.
Nous avons pris quelque chose comme une construction cassée et l'avons transformée en un exercice de consolidation d'équipe.
"Désolé mon mauvais!" est la façon dont je m'excuse habituellement quand j'ai cassé la version. Ça arrive. Mais comme d'autres l'ont dit, c'est une opportunité d'améliorer vos systèmes afin qu'une personne ne puisse pas facilement casser la construction pour tout le monde.
Je ne ferais pas d'excuses formelles dans ces circonstances, mais si vous pensez réellement que des excuses plus formelles sont appropriées, alors vos excuses devraient faire ces choses:
- Exprimer un regret.
- Indiquer le problème.
- Prendre la responsabilité.
- Faire amende honorable.
- Sauver la face.
C'est-à-dire, "Je suis désolé [REGRET EXPRESS] que je vous ai dérangé [PRENEZ LA RESPONSABILITÉ] en accidentellement [SAUVEGARDER LE VISAGE] en cassant la construction [DÉCLAREZ LE PROBLÈME]. Les beignets sont sur moi demain. [FAITES DES MODIFICATIONS]"
Chaque partie est nécessaire dans des excuses appropriées; si vous n'énoncez pas le problème, il n'est pas clair. Si vous n'exprimez pas de regrets, n'assumez pas de responsabilité et ne faites pas amende honorable, les gens ont l'impression que vous n'êtes pas sincère. La partie qui sauve la face est la partie la plus négligée des excuses; la partie qui sauve la face est ce qui rappelle à la partie blessée que vous êtes un précieux collègue qui fait parfois des erreurs, et non un idiot (ou un saboteur!)
Enfin, quelques réflexions sur la rupture de build:
Je travaille sur l'équipe du compilateur C #/Visual Basic. Bien sûr, Visual Studio est aujourd'hui un projet tellement gigantesque qu'il a sa propre équipe pour gérer les infrastructures de construction et une immense salle avec son propre système de climatisation dédié. Au milieu des années 1990, lorsque j'ai commencé en tant que stagiaire, l'équipe de création de Visual Basic était un stagiaire - moi - et un placard rempli de machines. Les temps ont changé!
À cette époque, avant l'intégration continue et les processus d'enregistrement solides, les équipes subissaient diverses sanctions en cas de rupture de la version. Dans certaines équipes, la pénalité était que si vous cassiez la construction, vous deviez porter un chapeau drôle tous les jours au travail jusqu'à ce que quelqu'un d'autre casse la construction. Dans certaines équipes, si vous portiez ce chapeau, vous étiez responsable de vérifier que la construction nocturne était correcte.
Ce dernier morceau semble peut-être cruel, mais il a en fait servi à un but précieux. Étant donné que presque tout le monde a interrompu la version à un moment ou à un autre, toute l'équipe apprendrait finalement les processus de vérification de la version nocturne.
Ne vous excusez pas. Ce sont vos collègues qui sont à blâmer pour ne pas avoir examiné votre premier commit et ne pas avoir de système de retour rapide pour les builds comme un serveur d'intégration continue.
Dans mon travail actuel, nous avons une règle informelle selon laquelle quelqu'un qui s'engage sournoisement juste avant de quitter le travail et s'avère briser la construction doit apporter des bonbons/gâteaux/boissons pour toute l'équipe le lendemain. Mais nous avons une intégration continue qui nous avertit d'une construction cassée pendant la journée. Et la règle ne s'appliquerait probablement pas au premier commit de quelqu'un.
Quoi qu'il en soit, un courrier officiel d'excuses est probablement un peu trop.
Une règle fondamentale - quand vous vous trompez, ADMETTEZ-LE: - | Vous n'avez pas à vous excuser. Tout le monde fait des erreurs. Les pros l'admettent. C'est du travail d'équipe. Les autres membres de l'équipe devraient se ressaisir pour vous aider. S'ils ne le font pas, DEMANDEZ de l'aide. Le plus à dire ensuite est: que pouvons-nous en tirer?
Ils disent qu'un mariage réussi est basé sur trois petits mots - "j'avais tort".
Si quelqu'un ne fait pas une erreur occasionnelle, il ne travaille pas, mais une erreur dont on n'apprend pas est deux erreurs.
Les meilleures excuses sont de réparer rapidement la pause
Si votre entreprise a déjà un moyen de tester vos modifications de build, alors (A) vos modifications ont échoué (mais vous les avez quand même enregistrées) ou (B) elles ont réussi (et vous devez créer un nouveau scénario de test).
Si vos collègues testent avec précaution leurs modifications et s'attendent à trouver des pauses dans la version nocturne, alors (C) vous avez un processus fragile (et vous devez introduire des tests comme ceux trouvés dans Extreme Programming).
Il est possible que (D) vos modifications aient provoqué des changements imprévus dans le code de Bill qui étaient en place auparavant ou modifiés sur la même version que la vôtre.
Selon la façon dont vous et votre entreprise testez, je m'excuserais au cas par cas:
- (A) J'ai échoué au test de construction, mais j'ai vérifié mes modifications. Désolé, je modifie mon processus donc je ne le referai plus.
- (B) J'ai réussi le test de build et ajouté le test JUnit XYZtest.Java pour réduire les risques de réapparition.
- (C) Puisque nous n'avons pas de processus de test de build, j'en crée un pour mes modifications. J'aimerais partager avec vous comment nous pouvons améliorer notre processus de construction.
- (D) Je travaillerai avec Bill pour écrire un test JUnit XYZtest.Java afin de réduire les risques de réapparition.
Je suis sûr qu'il y a un (E) auquel je n'ai pas pensé.
Notez que je dis "pour réduire les risques de réapparition" plutôt que "afin que cela ne se reproduise plus". Cela se reproduira. Mais vous pouvez améliorer votre processus pour réduire cette possibilité. C'est, je pense, l'une des marques d'un programmeur gagnant.
Hum. Vous obtenez le jeton de construction cassé . Passez la rage au prochain heureux bénéficiaire. Arrive tout le temps. La qualité est importante, mais les erreurs sont inévitables. Répare les. Passez. Honte au prochain pauvre gars.
Ne vous excusez pas. Vous êtes humain et vous ferez des erreurs. Tout le monde cassera la construction de temps en temps, la clé est de simplement la réparer rapidement.
Quant aux gens qui vous sautent dessus ... eh bien je suis curieux de savoir s'ils ont déjà écrit dans un bug.
La façon d'aborder cela dépend de l'atmosphère de votre groupe. Si c'est une culture de blâme, je serais très attentif aux excuses et à la façon dont vous le faites. Si c'est une atmosphère collaborative et positive, alors oui, quelque chose du genre "J'ai foiré, je suis désolé. Comment pouvons-nous éviter cela à l'avenir?" est probablement une bonne idée.
Dans tous les cas, une gaffe comme celle-ci devrait être accompagnée d'une sorte de post-mortem pour a) découvrir comment cela s'est produit et b) comment minimiser les chances que cela se reproduise.
Je ne connais pas votre structure (je travaille dans un environnement très différent) mais finalement, la réalité est qu'occasionnellement, les gens font des erreurs et les choses se cassent. Vous apprenez de l'expérience et passez à autre chose.
Dans mon environnement, si vous cassiez la construction, vous obtiendriez une bonne nervure et un cométaire plein d'esprit. Je ne sais pas dans quel pays anglophone vous vous trouvez, mais il se pourrait qu'en tant que non anglophone, vous n'obteniez pas le caractère soulignant des commentaires.
Étant de l'autre côté en tant que développeur senior, j'ai une fois commenté une révision du code selon laquelle une façon de faire x "aspirait" non pas parce que le code était mauvais, mais pour la structure du projet. C'était plus un commentaire pour moi que je dois résoudre le problème structurel. Ce n'est que plus tard que j'ai découvert que le Jr Dev bien que j'étais très en colère contre lui en raison de mon discours imprécis et désinvolte.
En règle générale, je dirais:
Si votre archivage provoque une erreur de compilation, vous vous seriez surpris si vous aviez fait un "get latest" avant l'enregistrement, un simple "whoops, my bad" est de mise. (surtout si vous vous promenez à 10 heures le lendemain matin, pendant que tout le monde décide à quel changement changer pour revenir)
Si votre enregistrement provoque un comportement général inattendu, même des erreurs d'exécution, je ne pense pas qu'il devrait être retenu contre vous. Cela vient avec le territoire. Tant que les "dernières informations" de tout le monde passent généralement devant leurs compilateurs, les gens ne devraient vraiment pas jeter un ajustement (à quelques exceptions près comme la suppression d'une base de données, la suppression de la copie serveur du projet et tous les ensembles de modifications) , ou toute autre chose si stupide que les gens doivent assumer une intention malveillante).
L'ÉQUIPE a échoué.
Votre entreprise a besoin de plus de révision de code sur un développeur effectuant une première construction.
Je ne vois tout simplement pas comment une équipe permet que cela se poursuive sans qu'elle fasse un examen et offre des garanties en cours de route que vous faites les choses correctement.
Être proche de l'heure de sortie n'est pas une excuse, mais une meilleure raison de revérifier le nouveau code.
Si votre version ne peut pas être facilement annulée, il y a des problèmes encore plus importants avec ce groupe.
Mieux vaut une réponse tardive que jamais ...
Comme beaucoup d'autres l'ont dit, ne vous excusez pas d'avoir cassé la version. Admettez simplement que c'était vous et continuez votre travail. Ce genre de choses se produirait que vous soyez là ou non, et personne ne mérite d'être mal traité à cause de cela. Les gens réagissent mal sous pression, donc si vous êtes capable de rester calme et de simplement continuer votre travail, vous vous démarquerez quand cela sera important. Mon conseil lorsque les gens vous donnent du fil à retordre est simplement d'éviter d'être sur la défensive, de désamorcer la situation en faisant savoir aux gens que vous êtes sur le problème ou que vous êtes prompt à demander conseil si vous constatez que vous êtes coincé.
Personnellement, je vois une construction cassée comme une opportunité.
- Si la construction se brise et que vous pouvez prouver que c'est votre faute, cela montrera probablement que les processus d'intégration et de construction continus font leur travail. C'est une bonne chose, car cela valide vos processus. Si la version ne se casse jamais, je craindrais qu'il y ait quelque chose qui cloche.
- Si vous avez cassé la construction d'une manière assez courante, et que cela se produit souvent de cette manière, alors peut-être qu'il manque quelque chose dans le processus CI. C'est l'occasion d'améliorer vos processus afin de mieux gérer les scénarios de défaillance courants.
- Si vous êtes allé au-delà de l'appel du devoir et que vous avez vraiment gâché la construction avec un problème obscur, vous avez l'occasion d'apprendre quelque chose de nouveau qui pourrait être suffisamment important pour déclencher un avertissement pour le reste de l'équipe.
Donc, ce que je dis, c'est que casser la construction signifie parfois que les gens font leur travail. Bien sûr, vous avez peut-être fait une erreur, mais si vous l'utilisez pour apprendre, vous faites votre travail simplement en apprenant à mieux le faire la prochaine fois.
Je ne comprends pas pourquoi les gens sont partout sur toi. Si le système est bien configuré, ils devraient être en mesure de mettre en évidence vos modifications/de les corriger très rapidement.
Mais encore une fois, si vous êtes un de ces gars qui ont cassé la construction de Windows, alors ... je ne peux pas aider. (Il est incroyablement difficile de le faire - avant que quiconque ne remette en question la philosophie de MS, mais de temps en temps, quelqu'un le fasse - et le contrôle qualité de toute l'entreprise s'arrête pendant une journée).
Et oui - ne vous excusez pas. Discutez simplement avec votre responsable et faites-lui comprendre que vous avez appris de ce que vous avez fait.
Les constructions se cassent tout le temps. Les bugs et les erreurs sont une réalité, et c'est pourquoi vous devriez avoir un processus qui minimise les effets des bugs et des erreurs.
Si une rupture de build est si importante, cela signifie que votre processus est cassé.
Vous devriez faire des builds continus, pas des builds nocturnes.