チケット駆動開発が進むべき道part4～チケット駆動開発がもたらした新しい観点 #tidd

チケット駆動開発が従来のどんな問題を解決して、どんな新しい観点をもたらしたのか、考えを整理してみる。

【元ネタ】
Twitter / @akipii: ツールの背後にあるチケット駆動開発の意義を汲み取って欲しい。RT @yusuke_kokubo 自分が管理してメンテナンスするならRedmineだけど自分が使う側だったらTracでもJIRAでもなんでもかまわない。ちゃんと使えれば

Twitter / @akipii: #redmine ツールの背後にあるチケット駆動開発が従来のどんな問題を解決して、SW開発にどんな新しい観点を提示したのか？を汲み取って欲しいのです。

【1】SW開発の難しさは、結合テスト以降の障害管理ではっきり現れてくると思う。
WF型開発であれAgile開発であれ、ある程度動くモジュールに対して、機能を追加して品質を向上していくプロセスは、そう簡単なものではない。

そもそもBTSを導入していないチームは、バグ情報がメールやExcelに散乱しているから、メンバー同士の情報共有すらできていない。
バグが発生した環境や操作手順を開発者に伝わらないために、バグの再現性に関する議論が延々と続いたりする。

又、せっかく見つけたバグも50個、100個と増えてくれば、バグの担当者はたらい回しにされたり、一部の担当者にバグ修正の負荷が集中したりする。
最悪な場合は、バグそのものが放置されて、どんどんバグが増えてプロジェクトそのものが破綻する。

特に、バグの再現性を確認しても、モジュールがどの時点で修正したバージョンなのか、をきちんとコントロールして検証しないと、バグを直したことにはならない。
ビルド管理、リリース管理で、Excelのソース管理台帳を見ながら、ソースのリビジョン1個ずつに対して手作業でタグ付けする場合、リリース漏れが発生しやすい。
最悪な場合は、ソースが先祖帰りして、せっかく直したバグが再現されてしまうデグレが起きる。そうすると、メンバーのモチベーションがガクンと落ちる。

【2】チケット駆動開発の意義は、それらの問題点に対して、一つの解決方法を示している。

まず、バグだけでなく、プロジェクト内部の作業は全てチケットへ集約する。
実績工数が発生するタスクは全てチケットに起票することで、メンバー全員が作業履歴を残し、それを誰もが検索して共有できる環境を作る。
チケットには作業内容だけでなく、進捗や構成管理の情報も付与するから、ソースからチケットへ変更理由も探すことができる。
それらは「Tikect First」「No Ticket, No Work」「No Tikcet, No Commit」という運用ルールで表現される。

次に、Redmineなど高機能化したITSには、柔軟なワークフロー管理機能がある。
この機能を使えば、バグだけでなく、ソフトウェア開発全般のタスク管理に拡張できる。
つまり、開発や設計書作成、リリース作業、更にはプロジェクト内部で発生した課題、顧客からの問合せ、インフラチームからベンダーへの質問などあらゆる情報は全てチケットに起票できれば、チケットの背後にあるワークフローによって、ステータスが一意に決まる。
バグやタスクだけでなく、問合せも課題もエスカレーションした問題も全て、何らかのワークフローの上に載っているのだから、チケットから最新状態を追跡できる。
TiDDでもっとも有効な隠れた機能が柔軟なワークフロー管理であり「Ticket Tracking」という運用ルールで表現される。

更に、ITS・SCM・CIというツールを組み合わせると、顧客の改善要望から開発、ビルド、リリースまでの作業を一貫して補強できる。
例えば、XPのイテレーション＝Redmineのバージョン＝SCMのリリースタグ＝CIのビルド番号のように連携すれば、リリース済みバージョンが自然にリリース履歴となり、ロードマップはリリース計画、その短期計画が自然にイテレーション計画に対応できる。

【3】ITS・SCM・CIの3つのツールを@haru_iidaさんはSW開発の3種の神器と呼ばれた。
その言葉の背後には、従来のツールを連携して組み合わせると、「No Tikcet, No Commit」のような新しい使い方が生まれて、ソフトウェア開発の生産性を上げてくれる事実を示している。

上田さんはこの事実から、チケット駆動開発はAjaxみたいだね、と言われた。
つまり、チケット駆動開発は、従来から知られている古いツール(BTS)から新しい使い方(Agile開発)を提示したことを言っていると思う。

チケット駆動開発が新しい観点をもたらしたのは、従来のKKD(山勘、経験、度胸)によるプロジェクト管理をツールによるプロジェクト管理へ変換して、ソフトウェア工学に基づいたプロジェクト管理へ脱皮できること。
例えば、BTSにためられたチケットは、集計機能によって、ガントチャートだけでなく、バーンダウンチャート、信頼度成長曲線、PMBOKのEVMなど各種の進捗や品質のメトリクスで出力できる。
それらの情報はプロマネの意思決定をサポートしてくれる。

更には、プロジェクト管理の問題をツールの一機能による実装に置き換えることで、プログラミングの問題に変換したこと。
BTSに機能が足りないと思うなら、実装してしまえばいいだけ。
特にRedmineならRailsで作られているので、テーブル設計もURLも綺麗だから、初心者でもCoCに慣れれば簡単に機能拡張できる。
プログラミングの問題に落とし込めれば、後は実際に動く機能を作ればいいだけのことだ。
Howの問題に変換できれば、Agile開発なら一瞬で問題解決できる。

RedmineでもTracでもMantisでも、チケット駆動開発は実践できると僕は経験した。
それらのツールの背後にはチケット駆動開発があり、チケット駆動開発は、ソフトウェア開発のマネジメントの権限をプロマネからプログラマへ移行させたことに一番意味があると思っている。