チケット駆動開発のスケールアップ

Redmineを大規模プロジェクトで使っている例を見たのでメモ。

【元ネタ】
複数プロジェクトとワークフローの設定について - Redmine Users (japanese) | Google グループ

上記のメールでは、下記の規模まで使っているらしい。

例1：
プロジェクト：12
ロール　　　： 8
ステータス　：25
トラッカー　：12

例2：
プロジェクト：200～400ぐらい
ロール　　　： いまのところ６個にしぼっているけど今後は２０ぐらいになりそう
ステータス　：６ぐらい
トラッカー　：２０以下

正直な感想は、すごい！の一言。
Redmineはおそらくこんな規模まで運用するとは想定していないと思う。

上記の問題点は、Redmineによるチケット駆動開発のスケールアップにある。
サブチームの数が無制限でも運用に耐えれるのか？という問題。

スケールアップはプロセスの標準化と密接に関係する。
そもそも1970年代にウォーターフォール型開発の論文が出てプロセスが提唱された理由の一つは、それまで職人芸で作られていたソフトウェア開発を、大規模なシステムでも開発できるように、スケールアップできるようにしたから、と聞いたことがある。
プログラムの規模、開発チームの規模、システムの規模、それらが大規模化した時、プロセスと言う共通のルールが無ければ、大規模なシステムは作れない。

TracやRedmineによるチケット駆動開発は、本来5人程度で1プロジェクトのタスク管理が発端だった。
そして、Redmineの複数プロジェクト機能を使えば、複数のサブチームのタスク管理も可能になる。
例えば、開発チームと問合せオペレータのチーム、開発チームとサーバー保守チーム、コンポーネント単位の開発チーム、など色んな観点がある。

だが、従来のRedmineではワークフローやロールまで大規模化するのは難しかった。
やはり、サブチーム特有のワークフローやロールはあるから、標準化しなければ、どんどん複雑化するからだ。

しかし、RedmineのVer0.9では、プロジェクトの階層が無制限になり、ユーザグループにも対応した。そして、Ver0.9.1のワークフロー設定画面では、トラッカーで使用されているステータスのみを表示させることもできるから、ワークフローの管理もやりやすくなった。

つまり、Redmineの最新バージョンでは、プロジェクト特有のワークフローやステータス、トラッカー、ロールを制御しやすくなっている。
棚卸しのための課題管理会議(CCB、CAB)を上手に運用できれば、単なる1プロジェクトだけではなく、社内全体の複数プロジェクトも管理できるようになるだろう。

Redmineはどんどんエンタープライズ向け機能で、スケールアップに力を入れているようだ。
大規模プロジェクトでのチケット駆動開発の運用について、色々考えてみたい。