チケット駆動開発を上手に運用するためのポイント

倉貫さんがチケット駆動開発を上手に運用するためのポイントを公開されていたのでメモ。
実際の経験に裏打ちされているだけあって、とても参考になる。

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

高速で無駄のないソフトウェア開発を実現するための7つのポイント - Social Change!

【1】役割分担

(引用開始)
Pivotal Trackerを使う役割はざっくり分けると２つです。一つは、開発のためのチケットを登録して、開発されたチケットを「Accept」して終わらせる役割と、もう一つは登録されたチケットを開発していく役割です。前者をプロダクトオーナー、後者をプログラマと呼んでいます。
(引用終了)

倉貫さんの指摘では、顧客がプロダクトーナーの役割を持つので、経営戦略から仕様を決定できるストラテジスト、システムの実現可能性も検討できるアーキテクトの役割を持つ。
そのため、プロダクトオーナー自身が仕様(ストーリー)をチケットに登録し、承認する役割も担う。
この考え方で実際のプロジェクトに応用すると、顧客はかなり大きな権限を持つことになる。
ユーザ企業がSIに丸投げするような受託開発では、多分運用できない。

RedmineなどのITSでは、管理者・開発者・報告者のロールが普通だ。
管理者はITSそのものの管理者だったり、チケット管理の最終責任者の役割を持ち、普通はプロジェクトリーダーが相当するだろう。
開発者ロールは、開発チームのメンバーに相当する。
報告者ロールは、障害報告や機能改善の要望をフィードバックする役割を持つ。

つまり、既存のITSのロールでは、顧客に相当する役割は報告者ロールという受け身の役割しかない。
顧客自身が要件や仕様を決めて、それらをタスクに細分化する所までの権限を持たせるならば、管理者ロールも必要になるだろう。

そもそもITSは障害管理から発展してきた経緯ゆえに、チーム外にいる顧客(プロダクトオーナー)や会社の上司(プロジェクトオーナー)はITSに関わらないのが前提になっている。
チケット駆動開発で弱い部分があるとすれば、チーム外にいるプロダクトーナーやプロジェクトオーナーをどのようなロールに当てはめて、チケット管理をどのように運用したらよいか、をプロセス化してITSへ実装する必要があるだろうと思う。

(引用開始)
ソニックガーデンの場合だと、youRoomを使って常時コミュニケーションをとれるようにしていて、youRoom上でのディスカッションの結果、チケット化することが多いです。私たちはチケット化することを「Pivo化」と呼んでいます。
(引用終了)

チケットとは別の機能で、タスクという観点ではなく、ラフなアイデアを元に議論した結果をチケット化する運用も出てくる。
この時、チケットと過去の議論を連携できるようにしておけば、後からWebで検索できるから、理解しやすくなる利点がある。

redmine.orgの運用を見ると、フォーラムで議論した結果、新しい機能を追加して欲しいとか、こんなプラグインがあったらいいな、など、色んなアイデアがチケットへタスク化される運用になっている。
僕のチームでは、phpBBという掲示板システムで別に議論していたり、QAや気づきというチケットで議論するようにしたが、多分色んなやり方があるだろう。

Rxtstudyの感想: プログラマの思索

【2】チケットの粒度

(引用開始)
ソニックガーデンでの基本的なルールは、プロダクトオーナーにとって意味のある粒度にする、ということです。どんなチケットもプロダクトオーナーが最終的には「Accept」か「Reject」する訳なので、そこが判断できることがチケットの絶対条件になります。
なのでチケットを切る際のポイントは「Accept」の条件が何かを、プログラマと合意しておくということです。その上で、なるべくチケットの単位を小さくするようにします。
(引用終了)

チケットの粒度の問題は、チケットの完了条件に密接に関わる。
Scrumで言う「Doneの条件」に相当するだろう。
チケットをスムーズに完了できるようにするには、チケットのスコープは小さい方がやりやすい。
チケットに書かれた作業内容が小さいほど、完了できたのか、未完了なのか、の判断はつきやすいからだ。

上記の指摘で興味深いのは、「プロダクトオーナーにとって意味のある粒度にする」という点だ。
つまり、顧客視点の粒度にするため、開発者視点の作業内容や作業スコープにはならない。
「A001～プログラムを実装する」などのチケットではなく「注文ボタンを押下する時に～という警告メッセージを出す」というチケットのように、ユーザ視点の内容になるだろう。

但し、上記の記事では、チケットの粒度がどうしても大きい場合、開発者視点のチケットはTASKSで子チケット化する運用をしているようだ。
Redmineなら親チケット＝ストーリーカードのタスク、子チケット＝タスクカードのような視点になるだろう。

また、ユーザ視点ではないものの、アーキテクチャ上どうしても必要なチケットは、Choreというカテゴリで追加する運用をしているらしい。
実際、ビルド環境を作る、フレームワークのVerUpに対応する、テストのために移行データを準備する、などのようにユーザ観点の機能レベルではなく、開発をスムーズに行うために必要なタスクは多い。
その場合、チケットのカテゴリという属性で、ユーザ観点ではないタスクを登録する運用にしているらしい。

僕のチームでは、上記のような状況では「管理」「準備」などのトラッカー(チケットのワークフローの単位)を作って運用していたが、チケットのワークフローは普通のタスクと同じなので、まどろこしかった。
だから、倉貫さんのような運用の方がやりやすいように思う。

【3】チケットを仕様にしない

