Redmineを使って気付いたことpart8～チケット駆動開発の先にある世界

チケット駆動開発やTestLinkなど各種ツールを運用して、SW開発とは一体何なのか？という疑問を感じた。
以下メモ書き。

Redmineでチケット駆動開発を実践すると、アジャイル開発における無駄な管理工数が減る。
TestLinkを導入すると、テスト工程における無駄なマネジメント工数が減る。
Hudsonによって、リリース作業の工数も減る。

では、それらでプロジェクトは楽になったのか？
確かに、以前よりも進捗管理は制御しやすくなった。

でも、SW開発そのものの難しさは変わっていないように思う。
むしろ、顧客と要件定義に時間を費やしたり、設計時に仕様変更の履歴を辿って本来の要件を理解しようとしたり、実装を意識した設計に時間を費やす。
いわゆる前工程へのフロントローディングが自然に行われるようになり、設計工程で多くの時間を割くようになった。

つまり、開発時の進捗管理に自信があるからこそ、曖昧な要件定義や設計工程にギリギリまで時間をかけることができる。
設計に時間を費やし、実装やテストはバグ無しで一発で通すようにする。
すなわち、リーンソフトウェア開発につながる。

SW開発ではビッグバン統合は失敗しやすい。
ウォーターフォール型開発や大規模案件が失敗しやすいのは、結合テストで初めて欠陥が人前にさらされるからだ。
もっと前工程で欠陥に気付けばいいのに、実際にシステムが初めて動く工程が結合テストだからだ。
IT業界は、結合テストでプロジェクトが火を噴くパターンを何度も繰り返している。

アジャイル開発の本質は、XPのプラクティスである小規模リリースに尽きると思う。
短期間の繰り返し型開発。
小刻みなVerUpで機能拡張していく。
小規模リリースはリスクが少ない。

「MS製品はVer3.0で使い物になる」とよく言われるが、MSのやり方もアジャイル開発に近いのではないか？
リリース当初は評判が悪くても、じきに市場を席巻する。

アジャイル開発のソース管理は、本番運用中と開発中の並行開発が基本だ。
いわゆるソフトウェアプロダクトラインに近い。
つまり、2本のコードラインで品質維持と最新ソースの同期を取る。
マージ作業は分散バージョン管理の方が楽な傾向がある。
GitやMercurialを使えば、ソース管理はもっと楽になるだろう。

チケット駆動開発は、プロジェクト管理や構成管理を全自動化する。
進捗管理、ソース管理、リリース作業の工数はそもそも不要。
PGがプログラムを作れば、即システムが出来上がる。

チケット駆動開発がなければ、従来通り、Excelの進捗管理やリスク管理しかない。
限られた工数のうち、マネジメント工数が実はかなりかかってはいないか？

アジャイル開発のような短期間の繰り返し型開発は、チケット駆動開発のように作業ステータスを自動集計する機構を必要としている。

KPTによるふりかえりで、イテレーション単位でリリース後の集計結果をメンバー全員に見せている。
それは、自分たちの開発チーム、そして各メンバーの成績表。
チームの開発速度、メンバーの貢献度が一目で分かる。
メトリクスの威力は恐ろしい。

チケット駆動開発がメンバーに根付くと、ワークフローと言う概念が自然に現れる。
どうやら、一つのチケットを他人に渡す時にステータスを変更して、他人に通知したいらしい。

バグ修正とバグ検証も然り。
課題の問合せと回答も然り。

それらのワークフローを集めたら、自然にそのチームの開発プロセスになっている。
Redmineならトラッカー、Tracならチケットの種類がワークフローに相当する。

ソフトウェア開発に必要なワークフローは一体どれだけ存在するのか？
それが分かれば、Redmineはソフトウェア開発のERPになりうる。