アダプティブS / W開発-クイックガイド

アジャイルとは何ですか？

文学用語では、「アジャイル」という言葉は、すばやく簡単に動くことができる人、またはすばやく明確に考えて行動できる人を意味します。ビジネスでは、「アジャイル」は、必要に応じて変更を加えることが仕事の重要な部分であることが理解されている、仕事の計画と実行の方法を説明するために使用されます。ビジネスの「敏捷性」とは、企業が常に市場の変化を考慮に入れる立場にあることを意味します。

ソフトウェア開発では、「アジャイル」という用語は、「変更に対応する能力-要件、テクノロジー、および人からの変更」を意味するように適合されています。

アジャイルマニフェスト

アジャイルマニフェストは2001年にソフトウェア開発者のチームによって発行され、開発チームの重要性を強調し、変化する要件と顧客の関与に対応しています。

アジャイルマニフェストは-

私たちは、ソフトウェアを開発し、他の人がそれを行うのを助けることによって、ソフトウェアを開発するより良い方法を発見しています。この仕事を通して、私たちは価値に到達しました-

• プロセスとツールを介した個人と相互作用。
• 包括的なドキュメント上で動作するソフトウェア。
• 契約交渉をめぐる顧客のコラボレーション。
• 計画に従った切り替えへの対応。

つまり、右側のアイテムには価値がありますが、左側のアイテムには価値があります。

敏捷性の特徴

敏捷性の特徴は次のとおりです-

• アジャイルソフトウェア開発における敏捷性は、権限を与えられ、自己組織化された、多分野にわたるクロスファンクショナルなチームを備えたチーム全体の文化に焦点を当てています。

• それは共有された責任と説明責任を促進します。

• 効果的なコミュニケーションと継続的なコラボレーションを促進します。

• チーム全体のアプローチにより、遅延や待機時間が回避されます。

• 頻繁で継続的な配信により、迅速なフィードバックが保証され、チームは要件に合わせることができます。

• コラボレーションにより、実装、欠陥修正、変更への対応において、さまざまな視点をタイムリーに組み合わせることが容易になります。

• 進歩は一定で持続可能であり、透明性を強調して予測可能です。

アジャイル手法

アジャイル手法の初期の実装には、Rational Unified Process、スクラム、Crystal Clear、エクストリームプログラミング、適応型ソフトウェア開発、機能駆動開発、および動的システム開発手法（DSDM）が含まれます。2001年にアジャイルマニフェストが公開された後、これらは現在、まとめてアジャイル手法と呼ばれています。

このチュートリアルでは、アジャイル手法を学びます- Adaptive Software Development。

適応型ソフトウェア開発とは何ですか？

適応型ソフトウェア開発は、複雑なシステムや複雑な環境のコンテキストで決定論的な実践を残し、適応型実践への動きです。適応型ソフトウェア開発は、複雑なシステムを構築するための手法として、コラボレーションと学習に重点を置いています。これは、Rapid Application Development（RAD）とEvolutionary LifeCyclesのベストプラクティスから発展したものです。その後、適応型ソフトウェア開発が拡張され、管理のための適応型アプローチが含まれるようになり、計画が推測に置き換わりました。

ジムハイスミスは2000年に適応型ソフトウェア開発に関する本を出版しました。ハイスミスの言葉で-

「適応型ソフトウェア開発は、進化モデルのように循環的であり、フェーズ名は推測、協調、学習し、ますます複雑化するシステムの予測不可能な領域を反映しています。適応型開発は、2つの重要な点でその進化的遺産よりもさらに進んでいます。まず、決定論を創発に明示的に置き換えます。第二に、それはライフサイクルの変化を超えて、管理スタイルのより深い変化になります。」

ソフトウェア開発ライフサイクル（SDLC）モデルは、ソフトウェア開発プロジェクトの各段階で実行されるアクティビティを記述するフレームワークです。

ソフトウェア開発ライフサイクルでは、アクティビティは5つのフェーズで実行されます-

• Requirements Gathering−開発するソフトウェアの要件を収集します。これらの要件は、顧客/ユーザーが理解できる言語になります。ドメイン固有の用語をお勧めします。

• Analysis −収集された要件は実装の観点から分析され、ソフトウェア仕様は機能要件と非機能要件の両方をカバーするように記述されています。

• Design −このフェーズでは、開発用に選択されたテクノロジに基づいて、ソフトウェアアーキテクチャと実装の詳細に到達します。

• Construction −このフェーズでは、コードが開発され、単体テスト、統合、統合テストが行​​われ、ビルドが作成されます。

• Testing−ビルドされたソフトウェアの機能テストは、このフェーズで行われます。これには、非機能要件のテストも含まれます。

これらのアクティビティを実行するには、2つのアプローチがあります-

• Prescriptive −フレームワークで定義された所定の方法でアクティビティを実行する方法を提供するSDLCモデル。

• Adaptive−従う必要のある特定のルールを使用して、アクティビティを柔軟に実行できるSDLCモデル。アジャイルメソッドはほとんどこのアプローチに従い、それぞれにルールがあります。ただし、適応型またはアジャイルアプローチに従うことは、ソフトウェアが規律に従わずに開発されることを意味するものではありません。これは混乱につながるでしょう。

特定のSDLCモデルが良いか悪いかは言えないことを理解する必要があります。それぞれに独自の長所と短所があるため、特定の状況に適しています。

プロジェクトにSDLCモデルを選択するときは、次のことを理解する必要があります。

• 組織のコンテキスト
• あなたのテクノロジーコンテキスト
• あなたのチーム構成
• あなたの顧客コンテキスト

たとえば、ソフトウェア開発が予測可能である場合は、規範的なアプローチを使用できます。一方、ソフトウェア開発が予測できない場合、つまり要件が完全にわかっていない場合、または開発チームが現在のドメインやテクノロジに事前に触れていない場合などは、適応型アプローチが最適です。

