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のチケット管理で実現できると思っているので、そのアイデアをもっと色々試してみたいと思っている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント