Posts in tetsuro.takao

・ユニファイド・プロセスと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などオブジェクト指向から生まれた図での表現なども含まれますが、それらは組織やプロジェクト、ソフトウェアに適した形でカスタマイズされること（この場合変形ではなく、ユニファイド・プロセスの各要素の取捨選択）を期待されており、ユニファイド・プロセスという明確に定義されたプロセスがあるわけではありません。もっとも有名な実体化されたユニファイド・プロセスはラショナル・ユニファイド・プロセスです。

・導入事例から学んだプロセス標準化 提案書を書くにあたって、まず調査を行いました。 Microsoft MVP for Visual Studio ALMの方たち※1のブログなどを読み漁り、OnlineとOn premiseはそれぞれ使いどころがあることを知り、TFSは一元管理に適したソース管理ツールであり、Gitは分散管理に適したソース管理ツールであることを知りました。また、ソース管理はApplication Lifecycle Management（以降「ALM」）の一部にすぎないことなどを知ることになります。通常提案書などを書く場合は、100ページ程度のものを1週間ぐらいで書きますが、私にとっての最初の洗礼は「ALMの提案は1週間程度で策定できるレベルのものではない」ということでした。 私はProject Management（以降「PM」）を経験済みであり、Project Management Body of […]

ある会社にApplication Lifecycle Management（以降「ALM」）を提案することになりました。 私はVisual Studioで開発を行ってきましたし、Team Faundation Server（以降「TFS」）でのソース管理も利用してきました。かなりの規模の案件です。 ただし、Team Faundation Serverの設定をやったこともなく、GitやSubversionも大規模案件に使ったことはありませんでした。そして、提案書を作成しながら、ALMがいかに開発者や運用者の良心やスキルに依存していたかを痛感しました。 ここでは、管理ツールの導入とその運用手順を明示した提案書で、そのような良心や運用に頼らない仕組みを実現できることを訴求した内容について、以下の5回に分けて報告していきたいと思います。 第1回：システムの構築プロセス（開発と運用）を定義する 第2回：システムリソースの一元管理と分散管理 第3回：Visual Studio Onlineを提案してみた […]