Team Foundation Server を利用してアジャイルな開発を (Part II)

  • Article

本日は前回のエントリーの続き、ツールの使い道について。
その前に、いつもの前説を… (懲りないロバートです)

先日の凹みはF1観戦ができなかったとか、大学バスケのトーナメント観戦できなかったと言った、大した凹みではありませんでしたが･･･
今日は… もう… 朝から火傷。早めに出社したのにテレカンのブリッジがいきなり変わっていたので、戸惑いながらテレカンに10分遅れて参加… マシンの調子は不調中の不調。仕事が何一つ手に付かず、一日中デスクでPCに向かって発狂していました。

 

そんなコケてばかりの一日… よくよく見ると3月も今日で終わり。2009年、早くも4分の1が経過してしまいましたよっ！！

 

不貞腐れて早めに帰宅し、家のPC (Vista x64 の DELL Inspiron 1720) でお仕事をしています。

でも、よく考えると、日曜日にアップしたポストの続きがまだだった！！

 

と言うことで、続き (前説長いんです)

 

スライド16 
アジャイルな開発を実現するために、ツールは必要だと言う話の中で、マイクロソフトの Visual Studio Team System の機能を利用して実現することも可能だと言うところに至ったかと思います。

そして、前回はその VSTS がアプリケーション ライフサイクル管理 (ALM) のコンセプトをベースに作られたこと; ALM の中ではビジネス、開発、運用と言った3つの大きな歯車に注目して、かつ各歯車 (ステークホルダー) によってビジネス バリューと言うものを確認し、要求し、開発し、最終的にはそのバリューを見出すものをデリバリーすると言うことをお伝えしました。VSTS はこれらステークホルダーのコミュニケーション ギャップを退けるために…または、そのコミュニケーションを支援するためにあるものでもあると説明しました。

アジャイルな開発を実施するにあたっても、Agile Manifesto にある通り、**ビジネス側の人間と開発側の人間は日々一緒に仕事をする必要がある**と言った、ごく当たり前のことを実施していかないことには、開発プロジェクトのバリュー (価値) と言うものをきちんと見出すことができないと言うことも…

 

VSTS には「クライアント」と「サーバー」のコンポーネントがあります。
VSTS に何かしらかかわったことのある方は、クライアント側に Architecture Edition、Database Edition、Development Edition、Test Edition の4つの製品と、それら全てを含む Team Suite があることをご存じかと思います。

更に、イベント、セミナー、記事などでも紹介している通り、Visual Studio Team System 2010 での SKU 変更に伴って、Development Edition か Database Edition のいずれかをお持ちのお客様はもう片方の SKU を無料でご利用いただけることもご存じかと思います。
えぇ。製品担当としては、こんな宣伝も突っ込んで行きますよ♪♪

上記キャンペーンについての詳細はこちらから:
Development Edition & Database Edition 最大活用キャンペーン

VSTS のサーバーは、Team Foundation Server。直訳するとチーム基盤サーバー。
チームでの開発基盤となる、重要な中核です。
「基盤」とまで言うと、これがなくてはチーム開発が砂上の楼閣になってしまうのではないかと… 思って下さって結構です。

セントラル情報リポジトリがあって、その情報がステークホルダーの皆が確認できると言った、透明性の高いものですから･･･
逆に、このサーバーがこなすことを手動で誰かが (主にプロジェクト マネージャさんでしょうけど) その情報を管理して、数値化して、具現化して… 時間がもったいないですよ。プロマネさん、死んじゃいますよ。

ツールは道具です。使ってなんぼです。 使えるものは使いましょう！

 

スライド9
このスライドを覚えていますか？
アジャイルに開発をするには、プロセスもツールも必要！と言う中で、Kent Beck が「特に、このようなプロセスを実装する、5つのことを実現するツールがあるべき」と言うものを描いているスライドです。

 

単体テスト
構成管理
継続的ビルド
リファクタリング
透明性

 

では、これらを上から見てみましょうか？セミナーでは、サーバー側でやること、クライアント側ですることと分けてお見せしましたが…

 

単体テスト (Unit Test)
言うまでもないと思いますが、アプリケーション開発をするにおいて単体テストは絶対です。
ただ、単体テストを書くのって結構面倒だったりします。
ひとつのプロジェクトにおいて、いくつも作る必要だってあります。

Visual Studio Team System の全クライアントでは (Visual Studio 2008 Pro でもできるようになっていますが)、この単体テストをより容易に作ることができます。

 

