第 10 章継続的フィードバック 将来を予測する最も良い方法は、将来に投資することである。 13 —Alan C. Kay 8 2 3 5 △図 10-1 1202 年、 Fibonacci は著書 fLiber Abaci] ( 算盤の書 ) の中で、のちにフィポナッ 数列であることが現在わかっている。およそ 1 , 000 年後の現在、この数列が見積 チ数列と呼ばれる数列を紹介した。これは自然界のさまざまなところで見られる 偶然ではないだろう。・ もりで再利用されていること ( 「第 3 章プロダクトオーナーシップ」を参照 ) も ① AIan C. Kay, "Predicting The Future," & a' ! ル Engineering 1 : 1 (Autumn 1989 ) この文書は、 http://www.ecotopia.com/webpress/futures.htm で参照できる。 ② http://www.mathacademy.com/pr/prime/articIes/fibonac/fibonac_8.gif および http://www.mathacademy.com/pr/prime/articles/fibonac/in dex. asp 、 1-6.
第 6 章開発 データの多様化によるテストの強化 今日では、セキュリティとクラウドという二大トピックにより、優れたエラー処 理や否定テストの必要性に対する意識が高まっています。単体テストについて考え る場合は、まず良いテストリストを作成することが大切です。・このとき、出力、 呼び出されるメソッド、コードバス、エラー条件という 4 つの変数について検討し ます。これらの変数の多様性が最も大きくなるような入力を使用すべきです。ェラー 条件を幅広く調べる否定テストも含める必要があります。工ラー処理コードに足り ない点を明らかにするという目的でテストデータを使用する場合もあるかもしれま せん。まだ対処していないエラー条件を見つけ出すために、どのようなエラー条件 があり得るかを一緒に考えてくれる同僚やテスト担当者が必要かもしれません。・ http://msdn.microsoft.com/ja-jp/library/ms182527.aspx ・「方法 : データドリプン単体テストを作成する」 詳細については、次の MSDN トピックを参照してください。 ください。 VisualStudio ではこれを簡単に行うことができます。 データや構成をいろいろと変えて、単体テストの使用範囲を広げることを検討して テストで使用するデータと構成にバリエーションを持たせる 年 1 月号 ) 。現在は http://http:〃www.exampler.com/testing-com/writings/omissions.html で参照できる。 ⑨ Brian Marick, "Faults of Omission. " 初出は「 Software Testing and Quality Engineering Magazine 」 ( 2 開 0 たとえ ( よ、 http://www.exampler.com/testing-com/writings/short-catalog.p df SQL データベースに保存し、自動テストで使用できます。 のテストデータを生成できる機能があります ( 図 6-20 を参照 ) 。生成したデータは テストに使える実データがない場合には、自分で定義したルールに基づいて架空 データを提供してもらうのも簡単です。 タソースにバインドできるので、対象分野に詳しい人の協力を仰いで有効なテスト を参照 ) 。単純な CSV ファイルや ExceI のスプレッドシートなど、さまざまなデー Visual Studio では、多様なデータを使ったテストを簡単に実行できます ( 図 6-19 http://msdn.microsoft.com/ja-jp/Iibrary/dd286743.aspx ー「コンピューターの設定およびテストの設定を使用した診断情報の収集」
2 第 1 章アジャイルコンセンサス の原則を採用するようになっており、ソフトウェア工ンジニアやその他のプロジェ アジャイルの採用は現実のものとなっている。あらゆる業界の組織がアジャイル チ社は次のように表現しています。 います。今は「アジリティ (Agility) 」こそが主流なのです。フォレスター・リサー 今では経営陣のほうがアジャイルプラクティスの導入を強く支持するようになって 答者が全体の 90 % に上りました ( 前年は 84 % ) 。・アジャイルの初期の時代とは逆に では、職場でアジャイル開発プラクティスをある程度以上採用していると答えた回 それから約 10 年後の 2010 年に、 91 か国 4 , 770 人の開発者を対象に行われた調査 ニフェスト (Agile Manifesto) 」を発表しました。 0 に彼らはアジャイルアライアンス (AgiIe AIIiance) を設立し、まず「アジャイルマ いた比較的「ヘビーな」開発プロセスに代わるもの、という発想でした。その週末 イトウェイト開発手法」について話し合いました。これは、当時一般的に使われて ちの 1 つです。 2001 年のある週末、 17 人の著名なソフトウェア技術者が集まり、「ラ リーンは、一般に「アジャイルプロセス」と呼ばれるいくつかのアプローチのう いかと考えていました。 フトウェア工ンジニアリングにおいてもリーンが大きな影響を及ばし得るのではな 題に立ち向かわねばなりませんでした。この期間、多くの業界リーダーたちは、ソ 経験し、企業内の IT 部門も、自分たちのビジネス価値を証明するという新しい課 もちろん、ソフトウェア業界も 2000 ~ 2002 年と 2008 ~ 2010 年に多くの破産を アジャイルの起源 【邦訳】 http://www.agilemanifesto.org/iso/j a/ http://www.agilemanifesto.org ④ あらゆる人がそこからより多くをつかもうとしているように見えます。 あらゆる業界アナリストがアジャイルを推奨し、あらゆる経営者がこれを採用し、 クトチームメンバーがアジャイルの技法を採用している。・ agility/q/id/5618 / レ 2 http://www.forrester.com/rb/Research/agile—development_mainstream_adoption—has—changed— in ReaI-WorId Adoption of Agile Methods", 17. 次のページから入手できる。 0 Dave West an d Tom Grant, "Agile DeveIopment: Mainstream A doption Has Changed Agility Tren ds http://agilescout.com/5th-annual-state-of-agile-survey-from-version-one/ 3 "5th AnnuaI State of Agile Survey" by Analysis. Net Research. 次のページで参照できる。
166 6.6.5 第 6 章開発 状況によっては、分岐階層において直接的な分岐関係のない分岐同士の間で変更 をマージすることが必要になる場合があります。 Visual Studio はそのような「べー スレスマージ」にも対応しており、通常のマージと同じように適切に追跡を実施で 変史セットのトうッキンり きます ( 図 6-43 を参照 ) 。 △図 6-43 「べースレスマ ージ」により、直接の分岐関係のない分岐に変更セット 39 をマ ーン。 分岐戦略を定める ー MSDN トピック「計画的な分岐」 CodePIex にある分岐のガイドを参照してください。 分岐を使って開発を構造化する方法の詳細については、 次の MSDN トピックと、 http://msdn.microsoft.com/ja-jp/library/ee782536.aspx ■ CodePlex 「 Visual Studio Team Foundation Server Branching Guide 」 6-45 を参照 ) 。 TooIs により Windows 工クスプローラーから実行したりできます ( 図 6-44 と図 せん。多くの機能は、 Eclipse (Team ExpIorer Evertwhere) や、 TFS Power トチェックイン ) を使用できるのは、 Visual Studi 。の統合開発環境だけではありま シェルプセット こまでに紹介した機能 ( チェックインポリシー EcIipse または Windows シェルでの直接操作 http://vsarbranchingguide.codeplex.com/ 、分岐、ゲー
116 第 5 章アーキテクチャ コンポーネント図、クラス図、シーケンス図という、抽象度がより低い 3 つの図は、 提案されたアーキテクチャまたは既存のアーキテクチャを文書化する方法です。ク ラス図とシーケンス図は、コードからのリバースエンジニアリングによって生成で きます ( 図 5-15 、図 5-16 、および前掲の図 5-7 を参照 ) 。・チームの体制によっては ( 特 に分散したチームでは ) 、スプリント計画の第 2 段階、つまり選択した PBI をその スプリントでどのようにして潜在的に出荷可能なソフトウェアのインクリメントに 仕立てるのかを決定するときに、これらの図をホワイトボード代わりに使って、アー キテクチャ設計上の決定事項を文書化することがあります。 cmp UMLComponentDiagram1 新 is iswhatwethinkwe'redoing. Simplification tO po 減供血 氈 ( & m hO 士 . し爪 0t0 SQL 、 CQtpppnent1 R 中 0 引 / ADO. Net ADO D 砒 ab ~ Moæ 加行 u は u △図 5-15 LINQ t0 SQL 論理ビューである。 のではなく、それよりも高い抽象度でコンポーネントアーキテクチャを表現した UML コンポーネント図は、コードや Visual Studio のプロジェクトを直接表すも ・【訳注】コードのリバースエンジニアリングによる UML クラス図の生成機能は、 Visual Studio 2010 Feature pack 2 (http://msdn.microsoft.com/ja-jp/vstudi0/ff655021.aspx) で提供されている (MSDN サ プスクリプション会員限定 ) 。詳細については MSDN トピック「方法 : コードから UML クラス図を作 成する」 (http://msdn.microsoft.com/j a-j p/Iibrary/ff6578()6. aspx ) を参照。
3 コ プロダクトオーナーシップとは 49 ー仕様拡大の問題 : 沈没する船 3.1.3 スウェーデン観光の目玉の 1 つに、戦艦ヴァーサ号があります。ヴァーサ号は 1628 年のある穏やかな天候の日に進水しましたが、港から 1 マイルのところで沈没 しました。ヴァーサ号は、当時のスウェーデンの軍事力を示すために最強の威容を 誇る戦艦として建造されたもので、国王の命により、ありとあらゆる武器が搭載され、 華麗な装飾が施されていました。しかしこれらの装備が仇になって、いざ航海とい うときに転覆したのです ( 図 3-3 を参照 ) 。 愚かなスウェーデン国王を見下すのは簡単ですが、現代のほとんどすべての兵器 システムも同じ仕様拡大の問題を抱えています。長い調達サイクル、迅速なフィー ドバックの欠如、そして要件を積み上げるステークホルダーが多すぎることが、今 日でも 400 年前と変わらす問題になっています。 い第ゞー 三、さ ヴァーサ号は 300 年間海中にあっても崩壊しないほど頑丈に造られており、現在 では完全に復元されている。不幸だったのは、膨れ上がった要件のせいで、航海 に適さないほど重装備になっていたことである。・これは仕様拡大の端的な例と言 える。 要件劣化の問題 : 無駄な装甲 3.1.4 近年の軍事史の中でもたびたび見られるもう 1 つの教訓は、「要件は劣化する」と いうことです。米軍と NATO 軍は最近の中東戦争において、かっての欧州戦争で 見られたような重火器による正面攻撃を想定し、それに耐えるよう設計された装甲 車両を投入しました。しかし残念ながら、両軍が受けたのは携帯電話から起爆する 即製爆発装置 (IED) による爆破攻撃であり、装甲車は役に立ちませんでした。 ⑥ http://mobile.vasamuseum.com/Default.aspx?s=84&p=3817 および http://www.mmk.su.se/—magnuss/images/vasa-hu112.jpg
178 7.4.1 第 7 章ビルドとテスト環境 全般 トリカー ワークスペース ヒルドの既定値 アイテム保持ポリシー フロセス △図 7-5 Team Fou ーⅵヒルドは Windows Workfiow (XAML) ファイルで定義されているビルドプロセステンプレートを使用します . このテン プレートの動作は、道択したテンプレートで提供されるヒルドプロセスパラメーターを設定することでカスタマイズできます . ビルドプロセステンプレート : 気定テンプレート ヒルドプロセスパラメーター ( P ) : 1. 必須 t' ヒルトする項目 コード分析の実行 3. 詳第 目動テスト ワークスペースのクリーン ログの詳細度 ヒルド番号形式 ) ソースおよびシンボルサーバ - の設定 詳を ) 表示 ( D ) 既定のプラットフォームと物成で $ / ( まーー ソースのインデックス作成 $(BuildDefinitionName)-$(Date:yyyyMMdd)$(Rev: ・「 ) を般 . と一致するアセンプリでテストを実行する このダイアログでビルド定義を作成できる。これにより、チームプロジェクト全 体に対してディリービルドやその他の定期的なビルドを自動的に生成できる。 ビルド定義の構成 Visual Studio でのビルド定義オプションの詳細については、 を参照してください。 「ビルド処理の定義」 http://msdn.microsoft.com/ja-jp/library/ms181715.aspx 0 ディリービルド 次の MSDN トピック CI とディリーピルドにそれぞれ異なるビルド定義を使用すると、ディリービルド を介してディリーメトリクスを収集できるようになります。・ディリービルド用の ビルド定義を作成するときは、少なくとも、インストール用のバイナリを生成する だけでなく、すべてのコード分析と BVT を実行し、プロジェクトの健全性追跡の ためのメトリクス生成を行うようにします。これにより、的確なトレンドをメトリ クスウェアハウスに収集し、「第 4 章スプリントの実行」で使用したようなレポー トやダッシュポードに表示することができます。 3 たとえば次のページを参照。 http://www.stevemcconnell.com/ieeesoftware/bp04.htm
第 3 章プロダクトオーナーシップ もあります。たとえば、「 1 , 000 ューザーという負荷条件で、発注の 95 % に対して 3 秒以内に確認が表示されなければならない」というパフォーマンス要件は、発注の シナリオに関する具体的なパフォーマンスサービス品質です。このようなサービス 品質は新たな PBI になります。 すべてのサービス品質がすべてのシステムに当てはまるわけではありませんが、 自分の担当システムではどれが重要なのかを把握しておく必要があります。サービ ス品質には大きなアーキテクチャ要件やリスクが含まれていることが多いので、プ ロジェクトの早い段階でステークホルダーと協議する必要があります。 検討すべきサービス品質をすべて網羅した決定的なリストはありません。標準も いくつか存在しますが、標準は技術が発展するにつれて古くなりがちです。・たと えば、セキュリティ問題とプライバシー問題は現代システムの最重要課題であるに もかかわらず、多くの主な標準では扱われていません。 0 以降の 4 つの項では、プロジェクトで考慮すべき最も一般的なサービス品質をい くっか紹介します。 セキュリティとプライバシー 3.4.1 インターネットの普及とともに、「セキュリティ」と「プライバシー」は、すべて のユーザーにとって無視できない関心事になりました。この 2 つのサービス品質は、 アプリケーションの開発と運用の両方において重要な意味を持っており、顧客側も、 どのような対策が講じられているかを知りたがるくらい高度な知識を持つように なっています。最近では、セキュリティとプライバシーは政府規制の対象になりつ つあります。 午可されていないユーザー、ウイルス、ワーム、スパイウェ ■セキュリティ ア、およびその他のエージェントによるアクセスと破壊を防ぐソフトウェア 機能。 個人情報の不正なアクセスまたは表示を防ぐソフトウェア ■プライバシー 機能。 66 一三ロ ・たとえば、 ISO/IEC 9126 / 2 開 1 および IEEE Std 610.12-19g 。これらの例の多くはここから得られる。 Rehabilitation Act ( リハビリテーション法 ) 、第 504 条、 29 U. S ℃ . 794d (http: 〃 www.usdoj.gov/ cr レ 508 / 5081aw. html で参照できる ) 0 最近は Payment Card lndustry Security Standards Council (http://www.pcisecuritystandards.org/ index. shtml) などで少しずつ見られるようになっている。
はじめに ( 23 ) もちろん、すべてのクライアントは TFS に対してデータの読み書きを行い、それ ぞれの状況はダッシュポードで確認できます ( 通常は SharePoint でホストされま す ) 。 ExceI Services または SQL Server Reporting Services を使用すると、これら のダッシュポードをカスタマイズできます。ダッシュポードの例については、第 4 章で詳しく説明します。 以前のバージョンとは異なり、 VisuaIStudi02010 にはロールべースのエディショ ンがありません。これは、多分野のメンバーから成る自己組織的なチームという理 念に従った結果です。 VisualStudi02010 では、スムーズな移行とエンドッーエンド のフローという点を特に重視しています。 Visual Studio の詳細情報については、 Visual Studio 製品サイト (http://www.microsoft.com/japan/visualstudio/) をご覧 ください。
103 5.1.3 5.2 既存のアーキテクチャの調査 保守性を考慮した設計 良いアーキテクチャには保守性とサポート容易性が求められます。良いアーキテ クチャは、後で他人がコードを保守するときの作業のしやすさを重視した設計になっ ています。このことの重要性は、 2 年前に書かれた見たこともないコードを相手に するはめになった開発者の立場を考えてみればよくわかるでしよう。 もちろん、保守性を考慮したシステムは一度設計すれば済むというものではあり ません。その代わりにチーム全体が、設計原則を守り、できる限り既知のパターン を使うということに合意する必要があります。そうすれば、元のコード作成者以外 の人でも簡単に保守できるようになります。長年実践されてきたプラクティスの多 くは保守性を考慮したものになっており、 KISS ・ (Keep it simple, Stupid) や YAGNI ・ (You ain't gonna need (t) など、さまざまな手法があります。また、コー ド関連のパターンに加えて、アプリケーションライフサイクル管理 (ALM) やチー ム作業に適用されるパターンもあります ( その 1 つが、次の章で説明する分岐パター ンです ) 。 3 httpン//c2.com/xp/YouArentGonnaNeedIt.html ② http://c2.com/cgi/wiki? KeepItSimpIe 当する開発者は、既存のシステムをつつがなく修正し、利用できるところは利用す きる自動テストがない場合は困難を極めます。したがって、既存コードの変更を担 しい仕事です。特に、将来的なリファクタリングのセーフティネットとして利用で 荷可能でなければならないからです。レガシーコードベースに変更を加えるのは難 ないことを確認する必要があります。なぜなら、スプリントの成果物は潜在的に出 チームは新しい機能を追加するだけでなく、その機能が既存の機能の妨げになら となるのが、レガシーアプリケーションを引き継ぐがゆえの複雑さです。 proj ect) 」と呼ばれます。プラウンフィールドプロジェクトでチームの大きな課題 ない「更地」から始まるプロジェクトは「グリーンフィールドプロジェクト (greenfield (brownfield project) 」と呼ばれます。それに対して、既存のコードをまったく含ま 開発されている土地を扱うという意味で、「プラウンフィールドプロジェクト 開発者の多くは、既存のシステムに属するコードを取り扱います。これは、既に 5.2.1 ーコードを理解する 既存のアーキテクチャの調査