次のセクションでは、業界全体のソフトウェア開発プロジェクトの実行中に進化した最も一般的なSDLCモデルについて理解します。また、それぞれの長所と短所、およびそれらがどのような状況で適切であるかを知ることができます。

ウォーターフォールモデルは、広く知られ、理解され、一般的に使用されている古典的なSDLCモデルです。これは1970年にロイスによって導入され、業界全体のさまざまな組織でソフトウェア開発の一般的なアプローチとして現在も採用されています。

ウォーターフォールモデルでは、各ライフサイクルフェーズは、前のライフサイクルフェーズが完了した後にのみ開始できます。したがって、フィードバックループのない線形モデルです。

ウォーターフォールモデル–強み

ウォーターフォールモデルの長所は次のとおりです。

• 理解しやすく、使いやすい。
• 経験の浅い開発チームに構造を提供します。
• マイルストーンはよく理解されています。
• 要件の安定性を設定します。
• 管理制御（計画、監視、レポート）に最適です。
• コストやスケジュールよりも品質が重要な場合にうまく機能します。

ウォーターフォールモデル–弱点

ウォーターフォールモデルの弱点または欠点は次のとおりです。

• 理想化-それは現実とよく一致しません。

• 非現実的-プロジェクトの早い段階で正確な要件を期待することはできません。

• より一般的な探索的開発の反復的な性質を反映していません。

• 変更を加えるのは難しく、費用がかかります。

• ソフトウェアは、プロジェクトの最後にのみ提供されます。このため-

  • 重大な欠陥の発見を遅らせます。

  • 廃止された要件の提供の可能性。

• 小さなチームやプロジェクトではコストがかかる可能性がある、かなりの管理オーバーヘッド。

• アナリスト、デザイナー、開発者、テスターなど、あらゆる段階で経験豊富なリソースが必要です。

• テストは、開発が完了した後にのみ開始され、テスターは初期のフェーズのいずれにも関与しません。

• 各フェーズはサイロで実行されるため、部門の枠を超えたチームの専門知識は共有されません。

ウォーターフォールモデルを使用する場合

次の場合にウォーターフォールモデルを使用できます。

• 要件は非常によく知られています。

• 製品の定義は安定しています。

• テクノロジーはよく理解されています。

• 既存の製品の新しいバージョン。

• 既存の製品を新しいプラットフォームに移植する。

• 構造化されたクロスファンクショナルチームを持つ大規模な組織。

• コミュニケーションチャネルは、組織内および顧客との間でも十分に確立されています。

進化的プロトタイピングモデル

進化的プロトタイピングモデルを使用したソフトウェア開発では、開発者は要件フェーズでプロトタイプを作成します。次に、エンドユーザーはプロトタイプを評価し、フィードバックを提供します。フィードバックは、プロトタイプの修正または追加機能です。フィードバックに基づいて、開発者はプロトタイプをさらに改良します。

したがって、この製品は、プロトタイプ→フィードバック→洗練されたプロトタイプサイクルを通じて進化するため、EvolutionaryPrototypingという名前が付けられています。ユーザーが製品の機能と動作に満足すると、プロトタイプコードは、最終的な製品の納品に必要な基準に達します。

進化的プロトタイピングモデル–長所

進化的プロトタイピングモデルの長所または利点は次のとおりです。

• 顧客/エンドユーザーは、プロトタイプを見て収集されたシステム要件を視覚化できます。

• 開発者は顧客から学ぶため、ドメインや本番環境に関する曖昧さはありません。

• 柔軟な設計と開発を可能にします。

• プロトタイプとの相互作用は、追加で必要な機能の認識を刺激します。

• 予期しない要件や要件の変更に簡単に対応できます。

• 着実で目に見える進歩の兆候が生まれます。

• 正確で保守可能な最終製品の提供。

進化的プロトタイピングモデル–弱点

進化的プロトタイピングモデルの弱点または欠点は次のとおりです。

• モデルで規定されているものではありませんが、コードと修正の開発で構造化された開発を放棄する傾向があります。

• このモデルは、手っ取り早い方法で評判が悪かった。

• 全体的な保守性は見過ごされがちです。

• 顧客は、開発者が最終ステップ、つまり最終製品の標準化を実行する機会を与えずに、プロトタイプの最終版の納品を要求する可能性があります。

• プロジェクトは（継続的なスコープクリープで）永遠に続く可能性があり、経営陣はそれを評価しないかもしれません。

進化的プロトタイピングモデルをいつ使用するか？

進化的プロトタイピングモデルを使用できます-

• 要件が不安定であるか、明確にする必要がある場合
• ウォーターフォールモデルの要件明確化段階として
• ユーザーインターフェイスを開発するには
• 短期間のデモンストレーション用
• 新規または独自の開発用
• 新しいテクノロジーを実装するため

反復型インクリメンタルモデルでは、最初に、システム全体の部分的な実装が構築され、成果物の状態になります。機能性が向上しました。以前の納品からの欠陥がある場合は修正され、動作中の製品が納品されます。このプロセスは、製品開発全体が完了するまで繰り返されます。これらのプロセスの繰り返しは、反復と呼ばれます。すべての反復の終わりに、製品の増分が配信されます。

反復型インクリメンタルモデル–長所

反復型インクリメンタルモデルの利点または長所は次のとおりです。

• 最初に優先要件を作成できます。

• 最初の製品配送はより速くなります。

• 顧客は重要な機能を早期に取得します。

• 初期配送コストを削減します。

• 各リリースは製品の増分であるため、顧客は常に機能する製品を手元に置いておくことができます。

• お客様は、製品の増分ごとにフィードバックを提供できるため、開発終了時の驚きを回避できます。

• 要件の変更に簡単に対応できます。

反復型インクリメンタルモデル–弱点

反復型インクリメンタルモデルの欠点は次のとおりです。