単体テストについて、Visual Studio 2005 Team Edition for Software Testers の頃には、以下のリンクにあるようなドキュメントを用意していました。
Visual Studio 2005 Team System を使用しての Unit Test Framework の単体テストおよびソース コード生成

スクリーン ショットなどをそろえて、Visual Studio Team System 2008 クライアントならびに Visual Studio 2008 Professional Edition での単体テストの作成の仕方や、利用方法と言うことをここに記載しても良いのですが･･･それを始めたら、今晩寝れそうにありませんので、また別の機会に載せますね。

でも、その分、皆さん自身でも MSDN でご確認できます！！

＜単体テストを説明する MSDN 記事集＞

    1. 単体テストの概要
      Team System テスト ツールの単体テストの種類について説明します。Visual Studio での単体テストの生成と編集の概要、プライベート メソッドのテスト、および単体テスト フレームワークの使用について説明します。
    2. ユニット テストの作成
      ASP.NET 単体テストやデータ ドリブン単体テストなどの単体テストの、生成と編集に関連するトピックへのリンクが用意されています。
    3. チュートリアル : 単体テストの作成と実行
      単体テストの作成とカスタマイズ、実行、およびテスト結果の検証を行います。
    4. ユニット テストのサンプル
      "Woodgrove Bank" サンプル プロジェクトを取得します。ここには、いくつかのチュートリアルで使用するコードが含まれています。
    5. チュートリアル : テストを実行し、コード カバレッジを表示する
      前のチュートリアルを基に構築されており、テスト中のプロジェクトのコードの割合を示すコード カバレッジ データの表示を行います。

  2. 参照

    1. Microsoft.VisualStudio.TestTools.UnitTesting
      UnitTesting 名前空間にいて説明します。この名前空間は、単体テストをサポートする属性、例外、アサートなどのクラスを提供します。
    2. Microsoft.VisualStudio.TestTools.UnitTesting.Web
      UnitTesting.Web 名前空間について説明します。この名前空間は、ASP.NET および Web サービスの単体テスト サポートを提供することで UnitTesting 名前空間を拡張します。

  4. 関連するセクション

    1. テストの管理
      テストの使用のさまざまな側面について説明します。テスト表示のカスタマイズやフィルタ処理の方法、テスト リストの使用方法、テストと作業項目の関連付けなどの方法について説明します。
    2. テストの実行
      テストの実行のさまざまな側面について説明します。テストの実行の構成方法、Visual Studio IDE やコマンド ラインでのテストの実行方法、テストの実行中のデバッグ方法などについて説明します。
    3. テスト結果の分析
      テスト結果とその扱い方について説明します。テスト結果を表示、保存、発行する方法や、テスト結果に基づいて作業項目としてのバグを作成する方法などについて説明します。
    4. Web テストの操作
      Web テストを作成、編集、実行、および表示する方法について説明します。
    5. ロード テストの操作
      ロード テストの用途、ロード テストを編集および実行する方法、ロード テストのパフォーマンス データを収集および格納する方法、およびロード テストの実行を分析する方法について説明します。
    6. 手動テストの操作
      手動テストを作成し、実行する方法を説明します。手動テストは、自動化されていない唯一のテストの種類です。
    7. 汎用テストの操作
      汎用テストを作成および実行する方法について説明します。汎用テストは、Team System テスト ツール用に開発されていない外部プログラムやテストをラップするために使用します。
    8. 順序指定テストの操作
      順序指定テストの作成方法を説明します。順序指定テストには、特定の順序で実行する必要のある他の複数のテストが含まれています。
    9. Test Edition チュートリアル
      組み込みのテストの種類を使用するチュートリアルや、コード カバレッジ データの収集などのトピックに関するリンクが用意されています。
    10. 方法 : 単体テストを生成する
      ソース コードまたはファイル システム内のアセンブリから単体テストを作成する方法について説明します。
    11. 方法 : 単体テストを編集する
      編集する単体テストを開く方法を説明します。単体テストの内容についても説明します。
    12. 方法 : ASP.NET 単体テストを作成する
      ASP.NET 単体テストを生成し、設定する方法を説明します。
    13. データ ドリブン ユニット テストのコーディング
      データ ドリブン単体テストの作成方法を説明し、コード例を示します。
    14. 方法 : データ ドリブン ユニット テストを構成する
      データ ソースのデータの使用中に繰り返し実行されるように単体テストを変更する方法について説明します。
    15. 方法 : プライベート メソッドをテストする
      プライベート メソッドをテストする単体テストの生成方法を説明します。
    16. 単体テスト フレームワーク
      単体テストのさまざまな使用方法をサポートする、Microsoft.VisualStudio.TestTools.UnitTesting 名前空間のクラスについて説明します。
    17. TestContext クラスの使用
      Microsoft.VisualStudio.TestTools.UnitTesting 名前空間の TestContext クラスについて、ASP.NET 単体テストやデータ ドリブン単体テストでのさまざまな使用方法を説明します。
    18. Assert クラスの使用
      単体テストにおいて値またはコレクションの比較やテスト結果のチェックなどの目的に使用できる各種のアサート ステートメントについて説明します。
    19. InternalsVisibleTo 属性の設定
      テスト対象コードを含むプロジェクトに InternalsVisibleTo 属性を追加することが必要となる可能性のある状況について説明します。

