読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

Pivotal TrackerをWater-Agile-Fall的に使えるかの実験(Part.1)

Agile Waterfall Project Management

プロジェクトの管理ツールとして、Pivotal Trackerがちょっと気になっている。このツールは所謂アジャイル開発プロセス向けに提供されていると理解しているのだけれども、個人的にはプロジェクトにはアジャイルウォーターフォールも無いと思っている。というわけで、試しに仮想的なウォーターフォール型(もしくは、ハイブリッド型)のプロジェクトでPivotal Trackerが適用できるのか、ちょっと検証してみようと思う。なお、途中で断念する可能性もある。今回はまず情報収集と事前のリサーチから。

Pivotal Tracker のはじめかた、を読んでみる。

Pivotal Tracker: はじめかた

なんとなくPivotal Trackerの全体像はわかるけど、それだけだったりする。うーん、イメージが湧かない……。

Sonic Gardenさん関連の記事を読んでみる。

チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント - Social Change!

ぼんやりとイメージができてくる。

  • Pivotal Tracker はコミュニケーションツール/仕様管理ツールとしては使わない。タスク管理として使う。
  • 仕様が固まっていないものはアイスボックスへ、プログラマが作業できるものをバックログへ。
  • 動作確認出来る状態になったらプロダクトオーナーがAcceptする。

この時点で考えた利用フローはこんな感じ。

  • いわゆる上流工程、コンセプトの検討段階ではPivotal Trackerは使わない
  • ストーリー(フィーチャ?)が洗い出され始めたら、タイトルを順次アイスボックスに放り込む
    • この時点では仕様は未確定な状態
  • 仕様が確定したらバックログに移す
  • 順次実装・開発者テストする
    • 問題が起こったらバグとしてストーリー追加(ここは少し悩ましい)
  • 動作確認できるようになったら、ユーザーが確認する
    • 問題が起こったらバグとしてストーリー追加

で、このゲームのグラウンドルールはこう。

  • アイスボックスにある全てのストーリーの完成がプロジェクト全体の目標
    • ストーリーの増減は関係者で話し合って管理する
  • アイスボックスにあるストーリーを(仕様を決めて)バックログに移すのはプロダクトオーナー(ユーザ)の責任にする
  • バックログにあるストーリーを(バグも含めて)消化するのはデベロッパーの責任にする

次に以下の記事も読んでみる。

youRoomとPivotalTrackerではじめる無駄のないコミュニケーション | Think IT

うん、あんまりイメージは間違っていないような気がする。あとは試してみないとわからないかな。

@ITの記事を読んでみる。

今回は事前リサーチなので、次に@ITに掲載された以下の記事もチェック。
いまアツいアジャイルプロジェクト管理ツール9選+Pivotal Tracker入門 (1/3) - @IT

  • 公共機関、非営利団体、個人利用、教育機関の場合無償で利用可能らしい。これは有難い。
  • 進捗を確認するチャート機能もあるのか……

というわけでだいたいイメージが湧いてきたので、次回は実際にPivotal Tracker を触ってみて検証をしてみたいと考えている。