• 反復の効果的な計画が必要です。

• 必要な機能を確実に組み込み、後で変更に備えるために、効率的な設計が必要です。

• 増分の定義を可能にするには、完全で完全に機能するシステムの早期定義が必要です。

• 他のインターフェースが開発されるずっと前に開発されるものもあるため、明確に定義されたモジュールインターフェースが必要です。

• システム全体の総コストは低くありません。

反復型インクリメンタルモデルを使用する場合

反復型インクリメンタルモデルは、次の場合に使用できます。

• 要件のほとんどは事前にわかっていますが、時間の経過とともに進化すると予想されます。

• 要件が優先されます。

• 基本的な機能を迅速に提供する必要があります。

• プロジェクトには長い開発スケジュールがあります。

• プロジェクトには新しいテクノロジーがあります。

• ドメインはチームにとって新しいものです。

Rapid Application Development（RAD）モデルには、次のフェーズがあります。

• Requirements Planning phase −所要量計画段階では、構造化された方法でビジネス上の問題について話し合うためにワークショップを実施する必要があります。

• User Description phase −ユーザー記述フェーズでは、自動化されたツールを使用してユーザーから情報を取得します。

• Construction phase −構築フェーズでは、コードジェネレーター、スクリーンジェネレーターなどの生産性ツールが、「完了まで実行」アプローチでタイムボックス内で使用されます。

• Cut Over phase −カットオーバーフェーズでは、システムのインストール、ユーザー受け入れテスト、およびユーザートレーニングが実行されます。

迅速なアプリケーション開発モデル–長所

Rapid ApplicationDevelopmentモデルの利点または長所は次のとおりです。

• チームメンバーの数を減らしてサイクルタイムを短縮し、生産性を向上させることは、コストの削減を意味します。

• サイクル全体を通して顧客が関与することで、顧客満足度とビジネス価値を達成できないリスクを最小限に抑えることができます。

• フォーカスは、何が見えるか、何が得られるか（WYSIWYG）のコードに移動します。これにより、構築されているものが正しいことが明確になります。

• モデリングの概念を使用して、ビジネス、データ、およびプロセスに関する情報を取得します。

迅速なアプリケーション開発モデル–弱点

Rapid ApplicationDevelopmentモデルの短所または長所は次のとおりです。

• 加速された開発プロセスは、ユーザーに迅速な対応を提供する必要があります。

• 閉鎖を達成しないリスク。

• レガシーシステムでは使いにくい。

• 開発者と顧客は、短縮された時間枠で迅速な活動に取り組む必要があります。

迅速なアプリケーション開発モデルをいつ使用するか？

迅速なアプリケーション開発モデルは、次の場合に使用できます。

• ユーザーはライフサイクル全体に関与できます。
• プロジェクトはタイムボックス化できます。
• 機能は段階的に提供できます。

Rapid Application Developmentモデルの長所は高く評価されていますが、業界ではあまり使用されていません。

スパイラルモデルは、ウォーターフォールモデルにリスク分析とRADプロトタイピングを追加します。各サイクルには、ウォーターフォールモデルと同じ一連のステップが含まれます。

スパイラルモデルには4つの象限があります。それらについて詳しく説明しましょう。

象限1-目的、代替案、制約を決定する

• Objectives −機能、パフォーマンス、ハードウェア/ソフトウェアインターフェイス、重要成功要因など。

• Alternatives −構築、再利用、購入、下請けなど。

• Constraints −コスト、スケジュール、インターフェースなど。

第2象限-代替案を評価し、リスクを特定して解決する

• 決定された目的と制約に関連する代替案を研究します。

• 経験不足、新技術、厳しいスケジュールなどのリスクを特定します。

• 特定されたリスクを解決して、プロジェクトへの影響を評価し、必要な緩和計画と緊急時対応計画を特定して実装します。リスクは常に監視する必要があります。

第3象限-次のレベルの製品を開発する

典型的な活動は次のとおりです。

• デザインを作成する
• デザインのレビュー
• コードを開発する
• コードを検査する
• テスト製品

第4象限-次のフェーズを計画する

典型的な活動は次のとおりです。

• プロジェクト計画を作成する
• 構成管理計画を作成する
• テスト計画を作成する
• インストール計画を作成する

スパイラルモデル–強み

スパイラル法の利点または長所は次のとおりです。

• 多くのコストをかけずに、リスクを早期に示します。
• ラピッドプロトタイピングツールにより、ユーザーはシステムを早期に表示できます。
• 重要な高リスク機能が最初に開発されます。
• デザインは完璧である必要はありません。
• ユーザーは、すべてのライフサイクルステップに密接に関与できます。
• ユーザーからの早期かつ頻繁なフィードバック。
• 累積コストは頻繁に評価されます。

スパイラルモデル–弱点

スパイラル法の短所または短所は次のとおりです。

• 次の反復に進む準備ができていることを示す、目標、検証可能なマイルストーンを定義するのは難しい場合があります。

• 計画、目標のリセット、リスク分析、およびプロトタイピングに費やされる時間は、オーバーヘッドになる可能性があります。

• リスクの評価に費やされる時間は、小規模または低リスクのプロジェクトには長すぎる可能性があります。

• スパイラルモデルは、新しいチームメンバーにとって理解するのが複雑です。

• リスク評価の専門知識が必要です。

• スパイラルは無期限に続く可能性があります。

• 開発者は、非開発フェーズのアクティビティ中に再割り当てする必要があります。

スパイラルモデルを使用する場合

スパイラルモデルは、次の場合に使用できます。

• プロトタイプの作成は適切です。
• リスク評価は重要です。
• プロジェクトは中リスクから高リスクです。
• ユーザーは自分のニーズに確信が持てません。
• 要件は複雑です。
• 製品ラインは新しいです。
• 探査中に大幅な変更が予想されます。
• 潜在的なビジネスの変化のために賢明でない長期的なプロジェクトのコミットメント。

