Comment faire des excuses quand vous avez cassé la construction nocturne [fermé]

Mon premier engagement dans mon projet a abouti à la destruction de la construction nocturne et les gens sont partout sur moi alors que nous approchons de la sortie. Je veux envoyer un courriel d'excuses qui devrait sembler sincère et indiquer en même temps qu'il s'agissait de mon premier engagement et que cela ne se reproduirait plus.

Étant non anglophone, j'ai du mal à trouver les mots corrects. Puis-je avoir une aide s'il vous plait?

Ne t'excuse pas !

• Briser la construction une fois dans une lune bleue n’est pas une grosse affaire et ne devrait jamais être un spectacle.
• C'est la faute de votre responsable pour ne pas configurer des builds automatisés et continus.

De plus, je parie que votre équipe échoue au test de Joel et ne peut pas construire en une étape.

Si tel 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é par le passé, la vérification du code erroné ou la perturbation des collègues est généralement résolue par l’apport de produits alimentaires excuses le lendemain.

Un jour, un gars a explosé dans une base de données de production, provoquant une panique massive et une soirée tardive pour l’ensemble de l’équipe. Le lendemain, il a grillé des hamburgers pour le déjeuner.

J'adore les excuses de mes collègues. Savoureux, savoureux excuses.

Deux citations pour vous:

L'homme qui ne fait pas d'erreur ne fait généralement rien .-- William Connor Magee

Celui qui ne fait pas d'erreur ne fait pas assez d'efforts .-- 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 au sec;)

Ne vous excusez pas, corrigez-le le plus rapidement possible. Tout va bien, tout le monde casse la construction au moins une fois. Dans ma dernière entreprise, c’était un rituel d’initiation. Lorsqu'un membre de l'équipe cassait le gabarit, nous mettions un duck en caoutchouc sur son bureau le matin avant son arrivée. Cela lui a permis de savoir qu'il avait brisé le gabarit et qu'il le réparerait.

Nous l'appelions le Duckie d'Intégration Continue et quand vous l'aviez pour la journée, les gens vous taquineraient, mais c'était amusant, rien de tout cela n'était censé être mesquin.

Nous avons pris quelque chose comme une construction brisée et l'avons transformé en exercice de renforcement d'équipe.

"Désolé mon mauvais!" C'est comme ça que je m'excuse habituellement quand j'ai cassé la construction. Ça arrive. Mais comme d’autres l’ont dit, c’est une occasion d’améliorer vos systèmes afin qu’une personne ne puisse pas casser aussi facilement la construction pour les autres.

Je ne ferais pas d'excuses officielles dans ces circonstances, mais si vous estimez réellement que des excuses plus formelles sont appropriées, alors vos excuses devraient faire ce qui suit:

• Exprimer un regret.
• Indiquer le problème.
• Prendre la responsabilité.
• Faire amende honorable.
• Sauver la face.

C’est-à-dire: "Je suis désolé [EXPRESS REGRET] de vous avoir dérangé [PRENEZ RESPONSABILITÉ] en cassant accidentellement [SAVE FACE]."

Chaque partie est nécessaire dans des excuses appropriées; si vous ne déclarez pas le problème, il n'est pas clair. Si vous n'exprimez pas de regrets, prenez des responsabilités et ne corrigez rien, les gens se sentiront comme si vous n'étiez pas sincères. La partie qui sauve la face est la partie la plus négligée des excuses; la partie qui sauve des visages est ce qui rappelle à la partie lésée que vous êtes un collègue précieux qui fait parfois des erreurs et non un idiot (ou un saboteur!)

Enfin, quelques réflexions sur la rupture de construction:

Je travaille sur l’équipe du compilateur C # / Visual Basic. Bien entendu, Visual Studio est aujourd'hui un projet tellement gigantesque qu'il dispose d'une équipe propre pour gérer l'infrastructure de construction et d'une vaste salle avec son propre système de climatisation dédié. Au milieu des années 90, lorsque j'ai commencé à travailler comme stagiaire, l'équipe de compilation de Visual Basic était composée d'un stagiaire - moi - et d'un placard rempli de machines. Les temps ont changé!

À une époque antérieure à l'intégration continue et à la mise en place de processus d'enregistrement robustes, les équipes se voyaient infliger diverses pénalités pour avoir rompu le build. Sur certaines équipes, la pénalité était que, si on cassait la carrure, il fallait porter un drôle de chapeau tous les jours au travail jusqu'à ce que quelqu'un d'autre casse la carrure. Sur certaines équipes, si vous portiez ce chapeau, il vous incombait de vérifier que la construction de nuit était correcte.

Ce dernier geste semble peut-être cruel, mais il a en fait servi un objectif précieux. Étant donné que presque tout le monde a cassé la construction à un moment ou à un autre, toute l'équipe devait éventuellement apprendre les processus de vérification de la construction nocturne.

Ne t'excuse pas. Ce sont vos collègues qui sont à blâmer pour ne pas avoir examiné votre premier commit et ne pas avoir un système de retour rapide pour les builds comme un serveur d’intégration continue.

