[アーカイブ] TFS 2012 プロジェクトのはじめ方 ~新TFSスクラム プロセステンプレート紹介つき [2/2]

<オリジナル投稿 2012年8月24日 本ポストの情報はオリジナル投稿時点のものです。マイクロソフトの正式な見解や製品の仕様を保証するものではないことをご了承ください。>

さて、続きです。

TFS 2012 でのチームプロジェクトの作成と、新たに標準搭載された Microsoft Visual Studio Scrum 2.0 (以下、VS Scrum) プロセステンプレートでプロジェクトをはじめる手順をお伝えしてきました:

今回は、具体的に、プロダクト バックログにて、プロダクト バックログ項目 (Product Backlog Item: PBI) を管理し、スプリントごとのスプリント バックログで、 PBI とタスクを管理し、タスクボードで運営するところまでを見ていきます。

※本来であれば、テスト管理、継続的インテグレーション、自動デプロイ含めて紹介するわけですが、情報量が多くなってしまいますので、また日を改めて。

見える化、分かる化

まずは、TFS 2012 のメリットですが、Web ブラウザでチームとプロダクトの状況が一望できることが挙げられます。
image
これは、まだ PBI もなにもセットしていない状況ですが、これでも、前回の投稿段階で、スプリント1 の期間と全体作業時間、バーンダウンチャートが一望できそうなのがわかりますね。

プロダクト バックログ

さて、プロダクト バックログに PBI をセットしていきましょう。PBI の作成は、先の画面で、imageをクリックすることで、フォームを開き行うことができます。
ただ、プロダクト バックログからだと、非常にスムーズに今わかっている情報をもとにインプットしていけますので、こちらをお勧めします。
[作業]タブをクリックすると、バックログ管理にアクセスできます。既定で表示されているのがプロダクト バックログになります。
image
ここで、既定で、「項目の追加: オン」という状況のため、
image
にタイトルを入力し、[追加] をクリックするだけでドンドン、PBI を追加していくことができます。
image
ほんと楽です。さて、予め PBI が決まっていて、それを一括でインプットしないならば・・・みんなが、大好きな Excel の力に頼りましょう!
image
Excel を開いて、コピペなどして、[発行] で TFS に一括登録、更新ができます。アプローチは、Excel を起動して、「チーム」タブで、「新しい一覧」をクリックし、TFS の設定とクエリを呼び出せばいいです。
Visual Studio からは、クエリを実行したら、[Excel でクエリを開く]でOKです。
image
これを見ただけでも、Web で PBI をインプットしたら、Visual Studio からも、Excel からも、Eclipse からも、瞬時に見ることができることがわかりますね。リポジトリが一つの TFS ならではのメリットです。
重要なのは、エンドユーザーにこの PBI でどういう価値を提供しようとしているのか、そのための基準(受け入れ基準)を利害関係者、チームでコンセンサスをとるということです。
VS Scrum の PBI には、「説明」と「受け入れ基準」のフリーテキストが予め用意されています。
image
ここに、業務シナリオ、目的であったり、それを満たすための受け入れ基準だったりをしっかりとプロダクト オーナー (PO) が入力し、ユーザーと開発チームが共通認識を持てるようにします。「説明」の隣に、「ストーリーボード」という気になる項目がありますが、これが PowerPoint を用いた動く絵コンテとしてのストーリーボードとつながるわけです。これで、より具体的なビジネス価値の共通認識を持てるようにします(詳しくは、この辺の動画でご覧ください)。
あとは、各 PBI の作業量の見積もりと、優先順位の決定です。これらも Web から直観的に行えます(もちろん、TFS 2010 までのように、VS や Eclipse, Excel からも行えます)。
作業量 (Effort: 相対的なポイントなどです。工数でも人月でもありません。例: ストーリーポイント)は、各 PBI を開いてセットするので、これは Excel で行うほうがやりやすいですね。プランニング ポーカー使いながら、見積もるといいですね。ちなみに、はじめのうちは、あまり正確にと・・・と慎重にならないことを個人的にお勧めします。今までの経験値上 (いち個人の経験値じゃないですよ。チームの経験値ですよ)、目星がつくものがあれば、それを基準に相対的に見積もるといいと思います。
たとえば、「ユーザーの登録」が 「2」だとしたら、「ユーザーの更新」は、「3」、「ユーザーの削除」は、「8」とかです。個人的に決めてしまうのではなく、プランニング ポーカーなどで各自の知見とチームの知見、共通認識を高めて行ってください。
// 本投稿の主旨からそれますが、そういう本質的なところに時間を使ってほしいので、TFS なんかは、これくらい統合され、使いやすくないといけないんですよね。本業への注力とその支援が大切!
優先順位は、Web ブラウザ上で、ドラッグ&ドロップで行えます。
image
ドラッグ&ドロップで、優先順位を検討しているところです。タッチでももちろん動かせますので、大きめのタッチパネルモニターがあれば、チームでやりやすいですね。
さて、このプロダクト バックログには、「予測」という機能があります。これはこのチームが各スプリントでこなせる作業量に基づき、どの PBI までをどのスプリントでこなせるのか、文字通り予測する機能です。
image
はじめてではベロシティといってもデータがないわけですが、過去スクラムで開発を行った経験のあるチーム (くどいですが、いち個人ではないですよ) なら、自分たちが1スプリント内でこなせる作業量はわかりますよね。それをベロシティといいます。
スプリントをこなせばこなすほど、相対的な作業量の見積もりと、スプリント計画の精度が増していくことになりやすくなります。そうするとこの「予測」機能がより活きてきます。
チームが、スプリントでこなせる作業量が 10 としたら、何スプリントで、全 PBI を顧客に提供できるのか (≠ 実装できるのか) を把握しやすくなるということです。これは PBI の優先順位をつけるときの大きな助けになります。
さて、優先順位づけを行い、今回のスプリントで実施する PBI が定まったら、PBI をドラッグ&ドロップで、スプリントへ割り当てます。
image
ドラッグ&ドロップするだけですね。もちろん、予定にあるスプリント2以降へのD&Dできますが、それは現実的ではないでしょう。プロジェクトの状況は変化しますので。