アジャイルメソッドはアジャイルマニフェストに基づいており、本質的に適応性があります。アジャイルメソッドは確実に-

• チームコラボレーション。
• 顧客とのコラボレーション。
• 継続的かつ継続的なコミュニケーション。
• 変更への対応。
• 動作する製品の準備。

いくつかのアジャイル手法が登場し、タイムボックス化された反復による反復型および増分型開発が促進されました。アジャイルメソッドは適応性がありますが、特定のメソッドのルールをバイパスすることはできないため、統制のとれた実装が必要です。

アジャイル手法–強み

アジャイル手法の利点または長所は次のとおりです。

• 早期および頻繁なリリース。
• 変化する要件への対応。
• 顧客と開発者の間の毎日のコミュニケーション。
• やる気のある個人を中心に構築されたプロジェクト。
• 自己組織化チーム。
• シンプルさ、すぐに必要なものに焦点を当てています。
• 将来のための構築やコードの過負荷はありません。
• 効果を向上させるために行動を調整するための定期的な反射。

アジャイル手法–弱点

スパイラル法の短所または短所は次のとおりです。

• 顧客の可用性が不可能な場合があります。

• チームは、メソッドのルールに従うための経験が必要です。

• イテレーションで提供する必要のある機能を迅速に決定するには、適切な計画が必要です。

• チームには、見積もりスキルと交渉スキルが求められます。

• チームは効果的なコミュニケーションスキルを持っている必要があります。

• 新しいチームは自分たちを組織することができないかもしれません。

• タイムボックス化された反復で開発および提供するには、規律が必要です。

• 設計はシンプルで保守しやすいものにする必要があるため、効果的な設計スキルが必要です。

アジャイルメソッドをいつ使用するか？

アジャイルメソッドは、次の場合に使用できます。

• アプリケーションはタイムクリティカルです。

• 範囲は限られており、形式的ではありません（アジャイルメソッドをより大きなプロジェクトにスケーリングすることが進行中であり、一部のアジャイルメソッドに特定の拡張があります）。

• 組織は規律ある方法を採用しています。

初期のSDLCモデルは、安定性、予測可能性、収穫逓減の実践をより重視しています。インターネットプラットフォームなどの業界は、リターン環境、予測不可能、非線形、および高速なアプローチを増やすために動いています。

適応型ソフトウェア開発（ASD）は、これらの問題に対処するために進化してきました。製品開発を管理する能力を強化するために、経営者の観点から最も重要な要素として出現に焦点を当てています。

Jim Highsmithの言葉によると、「適応型ソフトウェア開発フレームワークは、従来のソフトウェア開発手法、Rapid Application Development（RAD）技術に関するコンサルティング、実践、執筆、およびハイテクソフトウェア会社との製品開発管理における長年の経験に基づいています。実践」。

ウォーターフォールモデルは、わずかなフィードバックで、線形性と予測可能性によって特徴付けられることがわかります。それは一連のPlan → Build → Implement。

スパイラルモデルなどの進化的ライフサイクルモデルは、決定論的アプローチを適応的アプローチに移行しました。 Plan → Build → Revise Cycles。

しかし、開業医の考え方は決定論的であり、長期的な予測可能性は短期的な予測可能性に変わりました。RADなどの進化的ライフサイクルモデルの実践は、決定論的ではないことがわかっています。

アダプティブライフサイクル

アダプティブモデルは、別の観点から構築されています。進化モデルのように循環的ですが、フェーズの名前は、ますます複雑になるシステムの予測不可能な性質を反映しています。

アダプティブデベロップメントは、2つの重要な点でその進化的遺産よりもさらに進んでいます。

• これは、決定論を創発に明示的に置き換えます。

• それはライフサイクルの変化を超えて、管理スタイルのより深い変化へと進みます。

適応型ソフトウェア開発ライフサイクルの3つのフェーズは次のとおりです。

• Speculate − Speculateは、決定論的な単語の計画、製品仕様の計画、またはプロジェクト管理タスクの計画に置き換わるものです。

• Collaborate −コラボレーションとは、

  • 従来のプロジェクト管理の意味での管理、および

  • 創発に必要なコラボレーション環境の作成と維持。

共同作業は、環境の変化のペースを維持しながら、製品を構築します。

• Learn − Learnは、開発者と顧客の両方が、各開発サイクルの結果を使用して次の方向性を学習することを目的としています。

この章では、適応型ソフトウェア開発のさまざまな概念を理解します。

複雑適応系（CAS）理論

サンタフェインスティテュートのブライアンアーサーと彼の同僚は、複雑適応系（CAS）理論を使用して、物理学、生物学、進化、および経済学の理解に革命をもたらしました。

ブライアン・アーサーは、収穫逓減、均衡、決定論的ダイナミクスの基本的な仮定に支配された彼らの見解はもはや現実を理解するのに十分ではないことを主流派経済学者に納得させようとした20年以上の彼の最高潮に達しました。新しい世界は、収穫逓増、不安定性、および原因と結果を特定できないことの1つです。

2つの世界は、行動、スタイル、文化が異なります。彼らは-を要求します

• さまざまな管理手法
• さまざまな戦略
• 異なる理解

複雑なソフトウェア開発

ソフトウェアアプリケーションの範囲が爆発的に拡大しているため、ソフトウェア開発組織でさえ、上記と同様の矛盾が発生しています。

• One Worldは、安定性と予測可能性の基本に根ざした管理手法から派生した決定論的開発によって表されます（アーサーの用語では、収穫逓減を意味します）

• 第二世界は、予測不可能で非線形で高速なリターン環境の減少から増加へと移行する業界によって表されます。

この第2の世界の問題に対処するために、Jig Highsmithは、決定論的ソフトウェア開発とは異なるフレームワークである適応型ソフトウェア開発を提供しました。