(引用開始)
ソニックガーデンでは仕様はソースコードだとしています。チケットを仕様にしていません。チケットはあくまでこれから作ろうとする作業について書かれているだけです。その瞬間は仕様かもしれませんが、ソースコードに落とし込んで、アクセプトされた瞬間に正しい仕様はソースコードになるというイメージです。
もし、仕様をソースコードとは別で管理したいというのであれば、それはチケットとは別の仕様書という形で別のドキュメントを用意すると良いでしょう。あくまでチケットは前に進めるためのもので、正しさや厳密さを求めるものではない、というスタンスでいます。
(引用終了)

チケットをストーリーカードとして扱う場合、チケットに仕様を書いてしまいがちだが、あくまでどんなタスクなのかに注力して書いて運用するほうが良いという指摘。
僕はチケットをXPのタスクカードのように扱う運用が一番スムーズと思っているが、ストーリーカードとして扱う場合も細かな仕様はチケットではなく別のドキュメントないしWikiにまとめて参照する方が良いのだろう。

(引用開始)
プログラマにとっては、書かれた通りに作ることよりも、なぜ必要なのかを知った上で実現方法を考えながら作る方がクリエイティブですし、実際に作られるものも、本質的に価値のあるものができあがります。チケットになる前のWhyが重要です。
(引用終了)

チケット駆動開発がスムーズに運用できるようになると、ソース修正の時に過去の変更履歴を開発者自ら調査してくれるようになる。
ITSは全文検索機能が強力だし、チケットとソースのリビジョンが連携する機能もあるから、変更履歴を追跡できる環境が揃っているからだ。
システム開発のほとんどの作業は仕様を詰めていく作業であり、仕様を確定するには、何故そんな仕様になったのか、という経緯を踏まえる必要があり、それが変更管理というプロセスになる。
チケット駆動開発は、変更管理を強化してくれるインフラなのだ。

(引用開始)
厳密性とは少し異なりますが、どれだけのチケットをすることで全体像のうち、どこまでが進んでいるのかを知るための機能として、Pivotal Trackerには「EPICS」というものがあります。これは、最近追加された機能で、これまではラベルで表現していたものを一覧で見えるようにしたものです。
EPICSには大きめの機能群として登録しておき、そこにチケットを紐づけていくことで、それぞれの機能群がどれだけ進んでいるか、消化されたチケットと消化されていないチケットでわかるようになっています。
(引用終了)

「アジャイルな見積りと計画づくり」では、ストーリーの種類として、エピックやテーマが紹介されている。
エピックは、ストーリーより大きな粒度のストーリー(叙事詩、大長編)。
テーマは、リリース計画で見積りしやすくするために、複数のストーリーをまとめたもの。
上記の運用を推測すると、より大きなストーリー(機能)の単位で関連するストーリーのチケットをまとめておき、後から進捗が分かりやすくする運用なのだろう。
つまり、エピックとテーマの機能を兼ねたものと思える。

そして、Pivotal Trackerがエピックやテーマの機能をチケットの一属性として実現しているのが興味深い。
つまり、チケットの親子関係という複雑な機能ではなく、チケットの属性として集計できる仕組みにしている。
チケットの属性による集計の方が簡単だし、後から修正するのも楽だ。

【4】とにかく前に進める

(引用開始)
また、プログラマ側も完璧を目指すよりも前に進むことを重視します。チケットのWhyを理解して、その目的がほぼ達成できるのであれば、そのチケットの詳細にこだわって100%にするために時間をかけすぎなくて良いと判断します。80%くらいが着地点でしょう。
では残りの20%はどうするのか。これもまた別のチケットとして登録します。プログラマが自主的に分割して別のチケットにする訳です。分割したことをプロダクトオーナーと確認して、納得のいくレベルを目指して着地させる訳です。残りの20%のチケットはアイスボックスに入れておけばよくて、おそらく実装することはないでしょう。
Pivotal Trackerの特徴の一つは「アイスボックス」と呼ばれる一覧があることです。アイスボックスに何をいれるかというと、仕様が固まっていないものや、これから先やりたいと思っていることなど、つまり何でも入れていい訳です。逆に仕様が固まってもいないのにバックログに入れるのは良くないですね。プログラマが作業できないからです。
(引用終了)

上記の運用では、開発のスピードを重視するために、チケットの完了基準をやや緩めているようだ。
チケットの完了基準をきちんと守るのは、実際の運用では結構難しい。
【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索では、チケットの完了基準が曖昧なアンチパターンとして「停滞したチケット」を記載した。
例えば、進捗率が90％のまま停滞しており、いつまで経ってもチケットを完了できない状況(コンテキスト)に相当する。

その原因の殆どは、リファクタリングと新規機能の追加の作業が混じっているために当初の見積よりも工数がかかってしまったり、機能はほぼ動く所まで完了しているのに細かな仕様の不明点が残っているために完了できない場合が多い。
だから、チケットを分割したり、仕様の不明点は課題チケットとして別に切り出して、元のチケットはCloseさせるという運用を行ったりする。

上記の指摘では、残りの20％の不明点はアイスボックスにチケットとして入れ、必要になるまで放置する運用を勧めている。
この運用方法は、現実的な運用だと思う。
結局、チケット管理で何を価値とするか、という価値観に基づくから。
上記の運用方法では、現場のルールにこだわってガチガチに守るよりも、シンプルに運用して「価値あるソフトウェアをいち早く届けること」を重視している。

以上の考え方もチケット駆動開発のブラッシュアップに役立ててみる。