リリースフィーバー中に効率的なコードレビューを行う方法

リリースの締め切りは明日です。同僚はこのリリースに不可欠なタスクをやっと完了しました。プロジェクトマネージャーは肩越しに立ち向かい、最終的にビルドを作成するように促しました。重大なものではありませんが、明日リリースされなければ、手放せないものです。そして、事態を悪化させるには、できるだけ早く終了するために必要な自分の仕事があります。それで、あなたは何をしますか？プレッシャーにも関わらず異議を申し立てますか、それともこれを滑らせますか？

私が見つけた1つの方法は、このコミットを別のブランチに一時的にマージし、後で確認できるようにすることです。問題が表面的なものであり、コードレビューを待っている唯一の問題である場合に機能します。しかし、これを処理するより効率的な方法はありますか？たとえば、コードレビューとテストのみを1人で行うことをお勧めしますか？

ここでの答えは通信することです。

1. 技術/チームリーダーに問題について伝える
2. 潜在的な影響についてQAに相談する
3. プロジェクト管理者（あなたのすぐ後ろにいる）に、リリースが遅れる原因となる問題があるかもしれないことを伝え、すぐに（数分または数時間で）戻ってきます
4. この問題がリリースのショーストッパーであるかどうかを評価する

問題がショーストッパーでない場合は、リリースを続行します。QAとユーザーに問題を通知し、問題にパッチを適用するフォローアップ日にコミットします。これは、本番環境に移行する別のリスクになります。

これがショーストッパーである場合（最終結果または誰かの健康にマイナスの影響があることを意味します）は、リリースを遅らせることが推奨されていることをチェーンに伝え、理由を伝えます。次に、開発者に戻り、問題を修正するのにかかる時間を計算し、X分数/時間/日が必要であることを管理者に伝えます。

経営陣は、このゲームの後半にショーストッパーについて満足していませんが、実稼働環境にリリースすることは望んでいません。

通信し、管理者に電話をかけます。

問題を伝えるだけでなく、文書化する

これまでの他の回答に対する私の大きな懸念：差し迫った締め切りに直面している典型的なプロジェクトマネージャーに対してこれらの方針に沿って言うことはすべて無視されるか、忘れられる可能性があります。そうすれば、何かがうまくいかない場合でも、リスクを十分に伝えられないためにフックに留まることになります。

プロジェクトマネージャーに、発見した問題について知らせ、文書化することを伝えます。デューデリジェンスを示すことができる必要があります。

どこに文書化するか、誰に伝えるかは職場環境によって異なりますが、間違いなく上司を含めてください。

リスクと影響を特定する

問題は重大な問題ではないが、それが何を意味するのかを実際に定義してはいないとおっしゃいます。それを駆逐することがあなたの次のステップです。

問題、問題が発生する可能性（リスク）、およびリスクが結実した場合の影響の重大度（影響）を特定する迅速なリスクおよび影響分析を行います。上記のリンクにあるような明確に定義された用語（プロジェクトマネージャーが知っておくべき）を使用しますが、分析をバックアップする説明も提供します。

ドキュメントには、推奨される一連の行動 も含める必要があります。はい、懸念を提起してもリリースを続行することを推奨します。リスクを特定するのは正しいことです。

次のリリースはいつですか？

リスク/影響分析を完了した後、推奨事項についてまだ問題がある場合は、リリーススケジュールを考慮してください。2週間以内に修正プログラムを含めることができる場合、不完全なコードをリリースしても構いません。

あなたの懸念を修正することが「優先順位を下げられる」（つまり、次の光沢のある拡張を支持して無視される）可能性がある場合、それはあなたがそれを発見した後できるだけ早く問題を文書化するもう一つの理由です：問題の時計。

この場合、全員に通知して、彼らに決定を任せてください。これはおそらく、リリースされた最初のバグではありません。

締め切りは明日ですが、次のような状況に陥ります。

プロジェクトマネージャーが肩越しに立ち、最終的にビルドを作成するように促します

これは例外かもしれないので、1つのバグがすり抜けたからといって、プロセスに大幅な変更を加えないでください。あなたがすべきことは、いくつかの対策を整えることです。そのため、あなたは最後までビルドをしていません。うまくいけば、あなたはそれが成功するという自信をあなたに与えるのに十分な規則的な頻度でビルドを作っています。直前に実行するのに十分な理由ではありません。物事を十分にテストすることは、自信を高めるための別の要素です。

このことを主導している人にこのシナリオを提示します。

• どのタイプの問題を提示するかを決定します。
• オプションを特定します。
• 誰が決定するのか
• このすべてをいつ決定すべきですか？おそらくリリース日からの相対的なものになるでしょう。

これは、この最後の最後の問題をどう処理するかには答えませんが、将来それらに対処できるようにする方法を提供します。特に解放するプレッシャーがある場合、考えられ、感情によって動かされない方法で物事を処理する方法が必要です。

期限があり、あなたのマネージャーがあなたの肩越しにあなたのすぐ後ろを見ている場合、あなたは彼に立ち去るように言います。彼は去るか、あなたは去ります。プレッシャーの下でレビュ​​ーを強制されるので、コードをレビューしないことを彼に説明してください。

このような状況では、いくつかの重大なバグが発生することを確信できます。

AppleのApp Storeに提出するなど、新しいバージョンを撤回するのに数日かかる幸運な状況にあるかもしれません。しかし、コードが顧客に出荷されると、それは災害のレシピになります。次回、マネージャーがより良い計画を立てることを望みます。

他の回答は、品質管理プロセスを曲げようとしている上司の問題に焦点を当てています。

ただし、コードレビューには少なくとも2人が必要であるため、大幅な遅延が発生するという事実にどのように対処するかということです。たとえば、タスクの実装に2時間、レビューに2時間かかる場合、多くの場合、2つのアクティビティの間に長い一時停止があります。リアルタイムでタスクが完了するまでに2〜3日かかる場合があります。

これは、スループットとレイテンシの古典的な問題です。ソフトウェアを生産する機械（人間）では、コンテキストスイッチは高価であるため、誰かの仕事を即座にレビューするために先制することは一般的な方法ではありません。

問題を軽減するためのヒントを次に示します。

• タスクの作業中は、レビュー担当者が長い連続時間を予約する必要がないように、小さな部分でコードを送信します。
• コードレビューの優先度の高い文化を促進する。リクエストを受け取ったときに現在の作業単位を停止しないでください。ただし、次に何をすべきか疑問に思うときは、常にキューからレビューを選択してください。
• チームにタイムゾーンの違いがある場合は、それを利用します。
• コードレビューのみを一人で行わないでください。それは生産的です。彼が自分の仕事に真剣に取り組むならば、彼は負荷を処理することができなくなります。マネージャーは、1日を節約するためだけに、誰かがアイドル状態であるという考えを受け入れません。