適応型ソフトウェア開発は、複雑なシステムへの対応に重点を置いています-

• 開発ライフサイクルのための適応型ソフトウェア開発。

• 従来のプロジェクト管理手法とは異なる考え方を必要とする順応的管理手法。

このチュートリアルでは、これら両方の実装を理解できます。

適応型ソフトウェア開発（ASD）は、2つの視点に基づいています-

• この章の最初のセクションで説明した、複雑適応系（CAS）理論に基づく概念的な視点。

• に基づく実用的な視点

  • 決定論的ソフトウェア開発手法に関する長年の経験。

  • Rapid Application Development（RAD）技術に関するコンサルティング、実践、および執筆。ハイテクソフトウェア会社と協力して、製品開発の管理を行っています。

この章では、適応型ソフトウェア開発の概念的な視点を理解します。

複雑適応系（CAS）の概念

複雑適応系（CAS）理論には多くの概念があります。適応型ソフトウェア開発は、これらの概念の2つに基づいています-

• Emergence
• Complexity

出現

複雑なソフトウェア製品開発プロジェクトでは、結果は本質的に予測できません。しかし、成功する製品は常にそのような環境から生まれます。

これは、複雑適応系（CAS）理論に示されているように、創発によって発生する可能性があります。それは簡単な例、鳥の群れ行動によって理解することができます。

鳥の群れを観察すると、次のことに気づきます。

• 各鳥はしようとします

  • 他の鳥を含む、環境内の他のオブジェクトからの最小距離を維持します。

  • 速度を近隣の鳥と一致させます。

  • 近隣の鳥の重心に向かって移動します。

• グループの行動規則はありません。唯一のルールは、個々の鳥の行動に関するものです。

• しかし、鳥の群れという新たな行動が存在します。誤った鳥が追いつくために急いでいるとき、群れは障害物の周りで分裂し、反対側で改革します。

これは、適応開発における最も困難なメンタルモデルの変更の要件を示しています-個人の自由を管理および整理する方法から、創造的な新しい秩序が自発的な自己組織化から予期せず出現するという概念まで。

開発に加えて、創発は経営の観点からも最も重要な概念です。

複雑

ソフトウェア開発のコンテキストでは、複雑さは約-です。

• 開発者、顧客、ベンダー、競合他社、株主などのチームの個人、その数と速度。

• サイズと技術的な複雑さ。

適応型ソフトウェア開発の実践

適応型ソフトウェア開発は、ソフトウェア管理の実践に関して異なる視点を提供します。以下のセクションでは、品質とRADという2つの重要なプラクティスを理解できます。どちらも、要件の収集に影響を及ぼします。

すべてのプラクティスの詳細は、このチュートリアルの「適応型ソフトウェア開発プラクティス」の章にあります。

品質

複雑な環境では、最初から何が正しいかを予測できないため、「最初から正しく行う」という古くからの慣習は機能しません。あなたは正しい価値を生み出すことを目的とする必要があります。ただし、複雑な環境では、スコープ（機能、パフォーマンス、欠陥レベル）、スケジュール、リソースなどの値コンポーネントの組み合わせと順列が非常に大きいため、最適な値はあり得ません。したがって、焦点は、競争の激しい市場で最高の価値を提供するためにシフトすることです。

RADプラクティス

RADプラクティスには、通常、次の組み合わせが含まれます。

• 進化のライフサイクル
• カスタマーフォーカスグループ、JADセッション、テクニカルレビュー
• タイムボックス化されたプロジェクト管理
• 継続的なソフトウェアエンジニアリング
• 戦争室を備えた専用チーム

RADプロジェクトには、固有の適応性のある創発的なフレーバーがあります。多くのIT組織はRADに反対しています。ただし、Microsoftやその他の企業は、RADに匹敵する技術を使用して、信じられないほど大規模で複雑なソフトウェアを作成しています。

RADプラクティスとMicrosoftプロセスは、どちらも実際の適応開発の例です。彼らにラベルを付け（つまり、適応開発）、科学的知識（つまり、CAS理論）が増えていることに気付くと、彼らが機能する理由が説明されます。これは、これらのプラクティスをより広範囲に使用するための基礎を提供するはずです。

適応型ソフトウェア開発は、RADの実践から進化しました。チームの側面もこれらのプラクティスに追加されました。ニュージーランドからカナダまでの企業は、さまざまなプロジェクトと製品タイプで、適応型ソフトウェア開発を使用しています。

Jim Highsmithは、2000年に適応型ソフトウェア開発を公開しました。

適応型ソフトウェア開発の実践は、変化に対応する能力を提供し、ほとんど計画や学習なしで製品が進化するという激動の環境に適応できます。

ASDライフサイクルのフェーズ

適応型ソフトウェア開発は、進化モデルのように循環的であり、フェーズ名は複雑なシステムの予測不可能性を反映しています。アダプティブ開発ライフサイクルのフェーズは次のとおりです。

• Speculate
• Collaborate
• Learn

これらの3つのフェーズは、適応型ソフトウェア開発の動的な性質を反映しています。アダプティブ開発は、決定論を創発に明示的に置き換えます。それは単なるライフサイクルの変化を超えて、経営スタイルのより深い変化へと変わります。適応型ソフトウェア開発には、動的なSpeculate-Collaborate-Learnライフサイクルがあります。

アダプティブソフトウェア開発ライフサイクルは、タスクではなく結果に焦点を合わせており、結果はアプリケーション機能として識別されます。

推測する

定期保険は決定論的すぎて、望ましい結果についてかなり高い確実性を示しています。計画への適合という暗黙的および明示的な目標は、プロジェクトを革新的な方向に導くマネージャーの能力を制限します。

適応型ソフトウェア開発では、プランという用語は推測という用語に置き換えられます。チームは推測しながら計画を放棄しませんが、複雑な問題における不確実性の現実を認識しています。Speculateは、探索と実験を奨励します。短いサイクルでの反復が推奨されます。

