Redmine・Trac・Mantisによるチケット駆動開発を4年間やってきて、いつも新しい観点を発見している。
最初はRedmineプロジェクトへ組織構造をマッピングする件について考えたことをメモ。
全3回の予定。
【0】最初は小規模プロジェクトでRedmineを運用し始めて、じきに保守ブランチが必要になったり、メンバーが増えて複数チームになったり、現行ソースを他の顧客へカスタマイズして販売する派生開発になったりすると、複数プロジェクト機能を使わざるを得なくなる。
あるいは、一つの組織でいきなり全てのプロジェクトへRedmineを導入して運用しようとすると、Redmineプロジェクトの構造をどのように決めるか、考えなくてはならない。
自分が過去に運用したり、周囲を見聞きしてきて、下記の3パターンでまとめられるように思う。
それぞれについて解説してみる。
(1)派生プロジェクト
(2)保守プロジェクト
(3)CCBプロジェクト
【1】派生プロジェクト
よくある例は、安定運用しているシステムを他の顧客や他の製品へカスタマイズして開発するパターンだ。
このパターンでは、派生元システムは親プロジェクト、派生先システムは子プロジェクトになるのが普通だ。
このプロジェクト構造にする理由は幾つかある。
一つは、Redmineの複数プロジェクト機能で有効な機能があるから。
親プロジェクトのチケット一覧に子プロジェクトのチケットも表示・非表示を制御できるので、子プロジェクトのチケットも同様に検索したり出力できる。
つまり、子プロジェクトのチケットはあたかも親プロジェクトのチケットのように故意に扱うことによって、タスクを把握したり、管理しやすくなる。
又、プロジェクトの親子関係がある場合、子プロジェクトのリポジトリにチケットがリンクされる時に、親プロジェクトのリポジトリが小プロジェクトのそれを含んでいるならば、親プロジェクトのリポジトリにもチケットがリンクされる。
つまり、子プロジェクトのチケットを親プロジェクトのリポジトリにもリンクさせることによって、トレーサビリティを拡張することができる。
Redmineでは、トラッカーやカスタムフィールドをプロジェクト単位にアサインすることが可能だから、各プロジェクトに含まれるタスクのワークフローの観点で、必要なトラッカーやカスタムフィールドだけアサインすることも可能だ。
特定の派生製品のチケットだけ固有の属性を追加したい時、その派生プロジェクトだけカスタムフィールドをチェックすればいい。
また、ユーザグループでユーザを一活登録することもできるから、派生元プロジェクトは既存メンバー、派生先の新規開発プロジェクトは新規メンバー、などのように登録ユーザを使い分けることもできる。
つまり、各プロジェクトの特性に応じて、柔軟にチケットの属性やワークフロー、ユーザを自由自在に取り外しできるので、複数プロジェクト機能をうまく使いこなせば、厳格なプロジェクト管理も可能だ。
もう一つは、プロジェクトの寿命の観点で親子プロジェクトを使い分けること。
基本は、寿命の長いプロジェクトは親プロジェクト、寿命の短いプロジェクトは子プロジェクトに設定する。
何故なら、プロジェクトの親子関係は、オブジェクトの継承のように、親プロジェクトの性質を子プロジェクトも受け継ぐと言う観点からして、親プロジェクトが廃止されたら子プロジェクトも廃止されるのが自然だからだ。
すると、派生元製品の方が普通は派生先製品よりも寿命が長いから、親プロジェクトは派生元製品になる。
派生元製品には共通のフレームワークや部品があるため、それらを保守するタスクがチケットになるからだ。
この例は特にERPのようなパッケージ製品、組込製品が相当するだろう。
MSのOffice製品群、AppleのiPod・iPhone・iPadのように似たような製品だが細部は異なる製品群はまさにその例になるだろう。
すなわち、この考え方は最終的には製品系列の開発、つまりソフトウェアプロダクトラインの考え方に発展するだろうと思う。
【2】保守プロジェクト
よくある例は、新規開発したシステムをその後ほそぼそと運用保守で続けたり、2次開発で別システムを開発する場合に、新規開発プロジェクトと保守プロジェクトを別々に分けて、親子プロジェクトで関係付ける。
新規開発と保守の二つのプロジェクトに分ける理由は、それぞれのソースが新規機能重視なのか保守重視なのかという構成管理上の観点と、大規模プロジェクトで二つ以上のチームに分けて開発と保守を割り当てるという開発リソースの観点の2点が主にあるだろう。
小規模プロジェクトでは、開発も運用保守も一チームでやる時が多い。
すると、trunkは新規開発、リリースブランチは本番運用と意図的にコードラインを分けてソース管理する。
つまり、trunkは常に最新機能を持つ常時リリース可能なコードライン、リリースブランチはtrunkからリリースした時点で発生して障害修正のみ行う保守重視のコードラインになる。
構成管理のライフサイクルとしては、trunkからリリースする時にリリースブランチが生まれ、次のバージョンでリリースする時に既存のリリースブランチは廃止され、新規のバージョンに対応するリリースブランチが生まれる。
この構成管理パターンはいわゆるメインラインモデルに相当する。
オープンソースのソフトウェア開発ではごく自然に行われている開発スタイルだ。
すると、trunkは親プロジェクト、リリースブランチは子プロジェクトで関係付けるのが自然だろう。
何故なら、trunkの方がリリースブランチよりも寿命が長いので親プロジェクトするのが自然だし、trunkのチケットを保守する時に子プロジェクトにある障害修正のチケットも同時に見れた方が便利だからだ。
僕が並行開発でRedmineの複数プロジェクト機能を有効に使えた場面はこのパターンだった。
だが、大規模な業務システムの開発ではプロジェクトの親子関係の使い方が変わってくる。
複数チームによる開発の場合、よくある例は、既存メンバーは運用保守に割り当て、2次開発のように特定期間に発生した大きなプロジェクトは新規メンバーをアサインする時が多い。
複雑な業務システムほど保守が重要なので、保守にいきなり新規メンバーを大量投入するのは危険だからだ。
逆に2次開発の場合、新機能の追加になるから、既存メンバーの一部と新規メンバーでチームを構成すれば、リスクヘッジもできる。
すると、保守チームのタスク管理は親プロジェクト、新規開発のタスク管理は子プロジェクトで関係付けるパターンが多い。
つまり、保守プロジェクトの下に1次開発、2次開発、特定機能の短期開発などのような寿命の短い案件が子プロジェクトでぶらさがってプロジェクト管理される関係になる。
この構造にすれば、短期開発で行われたタスクは全て子プロジェクトのチケットに作業履歴が残っているから、その後の運用保守でもトレーサビリティを使えば有効活用できる。
子プロジェクトの新規開発時のチケットが残っているので、作業の引継ぎもその後の運用保守での調査にも役立つ。
更に、構成管理の観点では、保守プロジェクトはtrunk、新規開発プロジェクトはタスクブランチと目的を分けてブランチ管理するパターンが多い。
つまりtrunkは保守重視であり、新規開発チームはtrunkから派生したタスクブランチでどんどん機能追加して、リリースできる品質になったらtrunkへマージするパターンになる。
そのような構成管理にする理由は、trunkを品質保証されていないソースで汚したくないことや、新規追加のシステムならばtrunkへマージする作業もほとんど上書きコピーするだけで動くだろうという推測があるからだ。
この保守パターンで面白いのは、構成管理と複数プロジェクト機能が密接に関係していること。
そもそもRedmineでは１プロジェクト＝1リポジトリの設計思想があり、それは1リポジトリからビルドされてリリースされる製品と対応付けられるから、一つのコードライン、すなわちリリース可能なブランチとプロジェクトが1対1に対応付けられる。
構成管理ではtrunkの方がブランチよりも寿命が長いので、trunkを持つプロジェクトが親プロジェクトになる。
その時、リリースブランチやタスクブランチの観点で、子プロジェクトの構造の意味あいが異なってくるのが面白い。
【3】CCBプロジェクト
よくある例は、大規模プロジェクトで複数チームで開発している場合、各チームのタスク管理だけでなく全チーム共通の課題管理を行う必要がある時に出てくる。
つまり、PMBOKのCCB、ITILのCAB、アジャイル開発のスクラムオブスクラムのように、各チームのリーダーが集まった会議で、複数チームにわたる課題を調整したり、プロジェクト全体の方針を決定づけるように運営する。
すると、親プロジェクトはチーム横断の課題管理、子プロジェクトは各チームのタスク管理で関係付けられる。
マネージャのように複数チームのリーダーを管理する立場の人は、各チームの細かなタスク管理はチームリーダーに任せているので見る必要はない。
むしろ、プロジェクトの進捗を阻害する課題や各チームからあがってきた課題を見つけては解決していき、プロジェクトをスムーズに運営できるように維持する役割に徹するようになる。
だから、マネージャは、課題管理プロジェクトにあがったチケットを精査することで、プロジェクト運営を制御する方向で運用するようになるだろう。
このパターンの特徴はいくつかある。
一つは、課題管理プロジェクトとタスク管理プロジェクトでは、チケットのトラッカーや属性が異なること。
各チームのタスク管理は普通のRedmineの運用でよいが、課題管理プロジェクトでは、Excelで作られた顧客向けの課題一覧を元にチケットの属性を増やしたり、ワークフローを意図的に変えたりすることで運用する場合が多い。
Redmineプロジェクトで管理されるチケットは誰が保守するのか、という役割の観点によって、チケットが大きく変わる良い例だろうと思う。
マネージャが管理したいチケットとプログラマが作業しやすいチケットは、チケットの属性もトラッカーも全く別物にした方が運用は楽だろうと思う。
もう一つは、CCBプロジェクトと保守プロジェクトを組み合わせたパターンがよく見られること。
例えば、新規顧客の大規模プロジェクトでRedmineを使った場合、1次開発ではCCBプロジェクトの構造で親プロジェクトは課題管理、子プロジェクトは各チームのタスク管理のように関係付けて運用する。
そしてリリースが終わって運用保守に入った場合、運用保守プロジェクトを親プロジェクトとして新規に作り、1次開発の課題管理プロジェクトを子プロジェクトで関連付けて、1次開発のチケットを作業履歴として参照できるように運用していく。
この運用の利点は二つある。
一つは、過去の開発のチケットを参照しやすいので保守作業に役立つこと。
もう一つは、新たに2次開発が発生したら、子プロジェクトの2次開発用の新規開発プロジェクトや課題管理プロジェクトをぶら下げればいいこと。
特に後者の場合、今後、大規模でなくとも2次・3次と開発案件が発生するなら、運用保守チームとうまく連携して開発できるような仕組みが作りやすい。
【4】以上のような3パターンを経験的にまとめたけれども、他の案件では他のパターンもあるに違いない。
是非聴かせて欲しいなあと思う。
Redmineが持つ複数プロジェクト機能は、とても大きな可能性を秘めていると思う。
」は、複雑なシステムをOOAの観点でモデル化して、その複雑さを見える化しようとする。
」や羽生さんの本「
」に書かれているようなDOAのモデリング技法が根本的な解決策に近いだろうと思っている。
」をもじっているような気がする(笑)
」で上記の概念を翻訳してみる。
」の構成管理パターンとほぼ同等だ。
」では「トピックブランチ」に相当する。
」では、ファシリテーションとはプロセス設計の技術だ、と主張する一文があり、なるほどと思った時がある。
最近のコメント