リリースフィーバー中に効率的なコードレビューを行う方法
リリースの期限は明日です。同僚は、このリリースにとって重要なタスクをようやく完了しました。プロジェクトマネージャーは肩越しに立ち、最終的にビルドを行うように要求し、レビュー中に同僚のコードの欠陥に気づきます。重大な問題ではありませんが、明日リリースされなければリリースできません。そして、事態を悪化させるために、あなたは自分自身をできるだけ早く完成させる必要がある。それで、あなたは何をしますか？プレッシャーにもかかわらず、あなたは異議を唱えますか、それともこれを片付けますか？
私が見つけた1つの方法は、このコミットを別のブランチに一時的にマージして、後でレビューすることです。問題が表面的なものであり、まだコードレビューを待っている唯一の問題である場合に機能します。しかし、これを処理するより効率的な方法はありますか？たとえば、1人の人にコードのレビューとテストのみを委託することをお勧めしますか？
ここでの答えはコミュニケーションです。
- この問題についてテクニカル/チームリードに伝える
- 潜在的な影響についてQAに相談する
- プロジェクト管理（あなたのすぐ後ろにいる人）に、リリースが遅れる原因となる問題がある可能性があることを伝え、できるだけ早く（数分または数時間で）返信します
- この問題がリリースのショーストッパーであるかどうかを評価する
問題がショーストッパーでない場合は、リリースを続行します。 QAとユーザーに問題を通知し、問題にパッチが適用されるフォローアップ日を確約します。これは、生産に移行する別のリスクになります。
これがisの場合、ショーストッパー（つまり、それが最終的な収益または誰かの健康に悪影響を与える）の場合、リリースを遅らせることが推奨されていることをチェーンに伝え、その理由を伝えます。次に、開発者に戻って問題の修正にかかる時間を調べ、X分/時間/日が必要であることを経営陣に伝えます。
おそらく、経営陣はこのゲーム後半のショーストッパーについて満足していないでしょうが、それが本番環境にリリースされることを望まないでしょう。
コミュニケーションを取り、経営陣に電話をかけます。
問題を伝えるだけでなく、それを文書化する
これまでの他の回答に対する私の大きな懸念：差し迫った期限に直面している一般的なプロジェクトマネージャーに対してこれらの行に沿ってあなたが言うことは、無視されるか忘れられる可能性があります。その後、何かがうまくいかなかった場合でも、リスクを不十分に伝えるためのフックに留まることになります。
発見した問題をプロジェクトマネージャーに知らせ、それを文書化することを彼に知らせます。デューデリジェンスを指摘できるようにする必要があります。
どこに文書化し、誰に伝えるかは、作業環境によって異なりますが、必ず上司も含めてください。
リスクおよび影響の特定
問題はクリティカルではないが、それが何を意味するのかを明確に定義していないと述べました。その肉付けはあなたの次のステップです。
迅速に リスクと影響の分析 問題を特定し、問題を引き起こす可能性（リスク）と、リスクが実現した場合の影響の重大度（影響）を特定します。上記のリンクにあるような明確に定義された用語（プロジェクトマネージャーが知っておくべきこと）を使用しますが、分析を裏付ける説明も提供します。
ドキュメントには、推奨される一連のアクションも含める必要があります。はい、懸念を提起しても問題ありません。それでもリリースを続行することをお勧めします。 リスクを特定する は正しいことです。
次のリリースはいつですか？
リスク/影響の分析を完了した後も、何を推奨すべきかについて垣間見えている場合は、リリーススケジュールを考慮してください。 2週間以内に修正を含めることが期待できる場合、一部の不完全なコードはリリースしても問題ありません。
懸念の修正が「優先順位が下がる」（つまり、次の光沢のある機能拡張のために無視される）可能性がある場合は、問題を発見したらできるだけ早く問題を文書化するもう1つの理由です。問題の時計」。
この場合は、全員に通知して決定を任せます。それはおそらくあなたがリリースされた最初のバグではありません。
締め切りは明日ですが、次のような状況になります。
プロジェクトマネージャーはあなたの肩越しに立って、最終的にビルドを行うようにあなたに迫ります
これは例外である可能性があるため、1つのバグが抜け落ちたからといって、プロセスに大幅な変更を加えないでください。あなたがすべきことは、いくつかの対策を講じることですので、土壇場でビルドを作成していません。うまくいけば、あなたはそれが成功するという自信をあなたに与えるのに十分な規則的な頻度でビルドを作っているでしょう。それはまだそれらを最後に実行する十分な理由ではありません。物事を十分にテストすることは、自信を高めるためのもう1つの要素です。
このシナリオを、このことをリードしている人に提示します。
- 提示する必要がある問題のタイプを決定します。
- オプションを特定します。
- 誰が決定を下すか
- このすべてをいつ決定すべきですか？それはおそらくリリース日に対して相対的になるでしょう。
これは、このぎりぎりの問題をどう処理するかを答えるものではありませんが、将来それらに対処できるようにする方法を提供します。特に解放のプレッシャーがあるときは、考え抜かれて感情に動かされない方法で物事を処理する方法が必要です。
他の答えは、品質プロセスを曲げようとする上司の問題に焦点を当てています。
ただし、あなたが質問していると思うのは、コードレビューには少なくとも2人が必要であるため、大幅な遅延が発生するという事実にどのように対処するかです。たとえば、タスクの実装に2時間、確認に2時間かかる場合、多くの場合、2つのアクティビティの間に長い休止があります。リアルタイムでは、タスクが完了するまでに2〜3日かかる場合があります。
これは、スループットと遅延の典型的な問題です。ソフトウェア生成マシン（人間）では、コンテキストスイッチは高価であるため、すぐにレビューを行うために誰かの仕事を先取りすることは、一般的な慣習ではありません。
問題を軽減するためのヒントをいくつか紹介します。
- タスクの作業中は、コードを細かく分けて送信します。これにより、校閲者が長い時間の連続した時間を予約する必要がなくなります。
- コードレビューの優先順位の高い文化を促進します。リクエストを受け取ったときに現在の作業単位を停止しないでください。ただし、次に何をすべきか迷っているときは、常にキューからレビューを選択してください。
- チームのタイムゾーンの違いがある場合は、それを利用します。
- 1人の人にコードレビューのみを依頼しないでください。それは逆効果です。彼が自分の仕事に真剣に取り組むつもりなら、彼は荷を処理することができません。あなたのマネージャーは、誰かがアイドルであるという考えを受け入れません。
期限があり、あなたのマネージャーがあなたのすぐ後ろを肩越しに見ている場合、あなたは彼に離れるように言います。彼は去るか、あなたは去ります。プレッシャーの下でレビューを余儀なくされているため、コードをレビューしない方がよいことを彼に説明します。
このような状況では、いくつかの重大なバグが確実に発生するでしょう。
AppleのApp Storeに提出するなど、新しいバージョンを撤回する数日があるという幸運な状況にいる可能性があります。しかし、コードが顧客に出荷された場合、それは災害のレシピです。次回はあなたのマネージャーがより良い計画を立てることを望みます。