コードレビューを行うタイミング
最近、スクラムプロセスに移行し、スプリント内のタスクとユーザーストーリーに取り組んでいます。私たちは、コードレビューを頻繁に行って、面倒な作業を減らしたいと考えています。私たちはユーザーストーリーレベルでそれらを行うことを考えていますが、これを説明するためにコードを分岐する方法がわかりません。
私たちはVSとTFS 2010を使用しており、6人のチームです。
現在、機能の分岐を行っていますが、スクラムの分岐への変更に取り組んでいます。
現在、シェルベットセットは使用しておらず、他に利用可能なテクニックがある場合、実際には実装したくありません。
ユーザーストーリーごとにコードレビューを実装することをどのように推奨しますか？
それはユーザーストーリーの性質に依存します。
ユーザーストーリーごとにブランチを作成すると効果的です。さまざまなストーリーの進行状況が表示され、必要に応じてそれらを渡すことができます。スプリントでストーリーが完了していない場合、進行状況は次のスプリントのブランチにとどまることができます。 。最終レビューは、ユーザーストーリーの最後に使用ストーリーブランチで実行され、コードが標準に準拠している場合はマージされます。
スプリントの最後に管理できないマージタスクを防ぐために、ストーリーを細かくする必要があります。小さなストーリーは、他のユーザーストーリーに取り組んでいる開発者が常に（基本VCM）からプルする必要があるスプリントを通じて、開発ブランチの着実な更新を可能にします。
これにより、ブランチを常に作成およびマージしなければならないというプロセスオーバーヘッドが発生しますが、自動化スクリプトで解決できる場合もありますが、チームはまだVCSに非常に慣れている必要があります。
スプリントの最後に、開発ブランチを統合/本番環境などにマージします。
私もチームで働いていて、全員が1つの開発ブランチで作業しました。ユーザーストーリーが完了すると、コードはそのブランチにプッシュされてレビューとテストが行われます。誰かが開発ビルドを壊すものをプッシュした場合、チームビールを入手する必要があります。
コードをレビューする最も効果的な方法は、立ち上がって誰かを見つけ、彼らに来て、開発したばかりのコードについて話し合うよう依頼することです。
ローカルでコードをレビューする人が見つからない場合を除き、ツールを使用しないでください。
ペアリングすることでコードレビューを完全に回避できます。
チームの全員がローカルですか？その場合は、誰かに来て、コードがチェックインされる前に確認するよう依頼してください。ローカルではありませんか？お気に入りの画面共有プログラムを起動して、誰かに電話してください。私は個人的にこれを頻繁に行います。時々私は「ねえ、私がしたことを見てください！」
私は、このスタイルのアドホックコードレビューを、誰かが立ち上がってチームにコードを提示するスタイルよりも好みます。アドホックレビューは、ぎこちなくせずにペアリングの利点の多く（すべて？）を提供します。また、「レビュアー」は、非公式の1対1の設定で質問をしたり、改善を提案したりする可能性が高くなります。
コードレビューはSCRUMの正式な一部ではないと思いますが、改訂は、品質を達成してプロジェクト/チームを改善するための独立した戦術です。
したがって、SCRUM（または他のアジャイル開発方法論）を使用して、プロジェクトの品質を保証/改善し、スケジュールを維持します。また、通常のQA /テストタスクから独立して（コードではなく）製品リビジョンを実行するのも良い方法です。このアクティビティをチーム/パートナー/クライアント/オーディエンスの前で行うことができれば、さらに良いでしょう。
コード（またはその他の特定の）リビジョンを使用して、主にTEAMを改善し、中長期的な結果を期待する必要があります。これはあなたのプロジェクトに影響しますが、長期的にはあなたのチームの改善の結果として。
だから、あなたの質問に答えるために、私はあなたがスクラムから過度にプッシュしようとしていると私は信じています。
コードをチェックインする前にコードレビューを行うことは明らかではありませんか？
TFSはGITのように機能しないため、ブランチまたはトランクにコードをチェックインするときはいつでも、誰でも利用できます。
つまり、チェックイン時にレビューを行う必要があるため、悪い変更が全員の作業用コピーに反映されません。