これでどうだ！！
確かに、実際に製品が手元になければ使えないジャン！って方もいらっしゃいますよね？

そんな方には、こちらがお勧め:
MSDN バーチャル ラボ: Visual Studio 2008

バーチャルラボとして、いくつかのシナリオをベースに機能紹介をしていますが、普通に時間内に上記の記事にあることをお試しいただくことも (全部じゃないですけど) 可能ですよ！

 

特に見ていただきたいのは単体テストよりも、コード カバレッジの機能について。
単体テストは作成して、成功すれば良いのではありません。
コード カバレッジは、単体テストがソース コードをどれだけ網羅してテストを実施されているかを確認するための機能です。

簡単に言うと、100個の単体テストが100%成功していても、それがソースコード全体の2割のコードしかテストしていなかったら、結局その100個のテストが20%くらいの価値しかないってことです…

 

構成管理 (変更管理、ソースコード管理、文章管理など)、そして継続的ビルド
これは Team Foundation Server 側の機能として提供しています。

スライド18

チェックイン ポリシー: コードの修正を実施して、コードをチェックインする際に、条件をつける機能。ルールとして、作業項目 (タスク) との紐づけをきちんとしないことには、コードをチェックインさせなくすることができます。
チェックイン時のコード比較: チェックインしたコードにつき、どの部分が削除され、追加され、変更されたのかをカラーコードで見ることができます。

スライド19

また、コードのチェックインを行う度にソースコードの結合を実行する継続的インテグレーションも設定できます。こちらについては、上記で紹介したバーチャル ラボの中でもシナリオが用意されています！資料もしっかりと作られているのでぜひチェックしてみてください。
継続的インテグレーション、継続的にビルドを実施すると、単体テストも同時に実行、コード カバレッジも確認、あらゆる面でのチェックが入ります。

そして何より、これら情報が自動的に実行されるだけでなく、実際どの作業項目 (タスク) やアサインメントに基づいて実行されているのかを全てトラッキングするので:

いつ、誰が、どんな理由で、どのような変更を実行したのかを、常に認識することができます！
また、この情報は修正できないので、結果が良くても悪くても、絶対な情報になります。(これって、かなり重要なポイントですよ！) 都合の悪い結果を適当に修正できてしまうと、後に同じ過ちを起こす可能性を引き出してしまいます。

＜余談＞
歴史って同じだと思いません？
良く言いますよね。「歴史は勝者によって書かれる」って。
勝者にとって都合の悪い事実は過去とともに消え去ってしまうことが多くあると思います。
今の時代、マスコミも広がり、テクノロジも広がっているので「アカウンタビリティ」と言うことを追及しやすくなっていますが･･･一昔の歴史は、こんなことなんだろうなぁ…なんて思います。
悪いこともきちんと書き遺される歴史であったら、「歴史は繰り返す」などと言う (特に悪いことに関して) ことは、極力少なくなるんじゃないかと思います。

アプリケーション開発の世界がそのような事実を変えていけたら、業界なんかを越えてそれができたら、どんなに素晴らしいことでしょうか！！
＜余談は以上…でも、この辺、飲みながら皆さんと語ってみたいです (笑)＞

 

リファクタリング
リファクタリングとは、コードの外部動作は変更せずに、コードの内部構造を変更することで、コードを作成した後で改良するためのプロセスです。
この機能に関しては、Team System である必要はありません。
ただ、Database Edition があれば、データベース スキーマのリファクタリングもできるんですよ～！！

リファクタリングについても、今回は MSDN のリンク集で勘弁して下さい。
   (実は、日本語の環境はまだ作り直していないので、スクリーンショットを撮れないんです…)

情報はこちらから:

複数のプロジェクトのリファクタリング