スプリント バックログ

先の操作により、スプリント1には、いくつかの PBI がセットされたことになります。
image
この画面は、現在 | スプリント1 をクリックしたところです。2つの PBI が表示されました(要するにこの2つをD&Dしました)。さて、スプリント計画ミーティング2にて、タスク分割していきます。タスクの追加は、+をクリックしたらできそうに見えますよね。その通りです。直観的にタスクを追加していけます。
image
ここでのポイントは、「残存作業」に、このタスクの作業時間を入力するところです。あと、優先順位ですね。VS Scrum では、作業実績のインプットはありません。作業を終えたら「残存作業」が 0 になります。バーンダウンチャートで進捗を見る、検査と適用にフォーカスするやり方ですね。MSF for Agile には 残存時間と、実績時間があります。こちらは思惑と実際が明瞭になります。
さて、このタスク分割ですが、こちらもやはり、みんな大好き Excel がとてもやりやすいです。
image
スプリント バックログを Excel で開き、PBI の下の行に子供としてタスクを追加していけばいいわけです (ID が未割当なのが、今 Excel で追加したタスクです)。これを発行すれば、タスクの登録完了というわけです。
これは、予めタスクのパターンが決まっている場合はとくにやりやすいです。王道パターンを Excel で予めテンプレート化しておけば、それをコピペして、残存時間の検討に注力することができるわけです。
image
もちろん、Webブラウザからでも、Excel からでも、Visual Studio や Eclipse からでも追加したタスクはどこからでも見ることができます。たとえば、 Visual Studio から見ると
image
Eclipse から
image
※これはWindows上の Eclipse で Team Explorer Everywhere で接続していますが、もちろん、Eclipse とコマンドラインで、Mac OSX や Linux、Solaris などの UNIX からも接続できます。
Web ブラウザでは、以下のようになります。
image
Web Access からは、スプリント バックログの右側に、作業のリアルタイムな状況が見えてきます。タスク分割と見積もりを行ったところ、総作業時間が16時間で、きっちり16時間で終わる計算になったようですね。
さて、ここまで来たら、「ホーム」に戻ってみましょうか。
image
作業時間とバーンダウンチャートの準備ができました。後は、いつも通り開発作業を行っていけばいいわけです。TFS は、タスクやバグとソースコードの変更セットが常に追跡可能にできますので、スクラムによるよいプロジェクト運営をソースコード→ビルド→デプロイ→テスト結果といったエンジニアリングに必要な要素の下支えを確保してうえで行えます。
さて、「ホーム」をだしたので、余談です。下部の点線で囲われた黄色い部分には表示させたいお気に入りをセットできます。これをセットすることで、あらゆる関心ごとを1ページでみえる化、わかる化する助けとなります。
image

