TFSでは複数のプロセステンプレートを使用してさまざまな開発プロセス編成方法論をサポートできるため、まず最も一般的なSCRUMの1つだけを検討します。
知り合いには、仮想マシンのイメージ、 実験室作業のガイド 、ロシアのMSDNの実践的なレッスン、またはこの記事から選択できます。
トピックキャプチャプラン：
•要件の説明（バックログ）
•反復計画
•作業計画
•パフォーマーのワークロード
第11バージョンの作業の計画と管理のコンテキストは「チーム」です。 この快適な革新により、1つのプロジェクトで複数のチームの作業を整理しやすくなります。 したがって、チームのスケーリングにアプローチを適用すれば、柔軟な方法論に従って大規模なプロジェクトでも実装できます。 ただし、ここでは1つのチームの作業に焦点を当てます。
チームの場合、以下を決定する必要があります。
•チームメンバーのリスト
•チームが取り組んでいるサブシステムのセット
•チーム作業が関連付けられている反復
Webサイト上のチームには、サブシステムと反復に関連する要素のみが表示されるため、チームが突然タスクを表示しない場合は、タスクがチームのサブシステムのいずれかに割り当てられているかどうかを確認します。 記事を短くするために、チームが既に作成されていると仮定します。
要件の説明
そのため、メインページから製品バックログ（新しい製品要件のリスト）にアクセスできます。 すでに実装されて終了している要件は過去のセクションに移動し、表示されません。 現在稼働中のものは、「現在」セクションにあります。
SCRUMでは、要件の線形リストを維持する必要があるため、Webインターフェースはそのようなアプローチを実装しています。 ただし、バックログ要素間の階層関係を構築し、Visual Studioで、またはクエリを使用してWeb経由でそのようなツリーを操作する必要はありません。
リストには、機能的および非機能的の両方のすべての要件が含まれている必要があります。 新しいエントリを追加する最も速い方法は、タイトルを入力して[追加]ボタンをクリックすることです。 レコードはすぐにリストに表示されますが、追加のパラメーターは表示されません。 [タイトル]行が空のときに[追加]ボタンをクリックすると、パラメーターを入力するための完全なダイアログが表示されます。
反復計画
ここで、Effortフィールドに興味があります。これは、この要件の実装の複雑さの相対的な推定値が導入されるフィールドです。 評価は任意の単位で導入されます-ストーリーポイント（「オウムの中」-フォーク）。チーム評価中に取得されます。 SCRUM方法論では、このためにアジャイルポーカーを使用していますが、これは小さな記事の主題になる可能性があります。 この評価のツールは、チーム、インドア、テーブル、アジャイルポーカーのデッキです。 TFSでは、このプロセスは手段によってサポートされておらず、これは正しいです。そうでない場合、アジャイルポーカーではなく、対応ボクシングが行われます。 つまり [Effort]フィールドには、計画の結果得られた1桁をすでに入力しています。 これは時間ではなく、日でも、お金でも、コード行でも、クラスでもありません。これはおおよその相対的な慣習です。 ストーリーポイント。 Sep丸
ただし、最初のイテレーションが成功した後、チームがイテレーション期間中に実装するストーリーポイントの数-Velocity：
Velocityはさまざまな目的に使用できます。新しい反復の作業量の計画、作業の支払い額の決定、チームの効果を絶えず向上させるプロセスでの測定です。 オプションの1つは必ず取り消さなければなりません。
Forecastツールをオンにすることで、労働要件が今後の反復にどの程度適合するかを確認できます。
このリストの要素は、マウスで上下に移動できます（順序の変更）。現在の速度の他の推定値を[反復]フィールドに入力でき、特定の反復（スプリント）を指定できます。
ただし、反復を指定する前に、要件を承認する必要があります。 要件（「ウィッシュリスト」とも呼ばれます）は、ユーザー、企業、管理者、設計チームなどから寄せられたすべての人によって収集されます。 それらは新しい状態になります。 その後、この要件が承認される（承認される）か拒否される（削除される）かが決定されます。
拒否された要件はバックログに残り、新規および承認済みのままです。
新しいイテレーションを開始する前に、チームは優先順位、現在のパフォーマンス、および製品所有者の希望に基づいて、実装の要件を選択します（実装へのコミット）。 要件は承認済み状態からコミット済みに移行され、ウィッシュリストリストからも消え、特定の反復計画であるスプリントバックログに分類されます。
作業計画
要件（およびそのタスク）が現在の反復のタスクボードに表示されるようにするには、要件（タスク）にこの反復を指定する必要があります（上記を参照）。
ボードには、選択した要件を実装するために現在チームが取り組んでいるステッカータスクの形式で表示されます。
各要件の実装は、ビジネスロジックの作成、各プラットフォームのクライアントでのインターフェイスの作成、テストの説明、参照ドキュメントの作成など、いくつかの問題の解決で構成されます。
他の機能と同様に、非機能要件には、それを実装するための会計と努力が必要です。 たとえば、テストインフラストラクチャとパフォーマンステストの作成-パフォーマンス要件などのために。
要件の実装は複数の反復にまたがる場合がありますが、2〜3日より長い別のタスクを実行しないことをお勧めします。
ここで、ボード上でタスクを作成できます。タスクは、要件、サブシステム、および現在の反復に自動的に添付されます。
すぐに、[残存作業時間]フィールドに工数で見積もりを入力できます。 したがって、このツールを使用すると、相対的な要件評価方法と1時間ごとの負荷計画を組み合わせることができます。
To Doステータスに新しいタスクが表示され、残りの作業の評価がオンデマンドの作業の合計評価に追加されます。
ボード上で、パフォーマーを選択し（またはパフォーマーがタスクを選択できます）、マウスでそれをIn Progress状態にドラッグし、完了したら-完了にできます。
Visual Studioの便利なタスク管理に関連する興味深い機能があります。 これは、チームエクスプローラーでのアクティブなタスクとソースコードの変更との関連付けのリストであり、チェックイン時に自動的に完了状態になりますが、記事は既に長すぎます。
作業のリスト、反復の期間、および作業の時間単位の評価があるため、残りの作業の削減のダイナミクスのグラフを見ることができます（「作業の燃焼」のスケジュール）。
これで、アーティストのダウンロードの計画に戻るためのすべてが揃いました。
労働者の負荷：
ワークボードの最終的な外観ですが、すでにアーティスト別にグループ化されています。
バックログに移動して、現在のスプリントを選択し、同じタスクを確認します。ただし、ツリー形式で、右側の図のコマンドの読み込みを簡単に分析します。
チーム全体（54時間のチーム52）のワークロードの合計を確認します。
作業をカテゴリに分類（作業者：アクティビティ）-この分類は使用しませんでしたが、各タスクをカテゴリに割り当てることができます。
そして、パフォーマーのワークロードを確認します。 監査タスクが追加されたばかりのブライアンケラーの混雑は、赤で強調表示されています。
問題を解決するために、私はブライアンのマネージャーに行き、以前に同意したように、このイテレーションで1日4時間ではなく私のプロジェクトで作業するように頼みますが、5。
また、以前計画されていた1日の町外のチームビルディングについては何も触れずにいることに注意してください。
この日、私たちの湾ではオール4でのレースが計画されています。 チームワークは順調に進んでいると彼らは言います...
UPD： MSDNにさらに詳細な記事があることがわかりました 。 しかし、これは私のものです！ =）