連載
大規模プロジェクトにアジャイルを適用する方法−1:The Rational Edge (28)(4/4 ページ)
The Rational Edge より:本稿では、通常ならばアジリティの範囲を超えると見なされる大規模プロジェクトにアジャイルソフトウェア開発手法を適用するテクニックを説明する。筆者は、ソフトウェアアーキテクチャチームが地理、文化、あるいは専門を超えてアーキテクチャ部分に重点を置くコーディングチームに提供できるコミュニケーション能力について説明している。
まとめ:大規模アジャイルを成功させるポイント
以上、チームのサブセット(コードの疑似完全性を生み出すところ)のためにアジリティで理想的な状況作りを目的とする大規模プロジェクトが、チームで構成されたチームや、チーム間の効率的なコミュニケーションを確保することと、小規模プロジェクトでチームごとに期待される外部インターフェイスをインプリメントすることを主な目的とする補助チームによって徐々にまとまっていく様子を解説してきた。いままでのポイントを個条書きにしてみよう。非常に規模の大きいプロジェクトは以下のように進められる。
- チームの隅から隅までをカバーし、アーキテクチャチーム、管理チーム、あるいは統合チームをコミュニケーションの接点として利用するコミュニケーション
- チームレベルおよびチーム間レベルにおけるスクラムなどの促進および解決手法
- チームレベルおよびチーム間レベルにおける構築とリリース
- チームレベルおよび全体レベルで管理される問題とリスク
- すべてのチームが全体の同じリズムに合わせて作業することが好ましい
これを成功させるためには以下のような要因が重要になる。
- 補助チーム(アーキテクチャおよび統合)は、ほかのチームの補助に徹し、その逆になってはならない。開発チームを可能な限り効率的にすることが役割であるため、補助チームは外部とのコミュニケーションやリソースによって開発チームのニーズに可能な限り迅速に対処しなくてはならない。例えば、顧客やほかのチームとのコミュニケーションなどが考えられる。
- コード開発に携わるチームは、完成システムという究極の目的に留意する必要がある。これは自分のチームの目的、パフォーマンス、スケジュールなどより優先される。インフラに携わるチームは、自分たちの顧客、つまりほかのチームのニーズに敏感でなくてはならない。
- 文書化や形式化 (「儀式度」とも呼ばれる)は徐々に取り入れ、組織が効率的になるタイミングと場所に限定する必要がある。
- チームを超えたコミュニケーションや依存を最小限に抑えるようチーム構造を構築する場合はアーキテクチャが重要になる。
プロジェクト全体は、システムに関する判断を下せる有能で裁量権もある顧客担当者と迅速にコミュニケーションが取れなくてはならない。プロジェクトにはコード、テスト、およびテストスイートを短時間で処理できるよう管理し、変更管理をサポートするパワフルなツールが必要だ。そして、どのプロジェクトでも同じだが、最も重要な要素は技術力と意欲のある人材である。
【謝辞】
この解説は、2003年2月に開催されたCanadian Agile Workshop in Banffの参加者との会話、2003年3月および2004年3月のUSC提携調査論評、そしてRational Software Corporation(現IBM Rational)のGary Pollice、Walker Royce、Joe Marascoや、NRCのHakan Erdogmusによる社内論評が大いに役立っている。
【参考】
▼H. Erdogmus著、「Let's Scale Agile Up」、Agile Times, vol. 2、2003年刊、6-7ページ
▼P. B. Kruchten著, 「The Rational Unified Process」: An Introduction, 2nd ed. 2000年Addison-Wesley刊
▼A. Egyed, B. W. Boehm、D. Port、 M. Abi-Antoun共著、「Guidelines for the Life Cycle Objectives (LCO) and the Life Cycle Architecture (LCA) Deliverables for Model-Based Architecting and Software Engineering (MBASE)」、USC Los Angeles校、USC Technical Report USC-CSE-98-519, 1999年刊
▼P. Kruchten著、 「The 4+1 View Model of Architecture」、IEEE Software, vol. 6、1995年刊、45〜50ページ
▼M. Beedle、K. Schwaber共著、「Agile Software Development with SCRUM」、2002年Prentice-Hall刊
▼L. Brownsword、P. Clements共著、「A Case Study in Successful Product Line Development」、Software Engineering Institute、Technical report CMU/SEI-96-TR-035、1996年刊
▼K. Toth、P. Kruchten、T. Paine共著、「Modernizing Air Traffic Control Through Modern Software Methods」、38th Annual Air Traffic Control Association Conference、テネシー州ナッシュビル:ATCA、1993年刊
▼P. Kruchten著、「Iterative Software Development for Large Ada Programs」Proc. Ada-Europeカンファレンス、スイス、モントルー、vol. LNCS 1088、A. Strohmeier, Ed.:Springer-Verlag, 1996年刊、101〜110ページ
▼P. Kruchten、C. J. Thompson共著、「An Object-Oriented, Distributed Architecture for Large Scale Systems」、Proc. of Tri-Ada'94、ボルティモア、1994年11月:ACM、1994年刊
▼P. Kruchten著、「The Software Architect, and the Software Architecture Team」、Software Architecture, P. Donohue, Ed.、1999年、Kluwer Academic Publishers刊、565〜583ページ
本記事は「The Rational Edge」に掲載された「Scaling down large projects to meet the agile “sweet spot”」をアットマーク・アイティが翻訳したものです。
「The Rational Edge」バックナンバー
- トランザクション管理の複雑性を克服する(パート1)
- アジャイルとシステムテストの新たな関係(後編)
- アジャイルとシステムテストの新たな関係(前編)
- アジャイル開発の広範な普及を目指して
- 見積もりの精度 Accuracy of Estimation
- 複雑性を理解する(後編):ソフトウェアの複雑性を手なずける
- 複雑性を理解する(前編):ソフトウェアが複雑なのは仕方がない?
- 鈍重な開発チームは鈍重なシステムを作る?/パート3:役割とポリシー(後編)
- 人事評価と開発者のモチベーション/パート3:役割とポリシー(中編)
- 自己管理型チームの利点と弱点/パート3:役割とポリシー(前編)
- プロセスはチャンスが訪れるたびに改善する/パート2:プロセスと基準(後編)
- 開発プロセス導入のアンチパターン/パート2:プロセスと基準(中編)
- 反復開発の「ここはぜひカバーしたいポイント」/パート2:プロセスと基準(前編)
- 開発プロジェクト「統治」のピンポイント解説/パート1:原則と組織(後編)
- 開発プロジェクトを「統治」するベストプラクティス/パート1:原則と組織(前編)
- 初歩の「Perl」「Python」「Ruby」
- ビルドが全滅する原因/プロジェクトの状態を評価する:パート2(後編)
- 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する:パート2(前編)
- UMLを使ったビジネスモデリング(後編):そうだったのか! システムユースケース
- UMLを使ったビジネスモデリング(前編):なるほど! ビジネスユースケース
- 「この開発プロジェクトは中止!」の基準/プロジェクトの状態を評価する:パート1(後編)
- プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する:パート1(前編)
- 専門家に聞くモデル駆動開発のメカニズム
- 「設計」や「構築」よりも重宝されるスキル
- キミのコードが汚い理由
- 汎用グラフィカルモデリング言語「SysML」 パート2:グラフィカルなモデル言語で製品構造を記述
- 汎用グラフィカルモデリング言語「SysML」 パート1: 要件、ユースケース、およびテストケースのモデリング
- ウォーターフォールから反復型への移行手順
- ソフトウェアアーキテクティングのメリット
- ソフトウェアアーキテクティングのプロセス
- ソフトウェアアーキテクトの役割
- ソフトウェアアーキテクチャって何なの?(後編)
- ソフトウェアアーキテクチャって何なの?(前編)
- ITプロジェクトを見える化する
- ユーザー要件を引出すテクニック: ユースケースかストーリーボードか
- オブジェクト指向を超えて
- ルネサンスの巨匠たちに学ぶエンジニアリングの技
- ソフトウェア開発の「いま」と「近未来」の話
- 中国のソフトウェア開発現場はこんなにスゴイ
- 隣のテストチームが優秀ないくつかの理由(後編)
- 隣のテストチームが優秀ないくつかの理由(前編)
Copyright © ITmedia, Inc. All Rights Reserved.