コラボレーション

複雑なアプリケーションは構築されておらず、進化しています。複雑なアプリケーションでは、大量の情報を収集、分析し、問題に適用する必要があります。激動の環境では、情報の流れが速くなります。したがって、複雑なアプリケーションでは、大量の情報を収集、分析し、問題に適用する必要があります。これにより、チームのコラボレーションによってのみ処理できる多様な知識要件が生まれます。

コラボレーションには、結果を生み出したり、知識を共有したり、意思決定を行ったりするために共同で作業する能力が必要になります。

プロジェクト管理のコンテキストでは、コラボレーションは、従来の管理手法による管理と、出現に必要なコラボレーション環境の作成および維持との間のバランスを示します。

学ぶ

ライフサイクルの学習部分は、プロジェクトの成功に不可欠です。チームは、次のようなプラクティスを使用して、知識を絶えず強化する必要があります。

• テクニカルレビュー
• プロジェクトの回顧展
• カスタマーフォーカスグループ

レビューは、各反復後に行う必要があります。開発者と顧客の両方が彼らの仮定を調べ、各開発サイクルの結果を使用して次の方向性を学びます。チームは学ぶ-

• 製品変更について

• 製品がどのように開発されているかについての基礎となる仮定のより根本的な変更

チームが大きな間違いではなく小さな間違いから学ぶことができるように、反復は短くする必要があります。

推測-共同作業-全体としてのサイクルを学ぶ

上記のSpeculate-Collaborate-Learnサイクルからわかるように、3つのフェーズが非線形でオーバーラップしていることは明らかです。

アダプティブフレームワークから次のことがわかります。

• 学習せずにコラボレーションしたり、コラボレーションせずに学習したりすることは困難です。

• 学習せずに推測したり、推測せずに学習したりすることは困難です。

• 協力せずに推測したり、推測せずに協力したりすることは困難です。

適応型ソフトウェア開発ライフサイクルには、6つの基本的な特徴があります。

• ミッション重視
• 機能ベース
• Iterative
• Time-boxed
• リスク主導
• 変更耐性

この章では、適応型ソフトウェア開発のこれら6つの特徴を理解します。

ミッション重視

多くのプロジェクトでは、チームを導く全体的な使命は明確に表現されていますが、プロジェクトの開始時に要件が不確実な場合があります。ミッションステートメントは、最初は探索を奨励するガイドとして機能しますが、プロジェクトの過程では焦点が狭くなります。ミッションは、固定された目的地ではなく境界を提供します。ミッションステートメントとそれらのステートメントをもたらす議論は、重要なプロジェクトのトレードオフの決定を行うための方向性と基準を提供します。

明確な使命と絶え間ない使命の洗練の実践がなければ、反復的なライフサイクルは振動するライフサイクルになり、開発の進展なしに前後に揺れ動きます。

機能ベース

アダプティブソフトウェア開発ライフサイクルは、タスクではなくアプリケーション機能に基づいています。機能は、顧客の優先順位に基づいて反復中に開発される機能です。

顧客がフィードバックを提供すると、機能は数回の反復で進化する可能性があります。

実装後に顧客に直接的な結果を提供するアプリケーション機能が主要です。ユーザーマニュアルなどの顧客向けドキュメントも機能と見なされます。データモデルなどの他のドキュメントは、成果物として定義されている場合でも、常に二次的なものです。

反復

適応型ソフトウェア開発ライフサイクルは反復的であり、フィードバックを取得し、結果として得られる学習を吸収し、さらなる開発のための正しい方向を設定するために、頻繁なリリースに焦点を合わせています。

タイムボックス

適応型ソフトウェア開発ライフサイクルでは、反復はタイムボックス化されます。ただし、適応型ソフトウェア開発のタイムボックスは期限ではないことを覚えておく必要があります。コラボレーション環境に挑戦するためにチームを長時間働かせたり、成果物の品質を妥協したりするために使用しないでください。

適応型ソフトウェア開発では、タイムボックス化は、必要に応じて、ハードトレードオフの決定に焦点を合わせて強制するための方向性と見なされます。変化率が高い不確実な環境では、作業を完了するためにタイムボックスなどの定期的な強制機能が必要です。

リスク主導

適応型ソフトウェア開発では、反復は重大なリスクを特定して評価することによって推進されます。

変更耐性

適応型ソフトウェア開発は変更耐性があり、変更を競争上の優位性を組み込む能力と見なしますが、開発の問題とは見なしません。

適応型ソフトウェア開発の実践は、継続的な適応への信念によって推進されており、ライフサイクルは継続的な変化を標準として受け入れるようになっています。

適応型ソフトウェア開発ライフサイクルは、以下に専念しています。

• 継続学習
• 向きを変える
• Re-evaluation
• 不確かな未来へのピアリング
• 開発者、管理者、および顧客間の強力なコラボレーション

アダプティブSDLC

適応型ソフトウェア開発は、RADとソフトウェアエンジニアリングのベストプラクティスを組み合わせたものです。

• プロジェクトの開始。
• 適応サイクル計画。
• 並行コンポーネントエンジニアリング。
• 品質レビュー。
• 最終的なQAとリリース。

適応型ソフトウェア開発の実践は次のように説明できます-

上に示したように、適応型ソフトウェア開発の実践は、次の3つのフェーズにまたがっています。

• 推測-開始と計画

  • プロジェクトの開始

  • プロジェクト全体のタイムボックスを確立する

  • 反復回数を決定し、それぞれにタイムボックスを割り当てます

  • 各反復のテーマまたは目的を作成します

  • 各反復に機能を割り当てる

• Collaborate −同時機能開発

  • 分散チームのコラボレーション

  • 小規模プロジェクトのコラボレーション

  • 大規模プロジェクトのコラボレーション

