Pivotal Trackerとredmineの違い
Rxtstudyで@kuranukiさんが「RedmineからPivotal Trackerへ乗り換えた」話をしてくれた。
考えたことをラフなメモ書き。
間違っていたら後で直す。
【元ネタ】
Pivotal Tracker - Simple, Effective Agile Project Management & Team Collaboration, from Pivotal Labs
Pivotal Trackerの「Getting Started」を翻訳しました - Ruby x Agile
Twitter / @minitau: ICEBOX -> BACKLOGに移動して、BACKLOGでステータスをいじる #RxTstudy
Twitter / @sousoumt: @@kuranuki さんに補足:Pivotal TrackerでのICEBOX : チケットの冷蔵庫。いつかやるよ、的なリストです。 #RxTstudy
Twitter / @kiyotune: チケットのゴミ箱化 #RxTstudy ゴミ箱だったら捨てればいいじゃない
@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のチケット管理で実現できると思っているので、そのアイデアをもっと色々試してみたいと思っている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「Redmine」カテゴリの記事
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
コメント