コードレビューを行うタイミング

最近、スクラムプロセスに移行し、スプリント内のタスクとユーザーストーリーに取り組んでいます。コードを頻繁にレビューして、手間を軽減したいと考えています。ユーザーストーリーレベルでそれらを行うことを考えていますが、これを説明するためにどのようにコードを分岐させるのかわかりません。

VSとTFS 2010を使用しており、6人のチームです。

現在、機能の分岐を行っていますが、スクラムの分岐への変更に取り組んでいます。

現在、シェルフセットを使用しておらず、他に利用可能な技術がある場合は実際に実装したくありません。

ユーザーストーリーごとにコードレビューを実装することをどのようにお勧めしますか？

ユーザーストーリーの性質に依存します。

各ユーザーストーリーのブランチを作成すると効果的です。さまざまなストーリーの進行状況が表示されます。必要に応じてそれらを渡すことができます。 。その後、use storyブランチのユーザーストーリーの最後に最終レビューを実行し、コードが標準に達している場合はマージできます。

この方法で作業するには、スプリントの終了時に管理不能なマージタスクを防ぐために、ストーリーをきめ細かくする必要があります。小さなストーリーは、他のユーザーストーリーに取り組んでいる開発者が絶えずプルする必要があるスプリントを通じて、devブランチの安定した更新を可能にします（基本VCM）。

これにより、ブランチを絶えず作成してマージする必要があるプロセスのオーバーヘッドが発生します。これは、場合によっては自動化スクリプトで解決できますが、チームはVCSに非常に快適である必要があります。

スプリントの最後に、開発ブランチを統合/本番などにマージします。

また、私はチームで働いており、誰もが1つのdevブランチで働いています。ユーザーストーリーが完了すると、コードはレビューとテストのためにそのブランチにプッシュされます。

コードをレビューする最も効果的な方法は、立ち上がって誰かを見つけて、あなたが開発したばかりのコードについて話し合って議論することです。

コードをローカルでレビューできる人が見つからない場合を除き、ツールを使用しないでください。

ペアにすることで、コードレビューを完全に回避できます。

チームの全員がローカルですか？もしそうなら、誰かがやって来て、コードがチェックインされる前に見てみてください。お気に入りの画面共有プログラムを起動して、誰かに電話してください。私は個人的にこれを頻繁に行います。時々、「ねえ、私がやったことを見て！」

私は、誰かが立ち上がってコードをチームに提示するスタイルよりも、このスタイルのアドホックなコードレビューを好みます。アドホックレビューを行うと、ペアリングの多くの（すべての？）利点が不便さなしに得られます。また、「レビュアー」は、非公式の1対1の設定で質問をし、改善を提案する可能性が高くなります。

コードレビューはSCRUMの正式な部分ではありませんが、改訂は品質を達成し、プロジェクト/チームを改善するための独立した戦術です。

したがって、SCRUM（または他のアジャイル開発方法論）を使用して、プロジェクトの品質を保証/改善し、スケジュールを維持します。また、適切な戦術は、通常のQA /テストタスクから独立して製品の修正（コードではなく）を行うことです。このアクティビティをチーム/パートナー/クライアント/聴衆の前で行うことができれば、より良いでしょう。

主にTEAMを改善するために、コード（またはその他の特定の）リビジョンを使用し、中長期的に結果を期待する必要があります。これはプロジェクトに影響しますが、長期的にはチームの改善の結果として生じます。

だから、あなたの質問に答えるために、私はあなたがSCRUMからあまりにも多くを押し出そうとしていると信じています。

コードをチェックインする前にコードレビューを行うのは明らかではありませんか？

TFSはGITのように機能しないため、ブランチまたはトランクにコードをチェックインするたびに、誰でも利用できます。

これは、チェックイン時にレビューが行われる必要があるため、悪い変更が作業コピー全体に伝播されないことを意味します。