Dans mon poste actuel, nous appliquons une règle informelle voulant que quelqu'un qui s'engage sournoisement juste avant de quitter son travail et finisse par casser le modèle doit apporter des bonbons / des gâteaux / des boissons à toute l'équipe le lendemain. Mais nous avons une intégration continue qui nous prévient d'une construction brisé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, ADMET IT: - | Vous n'êtes pas obligé de 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 s’unir pour vous aider. S'ils ne le font pas, DEMANDEZ de l'aide. Ce qu’il faut en dire au plus, c’est: que pouvons-nous en apprendre?

Ils disent qu'un mariage réussi repose sur trois petits mots: "j'avais tort".

Si quelqu'un ne commet pas une erreur occasionnelle, il ne travaille pas, mais une erreur dont on ne tire pas les leçons est deux erreurs.

La meilleure excuse est de réparer la pause rapidement

Si votre société dispose déjà d'un moyen de tester vos modifications de génération, alors (A) vos modifications ont échoué (mais vous les avez archivées quand même) 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 failles dans la construction nocturne, alors (C) vous avez un processus fragile (et vous devez introduire des tests comme ceux de la programmation extrême).

Il est possible que (D) vos modifications aient provoqué des modifications imprévues dans le code de Bill qui étaient déjà en place ou ont été modifiées sur le même build que le vôtre.

En fonction de la manière dont vous et votre entreprise testez, je m'excuserais au cas par cas:

• (A) J'ai échoué au test de construction, mais j'ai archivé mes modifications. Désolé, je suis en train de changer mon processus afin que je ne recommence plus.
• (B) J'ai réussi le test de construction et ajouté le test JUnit XYZtest.java pour réduire les risques de récurrence.
• (C) Comme nous n'avons pas de processus de test de construction, j'en crée un pour mes modifications. Je voudrais partager avec vous comment nous pouvons améliorer notre processus de construction.
• (D) Je vais travailler avec Bill pour écrire un test JUNit XYZtest.java afin de réduire les risques de récurrence.

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écurrence" plutôt que "pour que cela ne se reproduise plus". Cela se reproduira. Mais vous pouvez améliorer votre processus pour réduire cette possibilité. Je pense que c'est l'une des marques d'un programmeur gagnant.

Ne t'excuse pas. Vous êtes humain et vous allez faire des erreurs. Tout le monde va casser la construction de temps en temps, la clé est de le réparer rapidement.

En ce qui concerne les gens qui sautent partout sur vous ... eh bien, je suis curieux de savoir s’ils ont déjà écrit dans un bogue.

Cela dépend de l’atmosphère de votre groupe. Si c'est une culture du blâme, je ferais très attention à vous excuser et à la façon dont vous le faites. Si c'est une atmosphère de collaboration positive, alors oui, quelque chose du genre "je me suis trompé, je suis désolé. Comment pouvons-nous éviter cela à l'avenir?" C'est probablement une bonne idée.

Dans tous les cas, une telle situation devrait être accompagnée d'une sorte d'autopsie pour a) découvrir comment cela s'est passé et b) comment minimiser les risques que cela se reproduise.

Je ne connais pas bien votre structure (je travaille dans un environnement très différent), mais au final, la réalité est que parfois, les gens font des erreurs et que des choses se cassent. Vous apprenez de l'expérience et continuez.

Dans mon environnement, si vous cassez la construction, vous obtiendrez une bonne nervure et un cométaire plein d’esprit. Je ne suis pas sûr du pays anglophone dans lequel vous vous trouvez, mais il se peut que vous n'obteniez pas la nature soulignée des commentaires en tant que non anglophone.

Étant de l'autre côté en tant que développeur senior, j'ai un jour commenté sur une révision de code qu'une manière de faire x "sucait" pas parce que le code était mauvais mais plutôt à la structure du projet. C’était plus un commentaire pour moi-même que je devais résoudre le problème structurel. Ce n’est que plus tard que j’ai découvert que Jr Dev était bien fâché contre lui à cause de mon discours inexact et désinvolte.

Hum Vous obtenez le jeton de construction cassé . Transmettez la rage au prochain destinataire chanceux. Arrive tout le temps. La qualité est importante, mais les erreurs sont inévitables. Répare les. Passez. Honte au prochain pauvre gars.

En règle générale, je dirais:

Si votre archivage provoque une erreur du compilateur, vous vous seriez attrapé si vous aviez fait une "obtention du dernier" avant l'enregistrement, un simple "whoops, my bad" est dans l'ordre. (surtout si vous vous promenez le lendemain matin à 10 heures, pendant que tout le monde décide du changement de groupe vers lequel revenir)

Si votre archivage provoque un comportement inattendu général, même des erreurs d’exécution, je ne pense pas que cela devrait vous être reproché. Il vient avec le territoire. Tant que tous les utilisateurs reçoivent les informations les plus récentes, leurs compilateurs ne doivent pas être pris au dépourvu . bête que les gens doivent assumer une intention malveillante).

