Pivotal Trackerとredmineの違い

Rxtstudyで@kuranukiさんが「RedmineからPivotal Trackerへ乗り換えた」話をしてくれた。
考えたことをラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
Pivotal Tracker - Simple, Effective Agile Project Management & Team Collaboration, from Pivotal Labs

Pivotal Tracker: はじめかた

Pivotal Trackerの「Getting Started」を翻訳しました - Ruby x Agile

Twitter / @minitau: ICEBOX -> BACKLOGに移動して、BACKLOGでステータスをいじる #RxTstudy

Twitter / @sousoumt: @@kuranuki さんに補足：Pivotal TrackerでのICEBOX　：　チケットの冷蔵庫。いつかやるよ、的なリストです。　#RxTstudy

Twitter / @kiyotune: チケットのゴミ箱化 #RxTstudy ゴミ箱だったら捨てればいいじゃない

Twitter / @sakaba37: @kuranukiさんのお話は1-2日のストーリーカードの管理だけで回せるというのがポイントかと RT: @yusuke_kokubo: 特にこだわりがなければ、Redmine+BacklogsよりもPivotal Trackerの方が自前の環境もいらないし簡単だし良いよね。

Twitter / @akipii: @kaorun55 @kuranukiさんのプレゼンを見た限りではIcebox(要望の貯蔵庫)→Backlog(ユーザが要望を順位付け)→Taskboards(メンバーが要望を取る。ユーザの受入チェックも含む)でチケットが流れます。#Rxtstudy #redmine

@kuranukiさんの話は、ソフトウェア開発をサービス業にするためのビジネスを自ら経営者で実践されているだけあって、とても説得力がある。
SKIPやYouroomのサービスのタスク管理では、RedmineからPivotal Trackerへ乗り換えたとのこと。

Pivotal Trackerのプレゼンを見て、Redmineよりも優れている点はいくつかある。
一つは、Icebox→Backlog→Taskboardsへチケットが流れることで、ユーザと開発者のビューをうまく切り替えていること。

Iceboxは冷蔵庫の比喩で、料理(システムのリリース)の前に、材料(要望)を冷蔵庫へ保管するように、要望(ストーリー)を入れておく貯蔵庫。
そして、ユーザはリリースしたい要望をIcebox(要望の貯蔵庫)から取り出して、Backlog(まな板)へ移し、上から順に優先順位を付ける。
開発者は、Backlogの要望を上から順に取り出してTaskboardsへ移動して実装していく。
Taskboardsでは、要望のステータスは完了・未完了のBooelanしかなく、実装が終われば完了ステータスに更新されて、ステージング環境(UAT：受入テスト環境)にリリースされる。
ステージング環境へリリースされた要望は、リリース確認前(？)という赤色のステータスになり、ユーザの受入テストの評価を待つ。
ユーザはステージング環境でリリースされた要望を確認して、OKなら、リリース済みの緑色のステータスに変わり、NGなら、フィードバックで赤色のステータスになり開発者へ差し戻す。
そして、受入OKとなった要望は本番環境へリリースされて終わる。

つまり、要望と言うチケットを作って初めてリリースの対象が分かり、リリースの順位が決まって、実装されてリリースされる。
@kuranukiさんはそれを「No Ticket, No Release! 」と呼んでいたのが印象的。

Pivotal TrackerがRedmineよりも優れているもう一つの点は、下記で言い尽くされている。

Twitter / @akipii: #RxtStudy　Redmineの優先順位はカテゴリで、ソート順が出ない。進捗も％は不要で、Boolean(未完了・完了)のみで十分。

Redmineのチケットには優先度があるが、「緊急」「高」「中」「低」などのカテゴリであり、作業の優先順位でソートされていない。だから、開発者はチケット一覧でどのチケットから作業すればいいのか、逐一指示を仰がないといけない。
また、Agile開発ならDoneの基準はとても明確なので、Boolean(未完了・完了)で十分だ。
わざわざ進捗率や複雑なステータスは必要ない。

但し、Pivotal Trackerを運用するには、いくつかの前提(コンテキスト)も必要。
@sakaba37さんが言うように、Pivotal Trackerでは全てのチケットは要望(ストーリー)であり、1～2人日程度で粒度がとても小さい。
自社のパッケージ製品のようにシステムを知り尽くしているなら、ストーリーを細かく刻むこともできるだろうが、いつもそのパターンで開発できるとは限らない。
RedmineのBacklogsプラグインはScrumの技法をそのまま反映しているので、ストーリーカードを更にタスクカードに分割してスプリント単位にリリースしていくから、Pivotal Trackerの運用フローとは異なる。

Twitter / @yusuke_kokubo: http://t.co/6J3Tsp7 Redmine Backlogsプラグインを試してみたい人はこちらからどうぞ

また、Agile開発に特化しているので、バグチケットを後から障害分析するためにチケットにたくさんの属性項目を追加することもできない。
ワークフローもシンプルだから、Agileな開発なら威力を発揮するが、インフラチームの課題管理や顧客からのインシデント管理に使うのには不向きだろう。

そういう前提を考慮しても、使いやすそうなUIなので、使ってみると面白いかもしれない。

ただ、僕自身はSW開発に現れる全ての作業(開発だけでなく、運用保守や課題管理、問合せ管理など)をRedmineのチケット管理で実現できると思っているので、そのアイデアをもっと色々試してみたいと思っている。