・ワークフローのどの部分をソース管理ツールに任せるか 社員が上流設計フェーズに参加できる能力としては、ALMを目的としているTFSでPLMを一緒に行うわけではないことを理解し、PLMの成果物やイテレーションを理解して、参加者としてPLMのタスクのステータスを推進していく必要がありました。PLMがTFS + MS Projectで管理されていようが、Git + Redmineで管理されていようが、PLMで定義された成果物に対するタスクのステータスを推進させていけば良いということになります。PLMのタスク化や成果物の定義などは、その組織や会社における製品戦略とのかかわりが強く、製品戦略における汎用的な手法（マーケティングなど）は、ALMのプロセス推進とは全く別物だからです。 一方、構築フェーズや運用フェーズでは、社員はALMの成果物とイテレーション、成果物に対するタスクのステータスを定義し、管理者として社外協力者やアライアンス、ベンダーなどをコントロールしていく必要があります。 必要な作業はロールの洗い出しと責務の定義、イテレーションの計画とイテレーション内のワークフローを構成するロールを策定することです。それらはTFSの運用設計であり、TFSにそのような機能があるわけではないからです。 前述（「プロセスを社内のワークフローに落とし込む」）のとおり、ロールには「プログラマー（コーダーを想定）」と「SE（コーダーとペアプログラミングを組む相手を想定）」および「ビルド管理者（開発責任者を想定）」を設定しました。このロールがワークフロー内でステートを推進していきます。イテレーションはワークフローのステートが完了まで行くことと換言できます。ステートが完了まで行くことで振り返りができ、次のイテレーションにフィードバックできるからです。CMMIの場合、確立されたプロセスに則った実践が、メンバーの習熟度を向上させるのに対して、Agileではイテレーションを繰り返すことでプロセスを完成させていく（または時代に合わせて変化させていく）というアプローチが採られることに注意が必要です。それが、Agile Unified ProcessではUnified Processを組織に合った形に合致させていくことを目的としているため、必ず次のイテレーションにフィードバックさせる必要があるということです。 このイテレーション内で、TFSの機能をどのように使い、運用としてどのようにプロセスを推進させていくかをブランチ機能や作業項目、ワークアイテム等のTFSの機能を使って解説していきます。 まず、Main、Dev、Releaseのブランチを作成します。この手順はVersion Control […]