ナイトリービルドを壊したときに謝罪する方法
プロジェクトでの最初のコミットの結果、毎晩のビルドが壊れてしまい、リリースが近づいているため、人々は私を覆っています。誠実に聞こえると同時に、これが私の最初のコミットであり、これ以上繰り返されないことを示唆する謝罪メールを送信したいと思います。
英語を母国語としないため、正しい単語を思いつくのに苦労しています。誰か助けてくれますか？
しないでください謝罪！
- ブルームーンでビルドを一度壊すことは大したことではなく、決してショーストッパーであってはなりません。
- 継続的で自動化されたビルドを構成しないのは、マネージャーの責任です。
また、あなたのチームは 'Joel Test' に失敗し、1つのステップでビルドを作成できないと思います。
もしそうなら、これはあなたが謝罪してはならないもう一つのことでしょう。確かに、それはチームのアンチパターンです。
ベーグル。ドーナツ。など以前私が働いていたある会社で、壊れたコードをチェックインしたり、同僚の混乱を引き起こしたりすることは、一般的に翌日謝罪の食品を持ち込むことで解決されます。
ある日、本番データベースを吹き飛ばした男がいて、チーム全体に大パニックと深夜を引き起こしました。翌日、彼は昼食のためにハンバーガーを焼きました。
私は同僚の謝罪が大好きです。おいしい、おいしい謝罪。
あなたのための2つの引用：
間違いをしない人は通常何もしません。--ウィリアム・コナー・マギー
間違いを犯さない人は、十分に頑張っていません。--Wess Roberts
私は Jim G。 に同意します。謝罪しないでください。ただし、それから学び、同じ間違いを繰り返さないようにしてください...保持してくださいDRY;）
謝罪せず、できるだけ早く修正してください。それは大丈夫ですが、誰でも少なくとも1回はビルドを中断します。私の最後の会社では、それは開始の儀式のようなものでした。チームメンバーがビルドを壊したとき、私たちは彼が来る前の朝に彼の机にゴム製のアヒルを置きました。これは彼がビルドを壊し、彼がそれを修正することを彼に知らせました。
私たちはそれを継続的統合ダッキーと呼びました。人々があなたをからかう日のためにそれを持っているとき、それはすべて面白かったので、どれもが意地悪であるはずではありませんでした。
私たちは壊れたビルドのようなものを取り、それをチームビルディングの演習に変えました。
「ごめんなさい！私の悪い！」ビルドを壊したときに私がいつもお詫びする方法です。それが起こります。しかし、他の人が言ったように、これはあなたのシステムを改善する機会であり、一人が他の人のために簡単にビルドを壊すことができないようにします。
私はこれらの状況では正式な謝罪をしませんが、より正式な謝罪が適切であると実際に感じる場合、あなたの謝罪はこれらのことをするべきです：
- 明白な後悔。
- 問題を述べる。
- 責任を取る。
- 補正を行います。
- 面目を保ちます。
つまり、「ご不便をおかけして申し訳ございません。[TAKE THE RESPONSIBILITY]誤って[SAVE FACE]ビルドを壊してしまいました[STATE THE PROBLEM]。ドーナツは明日私にあります。[MAKE AMENDS]」
各部分は適切な謝罪で必要です。あなたが問題を述べなければ、それは不明確です。あなたが後悔を表明せず、責任を負い、そして償いをしなければ、人々はあなたが不誠実であるように感じます。フェイスセービング部分は、謝罪の中で最も見落とされがちな部分です。顔を救う部分は、あなたが時々間違いを犯す貴重な同僚であり、ばかではない（または妨害者である）ことを負傷したパーティーに思い出させるものです。
最後に、ビルドブレイクに関するいくつかの考え：
私はC＃/ Visual Basicコンパイラチームで働いています。もちろん今日、Visual Studioは非常に大規模なプロジェクトになり、ビルドインフラストラクチャを管理するためだけの独自のチームと、専用の空調システムを備えた巨大な部屋を備えています。 1990年代中頃、私がインターンとして始めたとき、Visual Basicのビルドチームは1人のインターン（私）であり、クローゼットでいっぱいのマシンでした。時が変わった！
継続的な統合と強力なチェックインプロセスの前の時代には、チームはビルドを壊すことに対してさまざまなペナルティを課していました。一部のチームでは、ビルドを壊した場合、誰かがビルドを壊すまで、職場で毎日変な帽子をかぶらなければならなかったというペナルティがありました。一部のチームでは、その帽子をかぶっていた場合、ナイトリービルドが正しいことを確認する責任がありました。
その最後の部分はおそらく残酷に聞こえるかもしれませんが、それは実際に貴重な目的を果たしました。ほとんど誰もが一度にビルドを壊したので、結局、チーム全体が毎晩のビルドを検証するプロセスを学びます。
謝らないでください。最初のコミットを確認せず、継続的インテグレーションサーバーのようなビルド用の迅速なフィードバックシステムがないことを非難するのは、同僚です。
私の現在の仕事では、仕事を辞める直前にこっそりとコミットし、ビルドを壊すことが判明した人は、翌日、チーム全体にキャンディー/ケーキ/ドリンクを持ってくる必要があるという非公式のルールがあります。しかし、日中はビルドが壊れていることを警告する継続的な統合があります。そしてこのルールはおそらく誰かの最初のコミットには適用されないでしょう。
とにかく、謝罪の正式なメールは、おそらく少なすぎます。
基本的なルール-あなたが間違っている場合、それを認める：-|謝罪する必要はありません。誰でも間違いはある。プロはそれを認めます。それがチームワークです。他のチームメンバーは、それを解決するために力を合わせるべきです。そうでない場合は、助けを求めます。後で言わなければならない最も多くは-それから何を学ぶことができますか？
彼らは、結婚の成功は「私は間違っていた」という3つの小さな言葉に基づいていると言います。
誰かが時々過ちを犯さなければ、彼らは働いていませんが、そこから学べない過ちは2つの過ちです。
最善の謝罪は、迅速に休憩を修正することです
あなたの会社がすでにビルドの変更をテストする方法を持っている場合、（A）変更は失敗しました（しかし、とにかく変更をチェックしました）または（B）変更は成功しました（そして新しいテストケースを作成する必要があります）。
同僚が熱心に変更をテストし、ナイトリービルドの中断を見つけることを期待している場合、（C）脆弱なプロセスがあります（そして、Extreme Programmingにあるようなテストを導入する必要があります）。
（D）あなたの変更がBillのコードに予期せぬ変更を引き起こした可能性があります。それは以前に配置されていたか、あなたと同じビルドで変更されていました。
あなたとあなたの会社がどのようにテストするかに応じて、ケースバイケースでお詫びします：
- （A）ビルドテストに失敗しましたが、変更をチェックインしました。申し訳ありませんが、プロセスを変更しているため、今後は変更しません。
- （B）ビルドテストに合格し、JUnitテストXYZtest.Javaを追加して、再発の可能性を減らしました。
- （C）ビルドテストプロセスがないため、変更用に作成しています。構築プロセスをどのように改善できるかをお話ししたいと思います。
- （D）ビルと協力して、再発の可能性を減らすためにJUnitテストXYZtest.Javaを作成します。
思いもしなかった（E）があると確信しています。
私が「再発しないように」ではなく、「再発の可能性を減らすため」と言っていることに注意してください。それは再び起こります。しかし、その可能性を減らすためにプロセスを改善することができます。それは、優秀なプログラマーの特徴の1つだと思います。
ええと。 壊れたビルドトークン を取得します。狂犬病を次の幸運な受取人に渡します。いつも起こります。品質は重要ですが、間違いは避けられません。それらを修正します。進め。次の貧しい人が恥をかく。
謝らないでください。あなたは人間であり、間違いを犯します。誰もがビルドをときどき壊してしまいます。重要なのは、それをすばやく修正することです。
飛び跳ねる人々については……まあ、彼らがバグを書いたことがあるかどうか知りたいです。
これへの取り組み方は、グループの雰囲気によって異なります。それが非難の文化であるなら、私はvery謝罪とあなたがそれをどのように行うかについて注意するでしょう。協力的でポジティブな雰囲気の場合は、そうです。「めちゃくちゃ、ごめんなさい。将来、どうすればこれを避けることができますか？」おそらく良い考えです。
いずれにせよ、このようなグーフアップは、a）どうやってそれが起こったのかを調べ、b）それが再び起こる可能性を最小限に抑える方法のために、ある種の死後を伴うべきです。
私はあなたの構造に精通していません（私は非常に異なる環境で働いています）が、結局のところ、現実は、時々、人が過ちを犯し、物事が壊れるというものです。あなたはその経験から学び、次に進みます。
私の環境では、ビルドを壊した場合、良い性質のリブといくつかの機知に富んだ彗星が得られます。どの英語圏の国にいるのかはわかりませんが、英語を母国語としないユーザーは、コメントに下線を引いていない可能性があります。
シニア開発者として反対側から来たとき、私はかつてコードレビューにコメントしました。xを実行するいくつかの方法は、コードが悪いからではなく、プロジェクトの構造に影響を与えたからです。構造的な問題を修正する必要があるのは、私自身へのより多くの解説でした。後になって初めて、私は不機嫌なスピーチのために彼に非常に腹を立てていましたが、Jr Devを発見しました。
一般的なルールとして、私はこう言います：
チェックインによってコンパイラエラーが発生する場合は、チェックインする前に「最新の情報を取得」しておけば、簡単な「おっと、私の悪い」の順序で実行できます。 （特に、翌朝10時に散歩しているときに、誰がどのチェンジセットにロールバックするかを決定している場合）
チェックインが予期しない一般的な動作、さらにはランタイムエラーを引き起こす場合、私はそれがあなたに対して保持されるべきではないと思います。領土が付属しています。 全員の「最新を取得」が一般にコンパイラに合格している限り、人々は本当に適合をスローするべきではありません（データベースの削除、プロジェクトのサーバーコピーとすべての変更セットの削除など、いくつかの例外があります） 、または他の人が悪意のある意図を想定しなければならないほど愚かであるもの）。
チームが失敗しました。
あなたの会社は、最初のビルドを行う開発者に対して、より多くのコードレビューを必要としています。
私は、チームがレビューを行わず、あなたが物事を正しく行っている方法に沿っていくつかの保証を提供することなく、これがどのように進むのを許可するのかを見ていません。
リリース時間に近いことは言い訳にはなりませんが、新しいコードを再確認するより良い理由です。
リリースを簡単に元に戻すことができない場合、このグループにはさらに大きな問題があります。
遅刻しないほうがいいです...
他の多くの人が言ったように、ビルドが壊れたことを謝罪しないでください。それがあなただったことを認めて、仕事を続けてください。このことはあなたがそこにいてもいなくても起こり、誰もがそのために虐待されるに値するものではありません。人々はプレッシャーの下でひどく反応するので、落ち着いて仕事を続けることができれば、重要なときに目立ちます。人々があなたに苦労しているときの私のアドバイスは、防御的であることを単に避け、あなたが問題に直面していること、またはあなたが行き詰まった場合はすぐに助言を求めることのいずれかを人々に知らせることで状況を緩和することです。
個人的には、壊れたビルドを機会と考えています。
- ビルドが壊れて、それが自分のせいだと証明できる場合は、継続的な統合とビルドプロセスが機能していることを示している可能性があります。プロセスを検証するので、これは良いことです。ビルドが壊れない場合は、何か問題があるのではないかと心配になります。
- かなり一般的な方法でビルドを中断し、この方法で頻繁に中断する場合、CIプロセスに何かが欠けている可能性があります。これは、一般的な障害シナリオをより適切に管理できるようにプロセスを改善する機会です。
- コールオブデューティを超えて、不明瞭な問題でビルドをめちゃくちゃにした場合は、チームの他のメンバーに警告をトリガーするのに十分重要である可能性がある新しい何かについて学ぶ機会があります。
だから私が言っていることは、ビルドを壊すことは時々人々が仕事をしていることを意味するということです。間違いはあるかもしれませんが、それを学習の機会として使用する場合、次回はそれをよりよくすることを学ぶだけで仕事をしていることになります。
なぜ人々があなたの中にいるのか、私にはわかりません。システムが適切に設定されている場合、彼らはあなたの変更を取り除き、非常に素早く修正できるはずです。
しかし、繰り返しになりますが、もしあなたがウィンドウビルドを壊した人の一人なら、それでは...私は手伝うことができません。 （それを行うのは信じられないほど難しいです-MSが哲学を構築するのを誰かが質問する前に、時々誰かがそれを行います-そして会社全体のQAは1日停止します）。
そしてええ-謝罪しないでください。マネージャーとチャットして、マネージャーから学んだことを理解させてください。
ビルドは常に壊れます。バグとミスは日常茶飯事であり、そのため、バグとミスの影響を最小限に抑えるプロセスが必要です。
ビルドの破壊が大きな問題である場合、それはプロセスが破壊されていることを意味します。
毎晩のビルドではなく、継続的なビルドを行う必要があります。