Pivotal Trackerの4つのトラッカー

もう一度、Redmineでアジャイル開発が可能かどうか、フィットギャップ分析している。
僕はPivotal Trackerを仕事で使ったことがないので、あくまでも理解した範囲内で、考えたことをメモ書き。

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

Pivotal Tracker: はじめかた

ユカイ、ツーカイ、カイハツ環境！（27）：いまアツいアジャイルプロジェクト管理ツール9選＋Pivotal Tracker入門 (2/3) - ＠IT

Redmine Backlogsで簡単スクラム！プロダクトオーナーとして使う編 | 世界はどこまでもシンプルである

(引用開始)
ただし、Pivotal Trackerでは［Chore］［Bug］にポイントを付けることを強く否定しています。ひと言で理由を説明すると、［Chore］［Bug］はビジネス価値を提供しないからです。
(引用終了)

(引用開始)
作業(Chore) は必要ではあるものの、顧客の価値に直結しないストーリーです。たとえば「位置情報サービスへのサインアップ」「自動テストが長時間かかる原因を探し出す」などが作業です。作業には「コードの技術的負債」や他のチームに依存する箇所をあらわすことにも示せます。
(引用終了)

(引用開始)
そういった場合は、Pivotal Trackerではストーリーのカテゴリーに「Chore」と呼ばれるものがあり、それを設定します。歯車のアイコンで記されたChoreのチケットは、アクセプトが不要のワークフローが設定されています。つまり、プロダクトオーナーには関係なく、プログラマの作業が終わったら、それで終了になります。
(引用終了)

【1】Redmineでチケット管理をやり始めると、必ず問題になるのが、チケットの粒度だ。
特に、チケットをタスクカードと見なす場合、個人のToDoまで書くべきかどうか、必ず問題になってくる。

本来は、チケットはチームで共有すべき作業や課題を書くべきであり、自分一人だけのToDoはチケットに書く必要はない。
自分一人だけの作業までチケットに記載し始めると、チケットの枚数が極端に増えるデメリットがあるし、チームでチケットの棚卸しをする時にそれが対象になるのはおかしい。
でも、自分の忘れたくないタスクをチケットに書きたい時もある。

一つの解決方法は、Redmineのプライベートチケット機能を使って、自分だけのToDoは他の人に見せず、自分だけで管理するやり方がある。
そうすれば、他の人はプライベートチケットは管理の対象外になる。

もう一つの方法は、PivotalTrackerのように、内部タスクや顧客に価値を提供しないタスクは、別のトラッカーとしてチケットに登録するやり方もある。

【2】Pivotal Trackerには、Feature、Bug、Chore、Releaseの4つのトラッカーがある。

PivotalTrackerでは、顧客に価値を提供する作業は、Featureというトラッカーになり、ストーリーポイントによる見積り対象になる。
Featureのチケットは、プロダクトオーナーがストーリーをバックログに入れて、プログラマが上から順に取り出す。
プログラマがFeatureのチケットをDoneしたら、プロダクトオーナーにAcceptされて、OKならばリリースされて終了するし、NGならRejectされてPGへフィードバックされる。

一方、内部タスクを意味するChoreは、顧客に価値を提供しないタスクを意味する。
例えば、開発環境を作る、フレームワークをバージョンアップする、データ移行する、など、開発にとって重要だが、顧客にとっては価値とは思えないタスクを意味する。

ChoreのチケットはPGが自らチケットを作れるし、PG自らがDoneできる。
つまり、Choreのチケットの完了条件はプロダクトオーナーの承認が不要。

さらに、Choreのチケットはストーリーポイントによる見積り対象外になる。
なぜなら、顧客に価値を提供しないタスクなので、見積りに入れると、顧客の価値のサイズが狂ってしまうからだ。

すなわち、FeatureとChoreのチケットはトラッカーが異なるし、ワークフローも異なる。

【3】Redmineでも、Pivotal TrackerのFeatureとChoreの違いを取り入れて、チケット管理してもいいだろう。
その場合、トラッカーを区別し、ワークフローも区別する運用が良いだろう。

Pivotal Trackerを見ると、改めて、よくできているタスク管理ツールだと思う。
UIが直感的で、複雑な機能もない。

また、ストーリーポイントによる見積りを入力できるので、各スプリントのVelocityを収集できる。
過去の実績のVelocityが溜まってくれば、次回のスプリントでチームがどれだけのアウトプットを期待できるか、予測しやすくなる。
Pivotal Trackerが単なるタスク管理ツールだけでない理由は、Velocityを収集できるので、スプリントの見積りの精度が上がることと、それによってスプリント計画を立てやすくなることがあるのだろう。

この点は、WF型開発やPMBOKよりも優れている点だろうと思う。
WF型開発やPMBOKでも、PDCAサイクルを短く回す方法を何とか編み出そうとしているが、手続きやプロセスが重量過ぎることと、計画からリリースまでのサイクルが長すぎるために計画の変更がやりにくいことが弱点になるだろう。
実際、計画を変更しようとしても、過去の実績の数値は前工程の情報に過ぎず、後工程の見積りに使いづらいからだ。

【4】後もう一つの解決方法は、RedmineのBacklogsプラグインを入れて、RedmineでScrumを運用することだ。
Backlogsプラグインを入れれば、プロダクトバックログやスプリントバックログを管理できるし、親チケットをストーリー、子チケットをタスクとして登録できる。
また、課題はImpedimentとして、別のトラッカーとして管理できる。
さらに、ストーリーは予定工数で見積り可能なので、Velocityを計測することも可能だ。

【5】Redmineでアジャイル開発を実践する場合、基本はチケット駆動開発で十分に対応できると僕は思っている。
しかし、あえて弱点があるとすれば、下記3点があると思う。

1)チケットの粒度にバラつきが出やすい。
本来は、ストーリーカードとタスクカードは親子チケットにし、内部タスクは別トラッカーで管理するなどの工夫がいる。

2)チケットに優先「順位」を付けることができない。
Redmineチケットのデフォルト機能である優先度は、正直使いづらい。
「最優先」のチケットが2枚以上ある事実は基本はありえないから。
そうだとしたら、優先順位を付けていないのと同じ。

3)Velocityを計測しにくい。
予定工数、実績工数を入力し始めると、作業者はどうしてもバイアスがかかってしまい、予定工数を多めに余裕を持って見積もってしまいがち。
すると、その予定工数は余裕時間が多すぎて、正しい見積もりにならない。

いずれの弱点も、BacklogsプラグインやPivotal Trackerの良い部分を真似るのが一つの解決策。

この辺りをもう少し考えてみたい。