プログラマの思索

ストーリー駆動のチケット駆動開発について考えたことをメモ。

【元ネタ】
Twitter / @akipii: ストーリー駆動のチケット駆動開発はチケット管理以上に牛尾さんが提唱されたストーリー供給力とストーリー検証力の方が重要ではないかと最近考えている。ストーリーの整合性、実現可能性、ビジネス戦略の観点＋PivotalTrackerのようなかんばんに近いアジャイル開発の組合せが多分ベスト

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

【1】チケット駆動開発は本来はタスク管理から生まれたし、タスク駆動が一番やりやすい。
でも、チケット駆動開発の面白さは、課題管理やインシデント管理、ストーリー(要件)管理のように、他のやり方にも応用できる点にある。

ストーリー駆動の場合、チケットはストーリーカードと見なす。
実際の運用は、PivotalTrackerやそのRailsクローンFlucrumのように、顧客と開発者が一体になって、チケットを書き起こして作業してリリースしていく流れになるだろう。
そして、タスク駆動のチケット管理の運用ルールが「No Tikcet, No Work」なら、ストーリー駆動の場合は「No Ticket, No Release」(@kuranukiさん談)になる。
つまり、チケットにシステムに実装して欲しい機能を書かなければ、システムに反映されてリリースされないのだ。
顧客がリリースして欲しいと思うならば、まずチケットに書いてもらわないといけない。

【2】ストーリー駆動のチケット管理はまさに典型的なアジャイル開発だが、実際の運用はノウハウがなければ難しいだろうと思う。
その理由はいくつかある。
一つはチケットの粒度が大きいと、進捗管理がやりにくいこと。
この理由は下記に書いた。

Pivotal Trackerとredmineの違い: プログラマの思索

アジャイルに開発したいなら、チケットの粒度は1人日以下になるように、ストーリーを細かく分割しておく必要があるだろう。
すると、ストーリーをそれだけ細かく分割できるくらい、システムや要件を知り尽くしていなければ、そもそも分割すらできないだろう。

2つ目は、アーキテクチャが安定しないと機能改善ではなく障害修正ばかりになってしまいがちなこと。
@Sean_SFさんが似たようなTwitterを述べられている。

Twitter / @Sean_SF: 「いわゆる「チケット駆動開発」はレベルが高い。チケットを発行してまわるぐらいアーキテクチャとプロセスが安定している必要がある。チケット駆動にしたからといってプロセスが安定するわけではない。運用、改善フェーズには良い」 #devsumiC

Webシステム開発の場合、RailsやSeasarなどのように強力なフレームワーク上で細かいUI改善や機能改善が主な作業になるので、ストーリー駆動の開発がやりやすい。
でも、アーキテクチャを一から作るプロジェクトの場合、共通部品がまず揃ってからの開発になる。
それら共通部品を使いながら機能を開発していくが、実際は開発しながら共通部品のバグを見つけたり、共通部品の使いにくい部分を改善してもらったりする場合が多いだろう。
すると、共通部品の修正が発生して、他チームや他の機能まで影響してしまい、プロジェクト全体の開発が遅延してしまいがちになる。
特に製品系列開発や派生開発のように、コア資産をベースに次々に似たような製品や機能を開発していく場合、共通部品やアーキテクチャの信頼性や保守性が高くなければ、ストーリー駆動のチケット駆動開発は安定しないだろう。

【3】3つ目は、ストーリーそのものの品質が悪ければ、思うように開発できないこと。
ストーリーは顧客観点で書かれた要件だから、開発者視点とは違う。
だが、その要件がシステムとして実現可能性があるかどうか吟味した上でストーリーを作るべき。
すると、一つの要件を実現するために、たくさんの要件が芋づる式に出てきたり、既存の機能に影響を与えてしまったりする場合が頻繁に出てくる。
牛尾さんは、AgileTourOsaka2010で「ストーリー供給力」「ストーリー検証力」というアイデアを発表されたが、まさにそういう事象を指していると考える。

Agile Tour 2010 Osakaで講演してきました - メソッド屋の日記

Agile開発に足りないもの～モデリング技術: プログラマの思索

つまり、イテレーションを実施するために必要なストーリーをイテレーション開始前に8割以上は出せるようにする。
この作業が「ストーリー供給力」であり、普通は最初のイテレーション(スパイク)で、実装はせずに要件定義を中心に作業する方法もあるだろう。
そして、供給されたストーリーの整合性を取り、システムとして実現可能かどうか、矛盾していないか、MECEになっているか、などの観点でストーリーを吟味して、ストーリーを整理していく。
この作業が「ストーリー検証力」であり、アーキテクトという役割の人が最も活躍する場でもある。

【4】最近は「アジャイルサムライ−達人開発者への道−」のように、アジャイル開発のノウハウが公開されて、誰でも試せるようになってきた。
ストーリー駆動のチケット駆動開発は多分難しいだろうが、本来のアジャイル開発に近いだけに、是非とも実施できると面白いだろうと思う。