• Learn −品質レビュー

  • 顧客の視点から見た結果の品質

  • 技術的な観点からの結果の品質

  • デリバリーチームとプラクティスチームメンバーの機能が活用している

  • プロジェクトの状況

推測-開始と計画

適応型ソフトウェア開発では、投機フェーズには2つのアクティビティがあります-

• Initiation
• Planning

Speculateには、開始段階と計画段階で繰り返し実行できる5つのプラクティスがあります。彼らは-

• プロジェクトの開始
• プロジェクト全体のタイムボックスを確立する
• 反復回数を決定し、それぞれにタイムボックスを割り当てます
• 各反復のテーマまたは目的を作成します
• 各反復に機能を割り当てる

プロジェクトの開始

プロジェクトの開始には以下が含まれます-

• プロジェクトの使命と目的を設定する
• 制約を理解する
• プロジェクト組織の確立
• 要件の特定と概要
• 初期サイズとスコープの見積もりを行う
• プロジェクトの主要なリスクの特定

プロジェクト開始データは、速度を主要な側面として考慮して、予備的なJADセッションで収集する必要があります。開始は、中小規模のプロジェクトの場合は2〜5日の集中的な作業で、大規模なプロジェクトの場合は2〜3週間の作業で完了することができます。

JADセッション中に、機能を識別し、オブジェクト、データ、またはその他のアーキテクチャモデルの概要を確立するために、要件が十分に詳細に収集されます。

プロジェクト全体のタイムボックスを確立する

プロジェクト全体のタイムボックスは、プロジェクトの開始作業から生じる範囲、機能セットの要件、見積もり、およびリソースの可用性に基づいて確立する必要があります。

ご存知のように、推測は見積もりを放棄するものではありませんが、見積もりがうまくいかない可能性があることを受け入れることを意味します。

反復とタイムボックス

プロジェクト全体の範囲と不確実性の程度に基づいて、反復回数と個々の反復の長さを決定します。

中小規模のアプリケーションの場合-

• 反復は通常4週間から8週間まで異なります。
• 一部のプロジェクトは、2週間の反復で最適に機能します。
• プロジェクトによっては、8週間以上かかる場合があります。

自分に合った時間に基づいて時間を選択します。反復回数と各反復の長さを決定したら、各反復にスケジュールを割り当てます。

テーマまたは目的を開発する

チームメンバーは、反復ごとにテーマまたは目的を作成する必要があります。これは、スクラムのスプリント目標に似ています。各イテレーションは、レビューとフィードバックを可能にするために製品を顧客に見えるようにする製品機能を実証できる一連の機能を提供する必要があります。

イテレーション内で、ビルドは、統合プロセスを可能にし、製品を開発チームに表示できるようにするために、できれば毎日機能する機能を提供する必要があります。テストは、機能開発の継続的で不可欠な部分である必要があります。プロジェクトが終了するまで延期しないでください。

機能の割り当て

開発者と顧客は一緒に各イテレーションに機能を割り当てる必要があります。この機能割り当ての最も重要な基準は、すべての反復で、かなりの機能を備えた目に見える機能のセットを顧客に提供する必要があるということです。

反復への機能の割り当て中-

• 開発チームは、機能の見積もり、リスク、および依存関係を考え出し、それらを顧客に提供する必要があります。

• お客様は、開発チームから提供された情報を使用して、機能の優先順位を決定する必要があります。

したがって、反復計画は機能ベースであり、開発者および顧客とのチームとして行われます。経験によれば、このタイプの計画は、プロジェクトマネージャーによるタスクベースの計画よりもプロジェクトをよりよく理解できます。さらに、機能ベースの計画は、各プロジェクトの独自性を反映しています。

コラボレーション─並行機能開発

コラボレーションフェーズでは、開発に重点が置かれます。コラボレーションフェーズには2つのアクティビティがあります-

• 開発チームは協力して、機能するソフトウェアを提供します。

• プロジェクトマネージャーは、コラボレーションと同時開発活動を促進します。

コラボレーションは、開発チーム、顧客、およびマネージャーを含む共有作成の行為です。共有された創造は、信頼と尊敬によって育まれます。

チームは協力する必要があります-

• 技術的な問題
• ビジネス要件
• 迅速な意思決定

以下は、適応型ソフトウェア開発のコラボレーションフェーズに関連するプラクティスです。

• 分散チームのコラボレーション
• 小規模プロジェクトのコラボレーション
• 大規模プロジェクトのコラボレーション

分散型チームのコラボレーション

分散したチームが関与するプロジェクトでは、次のことを考慮する必要があります-

• さまざまなアライアンスパートナー
• 幅広い知識
• 人々が相互作用する方法
• 彼らが相互依存関係を管理する方法

小規模プロジェクトのためのコラボレーション

小規模なプロジェクトでは、チームメンバーが物理的に近接して作業している場合、非公式の廊下でのチャットやホワイトボードの落書きとのコラボレーションが効果的であることがわかっているため、これを推奨する必要があります。

大規模プロジェクトのコラボレーション

大規模なプロジェクトでは、追加のプラクティス、コラボレーションツール、およびプロジェクトマネージャーとのやり取りが必要であり、状況に応じて調整する必要があります。

学ぶ-品質レビュー

適応型ソフトウェア開発は、「実験と学習」の概念を奨励します。

間違いや実験から学ぶには、チームメンバーが部分的に完成したコードとアーティファクトを早期に共有する必要があります。

• 間違いを見つける
• それらから学ぶ
• 大きな問題になる前に小さな問題を見つけることで、やり直しを減らします

各開発イテレーションの最後に、学ぶべきことの4つの一般的なカテゴリがあります-

• 顧客の視点から見た結果の品質
• 技術的な観点からの結果の品質
• デリバリーチームとプラクティスチームの機能
• プロジェクトの状況

顧客の視点から見た結果の品質

