WF型開発にとらわれすぎたTiDDのアンチパターン #tidd

チケット駆動開発を運用してみて、悪いWF型開発のアンチパターンを頻繁に見かける。
考えたことをメモ。

【1】WF型開発がうまくいっているプロジェクトは、手戻り作業をできるだけ減らすように、前工程の品質チェックに力を入れる。
過去の経験値が生きる場合、いわゆるフロントローディングのやり方は有効に作用する。

しかし、僕はWF型の開発スタイルで上手くいった経験はあまりない。
ソフトウェア開発では、技術革新のスピードが早いため、過去の経験値が有効に作用せず、試行錯誤する回数がとても多い。
WF型開発が前提とする手戻り作業を減らす手法は、あまりにも綺麗過ぎる。
試行錯誤やリスクをあまりにも恐れている気がする。

Redmine・Trac・Mantisでチケット駆動開発をやってみると、リリースに至るまでの作業はいつも初めての問題にぶつかって試行錯誤して、どのイテレーションでも同じようにはならない。
チケット管理は結構泥臭い。

でも僕はそれでいいと思う。
100％計画通りにプロジェクトが進むようなら、それはルーチンワーク。
チケット駆動開発上でAgileに開発していると、アウトプットを少しずつ出しながら、目の前の大きな問題をいきなり解決するのではなく、問題のサイズを少しずつ小さくして、最終的に解決できるようにしていく。

【2】RedmineやTrac、Mantisでチケット駆動開発を運用して上手くいっていないチームを見ると、普通は、バージョンやロードマップの機能を全く使っていない。
だから、いつ何をリリースするのか、という基準がないために、数百枚のチケットを精査するのに難儀している場合がとても多い。
つまり、リリース計画がないので、本番リリースは1回だけと想定しているようだ。

そのアンチパターンの具体例は下記に書いた。

バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索

TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない: プログラマの思索

日本のWF型開発は、経産省が出した共通フレームでフレームワーク化されており、そこでは、本番リリースが1回なんて書いてはいない。

「共通フレーム2007 第2版」の発行

でも、開発チームの中にいると、最後の本番リリースだけのために作業して、リリース後の作業はあまり考えていないメンバーがとても多い。
本番リリースさえ終われば全て丸く収まることはありえない。
リリース後にユーザが実際に使って、障害や改善要望が上がって、それらに対処して、少しずつ改善していくサイクルが必要なのに。

多分、受託プロジェクトでは、開発工程とテスト工程に大量の開発者が動員されて、リリース後はプロジェクトから離れる開発者が多いため、本番リリースは1回だけで終わりという雰囲気になってしまうのだろうと推測する。

【3】また、WF型開発の概念にこだわりすぎて、RedmineやTrac、Mantisによるチケット駆動開発がうまくいっていないチームもよく見かける。
悪いWF型開発に囚われたチームは、Redmineバージョンを工程単位に作ったり、Redmineプロジェクトを工程単位に作ったりしている。
そのアンチパターンについては下記に書いた。

TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

工程単位にバージョンを作った場合、要件定義バージョン、設計バージョン、開発バージョン、結合テストバージョンのようになる。
すると、レビューや障害修正のたびに過去の工程のバージョンにチケットが追加されて、手戻り作業が発生する度にバージョンがReOpenされてしまうため、いつまで経っても、どのバージョンもCloseされない。
つまり、バージョンがイテレーションに対応していないため、ズルズルと納期が伸びる。
バージョンを工程単位にアサインしたロードマップは、そもそもリリース計画ではないのだ。

又、大規模プロジェクトで工程単位にRedmineやMantisのプロジェクトを作った場合、要件定義プロジェクト、設計プロジェクト、開発プロジェクト、結合テスト障害プロジェクトのようになる。
要件定義や設計プロジェクトでは、チケットのカテゴリを各チームに対応付ければ、課題管理に使えるので、最初は問題ない。

しかし、レビューや障害修正、後になって判明した仕様変更が起きると、手戻り作業が発生するので、どのプロジェクトにチケットを登録したらいいか分からなくなる。
例えば、障害の修正では、当然、設計書も修正するし、修正モジュールも検証するし、障害調査で新たな課題が出てくる時もある。
それらチケットは各工程のプロジェクトへバラバラに登録されてしまうので、タスクも管理しづらくなる。
つまり、各工程のプロジェクトのロードマップは、一つの製品のリリース計画になっていないので、成果物の変更履歴を追跡しづらい。

工程単位にバージョンやプロジェクトを作る場合も同様に、作業やリリースの判定基準、リリース計画があいまいだ。
設計をきちんとやってから開発して、全部ソースを書き終わったらテストを開始するという綺麗なやり方に固執し過ぎている。

【4】悪いWF型開発の最大の特徴は「工程単位に綺麗に開発して本番リリースは最後の1回だけ」という点に尽きると思う。
本番リリースが1回だけなので、頻繁にリリースしながら機能も品質も改善していくという小規模リリースの発想がそもそもない。
だから、イテレーションという概念が発生しない。

イテレーションという概念がない特徴から出てくるアンチパターンは下記に書いた。

TiDD初心者が陥りやすい罠～バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

イテレーションの考え方は締め処理と同じ: プログラマの思索

イテレーションがCloseされるタイミングで、終了チケットの実績工数やシステム規模が確定する。
すると、そこからScrumが発見したVelocityという概念が出てくる。
つまり、イテレーション単位の開発チームの生産能力が確定する。

XPやScrumが教える所では、開発チームの生産能力は安定すべきものであり、増やすべきものではない。
マネージャは、1イテレーションの作業量を2倍くらいに増やしたくなるが、そうするとメンバーを増やす対策をとる時が多く、それはチームに混乱をもたらす。
人月の神話で知られているように、チームの人員が増えるほど、開発チームの生産能力は逆に落ちていく。

WF型開発では、イテレーションという概念がないのでVelocityを収集しにくい。
だから、チームの生産能力が分からないので、普通は作業負荷が大きくなりがちで、メンバーに残業や休日出勤を強いる。

【5】チケット駆動開発はおそらく、どの開発プロセスでも、どの業界でも適用できるだろう。
その場合、チケット駆動開発の運用例から、どのような特徴が見えてくるのかを色々調べてみたい。