Le team a échoué.

Votre entreprise a besoin de plus de révision de code sur un développeur effectuant une construction initiale.

Je ne vois tout simplement pas comment une équipe permet que cela se poursuive sans qu'elle procède à un examen et offre certaines garanties en cours de route que vous agissez correctement.

Être près du temps de publication n'est pas une excuse, mais une meilleure raison de vérifier le nouveau code.

Si votre version ne peut pas être facilement annulée, il existe des problèmes encore plus graves avec ce groupe.

Je ne comprends pas pourquoi les gens sont partout sur vous. Si le système est bien configuré, il devrait pouvoir extraire vos modifications et les corriger très rapidement.

Mais encore une fois, si vous êtes un de ces gars qui ont cassé la construction de fenêtres, alors ... je ne peux pas vous aider. (C'est incroyablement difficile à faire - avant que quiconque ne s'interroge sur la philosophie de MS, mais de temps en temps, quelqu'un le fait - et le contrôle qualité de toute l'entreprise s'arrête un jour).

Et oui - ne t'excuse pas. Parlez simplement avec votre responsable et faites-lui comprendre que vous avez appris de ce que vous avez fait.

Construit la pause tout le temps. Les bugs et les erreurs sont une réalité de la vie, et c'est pourquoi vous devriez avoir un processus qui minimise les effets des bugs et des erreurs.

Si une rupture de construction est un si gros problème, cela signifie que votre processus est interrompu.

Vous devriez faire des constructions continues, pas des constructions nocturnes.

Mieux vaut une réponse tardive que jamais ...

Comme beaucoup d’autres l’ont dit, ne vous excusez pas pour cette erreur. Admettez simplement que c'était vous et continuez votre travail. Cela arriverait que vous soyez là ou pas, et personne ne mérite d’être mal traité à cause de cela. Les gens réagissent mal sous la pression. Par conséquent, si vous parvenez à rester calme et à vous consacrer au travail, vous vous démarquerez lorsque cela sera important. Mon conseil, lorsque les gens vous donnent du fil à retordre, est tout simplement d’éviter d’être sur la défensive, de désamorcer la situation en indiquant aux gens que vous êtes sur le point de résoudre le problème ou que vous cherchez rapidement conseil si vous vous trouvez coincé (e).

Personnellement, je vois une construction cassée comme une opportunité.

• Si la construction échoue et que vous pouvez prouver que c'est de votre faute, cela montrera probablement que les processus d'intégration continue et de construction font leur travail. C'est une bonne chose, car cela valide vos processus. Si la construction ne casse jamais, je crains que quelque chose ne va pas.
• Si vous avez cassé la construction de manière assez commune et que cela arrive souvent, il se peut que quelque chose manque dans le processus de CI. C'est l'occasion d'améliorer vos processus afin de mieux gérer les scénarios de défaillance courants.
• Si vous avez dépassé vos attentes et que vous avez vraiment gâché la construction avec un problème obscur, vous avez alors la possibilité d'apprendre quelque chose de nouveau qui pourrait être suffisamment important pour déclencher un avertissement au 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 commis une erreur, mais si vous l'utilisez comme une opportunité d'apprendre, vous faites votre travail simplement en apprenant à le faire mieux la prochaine fois.

Dites-leur qu'ils ont besoin de versions de CI par enregistrement. De cette façon, vous n’auriez pas à attendre la nuit pour savoir que c’est cassé. OUI!!! Dites-leur que c'est le processus qui ne va pas, rien d'autre. Vous venez d'identifier une lacune dans leur système.

Mais oui, assurez-vous de le réparer. Pas un gros problème. Ce n'est pas en production. Juste une nuit sans valeur.

Une pratique habituelle dans mon entreprise est:

• Crier "ce n'était pas moi!" (généralement, preuves CVS / SVN sinon)
• Vêtu d’un t-shirt portant la mention "my-userlogin ist Schuld!" (oui, 50% de notre développeur possède une telle chemise)
• Affirmer que cela fonctionne dans la sendbox locale et que tous les tests ont réussi

Mon entreprise a également un bon moyen de gérer un tel "incident":

• Le travailleur doit porter le costume suivant pendant une demi-journée ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• Je ne m'excuserais pas.

• Je voudrais blâmer le responsable de CI pour m'avoir permis de valider une construction brisée.

• Un processus de CI doit être mis en place pour empêcher les développeurs de valider du code erroné.

• Si la génération locale échoue, l'accès au serveur de génération ne doit pas être autorisé.

Bien que je pense que des excuses peuvent être en place, ne dites pas s'il vous plaît: "Je ferai en sorte que cela ne se reproduise plus." Parce que ça va. Et si cela se produit, il vous mordra.

Si vous travaillez sur un projet open source,

dites simplement "Désolé, je me suis cassé la construction. Peut-être que j'avais trop sommeil!"

et l'ajouter comme commentaire de github.

C'est parce que beaucoup de développeurs open source écrivent du code pendant minuit.