チケットがプロジェクトを駆動する #tidd

さかばさんの記事を読んで、チケット駆動の意味を改めて考えさせられた。
以下メモ書き。

【元ネタ】
[#TiDD] チケット駆動開発がもたらすプロセス: ソフトウェアさかば

[#TiDD] チケット駆動開発がもたらすプロセス その２: ソフトウェアさかば

僕の考えでは、アジャイル開発プロセスの基本は小規模リリースであり、その特徴が頻繁なリリースであり、そこにチケット駆動開発が当てはまると思っていた。
つまり、イテレーションありきでプロジェクトが開始すると思っていた。
その意味では、リリース計画駆動であり、本来のXPとは多分違ってくるのだろう。

さかばさんの指摘では、チケットでタスク管理を始めると、チケットに依存した開発スタイルから、チケットを中心とした開発スタイルに変わり、リアルタイムの見える化、スコープのコントロール、プロセス改善、頻繁なリリースが実現されるようになる、という流れ。
多分、その話の方が流れはスムーズだし、現場でも実践しやすいと思う。

まずは、やらなくてはならない作業を全てチケットにまず書き出してみる。
そして、それらチケットを一つずつこなしていく。

すると、毎日の進捗がチケットの集計結果から、いつでも誰でも見えるようになる。
開発者の観点では、自分が担当のチケットの予定が見通せるので、作業しやすくなる。
チームの観点では、いつまでに何を作るべきか、というゴールがはっきりしてくるので、マイルストーンを立てやすくなる。
この点が、メンバーとプロジェクトの2階層のプロセスという意味。

そして、各メンバーの作業量が見える化されるので、たくさんのチケットに優先順位をつけたり、作業順序を替えたり、アサインを変えたりする。つまり、自然にスコープをコントロールするようになる。
ある程度まとまった単位のチケットが終了すれば、一つの機能が動作できるわけだから、リリースして顧客に受け入れてもらえばいい。
リリース時期を遅らせるほど、本来発覚すべきリスクが先延ばしにされるので、リスクが大きくなる。だから、定期的に小さくリリースすることで、チームが許容可能なリスクは受け入れて、大きなリスクにならないように調整するわけだ。

そして、朝会やふりかえりミーティングで、チームのゴールや各人の役割や作業を確認するようにすれば、チームの中で自然な役割分担と運用ルールが生まれる。
メンバーの能力に見合った運用ルールでしか結局作業できないから、現場中心のプロセス改善になる。

定期的なリリースが怖くなくなれば、リリースするサイクル(イテレーション)を短くしながら頻繁にリリースしていけばいい。
チームの許容可能なリスクが以前よりも大きく取れるなら、故意に早めにリリースして顧客のフィードバックを早めにもらって、修正していく手法も取ることができる。
つまり、チームが許容可能なリスクのサイズとイテレーションの期間は反比例する。

頻繁にリリースするようになれば、いつ何をリリースするのか、というリリース計画が重要になってくる。
顧客から届いた仕様変更をどのタイミングでリリースすべきか、システムとの整合性やメンバーの作業負荷を考慮しながら、リリース計画を頻繁に修正して、現実に見合った内容に変えていく。

さかばさんの話では、チケット駆動開発はまさに「チケットがプロジェクト内部の作業を生成して、メンバーもチームもチケットを共有して、リスクベースでリリースしていく」開発スタイルになる。
確かにこの話の方が、「チケットファースト」からチケット駆動開発のプラクティスやチケット駆動開発の特徴を説明できるからいいかもしれない。