スタンドアップミーティング
私は私の整備士に行くかもしれません、そして私達は朝に少しスタンドアップミーティングをします：
ホイールを揃え、タイヤを回転させ、オイルを交換したいと彼に言います。「ちなみに、途中でブレーキが少し柔らかく感じました。ブレーキを見ていただけませんか？仕事に戻る必要があるので、どれくらい早く車を取り戻すことができますか？」
彼は私の車の下に頭を下げ、元に戻って、私のブレーキがオイルを漏らして故障し始めていると言います。彼は午前10時30分に到着する部品が必要になります。彼の男は昼食前に終わらないでしょう、しかし私は午後1時30分かそこらまでに私の車を取り戻すべきです。彼はしっかりと予約しているので、今日は他のことをすることができなくなります。私は別の予定を予約する必要があります。
私は彼が他のことをすることができるかどうか尋ねます、そして私はブレーキのために戻ってきます。事故の原因となる可能性があるため、ブレーキを固定せずに車を運転させることはできないとのことですが、別の整備士に行きたい場合は、けん引を依頼することができます。
車は昼食後すぐに完成するので、1時間早く車を取り戻すことができるように、彼の男性が遅い昼食を取ることができるかどうか尋ねます。
彼は、彼の部下が午前8時にやって来て、しばしば夕方まで働くと私に言います。彼らは彼らが得るすべての休憩を稼ぎます、そして彼の男は他のみんなと彼の昼食を取るに値します。
そのどれも私が聞きたかったものではありません。ホイール、タイヤ、オイルを片付けて、30分でそこから車で出て行くと聞きたかったのです。
私の整備士はまっすぐで私に正直でした。あなたはまっすぐであなたの経営陣に正直ですか？それとも、彼らが聞きたくないことを彼らに話すのを避けますか？
ユニットテスト
理解できないコード行には触れず、徹底的にテストしなかった新しいコード行をチェックインしませんでした。（少なくとも、意図的にではありません。）
あなたの質問は、文書化されていないコードの大規模なコーパスが、単体テストなしで過去のレビューを行ったことを意味しているようです。多分あなたはそれに参加しました、そして多分あなたはしませんでした。関係者全員が、管理を含め、その責任を受け入れる必要があります。とにかく、行われたことは行われます。戻って変更することはできません。
しかし、今のところ、そもそも問題の原因となった行動をやめるのは、みんなの責任です。あなたは、理解するのが難しく、単体テストがないコードで1年間働いたと言います。その年の間に、理解を深めるために一生懸命働いたときに、文書化してその理解を検証するために、いくつの単体テストを作成しましたか？
コードをゆっくりと理解するのに苦労したので、次回苦労する必要がないように、コメントをいくつ追加しましたか？
スクラムバックログ
個人的には、「スクラムバックログ」という用語は誤称だと思います。やるべきことのリストはただのリストです-あなたがそうするなら買い物リスト。整備士に行ったときにリストがありました。メカニックとのスタンドアップミーティングは、実際にはスプリント計画ミーティングでした。
スプリント計画会議は交渉です。あなたの経営陣がその交渉なしでタイムボックスを組んでいる場合、彼らは何も管理していません。彼らは単に10ポンドのたわごとを5ポンドの袋に詰め込もうとしているだけであり、そう言うのはあなたの責任です。
スプリント計画会議に出席するときは、一連の作業に取り組むことが期待されており、その準備をするのはあなたの責任です。準備とは、リストの各項目を完了するために何をしなければならないかをある程度理解することを意味します。これには、あいまいなコードを理解するのにかかる時間や、単体テストを作成するのにかかる時間も含まれます。
準備する時間がない計画会議に誰かがあなたを招待した場合は、会議を辞退し、時間があるようにいつ再スケジュールするかを提案します。
単体テストのない既存のコード本体があり、機能がそのコードの動作に影響を与える可能性がある場合は、影響を受ける可能性のある古いコードの単体テストを作成する必要があります。あなたが機能を書くことを約束するとき、あなたはその仕事をすることを約束しています。それでも他の機能にコミットする時間が少なすぎる場合は、そのように言ってください。他の機能にコミットしないでください。
欠陥を修正することを約束するとき、あなたはあなたの仕事をテストすることを約束します。明らかに、それは欠陥の単体テストを書くことを意味します。ただし、単体テストのない古いコードが含まれている場合は、まだ壊れていないものの単体テストを作成することも意味しますが、変更によって破損する可能性があります。他にどのように修正をテストしますか？
欠陥リストが一定のサイズのままである場合、チームは修正された分だけ後退します。ユニットテストが現在欠陥リストの縮小を妨げている回帰を防ぐことを理解する必要がある人に丁寧に説明してください。
あまりにも多くの機能にコミットしているためにそれらの単体テストを作成できない場合、その責任は誰にありますか？
リファクタリング
コードをリファクタリングするときは、すべてをテストする必要があります。つまり、すべてのコードの単体テストを作成する必要があります。単体テストのない大量のコードがある場合は、リファクタリングする前に、それらの単体テストをすべて作成する必要があります。
これらの単体テストが実施されるまで、リファクタリングを延期することをお勧めします。それまでの間、コミットする作業の見積もりに単体テストを含めることを主張すると、最終的にはそれらすべての単体テストがそこになります。そして、リファクタリングできます。
その唯一の例外は、テスト容易性のためのリファクタリングです。一部のコードはテスト用に設計されておらず、単体テストを作成する前に、依存性注入などをリファクタリングする必要がある場合があります。単体テストを必要とする機能を作成することを約束するときは、コードをテスト可能にすることを約束します。機能にコミットするときに、それを見積もりに含めます。
コミットメント+責任=力
あなたはあなたが無力だと言います。あなたが責任を受け入れ、必要なことをすることを約束するとき、私はあなたがあなたが必要とするすべての力を持っていることに気付くと思います。
PS単一の欠陥を修正するときに、誰かが「時間を無駄にする」複数の単体テストを書くことに不満を持っている場合は、80：20の法則でこのビデオを見せ、「欠陥クラスター」を頭に入れてください。