[#TiDD] チケット駆動でAdaptable Waterfall開発！

前に書いたようにチケット駆動揮発の特徴はプロジェクト改善です。そのプロセスはアジャイル的で、アジャイル開発においても効果的であるほか、従来型の開発においても管理上の問題を補完して効果を発揮するものです。これらはそれぞれ、完全型、補完型のチケット駆動開発と呼ばれています。ここでは、補完型のチケット駆動開発をAdaptable Waterfall 開発として再定義したいと思います。

１．Extreme Waterfallの限界

品質管理を強化した日本的な従来型開発をExtreme Waterfallと呼ばれています。実装に至るまでの課題をあらかじめ検討しておいて、定量的な数値(メトリクス)を用いて管理することで安定した開発を行うというものです。

このような従来型の開発において混乱の原因となるのが、仕様変更や予想外の不具合、実行環境の変化です。これらは、昔からある混乱原因です。それぞれ変更管理、障害管理、課題管理として帳票で管理され、それらの具体的な作業計画と実施が行われることで、一定の成果を上げていました。

しかしオブジェクト指向技術の発展、フレームワークなど開発環境による生産性の向上、ハードウェアの性能向上によって、対象業務の多様化、実現する機能数の増大、想定外の事象の多発という事態が恒常化しています。そして開発スピードの向上も伴うことで、帳票による管理は限界に達しています。

そこで、チケット駆動開発によって従来型開発の適応力を向上させます。仕様変更や不具合、想定外の事象をチケットで管理するのです。帳票による管理では難しいこれらの作業を、チケットに一元化し、リアルタイムな情報の共有と管理を可能にします。

従来型の開発では仕様変更や追加の作業を厳密に管理することで、プロセスの安定化を図っていましたが、その管理をBTSのチケットで効率化してAdaptable Waterfall開発を実現するのです。

２．なぜ、アジャイル開発できないのか

繰り返し開発やアジャイル開発では、仕様変更を受け付けるタイミングを明確にすることで、仕様変更を制御しています。開発を混乱させないために、それぞれのイテレーションには、変更の取り入れ、変化する作業の管理、リソースの配分、リリース、という一連のプロセスが必要です。

しかし、それは時として困難な場合があります。たとえば以下のような場合です。

(１) 作業を開始するには一括承認が必要
開発チームとシステムを企画・予算化する部門が異なるなど、予算を決済する権限が開発チームから遠い存在の場合、開発中のソフトウェアの仕様(スコープ)を随時変更することが困難になります。

(２) 他のシステムとの連携や必要なデータの入手が開発終盤になる：
連携する複数のシステムが並行開発される場合や、別チームで画面デザインが行われるなど、実装を優先することが困難な場合があります。特にハードウェアとの並行開発では仕様変更が難しい場合があり、仕様段階での検証に多くの時間が取られます。

(３) 機能の実装に必要なタスク集合の粒度が大きい：
タスクの分解が可能であってもタスク間に順序性があり、一つの機能の実装期間が長期になる場合、どうしても段階的な開発になってしまいます。仮に見かけ上だけ繰り返し開発を行ったとしても、その機能の取捨選択は初期のイテレーションでのみ可能です。

このように適度な粒度の実行可能なタスクの集合でない場合、アジャイル開発は困難です。

３．Adaptable Waterfall

そこで、現状の問題を解決してくれるのが補完型チケット駆動開発です。補完型チケット駆動開発では、計画外の作業をチケットで管理することで、従来型の開発を補完してAdaptable Waterfallを実現します。

チケットで仕様変更や障害を管理できるほか、それらを具体化したタスクや想定外のタスクを管理することができます。チケットの更新は関係者に通知され、リアルタイムな情報が共有されます。チケットは実現可能な期限と担当者が記録され、プロジェクト全体や担当者ごとの一覧、ガントチャートなどの形で可視化されます。チケットは、進捗率だけでなくその状態でも管理されます。チケットの種類によって状態を変更可能な権限が決められていますので、レビューの徹底や他のチームとの連携といったことも容易になります。

チケットは情報の中心であり、開発を助けます。チケットには、上記の情報のほか、関連する議論やチケットの詳細を表す様々な属性が記録されます。これらのの変更や、関連するソースコードの変更などもチケットに記録され、プロジェクト改善につながる現状分析のほか、障害発生時の参考情報になります。

Waterfall開発をAdaptableにする上で重要なものにリリース計画があります。原理主義的なWaterfall開発では開発の最後に一度だけリリースが計画されますが、必ずしも現実的ではありません。仕様書に表しきれない挙動を確認するには、なるべく早くユーザに操作してもらうことが効果的です。また、複数システムで連携する場合には、現物による早めのすり合わせは欠かせません。このような外部組織へのリリースなど、目標となるタイミングをマイルストーン(あるいはバージョン)として定めます。

プロジェクト全体を繰り返し開発にできない場合でも、段階的なリリースをマイルストーンと定めることは重要です。チケットはマイルストーンごとに一覧や集計ができますので作業の遅延が見える化されるほか、開発者のモチベーションに大きくかかわります。「今のうちに早く帰ろう」という発想は遅延が顕在化しないからできるのです。制約に合わせて作業を適切に配分し、見える化することが大切です。

４．まとめ

このようにアジャイル開発でなくても、あらかじめ計画が困難な、仕様変更、障害、想定外の作業をチケットで管理して、適切なリリース計画を立てれば、従来型の開発を改善することができます。それは、組織プロセスとしてだけでなく、進行中のプロジェクトの改善としても可能なものです。今のプロジェクトではアジャイル開発を実践できないから、とあきらめるのではなく、問題を見極めた上でチケット駆動開発を導入すれば、きっとより良い開発が実現できると思います。

今のところ唯一のチケット駆動開発の本です。