第 1 章アジャイルコンセンサス 4 カオス 複雑 やや複雑 やや複雑 単純 確実性に近い 確実性から遠い テクノロジ Stacey のマトリックス (Stacey Matrix)0 単純なマネジメントコンテキスト、や や複雑なマネジメントコンテキスト、複雑なマネジメントコンテキスト、カオス のマネジメントコンテキストを区別するもので、スクラムやその他のアジャイル プラクティスの着想の源になってきた。 △図 1 -1 実証的プロセスモデル 建物や橋の建設のように、要件が合意され、テクノロジが十分に理解されていれば、 そのプロジェクトは「単純」または「やや複雑」の領域に入ります。理論上は、容 易でリスクの低いソフトウェアプロジェクトがこの「単純」および「やや複雑」領 域に入ることもありますが、先ほど述べたように、 こうしたソフトウェアは既に存 在するので、資金を投入する対象にはなりません。 要件が必ずしも十分に合意されていないか、テクノロジが ( 少なくとも現在のチー ムに ) 十分に理解されていなければ、そのプロジェクトは「複雑」領域に入ります。 この領域に当てはまるソフトウェアプロジェクトには、開発資金が投入されます。 そこには差別化という競争力を手に入れる大きなチャンスがあるからです。 これらのプロジェクトが「複雑」領域に入るかどうかを決定するのは、不確実さ という要因です。これはよく「カオスの境界線」と呼ばれます。また、不確実さを 備えたプロジェクトは、定義されたプロセスモデルには適しません。このようなプ ロジェクトでは、後で変更されるとわかっていながら綿密な計画を立てるよりも、 もっと流動的なオプションを作り、少しだけ試して結果を検査し、その経験に基づ

第 6 章 ( 8 ) 第 7 章 目次 開発 6.1 6.2 6.3 6.4 6.5 6.7 6.8 6.6 アジャイルコンセンサスでの開発 スプリントのサイクル 6.2.1 ディリーサイクルで回避すべき 4 つのほころび・・ コードベースの完全性の維持 6.3.1 チェックイン時にエラーを検出・ 6.3.2 シェルブとチェックインの違い・ プログラミングエラーの早期検出 6.4.1 テスト駆動開発による明瞭化・・ 6.4.2 プログラミングエラーの検出 ( 自動および手動のコードレビュー ) ・ 副作用の発見 6.5.1 予想外の動作の原因究明・ 6.5.2 実稼動環境で発生した問題の原因究明・ 6.5.3 パフォーマンスのチューニング・ バージョンのずれの防止 6.6.1 バージョン管理が必要なもの・ 6.6.2 分岐・ 6.6.3 複数のバージョンに対する並行作業 まとめ 作業の透明化 6.6.5 Eclipse または Windows シェルでの直接操作 6.6.4 複数の分岐に該当する変更のマージと追跡・ ビルドとテスト環境 7.1 ス 2 7.3 7.4 7.5 サイクルタイム 「完了」の定義 継続的インテグレーション ビルドの自動化 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 ディリービルド・ ビルド検証テスト (BVT) ビルドレポート・ ビルド定義の管理・ ビルドエージェントの管理・ テスト環境へのデブロイメントの自動化 7.5.1 テスト環境のセットアップ・・ 7.5.2 テスト環境で実稼動環境と同様のテストを行うには・・ 7.5.3 デブロイメントとテストの自動化・・ 125 126 127 127 128 129 134 135 135 148 152 152 155 156 160 160 162 162 165 166 168 169 171 172 173 175 177 178 179 179 181 181 183 183 185 189

110 5.2.2 第 5 章アーキテクチャ Ord “」をノ 。物第議アイ : 1 : 4 物第星ー 1 、 ! 新しし第■・物 コ第純麸 h 川 0 ^ 第スキ , - マエ第・ビュ、・アーをア、・キナクチサ工クスプロ。・・ラ - 第エプ - ー第物出わを第やの第第・テスト第第第コード . 材、ソックス米第 △図 5-8 この UML シーケンス図では、シーケンスに変更案を追加したり ( 中央の色が違っ ている部分 ) 、補足説明のコメントを追加したりしている。 は御を維持する 創発的ソフトウェアアーキテクチャで最も難しい課題は、構造をきちんと制御す ることです。特に、依存関係のレイヤーを明確にすることが必要です。システムは 時間の経過と共に進化し、チームには新しい開発者が入ってくるため、脱線防止用 のガードレールが必要です。レイヤーを明確に維持していれば、システムのリファ クタリングや保守を容易に行うことができます。もしその部分がおろそかになって いれば、ただの泥団子になる危険性があります。 アーキテクチャはホワイトボード上にいくつかのポックスと線を描いて表現され ることがよくあります。 VisuaI Studio でも同様に、目的とする論理構造を「レイヤー 図」と呼ばれる設計レイアウト上に描くことができます。レイヤー図は、レイヤー 間で許容される参照を描画することによって、依存関係を制限するレイヤーを視覚 的に表現するもので ( 図 5-9 を参照 ) 、論理的 / 概念的なビューとして手動で作成し ます ( 頭の中に描いた論理構造を自動的に取り出して見せてくれるようなツールは ありません ) 。