適応型ソフトウェア開発プロジェクトでは、顧客からのフィードバックを得ることが最優先事項です。このための推奨される方法は、顧客フォーカスグループです。これらのセッションは、アプリケーションの作業モデルを調査し、顧客の変更要求を記録するように設計されています。

顧客フォーカスグループセッションは、jadセッションと同様に促進されたセッションですが、要件を生成したりプロジェクト計画を定義したりするのではなく、アプリケーション自体をレビューするように設計されています。顧客は、反復の結果として機能するソフトウェアに関するフィードバックを提供します。

技術的な観点からの結果の品質

適応型ソフトウェア開発プロジェクトでは、技術的な成果物の定期的なレビューを重要視する必要があります。コードレビューは継続的に行う必要があります。技術アーキテクチャなどの他の技術的成果物のレビューは、毎週または反復の最後に実施できます。

適応型ソフトウェア開発プロジェクトでは、チームは定期的に自分のパフォーマンスを監視する必要があります。回顧展は、チームがチームとして一緒に、自分自身と自分の仕事について学ぶことを奨励します。

反復終了の回顧展は、次のような定期的なチームパフォーマンスの自己レビューを容易にします。

• 何が機能していないかを特定します。
• チームがさらに行う必要があること。
• チームがより少なくする必要があること。

プロジェクトの状況

プロジェクトステータスのレビューは、さらなる作業の計画に役立ちます。適応型ソフトウェア開発プロジェクトでは、プロジェクトステータスの決定は機能ベースのアプローチであり、各反復の終了は完了した機能によってマークされ、ソフトウェアが機能します。

プロジェクトステータスのレビューには、次のものを含める必要があります。

• プロジェクトはどこにありますか？
• プロジェクトと計画はどこにありますか？
• プロジェクトはどこにあるべきですか？

適応型ソフトウェア開発プロジェクトの計画は投機的であるため、上記の質問2よりも、質問3が重要です。つまり、プロジェクトチームと顧客は、「これまでに何を学んだか、そしてそれは私たちがどこに行く必要があるかについての私たちの見方を変えるのか」と絶えず自問する必要があります。

従来のソフトウェア管理のフローチャートを以下に示します。

従来のソフトウェア管理は、コマンドコントロールという用語で特徴付けられてきました。

多くの組織は、最適化、効率、予測可能性、制御、厳密性、およびプロセス改善の伝統に浸っています。しかし、新たな情報化時代の経済には、適応性、スピード、コラボレーション、即興、柔軟性、革新、そしてしなやかさが必要です。

ハーバードビジネスレビューと管理の本は、エンパワーメント、参加型管理、学習組織、人間中心の管理などの用語を考え出しましたが、これらのどれも現代の組織の管理に入れられていません。

適応型ソフトウェア開発のコンテキストでは、ギャップははるかに広く見え、他の分野で成功していることが証明されている順応的管理手法を検討する必要があります。

順応的管理

順応的管理は、リソースマネージャーが利害関係者や科学者とチームとして協力し、次の目標を達成した環境で成功することが証明されています。

• 管理対象システムが人間の介入にどのように応答するかを学ぶ。

• 将来的に資源政策と慣行を改善するため。

順応的管理の背後にある原則は、その結果を事前に確実に予測できないため、多くのリソース管理アクティビティは実験であるということです。これらの実験は、将来の改善のための学習機会として使用されます。

順応的管理は、新しい情報に直面し、さまざまな利害関係者の目的や好みの設定でタイムリーに対応する能力を高めることを目的としています。それは、環境の不確実性が調査され、よりよく理解されている間、利害関係者が紛争を拘束し、それらを秩序だった方法で議論することを奨励します。

順応的管理は、利害関係者、管理者、およびその他の意思決定者が知識の限界と不完全な情報に基づいて行動する必要性を認識するのに役立ちます。

順応的管理は、次のことを明確にすることで、下された決定を変えるのに役立ちます。

• 決定は暫定的なものです。
• 経営陣の決定は必ずしも正しいとは限りません。
• 変更が予想されます。

順応的管理アプローチには2つのタイプがあります-

• パッシブ順応的管理。
• アクティブ順応的管理。

パッシブ順応的管理

順応的管理は、科学的知識を高め、それによって不確実性を減らすことを目的としています。

パッシブ順応的管理では、既存の情報と理解に基づいて、単一の好ましい行動方針が選択されます。管理アクションの結果は監視され、その後の決定は結果に基づいて調整されます。

このアプローチは、学習と効果的な管理に貢献します。ただし、選択したアクションのコースを超える条件の科学的および管理機能を強化する能力には限界があります。

アクティブ順応的管理

アクティブ順応的管理アプローチは、管理アクションが実行される前に情報を確認します。

次に、単一のモデルではなく、生態系と関連する応答（人口動態の変化、娯楽用途など）のさまざまな競合する代替システムモデルが開発されます。管理オプションは、これらの代替モデルの評価に基づいて選択されます。

リーダーシップ-コラボレーション管理

順応的管理は、適応型ソフトウェア開発に最適なものです。このアプローチには、リソースマネージャー、つまり、人と協力し、人間の介入を許可し、友好的な環境を作り出すことができるマネージャーが必要です。

ソフトウェア開発では、リーダーがこれらの責任を負うことがよくあります。司令官よりもリーダーが必要です。リーダーは協力者であり、チームと協力します。コラボレーティブ-リーダーシップは、アダプティブ開発で最も求められている実践です。

リーダーには次の資質があります-

• 方向をつかんで設定します。

• 関係者に影響を与え、ガイダンスを提供します。

• チームのコラボレーション、促進、マクロ管理。

• 方向性を提供します。

• 才能のある人々が革新的で創造的であり、効果的な意思決定を行うことができる環境を作ります。

• 時々彼らが命令する必要があることを理解してください、しかしそれは彼らの支配的なスタイルではありません。