・ユニファイド・プロセスとPLM、ALM
前回作成したブランチとマージの仕組みはProduct Lifecycle Management（以降「PLM」）とALMに登場する成果物の管理の枠組みに過ぎません。この枠組みに則って成果物のバージョンを管理していく必要があり、たとえば文書管理であれば、ALMやPLMの役割は下図のようになることを提案しました。
文書定義の役割分担
文書管理においてPLMとALMの管理を完全に切り離し、ALMの管理のみをTFSで行うことでソースと文書のバージョン管理を同期させることを計画しました。ALMの管理機能は、バージョン管理、進捗や人員リソースの管理、品質管理、ビルドやリリース管理、変更管理や追跡などがあり、これらすべての運用を定義する必要があります。まずバージョン管理については、メジャー、マイナー、リビジョン、ビルドのそれぞれのインクリメント・ルールとして、新機能（メジャー）、機能拡張（マイナー）、バグ修正（リビジョン）、ビルド（リファクタリング）という標準的なバージョニングを採用しました。この際、シェルブとチェックインをロールごとに使い分けるように計画しました。
コミットのワークフロー
チケット（TFSでの呼称は「ワークアイテム」）のステータス管理やロールについては、次項「プロセスを社内のワークフローに落とし込む」に詳細を解説しますが、ワークフローの最後のロールである「ビルド管理者」（おそらくは開発責任者）が、すべてのチケットのステータスを管理する点が重要です。このロールこそがアプリケーションのバージョンをコントロールするロールと言えます。
このロールに必要な知識として、プロセス定義の手法があります。バージョンのインクリメントに対する管理プロセスを策定するうえではCMMI（定義済みプロセスの定着を目的とした能力成熟度統合手法）、Scrum（少人数におけるコミュニケーションを中心としたスプリント推進によるプロセス確立手法）、Agile（ウォーターフォールを細分化したイテレーションによる柔軟なプロセス確立手法）がありますが、今回の提案ではAgileでTFSのインストールを行うことを提案しました。提案先の企業では、明確な開発プロセス、管理プロセスが確立されていなかったため、試験的なプロセスを策定し、それを繰り返しによって微調整しつつ確立する必要があったからです。
この試験的なプロセスを充足、改修することを目的とした微調整であることはチーム全員に周知する必要があります。開発者にとってもより良いプロセスを確立するために試験的なプロセスを行っているのであり、開発者のフィードバックが次のイテレーションの試験的なプロセスになるので、同じプロセスを繰り返すのであれば、確立されたプロセスに対するCMMI方式に移行する必要があると考えたからです。
試験的なプロセスは、ユニファイド・プロセスに則って策定しました。業務用ソフトウェアの開発ではユニファイド・プロセスに則ってAgileのイテレーションを計画すべきと考えたからです※：コラム「Agile Unified Process」参照。
ユニファイド・プロセスは、オブジェクト指向開発誕生以前からソフトウェア開発手法として確立されていたいくつかの手法をオブジェクト指向開発に適した形に統合した反復型開発手法です。これにはUMLなどオブジェクト指向から生まれた図での表現なども含まれますが、それらは組織やプロジェクト、ソフトウェアに適した形でカスタマイズされること（この場合変形ではなく、ユニファイド・プロセスの各要素の取捨選択）を期待されており、ユニファイド・プロセスという明確に定義されたプロセスがあるわけではありません。もっとも有名な実体化されたユニファイド・プロセスはラショナル・ユニファイド・プロセスです。
No responses yet