索 引 281 … 21 ムリ . Microsoft Visual Studio Scrum (Scrum) .. MSF for Agile Software Development (MSF Agile) .. . … 21 MSF for CMMI Process lmprovement (MSF CMMI)... 22 プロセスモデル 実証的プロセスモデル ... 定義されたプロセスモデル… プロダクトオーナー プロダクトパックログの手入れ .. リリース計画 ... プロダクトオーナーシップ… プロダクトバックログ… 手入れ… プロダクトバックログ項目 . テスト .. 分岐 .. リリース別分岐 .. 文書化 ... 分析症候群 . 平均故障間隔 . 平均復旧時間 . ペーバープロトタイピング .. ベルソナ .. べロシティ . 変更セット .. 第ほ 法令遵守 .. 保守性 .. ポトムアップサイクル .. ■ま ーティング .. 毎日の現場ミ 満足因子 .. ■み 魅力 .. 魅力性 .. ムダ… 無駄の削減 .. テスト .. 無駄の排除 .. ムラ .. ■め モニター容易性 .. .. 9 , 22 … 51 0 ゆ ユーサーエクスペリエンス .. ... 46 , 50 ユーサーストーリー … 7 , 9 , 25 , 28 テストの状態… ユーザビリテイラボ .. … 21 , 25 .... 206 ユースケース図 .. … 162 ... 165 要件の適切な粒度 .. . … 163 … 42 要件のレベル数 .. … 30 要件劣化 .. 余分な処理 .. … 68 ■り . … 68 リスク管理 .. リスクテスト . … 53 リファクタリング… … 8 , 80 リリース .. ... 129 リリース計画 . リリースビション ... リリース別分岐… メトリクス .. … 69 … 67 … 10 , 21 , 26 , 54 … 203 … 64 0 9 9 -1 … 42 . … 230 … 136 .... 7 , 24 , 25 … 52 … 52 , 54 ... 163 .. 42 … 68 , 103 累積フローグラフ .. ・れ … 165 レイヤー図 .. ... 34 , 77 レッド / グリーン / リファクタリング .. … 56 ロードテスト . ... 60 … 67 ワイヤーフレーム ... … 1 1 割れ窓 ... ... 6 , 10 .... 205 .. 194 … 196 … 136 ... 222 , 226 … 62

8 1.5.1 第 1 章アジャイルコンセンサス 潜在的に 出荷可能な インクリメント ディリー スクラム スプリント スプリント バックログ プロダクト バックログ △図 1 -3 スクラム手法の中心的な概念図。この図は管理的な視点で見たフローをよく表し ている。 スクラムの核になっているのは、「自己組織化されたチーム (self-managing team) 」という概念です。従来型の階層構造の下でプロジェクトマネージャーに管 理されるチームとは異なり、自己組織化されたチームでは、透明性の高いメトリク スを使って、自分たちの進行中の作業を自ら制御し、フローのべロシティ (velocity) を高めていきます。チームのメンバーには、無駄の削減に必要ならいつでも改善を 行うことが奨励されます。スプリントケイデンスでは、少なくとも 1 か月に 1 回は「ふ りかえり (retrospective) 」を行い、すぐに実施できるプロセス改善を洗い出し、優 先順位を付けることが定められています。スクラムでは、このサイクルを「検査と 適応 (inspect and adapt) 」と表現します。前述の温度調整の例よりも微妙な意味合 いを含んでいますが、発想は似ています。実際のプロセスとその結果を観察するこ とで、プロセスに漸進的な変更を加えていくのです。 潜在的に出荷可能 スクラムでは、透明性を保証するために、各スプリントの終了時に「潜在的に出 荷可能なインクリメント (potentially shippable increment) 」と呼ばれる、実際に -4 く 動作するソフトウェアの提出を規定しています。たとえば、コンシューマー Web サ イトに取り組んでいるチームならば、ある 1 つのスプリントではカタログ検索の機 能に集中的に取り組むといったことが考えられます。有効なチェックアウトプロセ