タスク ボード

さてさて、プロダクト バックログから、スプリント バックログへ、ときたらチームによる開発作業のスタートですが、ここでも TFS 2012 がいい仕事をサポートしてくれます。
image
タスクボードです。しっかりとスプリント バックログの情報を表示していますので、PBI ごとにタスクがボード上に配置されています。
こちらももちろん、ドラッグ&ドロップで遷移をさせることができます。
image
残作業時間、人のアサイン(タスクをとる行為)も、直観的に行えます。
image image
また、タスクボードは、情報の絞り込みも可能です。ボードの右上の「個人」にてメンバーを絞り込めます。
image
image
絞り込みを行うと、関係したタスクがない PBI については自動的に閉じた状態となります。また、絞り込み対象外のタスクは、色が分けられて表示され、全体感もわかりつつ、絞り込んだ人(たとえば自分のタスクだけみたい)の情報にフォーカスすることができます。
タスクボードは、PBI 単位だけでなく、メンバー単位で見ることもできます。
image

Visual Studio から見たタスク

Visual Studio からももちろん、タスクを見ることができます。開発者は、基本的には Visual Studio の中で開発にかかわるすべての作業が行えるようになります。したがって、自分のタスクについても、Visual Studio で、チームエクスプローラーから把握することができます。
チームエクスプローラーにて、担当作業 (My Work) にアクセスすると以下のように、開発者のタスクについて、Doing(処理中の作業=実施している作業), Pending(中断されている作業)、To Do(予定している作業=使用できる作業項目)、コードレビューの依頼と結果の情報を一望できます。
image
ソースコードに変更が入るとそれを変更セットとして、「処理中の作業」に自動的に加えてくれます(要するに変更したコードがどれだったか覚えておく必要もない)。また、そこに「使用できる作業項目」から、タスクやバグをドラッグ&ドロップするとその変更セットとタスクやバクを関連付けて作業途中から認識させることができます(TFS 2012 までは、チェックインの際に、タスクやバグとソースコードの変更セットを関連付ける)。もちろん、コード変更前に、タスクやバグ修正を宣言してはじめてもいいです(私はこっちのアプローチが好き)。
image image
タスクをドラッグ&ドロップしている途中と、D&Dを終えたあと。
「担当作業」では、関心ごとスイッチですごいことができるのですが、これらはまたの機会に紹介したいと思います。気になる方は、この辺の動画をご覧ください。

ベロシティとバーンダウンチャート

さて、レポート関連です。TFS 2012 からは標準で、ベロシティとバーンダウンチャートを提供します。TFS 2010 では、SQL Reporting Services の力を借り、Web と Excel レポートでこれらをカバーしていました。
もちろん、TFS 2012 でも引き続き、より高度なレポート機能を提供していきますが、レポート機能を持たない基本構成でも、これらの恩恵を受けることができるのは大きいですね(TFS Express ではこれらは使えません)。
今、セットしているプロジェクトにはまだ成果がありませんので、ベロシティも、バーンダウンも何もありませんが、どこに表示されるのかをご紹介しましょう。
ベロシティは、プロダクト バックログの右上に常に表示されます。
image
クリックで拡大されます。
image
バーンダウン チャートは、スプリント バックログとホームで表示されます(ホームでの表示は先述のため省略)。
image
同じく、右上に常に表示されています。クリックで拡大もベロシティと同様です。
image
さて、この投稿もこれで以上としたいと思います。
知っていただきたかったこと:

  • TFS 2012 は、スクラムをバランスよくサポートしてくれます
  • それぞれの立場が最適な道具を使って、本業に注力できる環境を作ってくれます
  • スクラムの持つ素晴らしい改善のフレームワークと成果物に、ソフトウェアエンジニアリングとしての裏付けデータで下支えしてくれます
  • スクラムをはじめとしたアジャイル プラクティスを自社プロセスなどあらゆるプロセス/現場で役立てることができます

ちょっと難しかったなと思われた方は、ぜひ、『アジャイルサムライ』と、『アジャイルソフトウェアエンジニアリング』を読んでください。