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

TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。

【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。
それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。

話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。
だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。

彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。
どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。

そのチケットはいつリリースするのか？の観点が漏れているみたい。
何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。
だから、担当者やカテゴリで絞ったりして、自分に必要なチケットをフィルタリングしているみたい。
だが、複数の担当者で一つの成果物を作る場合、それらのタスクの依存関係まで考慮されていないようだ。

だから、チケットが乱発されて放置されやすい。
チケットの棚卸が出来ていないみたい。
プロジェクトマネジメントで最も重要な手法であるスコープ管理が意識されていないから、納期までにどれだけのチケットをこなさなければならないのか、という観点が漏れている。
だから、タスク漏れや考慮漏れが多い。
つまり、作業ミスが多発したり、いつまでたってもデグレードしやすい弱点がある。

バージョンが設定されていないから、イテレーションのリズムが無い。
チケット一覧にスクロールできないくらいたくさん残っているチケットを、延々と消化し続けなければならない。
だから、残業や休日出勤が多いみたい。

見ていると、中間マイルストーンと言う観点もないようだ。
リリースとは言わなくても、内部で何らかの形式で報告するタイミングはあるのに、そのタイミングを一区切りとしてタスクを棚卸しする考え方が無いみたい。
だから、上司にすぐに進捗報告できる体制がないし、今どんな課題やリスクがあるのかを報告するのが大変みたい。

【2】何故バージョンの概念が出てこないのか、彼に聞いてみると、WF型開発の意識が強いようだ。
フィードバックが無いシーケンシャルな開発スタイルにしがみついているみたい。
つまり、工程単位の開発にこだわっている。
設計書をちゃんと書いて、それから開発して、全部開発が終わってから単体テスト、みたいな流れ。

このやり方で開発を進めると、本番リリースは一番最後の1回だけになる。
途中でリリースしたとしても、工程単位に開発しているから、設計だけ終わっても、それはリリースとは言えない。
動かないシステムをリリースしたと言っても、それは普通はリリースとは言わない。
開発が終わっても、単体テストが終わっていないシステムをリリースしてもまともに動かないから、リリースとは言いにくい。

リリースする時は必ずバージョンやタグを付けるけれど、リリースが1回しかないから、バージョンを付けるタイミングも1回しかない。
だから、わざわざバージョンをたくさん作って運用する理由がない。

Redmineの場合、バージョンが一つも設定されていないと、ロードマップは空になる。
しかも、設定画面でロードマップ表示をOFFにできるので、ロードマップそのものを使わない運用も可能。
だから、彼はロードマップが不要と判断したらしい。

彼のような運用スタイルはRedmineだけでなく、TracやMantisによるタスク管理でも起きやすい。
特に、TracやMantisでは、TracのマイルストーンやMantisの修正済みバージョンは、Redmineのバージョンに比べて正直使いづらい。
だから、Tracのチケット一覧やMantisのチケット一覧に、たくさんのチケットが無造作に登録されて乱発されてしまい、放置されてしまう。
すると、納期の観点が薄れるし、タスク漏れが起きやすく、チケット駆動開発の利点が薄れる。

【3】彼にバージョンの意味を教える時、僕が実際に運用しているRedmineのロードマップを見せたら、彼は一目でバージョンの意味を理解したようだ。
僕のRedmineのロードマップでは、バージョン名が実際のリリースバージョンに対応している。
また、Redmineはバージョンの横にリリース日が表示されるから、一目でRedmineのバージョンの意味が分かったみたい。

そして、ロードマップを見て、これが実際のリリース履歴なのだとすぐに分かったみたい。
つまり、過去のバージョンはどんな対応を行ったのか、ロードマップに表示された終了チケットのリンクを押せばいい。
そして終了チケットには、SVNリビジョンが一覧表示されているので、そのチケットでどんなソース修正が行われたのか、一目で分かる。
彼は、SCM連携機能を使っていなかったようなので、そのチケット画面を見てすぐにその利点が理解できたようだ。

【4】ソフトウェア開発で最も重要なものは、リリース計画だ。
いつ何をリリースするのか、一目でわかるようにした計画書であり、Redmineならロードマップになる。
Agile開発の観点では、短期計画のイテレーション計画に対し、リリース計画は長期計画に対応する。
PMBOKなら、リリース計画はプロジェクトマネジメント計画書そのものになるだろう。

Agile開発では、リリースの単位がイテレーションであり、それはリリース予定バージョンに対応する。
頻繁にリリースできるのがAgile開発の最大の特徴だ。

バージョンをイテレーションに同一視することによって、短期間に小刻みに機能拡張しながら、顧客へいち早くソフトウェアの価値を提供していくスタイル。
この仕組みが小規模リリースと言われるものになる。

だが、短期間に頻繁にリリースするのはたとえAgile開発でも難しい。
半年に1回のリリースが2～4週間に1回のリリースサイクルに変わったら、開発プロセスも成果物も抜本的に変えなければ、そのリリースサイクルに対応しきれないだろう。
1回のリリースでも大変なのに、何回もリリースするのはAgile開発でも難しさは変わらない。

まず、リリースする対象の機能を絞り込む必要がある。
そのために、プロジェクトマネジメントの観点を品質・コスト・納期ではなく、スコープ・コスト・納期へ切り替えて、スコープでコントロールする。
イテレーションが短いので、タスクはすぐにあふれやすいからだ。

又、ソフトウェア開発では、当初見込んだタスクだけではなく、バグ修正や仕様変更が頻発するから、マネジメントを意識しなければ、すぐにタスクが溢れてしまう。
だから、タスクの優先順位を変えるだけでなく、後回しにしたり、却下したり、チケットの取捨選択が重要になってくる。
チケット駆動開発は、プロジェクト管理をチケット管理に置き換えているのがミソになる。

そのために必要な概念がバージョン。
下記にも書いたが、イテレーションの概念を自分たちのプロジェクトで運用出来ているかどうかで、Agile度が分かるような気がしている。

Agile開発の肝はイテレーションにあり: プログラマの思索