( 14 ) 日本語版序文 返しです。今はその均衡期間と考えられます。 こ 10 年間は、ソフトウェア開発にとって非常に価値のある 10 年間でした。現 在の我々は、従来よりも無駄を抑え、プロセスの透明性を高めつつ、顧客のために より良い価値フローを生み出す方法を知っています。これは、アジャイルプラクティ スに則った、小規模で機動性の高い開発チームによって導かれるボトムアップの変 革です。これはグローバルな変革であり、エストニア、中国、プラジル、インドの ように互いに似たところのない場所でも同様の変革が起きています。 現在のように経済が成熟した時代では、変化に柔軟に対応することが必要です。 ソフトウェアのサプライチェーンはサプライエコシステムに変容しつつあります。 ソフトウェア開発も、すべてを一から設計して作成する時代ではなくなっています。 その代わりに、再利用できる部品を探し出し、新しいものを迅速に試し、再利用や 外部調達ができないものだけを作成します。皆さんがお使いのスマートフォンは、 このサイクルのメリットを示す好例です。 大野は短期実験の名手でした。トヨタは何十万回もの小さな実験と改良を繰り返 すことで、世界最大の製造メーカーになったのです。しかし、これらの実験は効率 性を目的としたものでした。 大野の場合とは異なり、今日の我々はソフトウェアの有効性を目的とした実験を 行います。我々が行うのは「パプリック」で「外向き」のテストです。テストの対 象になるのはプロダクトバックログ項目 ( 従来の用語で言えば「要件」 ) であり、顧 客価値を提供するためにふさわしいものを作成しているかどうかが焦点になります。 アジャイルエンジニアリングのプロセスと文化がしつかり根付いていなければ、 の実験は実施できません。本書が、継続的フィードバックという新たな世界を知る ための一助になれば幸いです。 Sam Guckenheimer 2012 年 4 月 ワシントン州レドモンドにて

8.10 まとめ まとめ 233 この章では、高い機能性を発揮しているチームがアジャイルコンセンサスに従っ て実行するテストについて説明しました。アジャイル開発者は単体テストしか実行 しないとか、アジャイルチームにはテスト担当者の仕事はないという間違った認識 が一部に見られますが、それどころか、 PBI のテストは「完了」の定義にとって絶 対必要なものです。実際、チームは PBI をできる限り短期間で受け入れテストから 完了へ移行させるように作業を進める必要があります。 VisuaI Studio はユニークなアプローチによってアジャイルチームをサポートしま す。これは、修正されたバグのみが顧客価値をもたらし、バグが報告されても修正 されなければ、それに関連する作業は ( 顧客価値という点では ) すべて無駄である、 という考え方から始まっています。 MTM は、検出されたすべてのバグを無駄なく 活用するために設計されたもので、開発者がテストケースを再現する手間を省き、 収集されたデータに基づいてすぐに作業を始められるようにします。 また、 VisuaI Studio ではロードテストを早い段階で実行できるので、パフォーマ ンスに影響する設計ミスを早い段階のスプリントで検出でき、時間があればリファ クタリングを行って設計を変更することができます。仮想環境での構成テストはビ ルド自動化のワークフローに組み込まれるので、実稼動環境に近い環境ですぐにテ ストを実行することができます。 これは基本的にはコラボレーテイプなテスト方法です。多分野にわたるチームが 一体となり、共通の目標に向かって作業することができます。これにより、従来的 なチーム間の壁を壊し、面倒な引き継ぎを回避して、顧客価値のフローと無駄の削 減に的を絞ることができます。 次の章は、これまで説明してきた原則を Micr 。 s 。 ft 社内でどのように実践したか という経験談です。すべてがパーフェクトに進んだわけではなく、検査と適応を繰 り返さなければなりませんでした。これまでに紹介してきた製品群がどのような経 緯をたどって完成したのかがわかるでしよう。

214 第 8 章テスト 8.3.2 ー探索的テストの必要性 高度にスクリプト化されたテストや自動テストは、 Boris Beizer が「殺虫剤のパ ラドックス (pesticide paradox) 」と名付けたリスクと隣り合わせです。・ バグの予防または検出のためにどのような方法を使ったとしても、その方法が効 かないバグがわすかに残ってしまうものだ。 これは言い換えると、ソフトウェアは既存のテストに対して免疫を持っ可能性が あるということです。このパターンは、回帰テストだけを行っていて、テストプー ルが非常に安定している場合に特に問題になります。探求的テストは、殺虫剤パラ ドックスに対する最善の解毒剤です。微生物が殺虫剤に対する抵抗力を次第に身に 付けるのと同じように、ソフトウェアも古いテストでは次第にバグが見つからなく なります。そこで、残っているバグを見つけるために、テストも進化させる必要が あります。通常とは異なる動作が現れるまで、データ、シーケンス、環境、前提条件、 シナリオの複雑さ、エラーからの復旧の選択肢などを変更してみましよう。 手動テストケースのところで説明しましたが、 MTM でテストケースを使用して 探索的テストを実行すると、非常に多くのバグ情報を入手することができます。探 索は好きなだけ行うことができますが、探索的テストセッションでバグを登録する 浦恒央訳 ( 日経 BP 社、 1994 年 ) 【邦訳】「ソフトウェアテスト技法ー自動化、品質保証、そしてバグの未然防止のために」小野間彰、山 Boris Beizer, SQ 尹観尾花、ⅵ〃 g 花勧ⅲ 4 ″い (Boston: lnternational Thomson Computer Press, 19 ) , 9. ② れにより、探索の無関係な部分を除外できます。 ときには、記録するデータの量を必要に応じて決定できます ( 図 8-11 を参照 ) 。

