ソース管理ツールは、製品のロードマップがあって組織内の様々なプロセスの後に形成されるALMを基盤として、その上で利用するものですから、それらの先行作業なしにツールを利用することはできません。しかしながら、多くの組織ではバージョン管理ツールを使うことに執心し、製品戦略との兼ね合いや構築プロジェクト完了後の継続的デリバリを意識すること無く、納品後のソースコードそのものがファイルサーバーに置かれていたりします。この記事では、ソース管理ツールが製品戦略の中でどのような役割を果たし、製品の継続的デリバリがどのようになされるのかについて解説します。 ALM ALM(Application Lifecycle Management)は、継続的デリバリには欠かせない作業です。ALMはPLM(Product Lifecycle Management)の一部であり、サービスのリリース時期、機能の拡張時期といったビジネスに直結する要素と分離された状態では、機能を実現する際の技術検証や懸念事項が犠牲にされプロジェクトのリスクが高まります。 ALMツール PLMで定義された製品化カタログはALM側でユーザーストーリーに置き換え、PLMで計画されたリリース単位、リリース時期をALM側でイテレーションに置き換えて、機能以外のドキュメントっ作成なども考慮したタスク群の入れ物となるバックログを作成していきます。その作業を支えるのがALMツールであり、いくつかの製品が販売されています。 ALMでは、ソースコードやバッチなどのリソース(≒プロジェクトの成果物)の状態を定義し管理します。設計文書などの状態なども定義し管理します。 ソースコード等のリソースの状態の定義とは、イテレーション内のユースケースを構成する複数のタスクのうちプログラムやバッチとして定義したタスクをフィーチャー(機能)として複製し量と質を管理していきます。量の管理とは、機能単位でソースコードが追加された、改修された、拡張された等を指し、アジャイル開発プロセスを採用している場合はできる限り1日単位(8h程度)のタスクにすることを推奨します。 また質の管理とは、その機能はどのような作業(コードレビューが終了した、単体試験が終了した等)で構成されているのかといった質の単位を定義し管理します。
業務用かどうかに関わらず、ソフトウェアの開発ではユニファイド・プロセスが重要であると考えます。ユニファイド・プロセスはAgileやScrum、Extream Programming等と相反するものではなく、ユニファイド・プロセスがカスタマイズされたものであると考えられるからです。元来、ユニファイド・プロセスはプロジェクトや組織によってカスタマイズされることを期待しており、適切なカスタマイズは、ユニファイド・プロセスの導入効果を最も発揮する重要な手法です。 業務用ソフトウェアの場合、このプロセスの単位は大小さまざまであると考えます。大きなひとつの構築プロセスと小さな改修プロセスや機能追加プロセス、技術検証プロセスなどが同時に推進していくことの方が多く、構築がひと段落してから第2フェーズの機能追加、バグ改修といった”裕福な”プロジェクトはそう多くはありません。多くの場合、運用しながら並行して機能追加や既知の潜在バグ改修といったプロジェクト推進が求められます。 このような形態のプロジェクト推進に対応しやすいと思われるのがAgile Unified Processです。Rational Unified Processを簡素化したAgile Unified Processは、規律をベースとするプロセス推進法であり、 Test-Driven Development (TDD)やAgile Modelingなどを含み、それらの作業を簡略化するツールの使用が推奨されています。Agile Unified Processは、大小さまざまな各プロセスの規律がイテレーション後に充足、改修されながら確立されていくため、最初に試験的なプロセスが必要となります。 […]
Presentation document for Community Open Day 2013 http://sdrv.ms/13LYYJ7 Microsoft Virtual Academy
Silverlightを囲む会東京7回の資料「画面の更新を考える」を公開しました。 資料はこちら
コミュニティオープンディのD6資料公開しました。 資料はこちら
資料はこちらになります。 Sample solution file
Silverlightを囲む会東京第6回の資料公開しました。 Silverlight5でPInvokeを利用してIn Browser、Out Of BrowserでのDllImportを行っています。 資料はこちらです
サンプルコードから、作成したの人の考え方などを拾えたらいいなと思いました。 資料はこちらです。
Silverlightを囲む会東京第5回でお話しした「Silverlightを囲む会の座席表作ります」の続編となります。 今回は、上図のSilverlightアプリケーションのうち、Windows Phone版でないPC版の方を作成します。まず、シンプルなSilverlightアプリケーションを作成し、ASP.NET開発サーバーを使ってWCFサービスの値を受け取るクライアントアプリケーションを作ります。 次回からの後続の記事は以下のように続きます。 ・作成したWCFサービスを双方向通信に改造して、クライアントの名前等をサービスに通知、送った情報を双方向で受け取るという部分を作成します。 ・管理画面を作って、座席表の形態(セミナータイプとか会議室タイプなど)をASP.NET開発サーバー側に送り、XMLファイルとしてASP.NET開発サーバー側に保存します。 ・今回作成するユーザー画面を改良して、ユーザーが自分の座席の位置を登録できるようにします。この際、IIJの会場以外の場所からオンラインでセミナーに参加している方々の登録も想定し、Azureでのサービスに切り替えます。 ・Windows Phone版のアプリケーションを追加で作成します。 では、さっそく以下の手順でSilverlightアプリケーションを作成してみましょう。 手順1:テンプレート Visual Studio で空のソリューション「TheSekihyo」を作成し、プロジェクト「TheSekihyoSilverlight」をVisual Studioのテンプレート「Silverlightアプリケーション」で追加します。新しいWebプロジェクトでホストするASP.NET Webアプリケーション […]
Silverlightを囲む会 東京 第5回の資料公開しました。 資料のリンク