バックログのグルーミングと見積り
アジャイル手法に従って、製品所有者が製品の上位の計画を作成した後で、バックログのグルーミング項目を見積もるに、チームは会議。追加の作業を、調査のような表現または重要なバグに対処する項目を追加、の項目を定義することで、バックログのグルーミング。工数レベルを見積もる前に、チームの成功に一致する項目ごとに意味にする必要があります。
架空ファイバー Fabrikam のチーム メンバーに製品バックログを作成し、アジャイル手法に従ってスプリント サイクルを移動すると、それに続くこのトピックでは チュートリアル を続けます。チームでを使用する Team Web Access のバックログとタスクはページに乗ります。
ジュリアは、製品所有者のような プロダクト バックログの作成または追加 に説明されているように、一連のバックログ項目に、顧客サポートのポータルの自分の高レベルのビジョンとロードマップをキャプチャします。チームがバックログのグルーミング、推論する準備ができました。
[!メモ]
Visual Studio Scrum 2.0 のプロセス テンプレートを使用すると、プロジェクトのユーザー ストーリー、要件、または交付できる部分を説明する 製品バックログ項目 を作成します。アジャイル ソフトウェア開発用の MSF を使用すると、ユーザー ストーリーを作成します。MSF for CMMI Process Improvement に MSF を使用すると、要件を作成します。
このトピックの内容
レビューの承認基準と見積もりの作業
バックログのキャプチャのスパイクや非ストーリーの作業
作業を見積もることをサポートする追加のリソース
要件
このトピックの手順を実行するには、次の要件があります:
Visual Studio Premium、Visual Studio Ultimate、または Visual Studio Test Professional
チームのメンバーである [許可] に設定 [このノードの作業項目を編集します] のアクセス許可が必要です。チーム [共同作成者] グループがチーム プロジェクトのグループのメンバーであるため、既定では、チームのすべてのメンバーに、このアクセス許可があります。
[バックログ] のページを表示するには、Team Web Access でのアクセス 完全には グループに属している必要があります。
詳細については、「マイ プロファイルの管理と保有しているアクセス許可の表示」および「Team System Web Access の機能へのアクセス」を参照してください。
レビューの承認基準と見積もりの作業
バックログ項目とバグをだけでなく、記述する必要がありますが、項目が満たされている、バグが修正されたかどうかを検証するために使用する基準を入力するには応じて詳細を提供します。承認基準を定義する場合、チームはどのプロセスを採用して、共同で、バックログ項目に従ってを推論できます。
.png "バックログ項目の承認基準と工数")
開いている Team System Web Accessのチーム プロジェクトまたはチームのホーム ページへの移動、および [バックログの表示] を選択します。
ユーザーが確認するダブルクリック、またはを選択し、Enter キーを押して、作業項目が。
バックログ項目、バグのチームの一致の [説明] と [受け入れ基準] のフィールドを確認および更新します。
.gif "ヒント")
ヒントチーム プロジェクト (たとえば、[承認基準を含む説明] または [説明] の作成に使用されたプロセス テンプレートに基づいてこれらのフィールドの名前が異なる場合があります。
承認基準について: イテレーションまたはスプリントの終わりに貴社または製品所有者は、完成したとしてユーザー ストーリーを承認または却下します。スプリントを開始する前に、顧客の承認基準をできる限り明確に記述しておく必要があります。もちろん、ユーザー ストーリーが予想外の理由で承認されないことがあります。ただし、承認基準を定義するチームとの間貴社のスレッドは、チームで貴社の予測を理解するうえで役に立ちます。承認基準は承認テストの土台として使用できるため、ユーザー ストーリーを完成させることができたかどうかをより効果的に評価できます。
チームの使用を見積もるのメソッドに基づいて、[作業量] の値を入力します。プロジェクトの初期の段階でのみ、大まかな見積もりが必要です。
[!メモ]
Scrum のチーム プロジェクト、CMMI のアジャイルのたとえば、[作業量]、[ストーリー ポイント]、および [サイズ] の作成に使用されたプロセス テンプレートに基づいてこれらのフィールドの名前が異なる場合があります。
ストーリー ポイントについて: 自分の書籍では、アジャイル計画の Mike Cohn は、ストーリー ポイントをこの方法で定義します: "ストーリー ポイントで、ユーザー ストーリーの全体のサイズを表すための機能単位、またはそのほかの作品" は。Cohn は、ストーリー ポイントが特定の時間数に直接変換しない相対値であることを示しています。ストーリー ポイントは、チームがユーザー ストーリーの全般的なサイズを数値化するのに役立ちます。これらの相対的な見積もりは正確さに欠けるため、最初は工数を少なく見積もる必要があり、見積もりは時間の経過と共に精度を増していきます。ストーリー ポイントで見積もることによって、チームはユーザー ストーリーの現時点での全般的なサイズを示し、チーム メンバーがユーザー ストーリーを実装する段階になると、作業時間のより詳細な見積もりができ上がります。詳細については、「見積もり」を参照してください。
[保存して閉じる] のボタンをクリックします。
バックログのキャプチャのスパイクや非ストーリーの作業
チームは、ユーザー ストーリーまたは製品要件を直接実装ではない作業を行う必要があります。この作業はスパイクと呼ばれます。通常、スパイクには、調査、バグ負債、およびプロセスまたはエンジニアリングの改良の 3 種類があります。Team Foundationのスパイクを作成するには、バックログ項目、またはユーザー ストーリーを作成し、必要に応じてタイトル内のスパイク "" を指定し、他のユーザー ストーリーとともに製品バックログに回します。
.png "製品バックログ ページでのパネルの追加")
製品バックログのページの追加のパネルで、説明を完了する必要がある入力し、を [追加] のボタンを選択します。スパイクまたは非ストーリーの作業で [タイトル] のフィールドで。
ヒント追加のパネルが表示されない場合は、表示を有効にするには [add items on] のリンクを選択します。
次のアクティビティの非ストーリーの作業を定義すること:
調査: チームはユーザー ストーリーと見積もりが完全に分割するタスクになる前に応答するユーザー ストーリーに関する質問がある場合、質問に回答するために必要な調査を見積もる必要があります。たとえば、"ストーリーには、チームが決まります確認して、常客として、My は、複数の未解答の事項を" 特典の旅行を予約できます。チームは、項目を、メンバー、"My "Book 特典の旅行" が" 意味を理解してチームで作成します スパイクを表す場合。チームは他のバックログ項目を見積もるのと同じ単位で必要ないうアクティビティを見積もります。
.gif "重要 :")
重要チームが調査を完了するまで調査が必要なバックログ項目のいずれも、現在のイテレーションに追加することはできません。というアクティビティとそのバックログ項目を別の今後の反復に発生するようにスケジュールする必要があります。
バグ負債: バグを修正するのに最適なタイミングは、が見つからない場合です。これで当日修復できない場合は、作成します。これで追跡されることを確認するために、バグ作業項目を検索します。バグをため込まないように注意してください。チームがバグを収集する場合は、スパイクを他のユーザー ストーリーおよびスパイクとともに見積もりと優先度付けを行うために、ユーザー ストーリーを作成し、スパイクにバグをリンクします。
プロセスまたはエンジニアリングの改良: チームは成功の方向に、の操作を支援するプロセスまたはエンジニアリングの改良があります。これらのアップグレードは、スプリント振り返りまたは毎日のスクラム会議で識別されます。たとえば、場合によっては、単体テストでコード カバレッジを改良したり、継続的インテグレーション サーバー上でビルド時間を短縮したりする必要があります。
チームは、スパイクまたは非キャプチャ各ストーリーの作業項目ごとに、チームを確認レビューの承認基準と見積もりの作業 "" に説明されているように、手順 2 ~ 5 を理解し、実行する作業を推定する作業を実行します。詳細については、「プロダクト バックログの作成または追加」を参照してください。
推論をサポートする追加のリソース
次のリソースから推定アジャイル手法についての追加情報にアクセスできます:
アジャイル推論: Mike Cohn の Web サイトのアジャイル推論で表示を提供します。
このチュートリアルのトピック
Home | バックログを作成します。 | かんばんの委員会でバックログを表示および管理します。 | イテレーションの計画 | イテレーションを実行します。 | イテレーションの完了