第 7 章ビルドとテスト環境 7.6.3 ーフロー内の非効率を検出する 開発チームには、各スプリントの期間内で、実際に動作する、テスト済みの、統 合されたソフトウェアのデリバリーが求められます。ソフトウェアが BVT に合格 しない場合や、 BVT および単体テストが不十分である場合、あるいは変更箇所がテ スト中に動作しなくなった場合は、その問題を根本から解決する必要があります。 Visual Studio では、フロー内の非効率性やその兆候を、次に紹介するレポートを通 じて見つけることができます。 残存作業 継続的なフローを追跡するための 1 つの方法は、開発からテスト、完了へと進む 作業のフローを追跡することです。図 1-4 で示した「ストーリーの概要」レポート も便利ですが、作業のフローを追跡するためには、累積フローグラフ・が役立ちま す ( 図 7-24 を参照 ) 。このグラフでは、フローを時間経過に沿って把握できます。 イテレーション ( スプリント ) 内の 1 日ごとの状況、またはチームプロジェクト内 のイテレーション ( スプリント ) ごとの状況を知るためには、これが大いに役立ち ます。 196 140 120 100 7 宿 7 ハ 5 7 / 靆 7 / 四 8 / 5 町 12 町四 8 / 9/2 9/9 どのくらいの作業が残っていて、それがいつ完了するかを把握する。この累積フ ローグラフでは、残存作業の数を、そのスプリント内で「解決済み」および「終了」 の状態に到達する予定の P 引の数で測定している。 色分けされた各データ系列は ( 紙面上はグレースケールで掲載 ) 、その日付にそれ ぞれの状態に到達したストーリーの数を表しています。全体の高さは、そのイテレー ション ( スプリント ) で行われる作業の総数です。 0 累積フローグラフをソフトウェアに導入したのは Anderson である。 Anderson, Agi1e M 〃住 g 群〃夜な r SQ 〃ル尾 Engineering, 61. △図 7-24

4.1 定義されたプロセス制御よりも実証的プロセス制御 75 いました。・鉄の三角形の考え方では、プロジェクトマネージャーが管理する可変 要素は、「時間」、「機能」、「リソース」 ( 人的資源も含む。これは生産単位に還元さ これを含めると図 4-2 のような四面体になります。 れる ) の 3 つに限定されます。この 10 年間で、新たに「品質」という第四の次元が 認識されるようになっており、 機能 △図 4-2 鉄の三角形 ( または四面体 ) では、「定義されたプロセス」の古典的概念に従い、 プロジェクトをタスクの固定的集合と見なす。この四面体のいずれかの面を拡大 するには、他の面も拡大する必要がある。 Steve McConnell は fRapid DeveIopment 』の中で、鉄の三角形について次のよ うに述べています。 三角形のバランスを保つには、スケジュール、コスト、成果物のバランスをとる 必要がある。この三角形の成果物のコーナーを拡大するには、コストとスケジュー ルのどちらか一方または両方を拡大する必要がある。これは他のどのコーナーに ついても同様である。三角形のいずれかのコーナーを変えるには、残りの 2 つのコー ナーの少なくともどちらかを変えてバランスをとらなければならない。・ この考え方で言うと、プロジェクトは最初にある程度のリソースと時間を用意し ています。機能または品質を変更する場合は、時間またはリソースを増やす必要が あります。すべての面がつながっているので、どれか 1 つを大きくするなら他も大 きくしなければなりません。 このパラダイムは広く普及していますが、むしろ逆効果を招くモデルです。たと えば、プロジェクトを円滑な価値フローを生み出すためのパイプだと考えてくださ い。鉄の三角形は、パイプの特定の点における断面のようなものです。パイプの下 3 Steve McConneII, 犬叩 D ど比 / 0 〃〃肥襯 (Redmond, WA: Microsoft Press, 1996 ) , 126. ②たとえば、 PMBOK (http://www.pmi.org/) の教えを参照。 ( アスキー、 1998 年 ) 【邦訳】「ラピッドデベロップメントー効率的な開発を目指して」日立インフォメーションアカデミー訳