Visual Studio では、同じソリューション内にあるプロジェクトに対して、複数のプロジェクトのリファクタリングがサポートされています。ファイル間の参照を修正するすべてのリファクタリング操作では、同じ言語を使用するすべてのプロジェクト間で、この種の参照が修正されます。これは、プロジェクト対プロジェクトのすべての参照に適用されます。たとえば、クラス ライブラリを参照するコンソール アプリケーションがある場合、[名前の変更] リファクタリング操作を使用してクラス ライブラリ型の名前を変更すると、コンソール アプリケーションでのこのクラス ライブラリ型への参照も更新されます。

[変更のプレビュー] ダイアログ ボックス

多くのリファクタリング操作には、リファクタリング操作によってコードで実行される参照の変更すべてを、コミットする前にレビューする機能があります。このようなリファクタリング操作では、リファクタリング ダイアログ ボックスに [参照の変更のプレビュー] オプションが表示されます。このオプションを選択し、リファクタリング操作を受け入れると、[変更のプレビュー] ダイアログ ボックスが表示されます。[変更のプレビュー] ダイアログ ボックスには、2 つのビューがあります。下部ビューには、リファクタリング操作によって参照がすべて更新された状態で、コードが表示されます。[変更のプレビュー] ダイアログ ボックスの [キャンセル] をクリックすると、リファクタリング操作は中断し、コードは変更されません。

エラーを許容するリファクタリング

リファクタリングでは、エラーが許容されます。つまり、ビルドできないプロジェクトでもリファクタリングを実行できます。ただし、このような場合、あいまいな参照がリファクタリング処理によって正しく更新されないことがあります。

参照

処理手順

方法 : C# リファクタリング スニペットを復元する

 

プロジェクトの透明性
僕からすると、アジャイルに開発を実行するには、この部分が一番重要だと思います。

スライド32

Team Foundation Server のチーム プロジェクトを作成すると、自動的にプロジェクト ポータルが作成されるんです。
このポータルは Windows SharePoint Service もしくは SharePoint Server 上に作成されます。
また、充分な権限が与えられていれば Team Web Access などを利用して、外部の方もプロジェクトの進捗度を確認することができます。

 

Agile Manifesto の中でも、**ビジネス側と開発側の共同の作業**と言うところを何度もピックアップしたのはここにあります。
透明性が大事なんです。それがなければ、価値のある開発なんてできないんです。一方的に「いいんじゃねーの？」なものしか作れません。
コミュニケーションが重要なんです。
それも、とてもオープンでフランクなコミュニケーションが。

日本の方達は、どうもその辺は苦手なのでしょうかね？一般的に感じることです。決して皆がそうだと言っているのではないですけど、ある意味アメリカ人のように図々しくてもイイ部分ってあるんだと思いますよ。
「こう言うものが欲しいんだ！」 ＝＝ これが要求ですよね？
その要求だって、時間とともに変化していくし、プロジェクトが進むにあたって、徐々に形になっていくものを見て、変化していくものなんです。

要求定義なんて日々変化していくんです。
それを申し訳ないから言わないで、特に必要でもない成果物を納品されても… なんだか、すごくお金の無駄遣いに感じませんか？

 

「お客様は神様」と言うのは、言いすぎだと思います。英語でも “The customer is always right” と言う表現があります。これも、どうかと思います。
でも、要求する分には、間違いなんてないんですよね。できるかできないか…テクノロジの限界だったり、技術の限界はありますから･･･「そんなバジェットで作れる訳ない」って言う理由かも知れません。
ですが、そのようなコミュニケーションはあるべきです。

 

 

ロバート的アジャイルな開発の肝

僕だって決してエキスパートじゃないので、なんとも言いきれないのですが…
アジャイルはツールやプロセスよりも人や相互作用といった根本を改めて考えてみてください。
それは、ツールもプロセスも必要な中で、コミュニケーションとコラボレーションを最も重視している考え方なんだと思います。

個人的には、それが正しいことだと思います。

開発だけにおいたことではなく…
政治においても
ビジネスにおいても
恋愛においても…

コミュニケーションが人として最も大事なことなんじゃないでしょうか？

 

と、なんちゃって哲学者的発言をしたところで、本日は終了したいと思います。

スクリーンショットおよび各機能のより詳細な説明は、また後日記載しますね！ (だからたまに遊びに来て下さい w)
いや、ぶっちゃけ、作るのも結構大変なんですよ… (汗)

 

Eric Johnson の Cliffs of Dover を聞きながら、今晩も遅くまでお仕事を続けます…