Loading article…
アジャイルソフトウェア開発とは、2001年に17人のソフトウェア実務家が集まったアジャイルアライアンスが合意した価値観と原則を反映したソフトウェア開発手法の総称です。 [1]アジャイルソフトウェア開発宣言に記載されているように、実務家は次の点を重視しています。[2]
- プロセスやツールよりも個人と交流を重視
- 包括的なドキュメントよりも実用的なソフトウェア
- 契約交渉よりも顧客との協力
- 計画に従うよりも変化に対応する
実践者たちは、エクストリームプログラミング、スクラム、動的システム開発手法、適応型ソフトウェア開発など当時の新しい実践からインスピレーションを得たと述べ、ドキュメンテーション主導の重いソフトウェア開発プロセスに代わる方法の必要性に共感した。[3]
多くのソフトウェア開発手法は、アジャイルの考え方から生まれました。アジャイル（大文字のA）と呼ばれることもあるこれらのアジャイルベースの手法[4]には、自己組織化チームと機能横断型チームによる顧客/エンドユーザーとの共同作業による要件定義、発見、ソリューションの改善が含まれます。[5] [6]
アジャイルな考え方とアジャイルベースのプラクティスがソフトウェア開発プロセスを改善するという逸話的な証拠は数多くあるが、経験的な証拠は限られており、決定的なものではない。 [7] [8] [9]
歴史
反復的かつ漸進的なソフトウェア開発手法は1957年にまで遡ることができ、[10]進化型プロジェクト管理[11] [12]と適応型ソフトウェア開発[13]は1970年代初頭に登場しました。[14]
1990 年代には、過度に規制され、計画され、細かく管理されていると批評家が評した当時の重量級の開発手法 (まとめてウォーターフォールと呼ばれることが多い)への反応として、いくつかの軽量なソフトウェア開発手法が生まれました。[15]これらの軽量な開発手法には、 1991 年のラピッド アプリケーション開発(RAD)、[16] [17] 1994 年の統一プロセス( UP) と動的システム開発手法(DSDM)、 1995 年のScrum、1996 年の Crystal Clear とエクストリーム プログラミング(XP)、 1997 年の機能駆動開発(FDD) などがあります。これらはすべてアジャイル宣言が出版される前に生まれましたが、現在では総称してアジャイル ソフトウェア開発手法と呼ばれています。[3]
すでに1991年以降、製造業[18] [19]やリーン経営から派生した経営思想[20]においても同様の変化が進行していた。
2001年、17人のソフトウェア開発者がユタ州スノーバードのリゾートに集まり、軽量開発手法について議論した。メンバーは、ケント・ベック（エクストリームプログラミング）、ウォード・カニンガム（エクストリームプログラミング）、デイブ・トーマス（プラグマティックプログラミング、Ruby）、ジェフ・サザーランド（スクラム）、ケン・シュワバー（スクラム）、ジム・ハイスミス（アダプティブソフトウェア開発）、アリスター・コックバーン（クリスタル）、ロバート・C・マーティン（SOLID）、マイク・ビードル（スクラム）、アリー・ヴァン・ベネカム、マーティン・ファウラー（OOADおよびUML）、ジェームズ・グレニング、アンドリュー・ハント（プラグマティックプログラミング、Ruby）、ロン・ジェフリーズ（エクストリームプログラミング）、ジョン・カーン、ブライアン・マリック（Ruby、テスト駆動開発）、スティーブ・メラー（OOA ）である。このグループ、アジャイルアライアンスはアジャイルソフトウェア開発宣言を出版した。[2]
2005年、コックバーンとハイスミスが率いるグループは、アジャイルソフトウェア開発手法に従ったソフトウェアプロジェクト管理をガイドするための プロジェクト管理原則の補遺であるPM相互依存宣言[21]を作成しました。
2009 年、マーティンと共同作業するグループは、専門的な行動と習熟度 に応じてアジャイル ソフトウェア開発をガイドするためのソフトウェア開発原則の拡張である「ソフトウェア クラフトマンシップ マニフェスト」を作成しました。
2011年、アジャイルアライアンスはアジャイルプラクティスガイド（ 2016年にアジャイル用語集に改名）を作成しました。[22]これは、アジャイルプラクティス、用語、要素の実用的な定義と、世界中のアジャイル実践者コミュニティによる解釈と経験ガイドラインをまとめた、 進化を続けるオープンソースの概要です。
価値観と原則
価値観
アジャイル宣言にはこう書かれている: [2]
私たちは、自らソフトウェアを開発し、他の人のソフトウェア開発を支援することで、ソフトウェア開発のより良い方法を見つけ出しています。この仕事を通じて、私たちは以下の点に価値を見出しました。
- プロセスやツールよりも個人と交流を重視
- 包括的なドキュメントよりも実用的なソフトウェア
- 契約交渉よりも顧客との協力
- 計画に従うよりも変化に対応する
つまり、右側の項目にも価値がありますが、左側の項目の方がより価値があるということです。
スコット・アンブラーは次のように説明した。[23]
- ツールとプロセスは重要ですが、有能な人材が効果的に協力し合うことがさらに重要です。
- 優れたドキュメントは、ソフトウェアがどのように構築され、どのように使用されるかを人々に理解させるのに役立ちますが、開発の主な目的はドキュメントではなくソフトウェアを作成することです。
- 契約は重要ですが、顧客と緊密に連携して顧客のニーズを発見することに代わるものではありません。
- プロジェクト計画は重要ですが、テクノロジーや環境の変化、利害関係者の優先順位、問題とその解決策に対する人々の理解に対応できないほど厳格であってはなりません。
アジャイルアライアンスを代表してこのマニフェストを紹介したジム・ハイスミス氏は次のように述べた。
アジャイル運動は方法論に反対するものではなく、実際、私たちの多くは方法論という言葉の信頼性を回復したいと考えています。バランスを取り戻したいのです。モデリングは受け入れますが、それは埃をかぶった企業のリポジトリにダイアグラムを保管するためではありません。ドキュメントは受け入れますが、何百ページにも及ぶメンテナンスもほとんど行われない大冊は受け入れません。計画はしますが、不安定な環境における計画の限界を認識しています。XP や SCRUM、その他のアジャイル方法論の支持者を「ハッカー」と呼ぶ人は、方法論とハッカーという用語の本来の定義の両方を知らないのです。
— ジム・ハイスミス、歴史：アジャイル宣言[24]
原則
これらの価値観は以下の原則に基づいています: [25]
- 価値あるソフトウェアを早期かつ継続的に提供することで顧客満足を実現します。
- 開発後期であっても、要件の変更を歓迎します。
- 動作するソフトウェアを頻繁に（数か月ではなく数週間）提供します。
- ビジネスマンと開発者の間の密接な日常的な協力。
- プロジェクトは、信頼できる意欲的な個人を中心に構築されます。
- 対面での会話は、コミュニケーション（共存）の最良の形態です。
- 動作するソフトウェアは進捗状況を測る主な指標です。
- 一定のペースを維持できる持続可能な開発。
- 技術的な卓越性と優れたデザインへの継続的な配慮。
- シンプルさ、つまり、やらない仕事の量を最大化する技術が不可欠です。
- 最良のアーキテクチャ、要件、設計は、自己組織化されたチームから生まれます。
- チームは定期的に、より効果的になる方法を検討し、それに応じて調整します。
概要
反復的、漸進的、進化的
アジャイル開発手法の多くでは、製品開発作業を小さな増分単位に分割して、事前の計画と設計の量を最小限に抑えます。反復、またはスプリントは、通常1週間から4週間続く短い時間枠（タイムボックス）[26]です。 [27] : 20 各反復には、計画、分析、設計、コーディング、単体テスト、受け入れテストのすべての機能に取り組む部門横断的なチームが関与します。反復の最後には、動作する製品が利害関係者に示されます。これにより、全体的なリスクが最小限に抑えられ、製品は変更にすばやく適応できます。[28] [29]反復では、市場へのリリースを保証するのに十分な機能が追加されない可能性がありますが、各反復の終了時に（バグが最小限の）リリースが利用可能になることが目標です。[30]増分開発を通じて、製品は、最終リリース日に大幅に失敗するのではなく、各反復フェーズ全体を通して「頻繁かつ早期に失敗する」余地があります。 [31]製品または新機能をリリースするには、複数の反復が必要になる場合があります。実際に動作するソフトウェアが進捗状況を測る主な指標である。[25]
アジャイル アプローチの主な利点は、市場投入までのスピードとリスクの軽減です。通常、小さな増分単位で市場にリリースされるため、ユーザーの要件を満たさない製品を設計する時間とコストのリスクが軽減されます。
効率的で対面的なコミュニケーション
ソフトウェア開発のアジャイル宣言の 6 番目の原則には、「開発チーム内および開発チーム内で情報を伝達する最も効率的で効果的な方法は、対面での会話である」と記されています。ビデオ会議が広く普及していなかった 2001 年に書かれたこの宣言では、情報の伝達に関してこれを述べており、必ずしもチームが同じ場所にいなければならないとは述べていません。
コロケーションの原則は、同じチームの同僚が一緒にいることで、チームとしてのアイデンティティを確立し、コミュニケーションを改善するというものです。[32]これにより、理想的にはホワイトボードの前での対面でのやり取りが可能になり、電話、永続的なチャット、ウィキ、または電子メールを介して質疑応答を行う場合に通常かかるサイクルタイムが短縮されます。 [33] COVID-19パンデミック中にリモートワークが広く採用され、ツールが変更されたため、コロケーションと分散型作業に関するより多くの研究が実施され、 [34]コロケーションの重要性がますます低下していることがわかりました。
どの開発手法を採用する場合でも、すべてのチームに顧客担当者（スクラムではプロダクトオーナーと呼ばれる）が必要です。この担当者は、ステークホルダーの代理として行動することをステークホルダーから承認されており、イテレーション全体を通じて開発者の質問に答える用意があることを個人的に約束します。各イテレーションの終了時に、プロジェクトのステークホルダーは顧客担当者とともに進捗状況をレビューし、投資収益率（ROI）を最適化し、顧客のニーズと会社の目標との整合性を確保することを目的として優先順位を再評価します。各フェーズの終了時に頻繁にやり取りとレビューを行うことでステークホルダーの満足度が重要になるため、このアプローチは顧客中心の方法論と呼ばれることがよくあります。[35]
情報ラジエーター
アジャイルソフトウェア開発において、情報ラジエーターとは（通常は大型の）物理的なディスプレイ、付箋紙などが貼られたボードであり、開発チームの近くの目立つ場所に設置され、通行人の目に触れるようになっている。[36]製品開発状況の最新の概要を表示する。[37] [38]ビルドライトインジケーターは、チームに製品開発の現在の状況を知らせるために使用されることもある。
非常に短いフィードバックループと適応サイクル
アジャイルソフトウェア開発の共通の特徴は、毎日のスタンドアップ（スクラムフレームワークではデイリースクラムとして知られている）である。短いセッション（例えば15分）で、チームメンバーは目標に向かってどのように進んでいるかを集団でレビューし、アプローチを調整する必要があるかどうかについて合意する。合意された時間制限を守るために、チームはしばしば単純なコード化された質問（前日に何を完了したか、その日に何を完了することを目指しているか、進捗を妨げる障害やリスクがあるかどうかなど）を使用し、詳細な議論や問題解決をスタンドアップの後まで延期する。[39]
品質重視
継続的インテグレーション、自動ユニットテスト、ペアプログラミング、テスト駆動開発、デザインパターン、ビヘイビア駆動開発、ドメイン駆動設計、コードリファクタリングなどの特定のツールやテクニックは、品質を向上させ、製品開発の俊敏性を高めるためによく使用されます。[40]これは、最初から品質を設計して構築し、いつでも、または少なくとも各イテレーションの最後に顧客にソフトウェアをデモンストレーションできることを前提としています。[41]
哲学
従来のソフトウェア エンジニアリングと比較すると、アジャイル ソフトウェア開発は主に、動的、非決定的、非線形の特性を持つ複雑なシステムや製品開発を対象としています。正確な見積もり、安定した計画、予測は、初期段階では得にくいことが多く、それらに対する信頼は低い可能性があります。アジャイル実践者は、価値の証拠を得る前に必要な「信仰の飛躍」を減らすために自由意志を使用します。 [42]要件と設計は創発的であると考えられています。そのような場合、大規模な事前仕様はおそらく多くの無駄を引き起こし、経済的に健全ではありません。これらの基本的な議論と、長年の成功と失敗から学んだ以前の業界経験は、アジャイル開発が適応型、反復型、進化型開発を好むように形作るのに貢献しました。[43]
適応型と予測型
開発手法は、適応型から予測型まで連続体上に存在する。[44]アジャイルソフトウェア開発手法は、この連続体の適応型側に位置する。適応型開発手法の鍵となるのは、スケジュール計画に対するローリングウェーブアプローチであり、マイルストーンを特定しながらも、そこに到達するための経路に柔軟性を残し、マイルストーン自体の変更も可能にする。[45]
適応型手法は、変化する現実に素早く適応することに重点を置いています。プロジェクトのニーズが変わると、適応型チームも変わります。適応型チームは、将来何が起こるかを正確に説明することが困難です。日付が遠いほど、適応型手法ではその日に何が起こるかについて曖昧になります。適応型チームは、来週に行うタスクを正確に報告することはできませんが、来月に計画している機能についてのみ報告できます。6 か月後のリリースについて尋ねられた場合、適応型チームはリリースのミッション ステートメント、または期待される価値とコストのステートメントのみを報告できる可能性があります。
対照的に、予測的手法は、将来を詳細に分析および計画し、既知のリスクに対処することに重点を置いています。極端な場合、予測チームは、開発プロセス全体にわたって計画されている機能とタスクを正確に報告できます。予測的手法は、効果的な初期段階の分析に依存しており、これが大きく失敗すると、プロジェクトの方向転換が困難になる可能性があります。予測的チームは、最も価値のある変更のみを考慮するように、 変更管理委員会を設置することがよくあります。
リスク分析は、適応型（アジャイルまたは価値主導型）と予測型（計画主導型）の手法を選択するために使用できます。 [46] バリー・ボームとリチャード・ターナーは、連続体のそれぞれの側には、次のように独自のホームグラウンドがあると示唆しています。 [47]
アジャイル vs. ウォーターフォール
アジャイル ソフトウェア開発手法とウォーターフォールの違いの 1 つは、品質とテストへのアプローチです。ウォーターフォール モデルでは、作業はソフトウェア開発ライフサイクル(SDLC) の各フェーズを経て進み、1 つのフェーズが完了してから次のフェーズが開始されます。そのため、テスト フェーズは独立しており、ビルド フェーズの後に続きます。一方、アジャイル ソフトウェア開発では、テストはプログラミングと同じ反復で完了します。
テストはソフトウェアの小さな部分を開発するすべてのイテレーションで行われるため、ユーザーは新しいソフトウェアを頻繁に使用して価値を検証できます。更新されたソフトウェアの本当の価値をユーザーが知った後、ソフトウェアの将来についてより適切な決定を下すことができます。各イテレーションで価値の振り返りとソフトウェアの再計画セッションを行うことで ( Scrum のイテレーションは通常 2 週間だけです)、チームは計画を継続的に調整して、提供する価値を最大化することができます。これは、作業が計画され、実行され、確認され(レビューと振り返りで)、合意された変更が行われるという、計画-実行-確認-改善(PDCA) サイクルに似たパターンに従います。
この反復的なアプローチは、プロジェクトではなく製品という考え方をサポートします。これにより、開発プロセス全体にわたって柔軟性が高まります。一方、プロジェクトでは要件が最初から定義され、固定されているため、後で変更することが困難になります。反復的な製品開発により、ビジネス環境や市場の要件の変化に応じてソフトウェアを進化させることができます。
コードとドキュメント
IEEE Computerへの手紙の中で、Steven Rakitinはアジャイルソフトウェア開発について「ソフトウェアエンジニアリングの規律を弱体化させようとするもう一つの試み」と呼び、また「包括的なドキュメントよりも動作するソフトウェア」を「私たちはコーディングにすべての時間を費やしたいのです。本当のプログラマーはドキュメントを書かないことを忘れないでください」と翻訳した。[48]
これに対してアジャイルソフトウェア開発の支持者は異論を唱えており、開発者はそれが関連する目標を達成するための最善の方法であるならばドキュメントを書くべきだが、静的なドキュメントを書くよりも目標を達成するためのより良い方法があることがよくあると主張している。[49] スコット・アンブラーは、ドキュメントは「かろうじて十分な程度」であるべきである (JBGE) [50]と述べ、ドキュメントが多すぎたり包括的すぎると通常は無駄が生じ、開発者は詳細なドキュメントを信頼することはめったにない。なぜなら、ドキュメントはコードと同期していないことが多いからである[49]一方、ドキュメントが少なすぎると、メンテナンス、コミュニケーション、学習、知識共有に問題が生じる可能性がある。アリスター・コックバーンはクリスタルクリアメソッド について次のように書いている。
Crystal は開発を一連の協力型ゲームとみなし、ドキュメントが次のゲームで勝つために十分であることを意図しています。Crystal の作業成果物には、ユースケース、リスク リスト、反復計画、コア ドメイン モデル、および選択に関する情報を提供する設計メモが含まれます。ただし、これらのドキュメントにはテンプレートがなく、説明は必然的に曖昧になりますが、目的は明確で、次のゲームに十分なドキュメントです。私はいつも、チームに対してこれを次のように特徴づけています。「明日チームに参加したら、何を知りたいですか。」
— アリスター・コックバーン[51]
方法
アジャイルソフトウェア開発手法は、ソフトウェア開発ライフサイクルの広範囲をサポートします。[52]いくつかの手法はプラクティスに焦点を当てており（例：XP、プラグマティックプログラミング、アジャイルモデリング）、いくつかは作業フローの管理に焦点を当てています（例：スクラム、カンバン）。いくつかは要件仕様と開発の活動をサポートしますが（例：FDD）、いくつかは開発ライフサイクル全体をカバーしようとします（例：DSDM、RUP）。
注目すべきアジャイル ソフトウェア開発フレームワークには以下のものがあります。
アジャイルソフトウェア開発の実践
アジャイルソフトウェア開発は、要件、設計、モデリング、コーディング、テスト、計画、リスク管理、プロセス、品質などの分野をカバーする数多くの具体的な実践によってサポートされています。注目すべきアジャイルソフトウェア開発の実践には次のようなものがあります。[53]
受け入れテスト駆動開発
受け入れテスト駆動開発（ATDD）は、ビジネス顧客、開発者、およびテスター間のコミュニケーションに基づいた開発方法論です。 [54] ATDDには、例示による仕様記述（SBE）、[55] [56] 動作駆動開発（BDD）、[57]例駆動開発（EDD）、[58]およびストーリーテスト駆動開発（SDD）とも呼ばれるサポート駆動開発と同じプラクティスの多くが含まれます。[59]これらのプロセスはすべて、開発者とテスターが実装前に顧客のニーズを理解するのに役立ち、顧客が独自のドメイン言語で会話できるようにします。
アジャイルモデリング
アジャイルモデリング（AM）は、ベストプラクティスに基づいてソフトウェアシステムをモデリングおよび文書化する方法論です。これは、（アジャイル）ソフトウェア開発プロジェクトに適用できる価値と原則の集合です。この方法論は従来のモデリング方法よりも柔軟性が高く、急速に変化する環境に適しています。[60]これは、アジャイルソフトウェア開発ツールキットの一部です。
アジャイルテスト
アジャイル テストは、アジャイル ソフトウェア開発の原則に従ったソフトウェア テストの実践です。アジャイル テストには、テスターによる専門知識を備えた多機能アジャイル チームのすべてのメンバーが関与し、持続可能なペースで作業しながら、顧客が望むビジネス価値を頻繁に提供できるようにします。例による仕様は、望ましい動作と望ましくない動作の例をキャプチャし、コーディングをガイドするために使用されます。
バックログ
アジャイルプロジェクト管理
において、プロダクトバックログとは、製品に含まれるべき機能の優先順位リストを指します。これは、to-doリストと呼ばれることもあり、[61]スクラムソフトウェア開発フレームワークでは「成果物」（ドキュメントの一種）と見なされます。[62]プロダクトバックログは、スクラムではプロダクトバックログ、[62] [63]ディシプリンドアジャイルでは作業項目リスト、[63] [64]リーンではオプションプールなど、プロジェクト管理フレームワークによって異なる名前で呼ばれます。[63]スクラムフレームワークでは、プロダクトバックログの作成と継続的なメンテナンスは、プロダクトオーナーの責任の一部です。[65]
行動主導型開発
継続的インテグレーション
継続的インテグレーション(CI) とは、ソース コードの変更を頻繁に統合し、統合されたコードベースが動作可能な状態であることを保証する手法です。
多機能チーム
クロスファンクショナルチーム
（XFN）は、マルチディスシプリナリーチームまたはインターディスシプリナリーチームとも呼ばれ、[66] [67] [68]共通の目標に向かって取り組む、異なる機能の専門知識を持つ人々のグループです。[69]財務、マーケティング、運用、人事部門の人々が含まれる場合があります。通常、組織のすべてのレベルの従業員が含まれます。メンバーは組織外（特に、サプライヤー、主要顧客、またはコンサルタント）から来る場合もあります。
毎日のスタンドアップ
方法のカスタマイズ
文献では、メソッドの適応の概念を指すさまざまな用語が使用されており、「メソッドの調整」、「メソッドの断片の適応」、「状況に応じたメソッドのエンジニアリング」などがあります。メソッドの調整は次のように定義されています。
コンテキスト、意図、およびメソッドの断片間の応答的な変化と動的な相互作用を通じて、人間のエージェントが特定のプロジェクト状況に対するシステム開発アプローチを決定するプロセスまたは機能。
— メフメット・ナフィズ・アイディン他「アジャイル情報システム開発手法の実践」[70]
状況適合性は、アジャイル手法と、より計画主導型のソフトウェア開発手法とを区別する特徴として考えるべきであり、アジャイル手法では、製品開発チームが個々の製品のニーズに応じて作業方法を適応させることができます。[71] [70]潜在的には、ほとんどのアジャイル手法は、 CMMコンテキストで調整されたDSDMなど、手法の調整に適しています。[52 ] [72]およびルール記述プラクティス(RDP) テクニックで調整された XP。[73]ただし、すべてのアジャイル支持者が同意するわけではありません。Schwaber は、「問題は完璧な方法論がないことだと考え、それがそもそも問題になった原因です。努力は、企業で必要な変更に集中する必要があります」と述べています。[74] Bas Vodde はこの見解を補強し、要素を取捨選択する必要がある従来の大規模な方法論とは異なり、Scrum は基本を提供し、その上に要素を追加して使用をローカライズおよびコンテキスト化することを示唆しています。[75]実践者はシステム開発手法、特にアジャイル手法を教科書通りに使用することはほとんどなく、社内用の手法を作成するために手法の一部を省略したりカスタマイズしたりすることを選択することが多い。[76]
実際には、さまざまなツールを使用してメソッドをカスタマイズできます。統一モデリング言語などの汎用プロセスモデリング言語を使用して、ソフトウェア開発メソッドをカスタマイズできます。ただし、 SEMATのソフトウェアエンジニアリングのエッセンス理論など、メソッドエンジニアリング専用のツールも存在します。[77]
大規模、オフショア、分散型
アジャイルソフトウェア開発は、グリーンフィールドプロジェクトに取り組む専門家の小規模チームを含む特定のタイプの環境に非常に適していると広く考えられてきました。[ 47] [78]また、レガシーインフラストラクチャを備えた大規模組織でアジャイルソフトウェア開発手法を導入する際に直面する課題と制限は、十分に文書化され、理解されています。[79]
これに応じて、大規模な開発作業（20人以上の開発者） [80] [81]や分散型（非共同）開発チーム[82] [83]などの課題を克服するためのさまざまな戦略とパターンが進化しており、現在ではこれらの課題を軽減または回避しようとするいくつかの認知されたフレームワークが存在します。
これらすべてが効果的であるか、あるいはアジャイル開発の定義に実際に適合するかどうかについては多くの相反する見解があり、これは現在も活発に研究が続けられている分野です。[80] [84]
アジャイル ソフトウェア開発が分散環境 (チームが複数の事業所に分散している) で適用される場合、一般的には分散アジャイル ソフトウェア開発と呼ばれます。目標は、各アプローチが提供する独自の利点を活用することです。分散開発により、組織は戦略的に世界中のさまざまな場所にチームを配置してソフトウェアを構築し、事実上 24 時間体制でソフトウェアを構築できます (一般的にはフォロー ザ サン モデルと呼ばれます)。一方、アジャイル開発では、透明性が向上し、フィードバックが継続され、変更に対応する際の柔軟性が高まります。
規制対象ドメイン
アジャイルソフトウェア開発手法は当初、重要でない製品開発に最適であると考えられていたため、医療機器、製薬、金融、原子力システム、自動車、航空電子工学などの規制対象分野での使用は除外されていました。しかし、ここ数年、これらの分野にアジャイル手法を採用するための取り組みがいくつか行われてきました。[85] [86] [87] [88] [89]
規制対象領域に適用される規格は数多くあり、その中にはISO 26262、ISO 9000、ISO 9001、ISO/IEC 15504などがある。規制対象領域では、いくつかの重要な懸念事項が特に重要である。[90]
- 品質保証(QA): 管理された専門的なプロセスと製品の信頼性および正確性を支える体系的かつ固有の品質管理。
- 安全性とセキュリティ: ユーザーの安全上のリスクを軽減し、意図しない悪意のある誤用からユーザーを安全に保護するための正式な計画とリスク管理。
- トレーサビリティ: 規制遵守の監査可能な証拠を提供し、トレーサビリティと問題の調査を容易にするドキュメント。
- 検証と妥当性確認(V&V): ソフトウェア開発プロセス全体に組み込まれます (例: ユーザー要件仕様、機能仕様、設計仕様、コードレビュー、単体テスト、統合テスト、システムテスト)。
経験と採用
アジャイルソフトウェア開発手法は、実際にはどんなプログラミングパラダイムや言語でも使用できますが、もともとは Smalltalk、Lisp、後に Java、C# などのオブジェクト指向環境と密接に関連していました。アジャイル手法を最初に採用したのは、通常、最終決定が難しく、システムの開発中に変更される可能性のある要件を持つ前例のないシステムに取り組んでいる小規模から中規模のチームでした。このセクションでは、組織がアジャイルソフトウェア開発手法を採用しようとする際に遭遇する一般的な問題と、アジャイルチームの品質とパフォーマンスを測定するさまざまな手法について説明します。[91]
敏捷性の測定
内部評価
アジリティ測定指標は、製品開発の5つの側面（期間、リスク、新規性、労力、相互作用）に基づいて開発を評価する。[92]他の手法は測定可能な目標に基づいており[93]、ある研究では速度がアジリティの指標として使用できることが示唆されている。チームがアジャイルソフトウェア開発手法を使用しているかどうかを判断するためのアジャイル自己評価もある（ノキアテスト、[94]カールスクルーナテスト、[95] 42ポイントテスト）。[96]
公共調査
アジャイルソフトウェア開発手法の使用による品質、生産性、ビジネス満足度の向上を報告した初期の研究の1つは、2002年11月から2003年1月にかけてシャインテクノロジーズが実施した調査でした。[97]
同様の調査である「アジャイルの現状」は、2006年から毎年、ソフトウェア開発コミュニティの何千人もの参加者を対象に実施されている。これは、アジャイルのメリット、学んだ教訓、優れた実践に関する傾向を追跡するものである。各調査では、アジャイルソフトウェア開発によってソフトウェアの提供が迅速化され、顧客の優先順位の変化に対応する能力が向上し、生産性が向上すると回答する人が増えていると報告されている。[98]また、調査では、アジャイル製品開発手法の方が従来のプロジェクト管理よりも良い結果が一貫して示されている。[99] [100]一方、アジャイル開発手法はまだ初期段階であるため、その成功について広範な学術研究を行うことはできないと考える人もいるという報告もある。[101]
アジャイルソフトウェア開発のよくある落とし穴
アジャイルソフトウェア開発を実装している組織やチームは、ウォーターフォール開発などの従来の方法から移行する際に、アジャイルプロセスを強制されるチームなど、困難に直面することがよくあります。 [102]これらは、アジャイルアンチパターン、またはより一般的にはアジャイルスメルと呼ばれることがよくあります。以下に一般的な例をいくつか示します。
全体的な製品デザインの欠如
アジャイルソフトウェア開発の目標は、ドキュメントよりも、実際に動作するソフトウェアの作成に重点を置くことです。これは、プロセスが高度に制御され、システムに小さな変更を加えると、サポートドキュメントを大幅に改訂する必要があるウォーターフォールモデルとは対照的です。ただし、分析や設計をまったく行わないことを正当化するものではありません。設計に注意を払わないと、最初はチームが迅速に作業を進めても、システムを拡張しようとすると大幅なやり直しが必要になる可能性があります。アジャイルソフトウェア開発の主な特徴の 1 つは、反復的であることです。正しく実行すれば、アジャイルソフトウェア開発では、システムの開発中に設計が浮かび上がり、チームが共通点や再利用の機会を発見するのに役立ちます。[103]
進行中のイテレーションにストーリーを追加する
アジャイルソフトウェア開発では、ストーリー（ユースケースの説明に似ている）は通常、要件を定義するために使用され、イテレーションはチームが特定の目標に取り組む短い期間です。[104]進行中のイテレーションにストーリーを追加すると、作業の流れが悪くなります。これらは製品バックログに追加され、後続のイテレーションに優先される必要があります。まれに、イテレーションがキャンセルされることもあります。[105]
これは、ストーリーを拡張できないという意味ではありません。チームは新しい情報に対処する必要があり、それによってストーリーに追加のタスクが生成される場合があります。新しい情報によってイテレーション中にストーリーを完了できない場合は、次のイテレーションに持ち越す必要があります。ただし、新しい情報によってストーリーの元の優先順位が変更されている可能性があるため、残りのすべてのストーリーよりも優先する必要があります。
スポンサーのサポート不足
アジャイルソフトウェア開発は、多くの場合、ソフトウェア開発チームが開発プロセスを最適化し、ソフトウェア開発ライフサイクルの一貫性を確保するために、組織内で草の根の取り組みとして実装されます。スポンサーのサポートがないと、チームはビジネスパートナー、他の開発チーム、経営陣からの困難や抵抗に直面する可能性があります。さらに、適切な資金とリソースがないと、チームは苦しむ可能性があります。[106]これにより、失敗する可能性が高まります。[107]
不十分なトレーニング
VersionOneが実施した調査によると、回答者はアジャイル実装の失敗の最大の原因としてトレーニング不足を挙げている[108]。チームは、ウォーターフォールなどの他のアプローチと比較してアジャイルソフトウェア開発のプロセスが削減されていると想定する罠に陥っており、アジャイルソフトウェア開発には実際のルールがないことを意味する。[要出典]
プロダクトオーナーの役割が適切に果たされていない
プロダクトオーナーは開発活動においてビジネスを代表する責任があり、最も要求の厳しい役割を担うことが多い。[109]
よくある間違いは、開発チームの誰かをプロダクトオーナーの役割に就かせることです。これにより、チームはビジネスからの実際のフィードバックなしに優先順位を独自に決定する必要があります。彼らはビジネス上の問題を内部で解決しようとしたり、チーム外に指示を求めて仕事を遅らせたりします。これはしばしば注意散漫やコラボレーションの崩壊につながります。[110]
チームは集中していない
アジャイルソフトウェア開発では、チームは製品に対するコミットメントを満たす必要があるため、その製品のみの作業に集中する必要があります。しかし、余裕があるように見えるチームメンバーは、他の作業を引き受けることが求められることが多く、チームがコミットした作業の完了に貢献することが困難になります。[111]
過剰な準備/計画
チームは、準備や計画に時間をかけすぎるという罠に陥ることがあります。これは、アジャイル ソフトウェア開発にあまり慣れていないチームによくある罠で、チームはすべてのストーリーを完全に理解し、仕様を定めなければならないと感じています。チームは、自信を持っているストーリーのみで前進する準備をし、反復中に後続の反復のための作業 (バックログの洗練またはグルーミングと呼ばれることが多い) を継続的に発見して準備する必要があります。
毎日のスタンドアップでの問題解決
毎日のスタンドアップは、チームメンバー全員が情報を発信する、集中的でタイムリーな会議であるべきです。問題解決が行われる場合、多くの場合、特定のチームメンバーのみが関与することになり、チーム全体の時間を最も有効に活用できない可能性があります。毎日のスタンドアップ中にチームが問題解決に取り組み始めた場合は、通常はスタンドアップが完了した直後にサブチームが議論できるまで、スタンドアップを脇に置いておく必要があります。[112]
タスクの割り当て
アジャイルソフトウェア開発の意図された利点の1つは、問題に最も近いチームに選択の権限を与えることです。さらに、決定にタイムリーな情報を使用するために、実装にできるだけ近い時点で選択を行う必要があります。チームメンバーに他の人がタスクを割り当てたり、プロセスの早い段階でタスクを割り当てたりすると、局所的でタイムリーな意思決定の利点が失われる可能性があります。[113]
仕事が割り当てられると、チームメンバーは特定の役割に制約され（たとえば、チームメンバーAは常にデータベース作業を行わなければならない）、クロストレーニングの機会が制限されます。[113]チームメンバー自身が、自分の能力を伸ばし、クロストレーニングの機会を提供するタスクを引き受けることを選択することができます。
貢献者としてのスクラムマスター
アジャイルの価値と原則に一致していると主張するスクラムフレームワークでは、スクラムマスターの役割は、スクラムプロセスが遵守されていることを確認することと、そのプロセスを通じてスクラムチームを指導することに責任があります。よくある落とし穴は、スクラムマスターが貢献者として行動することです。スクラムフレームワークでは禁止されていませんが、スクラムマスターは、まずスクラムマスターの役割を果たす能力があり、開発タスクに取り組まないことを確認する必要があります。スクラムマスターの役割は、製品を作成することではなく、プロセスを促進することです。[114]
スクラムマスターがマルチタスクをこなすと、コンテキストスイッチが多すぎて生産性が低下する可能性があります。さらに、スクラムマスターはチームが前進できるように障害を取り除く責任があるため、個々のタスクを前進させることで得られる利益は、能力不足のために延期される障害を上回らない可能性があります。[115]
テスト自動化の欠如
アジャイル開発は反復的な性質を持っているため、複数回のテストが必要になることがよくあります。自動テストは、繰り返し行われる単体テスト、統合テスト、回帰テストの影響を軽減し、開発者とテスト担当者がより価値の高い作業に集中できるようにします。[116]
テスト自動化は、反復的なソフトウェア開発に必要な継続的なリファクタリングもサポートします。開発者がテストを迅速に実行して、リファクタリングによってアプリケーションの機能が変更されていないことを確認できるようにすることで、作業負荷が軽減され、クリーンアップ作業によって新しい欠陥が発生していないという確信が高まります。
技術的負債を蓄積させる
新しい機能を提供することに重点を置くと、技術的負債が増加する可能性があります。チームは欠陥の修正とリファクタリングのための時間を確保する必要があります。技術的負債は、生産上の欠陥がチームのさらなる進歩を妨げるため、予定外の作業量を増加させ、計画能力を妨げます。[117]
システムが進化するにつれて、リファクタリングが重要になります。[118]時間の経過とともに、継続的なメンテナンスの欠如により、欠陥と開発コストが増加します。[117]
反復で多くのことをやろうとする
アジャイルソフトウェア開発では継続的な変更が可能であるという誤解がよくありますが、イテレーションバックログはイテレーション中に完了できる作業の合意です。[119]進行中の作業（WIP）が多すぎると、コンテキストの切り替えやキューイングなどの非効率が生じます。 [120]チームは、追加の作業を引き受けるプレッシャーを感じないようにする必要があります。[121]
固定された時間、リソース、範囲、品質
アジャイルソフトウェア開発では、時間（反復期間）、品質、そして理想的にはリソースを事前に固定しますが（ただし、開発者が生産インシデントを処理するためにタスクから頻繁に引き離される場合、固定リソースを維持することは困難です）、スコープは可変のままです。顧客または製品所有者は、反復の固定スコープを要求することがよくあります。ただし、チームは、固定された時間、リソース、スコープ（一般にプロジェクト管理の三角形として知られています）にコミットすることに消極的である必要があります。アジャイルソフトウェア開発の固定された時間とリソースにスコープを追加しようとすると、品質が低下する可能性があります。[122]
開発者の燃え尽き
アジャイルプラクティスは集中したペースと継続的な性質を持っているため、デリバリーチームのメンバーが燃え尽きてしまうリスクが高まります。[123]
アジャイル管理
アジャイルプロジェクト管理は反復的な開発プロセスであり、ユーザーや関係者からフィードバックを継続的に収集して、適切なユーザーエクスペリエンスを作成します。アジャイルプロセスを実行するには、スクラム、エクストリームプログラミング、リーン、カンバンなどのさまざまな方法を使用できます。[124]アジャイル管理 という用語は、アジャイルソフトウェア開発宣言で表現されている原則に基づいて、非常に柔軟でインタラクティブな方法で新しい製品またはサービスの開発を提供することを目的とした、エンジニアリング、情報技術、およびその他のビジネス分野の設計および構築アクティビティを管理する反復的で漸進的な方法に適用されます。[125] アジャイルプロジェクト管理メトリックは、開発サイクル全体を通じて混乱を減らし、弱点を特定し、チームのパフォーマンスを測定するのに役立ちます。サプライチェーンのアジリティとは、サプライチェーンがオファーと需要の不確実性と変動性に対処する能力です。アジャイルサプライチェーンは容量を迅速に増減できるため、急速に変化する顧客の需要に適応できます。最後に、戦略的アジリティとは、環境の変化に応じて組織が行動方針を変更する能力です。戦略的敏捷性の鍵は、外部の変化を早期に認識し、変化する環境に適応するためのリソースを割り当てることです。[124]
アジャイルX技法は、エクストリームプロジェクトマネジメントとも呼ばれます。これは、成果物が段階的に提出される反復ライフサイクル[126]の変形です。アジャイル開発と反復開発の主な違いは、アジャイル手法では各配信サイクル（反復）で成果物の小さな部分を完了するのに対し、[127] 反復手法では成果物のセット全体を時間の経過とともに進化させ、プロジェクトの終わり近くに完了することです。反復手法とアジャイル手法はどちらも、より順次的な形式のプロジェクト組織で発生したさまざまな障害への対応として開発されました。たとえば、技術プロジェクトが複雑になるにつれて、エンドユーザーはプログレッシブプロトタイプを確認できずに長期的な要件を定義することが困難になる傾向があります。反復で開発されるプロジェクトでは、それらの要件を洗練するために常にフィードバックを集めることができます。
アジャイル管理は、チームメンバー間のコミュニケーションと過去の仕事の振り返りを促進するシンプルなフレームワークも提供します。 [128]従来のウォーターフォール計画を使用していたチームがアジャイル開発方法を採用した場合、通常は変革フェーズを経て、よりスムーズな変革を導くアジャイルコーチの助けを借りることがよくあります。アジャイルコーチングには、プッシュベースとプルベースの2つのスタイルがあります。ここで「プッシュシステム」とは、スプリントに組み込むことができるタスクの事前見積もり（プッシュ作業）を指し、たとえばスクラムで一般的です。一方、「プルシステム」とは、キャパシティが利用可能な場合にのみタスクが実行される環境を指します。[129]アジャイル管理アプローチは、ビジネスおよび政府部門にも採用され、適応されています。たとえば、米国連邦政府では、米国国際開発庁（USAID）が、プログラミングを反復および適応させるために、コラボレーション、学習、適応（CLA）戦略を組み込むことに焦点を当てたコラボレーションプロジェクト管理アプローチを採用しています。[130]
アジャイル手法は、『プロジェクトマネジメント知識体系ガイド』（PMBOK ガイド第 6 版）の製品開発ライフサイクルの定義に記載されています。
プロジェクトライフサイクルには、通常、製品、サービス、または結果の開発に関連する 1 つ以上のフェーズがあります。これらは開発ライフサイクルと呼ばれます (...) 適応型ライフサイクルは、アジャイル、反復型、または増分型です。詳細な範囲は、反復の開始前に定義され、承認されます。適応型ライフサイクルは、アジャイルまたは変更主導型ライフサイクルとも呼ばれます。[131]
ソフトウェア開発以外のアプリケーション
ジャン＝ルー・リシェ（ ESSEC戦略イノベーション＆サービス研究所の研究員）によると、「このアプローチは、特にイノベーションと不確実性の分野において、非ソフトウェア製品やプロジェクト管理全般に効果的に活用できます。」その結果、現在の顧客ニーズに最も適した製品やプロジェクトが最小限のコスト、無駄、時間で提供され、企業は従来のアプローチよりも早く収益を上げることができます。[132]
アジャイルソフトウェア開発手法は、ソフトウェア製品の開発に広く使用されており、オブジェクトテクノロジーなどのソフトウェアの特定の特性を使用しているものもあります。[133]ただし、これらの手法は、コンピューター、医療機器、食品、衣料品、音楽などの非ソフトウェア製品の開発にも適用できます。[134]アジャイルソフトウェア開発手法は、開発以外のITインフラストラクチャ の展開と移行にも使用されています。 アジャイルソフトウェア開発のより広範な原則の一部は、ビジネスアジリティまたはアジャイルビジネスマネジメントという用語で、一般的な管理[135] （戦略、ガバナンス、リスク、財務など）にも適用されています。 アジャイルソフトウェア方法論は、学習科学、人間中心設計、データに基づく意思決定を適用して学習者とその発達を支援する反復的なデータ情報に基づくプロセスである学習エンジニアリングプロセスでも採用されています。 [136]
アジャイルソフトウェア開発パラダイムは、子育てなど、人生の他の分野でも活用できます。子どもの発達における成功は、コミュニケーション、適応、認識といった基本的な管理原則に基づいている可能性があります。TEDトークで、ブルース・ファイラーは、基本的なアジャイルパラダイムを家庭管理と子育てにどのように適用したかを語りました。[137]
批判
アジャイルプラクティスは、大規模な組織や特定の種類の開発では潜在的に非効率的であると指摘されてきました。[138]多くの組織は、アジャイルソフトウェア開発方法論は極端すぎると考え、アジャイルソフトウェア開発と計画主導型アプローチの要素を組み合わせたハイブリッドアプローチを採用しています。[139]動的システム開発法（DSDM）などの一部の方法は、基本原則を犠牲にすることなく、規律ある方法でこれを試みます。
アジャイル手法の採用が増えていることは、既存の優れた手法を新しい専門用語で単純に表現し、開発戦略に対して画一的な考え方を推進し、結果よりも方法を誤って強調する経営上の流行であると批判されている。[141]
アリスター・コックバーンは、2011 年 2 月 12 日にユタ州スノーバードでアジャイル ソフトウェア開発宣言10 周年記念式典を開催し、最初の会議とそれ以降に関わった約 30 名以上の人々を集めました。約 20 の「議論の余地のない」アジャイルの話題/問題のリストが収集され、アジャイル ソフトウェア開発の実践とコンテキストの提携、失敗と限界 (考えられる原因: 商業的利益、コンテキストからの逸脱、失敗に基づいて進歩する明らかな方法がない、客観的証拠が限られている、認知バイアスと推論の誤り)、政治、文化などの側面が含まれていました。[142]フィリップ・クルヒテンは次のように書いています。
アジャイル運動は、ある意味ではティーンエイジャーに少し似ています。非常に自意識過剰で、鏡で自分の姿を常にチェックし、批判をほとんど受け入れず、仲間と一緒にいることにしか興味がなく、過去の知恵を、それが過去のものだという理由だけで、一括して拒絶し、流行や新しい専門用語を取り入れ、時には自信過剰で傲慢です。しかし、それがさらに成熟し、外の世界に対してよりオープンになり、より思慮深くなり、したがってより効果的になることに私は疑いの余地がありません。
— フィリップ・クルヒテン[142]
「マニフェスト」は高等教育の管理とリーダーシップに悪影響を及ぼした可能性がある。それは、管理者に対して、より遅い伝統的で審議的なプロセスを、より「機敏な」ものに置き換えるべきだと示唆したからである。この概念は大学教員の間でほとんど受け入れられなかった。[143]
もう一つの批判は、アジャイル管理と従来の管理手法は、多くの点で互いに相反するものになってしまうという点です。この手法に対する一般的な批判は、潜在的なメリットがあるにもかかわらず、手法の習得と実装に費やす時間はコストがかかりすぎるというものです。従来の管理からアジャイル管理に移行するには、アジャイルへの完全な服従と、組織のメンバー全員がプロセスを最後までやり遂げるという確固たる決意が必要です。組織全体で結果が不平等になること、従業員の対応能力を超えた変化が多すぎること、変革の最後に保証がないなどの問題は、ほんの一例です。[144]
参照
- アジャイル自動化
- 多機能チーム
- スクラム（ソフトウェア開発）
- フェイルファスト（ビジネス）は、ビジネス管理の関連テーマです。
- カンバン
- アジャイルリーダーシップ
- アジャイル契約
- 合理的な統一プロセス
参考文献
- ^ 「アジャイルとは何か?」Agile Alliance . 2024年7月16日閲覧。
- ^ abc Kent Beck ; James Grenning; Robert C. Martin ; Mike Beedle; Jim Highsmith ; Steve Mellor ; Arie van Bennekum; Andrew Hunt ; Ken Schwaber ; Alistair Cockburn ; Ron Jeffries ; Jeff Sutherland ; Ward Cunningham ; Jon Kern ; Dave Thomas ; Martin Fowler ; Brian Marick (2001). 「アジャイルソフトウェア開発宣言」. Agile Alliance . 2010年6月14日閲覧。
- ^ ab ラーマン、クレイグ (2004)。アジャイルおよび反復開発: マネージャー向けガイド。アディソン・ウェズレー。p. 27。ISBN 978-0-13-111155-4。
- ^ Rally (2010). 「大文字の「A」の Agile と小文字の「a」の Agile の違い」。2016年1月5日時点のオリジナルよりアーカイブ。2015年9月9日閲覧。
{{cite web}}: CS1 maint: unfit URL (link) - ^ コリアー 2011年。
- ^ 「アジャイルソフトウェア開発とは何か?」 Agile Alliance 2013 年 6 月 8 日. 2015 年4 月 4 日閲覧。
- ^ Dybå, Tore; Dingsøyr, Torgeir (2008 年8 月 1 日)。「アジャイル ソフトウェア開発の実証研究: 体系的レビュー」。情報およびソフトウェア技術。50 (9–10): 833–859。doi : 10.1016 /j.infsof.2008.01.006。ISSN 0950-5849。S2CID 2244031 。
- ^ Lee, Gwanhoo; Xia, Weidong (2010). 「アジャイルに向けて: ソフトウェア開発のアジリティに関する定量的および定性的な現場データの統合分析」MIS Quarterly . 34 (1): 87–114. doi :10.2307/20721416. JSTOR 20721416. S2CID 26477249.
- ^ Kroll, J.; Richardson, I.; Prikladnicki, R.; Audy, JL (2018). 「Follow the Sun ソフトウェア開発における実証的証拠: 体系的なマッピング研究」.情報およびソフトウェア技術. 93 : 30–44. doi :10.1016/j.infsof.2017.08.011. hdl : 10344/6233 .
- ^ ジェラルド・M・ワインバーグ、ラーマン＆バシリ2003、47～56ページより引用 「我々は1957年という早い時期に、IBMのサービスビューローコーポレーションのバーニー・ディムズデールの指導の下、ロサンゼルスで増分開発を行っていた。彼はジョン・フォン・ノイマンの同僚だったので、おそらくそこで学んだか、まったく自然なことだと思っていたのだろう。ハーブ・ジェイコブス（主にジェイコブスだが、私たち全員が参加していた）がモトローラ向けの大規模なシミュレーションを開発していたのを覚えています。私が知る限り、そこで使用された手法は… 記憶している限り、私たち全員が、巨大プロジェクトにウォーターフォールを採用するのはかなり愚か、あるいは少なくとも現実を無視していると考えていました。ウォーターフォールの説明によって、自分たちが何か他のこと、つまり「ソフトウェア開発」以外の名前のつかないことをやっていることに気付いたのだと思います。」
- ^ 「進化型プロジェクト管理（オリジナルページ、外部アーカイブ）」。Gilb。2016年3月27日時点のオリジナルよりアーカイブ。2017年4月30日閲覧。
- ^ 「進化型プロジェクト管理（新ページ）」Gilb . 2017年4月30日閲覧。
- ^ Edmonds, EA (1974). 「非技術者向けソフトウェア開発プロセス - 適応型システムとして」.一般システム. 19 : 215–18.
- ^ Gilb, Tom (1981 年 4 月 1 日). 「進化的開発」. ACM SIGSOFT ソフトウェア エンジニアリング ノート. 6 (2): 17. doi :10.1145/1010865.1010868. S2CID 33902347.
- ^ Swamidass, PM, ed. (2000)、「ヘビーウェイト プロジェクト組織HEAVYWEIGHT PROJECT ORGANIZATION」、Encyclopedia of Production and Manufacturing Management、ボストン、MA: Springer US、pp. 261–262、doi :10.1007/1-4020-0612-8_400、ISBN 978-1-4020-0612-8、 2022年6月22日閲覧
- ^ マーティン、ジェームズ (1991)。ラピッドアプリケーション開発。マクミラン。ISBN 978-0-02-376775-3。
- ^ Kerr, James M.; Hunter, Richard (1993). Inside RAD: 90日以内で完全に機能するシステムを構築する方法. McGraw-Hill. p. 3. ISBN 978-0-07-034223-1。
- ^ アイアコッカ研究所 (1991)。「21 世紀の製造業の企業戦略: 業界主導の視点」。アイアコッカ研究所、リーハイ大学、ペンシルバニア州ベスレヘム。
- ^ Presley, A., J. Mills および D. Liles (1995)。「Agile Aerospace Manufacturing」。Nepcon East 1995、ボストン。
- ^ Sanchez, Luis (2010年11月)。「アジャイル製造システムのレビュー」。International Journal of Production Research (39(16):3561-3600)。
- ^ アンダーソン、デイビッド（2005年）。「相互依存宣言」。2018年1月27日時点のオリジナルよりアーカイブ。2018年10月4日閲覧。
- ^ McDonald, Kent (2016 年 11 月 1 日)。「Agile Alliance の支援を受けるためにできること」。Agile Alliance ブログ。2017年7 月 4 日閲覧。
- ^ 「アジャイル宣言の検証」 Ambysoft Inc . 2011 年4 月 6 日閲覧。
- ^ Jim Highsmith (2001)。「歴史: アジャイル宣言」。agilemanifesto.org。
- ^ ab Kent Beck ; James Grenning; Robert C. Martin ; Mike Beedle; Jim Highsmith ; Steve Mellor ; Arie van Bennekum; Andrew Hunt ; Ken Schwaber ; Alistair Cockburn ; Ron Jeffries ; Jeff Sutherland ; Ward Cunningham ; Jon Kern ; Dave Thomas ; Martin Fowler ; Brian Marick (2001). 「Agile マニフェストの背後にある原則」. Agile Alliance. 2010 年 6 月 14 日時点のオリジナルよりアーカイブ。2010年6 月 6 日閲覧。
- ^ Project Management Institute 2021、2.3.3 開発アプローチ。
- ^ ルビン 2013.
- ^ Project Management Institute 2021、§3.12 想定される将来の状態を達成するための変更を可能にする。
- ^ Moran, A. (2014).アジャイルリスクマネジメント. Springer Verlag. ISBN 978-3319050072。
- ^ Beck, Kent (1999). 「エクストリームプログラミングによる変化の受け入れ」.コンピュータ. 32 (10): 70–77. doi :10.1109/2.796139.
- ^ Mergel, Ines (2016年7月). 「政府におけるアジャイルイノベーション管理：研究課題」.政府情報四半期誌. 33 (3): 516–523. doi :10.1016/j.giq.2016.07.004.
- ^ Preuss, Deborah Hartmann (2006 年 10 月 13 日)。「調査: 共同配置チーム vs. キュービクルファーム」。InfoQ。2018年10月 23 日閲覧。
- ^ Cockburn, Alistair (2007). 「アジャイルソフトウェア開発: 協力ゲーム」www.pearson.com (第2版). Addison-Wesley Professional . 2018年10月23日閲覧。
- ^ 「マネジメントの変革 | 研究」。
- ^ Jain, Parita; Sharma, Arun; Ahuja, Laxmi (2018 年 8 月)。「アジャイル ソフトウェア開発プロセスがソフトウェア製品の品質に与える影響」。2018年 7 回目の信頼性、情報通信技術、最適化に関する国際会議 (動向と今後の方向性) (ICRITO)。インド、ノイダ: IEEE。pp. 812–815。doi : 10.1109 / ICRITO.2018.8748529。ISBN 978-1-5386-4692-2. S2CID 195775457。
- ^ Project Management Institute 2021、§2.7.3.2 情報ラジエーター。
- ^ コックバーン、アリスター（2008年6月19日）。「情報ラジエーター」
- ^ アンブラー、スコット (2002 年 4 月 12 日)。アジャイルモデリング: エクストリームプログラミングと統合プロセスのための効果的な実践。ジョン ワイリー アンド サンズ。pp . 12、164、363。ISBN 978-0-471-20282-0。
- ^ Vasiliauskas, Vidas (2014). 「アジャイルプロジェクトのタスクとチーム管理の実践の開発」 Eylean. 2014年9月15日時点のオリジナルよりアーカイブ。 2014年9月15日閲覧。
- ^ Jeffries, Ron; Anderson, Ann; Hendrickson, Chet (2001). Extreme Programming のインストール。Addison-Weslsy。pp. 72–147。ISBN 978-0201-70842-4。
- ^ Lisa Crispin、Janet Gregory (2009)。アジャイルテスト：テスターとアジャイルチームのための実践ガイド。Addison-Wesley。
- ^ ミッチェル、イアン (2016)。アジャイル開発の実践。タマレハウス。p. 11。ISBN 978-1-908552-49-5。
- ^ ラーマン、クレイグ (2004)。アジャイルおよび反復開発:マネージャー向けガイド。アディソン・ウェズリー。p. 27。ISBN 978-0-13-111155-4。
- ^ Boehm, B. ; R. Turner (2004).敏捷性と規律のバランス: 困惑した人のためのガイド. ボストン、マサチューセッツ州: Addison-Wesley. ISBN 978-0-321-18612-6。付録A、165～194ページ
- ^ Larman, Craig (2004)。「第 11 章: 実践のヒント」。アジャイルおよび反復開発: マネージャー向けガイド。Addison-Wesley Professional。p. 253。ISBN 9780131111554. 2013年10月14日閲覧。
- ^ Sliger, Michele; Broderick, Stacia (2008).ソフトウェアプロジェクトマネージャの敏捷性への架け橋. Addison-Wesley. p. 46. ISBN 978-0-321-50275-9。
- ^ ab Boehm, B. ; R. Turner (2004).敏捷性と規律のバランス: 困惑した人のためのガイドボストン、マサチューセッツ州: Addison-Wesley. pp. 55–57. ISBN 978-0-321-18612-6。
- ^ Rakitin, Steven R. (2001). 「Manifesto Elicits Cynicism: Reader's letter to the editor by Steven R. Rakitin」. IEEE Computer . 34 (12): 4. doi :10.1109/MC.2001.10095. S2CID 221106984.
「アジャイル ソフトウェア開発: イノベーションのビジネス」と題された記事は、ソフトウェア エンジニアリングの規律を弱体化させようとするもう 1 つの試みです... 私たちはコーディングにすべての時間を費やしたいと思っています。覚えておいてください、本物のプログラマーはドキュメントを書きません。
- ^ ab Scott Ambler (2023年4月16日). 「アジャイル/リーン ドキュメンテーション: アジャイル ソフトウェア開発の戦略」
- ^ Scott Ambler. 「Just Barely Good Enough Models and Documents: An Agile Best Practice」。2014 年 10 月 8 日時点のオリジナルよりアーカイブ。2014年1 月 24 日閲覧。
- ^ Geoffrey Wiseman (2007 年 7 月 18 日)。「アジャイル手法にはドキュメントが必要ですか?」InfoQ。Cooper, Ian (2007 年 7 月 6 日)の引用。「Staccato Signals:Agile and Documentation」、WordPress.com。
- ^ abc Abrahamson P, Salo O, Ronkainen J, Warsta J (2002). アジャイルソフトウェア開発手法: レビューと分析(PDF) (技術レポート). VTT . 478.
- ^ 「アジャイルプラクティスガイド」。アジャイルアライアンス。2014年2月9日時点のオリジナルよりアーカイブ。
- ^ Pugh, Ken (2011).リーンアジャイル受け入れテスト駆動開発: コラボレーションによるソフトウェアの改善. Addison-Wesley. ISBN 978-0321714084。
- ^ Adzic, Gojko. (2009)コミュニケーションギャップを埋める: 例示による仕様とアジャイル受け入れテスト、Neuri Limited、
- ^ Adzic, Gojko (2011).例による仕様: 成功するチームはどのようにして適切なソフトウェアを提供するのか. Manning. ISBN 978-0-321-27865-4。
- ^ Chelimsky, David、Dave Astels、Zach Dennis、Aslak Hellesøy、Bryan Helmkamp、Dan North。RSpecブック: RSpec、Cucumber、および仲間による動作駆動開発。The Pragmatic Bookshelf。
- ^ 「例に基づく設計」 。2013年4 月 15 日閲覧。
- ^ 「ストーリー テスト駆動開発」(PDF) 。2013 年4 月 15 日閲覧。
- ^ アジャイルモデリング (AM) ホームページ、モデリングとドキュメント作成の効果的な実践
- ^ Atlassian. 「プロダクトバックログ：究極のToDoリスト」. Atlassian . 2021年12月19日閲覧。
- ^ ab 「プロダクトバックログとは何か？」。Scrum.org 。 2021年12月19日閲覧。
- ^ abc 「アジャイルコアプラクティス：優先順位付けされた要件」。agilemodeling.com 。 2021年12月19日閲覧。
- ^ 「Artifact: 作業項目リスト」www.utm.mx . 2021年12月19日閲覧。
- ^ “製品製造 | Digitaliseringsdirectoratet” . 2021 年11 月 15 日に取得。
- ^ クロスファンクショナルチームとは何か？定義と意味
- ^ XFNの略語としての使用
- ^ XFN というリーダーシップ ブログ。
- ^ Krajewski, LJ および LP Ritzman。2005 年。「オペレーション管理: プロセスとバリュー チェーン」。Pearson Education、アッパー サドル リバー。
- ^ ab Aydin, MN; Harmsen, F.; Slooten; Stagwee, RA (2004). 「アジャイル情報システム開発手法の活用」Turk J Elec Engin . 12 (2): 127–138.
- ^ Morris, David (2015).アジャイル変革のパラドックス: アジャイルになろうとしすぎると組織が真にアジャイルになることができなくなる理由ニュージーランド: オークランド大学。doi :10.13140/RG.2.2.32698.08640 。
- ^ Abrahamsson, P., Warsta, J., Siponen, MT, & Ronkainen, J. (2003). アジャイル手法の新しい方向性: 比較分析. ICSE'03 議事録, 244-254
- ^ Mirakhorli, M.; Rad, AK; Shams, F.; Pazoki, M.; Mirakhorli, A. (2008). 「RDP テクニック: XP をカスタマイズする実践」。2008年国際ワークショップ「アジャイル プラクティスの精査」または「アジャイル コラルでのシュートアウト」(APOS '08) の議事録。ACM。pp . 23–32。doi : 10.1145 /1370143.1370149。ISBN 978-1-60558-021-0. S2CID 9528636。
- ^ Schwaber, K (2006) Scrum は難しく、破壊的です。
- ^ Vodde, B (2016) LeSS のストーリー。閉会基調講演。Scrum Australia、メルボルン。2016 年 4 月。
- ^ Lagstedt, A., Dahlberg, T. (2018). ISD 方法選択の希少性を理解する – 限定合理性と機能的愚かさ。PACIS 2018 Proceedings。154。https://aisel.aisnet.org/pacis2018/154。
- ^ Park, JS, McMahon, PE, Myburgh, B. (2016). Scrum Powered by Essence. ACM SIGSOFT ソフトウェアエンジニアリングノート、41(1)、pp. 1–8。
- ^ Beck, K. (1999). 『エクストリームプログラミングの解説：変化を受け入れる』 ボストン、マサチューセッツ州：Addison-Wesley. ISBN 978-0-321-27865-4。
- ^ Evans, Ian. 「British Telecom における Agile Delivery」2011 年2 月 21 日閲覧。
- ^ ab W. Scott Ambler (2006) Supersize Me、Dr. Dobb's Journal、2006年2月15日。
- ^ Schaaf, RJ (2007). Agility XL Systems and Software Technology Conference 2007 2016年3月13日アーカイブ、Wayback Machine、フロリダ州タンパ
- ^ 「Bridging the Distance」 Sdmagazine.com . 2011年2月1日閲覧。
- ^ Fowler, Martin. 「オフショア開発でのアジャイル ソフトウェア プロセスの使用」。Martinfowler.com。2010年6 月 6 日閲覧。
- ^ アジャイルプロセスワークショップ II 複数の同時アジャイルプロジェクトの管理。ワシントン: OOPSLA 2002
- ^ Cawley, Oisín; Wang, Xiaofeng; Richardson, Ita (2010)。「規制環境におけるリーン/アジャイルソフトウェア開発方法論 - 最新技術」。Abrahamsson, Pekka、Oza, Nilay (編)。リーンエンタープライズソフトウェアとシステム。ビジネス情報処理の講義ノート。第 65 巻。pp. 31–36。doi : 10.1007/978-3-642-16416-3_4。hdl :10344 / 683。ISBN 978-3-642-16415-6。
- ^ McHugh, Martin; McCaffery, Fergal; Coady, Garret (2014 年 11 月 4 日)。「医療機器ソフトウェア組織におけるアジャイル実装」。Mitasiunas, Antanas、Rout, Terry、O'Connor, Rory V.、他 (編)。ソフトウェア プロセス改善と能力判定。Communications in Computer and Information Science。第 477 巻。pp. 190–201。doi : 10.1007 /978-3-319-13036-1_17。ISBN 978-3-319-13035-4。
- ^ Wang, Yang; Ramadani, Jasmin; Wagner, Stefan (2017 年 11 月 29 日)。「スクラム開発プロセスをセーフティクリティカルシステムに適用する探索的研究」。製品重視のソフトウェアプロセス改善。コンピュータサイエンスの講義ノート。第 10611 巻。pp. 324–340。arXiv : 1703.05375。Bibcode : 2017arXiv170305375W。doi : 10.1007 /978-3-319-69926-4_23。ISBN 9783319699257.S2CID 4585465 。
- ^ “セーフスクラム - SINTEF”.シンテフNo. 2019 年3 月 26 日に取得。
- ^ Thor Myklebust、Tor Stålhane、Geir Kjetil Hanssen、Tormod Wien、Børge Haugset: スクラム、ドキュメント、および IEC 61508-3:2010 ソフトウェア標準、http://www.sintef.no/globalassets/ec-61508-documentation-and -safescrum-psam12.pdf
- ^ Fitzgerald, B.; Stol, K.-J.; O'Sullivan, R.; O'Brien, D. (2013 年 5 月)。「アジャイル手法の規制環境への拡張: 業界のケース スタディ」。2013年 35 回国際ソフトウェア エンジニアリング会議 (ICSE)。pp. 863–872。doi :10.1109/ICSE.2013.6606635。hdl : 10344 / 3055。ISBN 978-1-4673-3076-3.S2CID 192403 。
- ^ ベック、ケント (2000)。エクストリームプログラミング解説。アディソン・ウェズリー。pp. 1–24。ISBN 978-0201616415。
- ^ Datta, Subhajit (2006). 「アジリティ測定指標: ソフトウェア開発方法論の交差点における指標」ACM-SE 44 Proceedings of the 44th annual Southeast regional conference . p. 271. doi :10.1145/1185448.1185509. ISBN 1595933158。
- ^ Peter Lappo、Henry CT Andrew。「Assessing Agility」（PDF） 。 2009年9月15日時点のオリジナル（PDF）からアーカイブ。 2010年6月6日閲覧。
- ^ Joe Little (2007 年 12 月 2 日)。「Nokia テスト、スクラム固有のテスト」。Agileconsortium.blogspot.com。2010年6 月 6 日閲覧。
- ^ Mark Seuffert、スウェーデン、Mayberg。「Karlskrona テスト、汎用アジャイル採用テスト」。Mayberg.se。2014年4 月 5 日閲覧。
- ^ 「あなたはどれだけアジャイルですか? (この 42 ポイント テストを受けてください)」。allaboutagile.com/。2014 年 5 月 5 日時点のオリジナルよりアーカイブ。2014年4 月 3 日閲覧。
- ^ 「アジャイル手法調査結果」(PDF) 。 Shine Technologies。 2003 年 1 月。 2010 年 8 月 21 日のオリジナル(PDF)からアーカイブ。 2010 年6 月 3 日に取得。
95% が効果なしまたはコスト削減があったと回答... 93% が生産性が向上したか大幅に向上したと回答... 88% が品質が向上したか大幅に向上したと回答... 83% がビジネス満足度が向上したか大幅に向上したと回答
- ^ 「2013 State of Agile report: Why Agile?」 stateofagile.com. 2014年1月27日。2014年8月28日時点のオリジナルよりアーカイブ。2014年8月13日閲覧。
- ^ Status Quo Agile、アジャイル手法の成功と使用形態に関する第 2 次調査。2015 年 7 月 1 日閲覧
- ^ Ambler, Scott (2006 年 8 月 3 日)。「調査結果: アジャイルの実践」。Dr . Dobb's。2010年6 月 3 日閲覧。
生産性が低下したと回答したのはわずか 6% でした... 回答者の 34% は生産性に変化はないと回答し、60% は生産性が向上したと回答しました... 66% は品質が向上したと回答しました... 58% の組織は満足度が向上したと回答しましたが、満足度が低下したと回答したのはわずか 3% でした。
- ^ 「「アジャイル手法が機能するという証拠はどこにあるのか」という質問への回答」 Agilemodeling.com。2007 年 1 月 19 日。2010年4 月 2 日閲覧。
- ^ ショア＆ウォーデン 2008、47ページ
- ^ ベック、ケント (2000)。エクストリームプログラミング解説。アディソン・ウェズリー。pp. 48–49。ISBN 978-0201616415。
- ^ Rouse, Margaret. 「スプリント（ソフトウェア開発）の定義」searchsoftwarequality.techtarget.com . 2015 年10 月 2 日閲覧。
- ^ Goldstein, Ilan (2011 年 10 月 11 日)。「スプリントの問題 - スプリントがクロールに変わるとき」。www.axisagile.com.au。2014年6月 8 日閲覧。
- ^ 「プロジェクトの役割と責任の分配」。agile -only.com。2014年6 月 15 日閲覧。
- ^ Bourne, Lynda. 「プロジェクトスポンサーは実際に何をするのか?」blogs.pmi.org。 2014 年 6 月 7 日時点のオリジナルよりアーカイブ。2014 年6 月 8 日閲覧。
- ^ 「第9回アジャイルの現状レポート」。アジャイル調査の段階。VersionOne。2015年1月12日時点のオリジナルよりアーカイブ。2014年6月8日閲覧。
- ^ Sims, Chris; Johnson, Hillary Louise (2011 年 2 月 15 日)。The Elements of Scrum (Kindle 版)。Dymaxicon。p. 73。
- ^ Rothman, Johanna Rothman (2011 年 8 月 25 日). 「When You Have No Product Owner at All」. www.jrothman.com . 2014 年6 月 8 日閲覧。
- ^ Fox, Alyssa (2014 年 4 月 8 日)。「複数の Agile チームでの作業」techwhirl.com/。2014年6 月 14 日閲覧。
- ^ 「Daily Scrum Meeting」www.mountaingoatsoftware.com . 2014 年6 月 14 日閲覧。
- ^ ab May, Robert. 「効果的なスプリント計画」www.agileexecutives.org。2014 年 6 月 28 日時点のオリジナルよりアーカイブ。2014 年6 月 14 日閲覧。
- ^ Berczuk, Steve. 「Mission Possible: ScrumMaster and Technical Contributor」www.agileconnection.com . 2014 年6 月 14 日閲覧。
- ^ 「アジャイルスクラムの実装方法」 。 2022年1月4日閲覧。
- ^ Namta, Rajneesh. 「アジャイルにおけるテスト自動化に関する考察」www.infoq.com 。2014年6 月 14 日閲覧。
- ^ ab Band, Zvi (2014年3月22日). 「技術的負債 + レッド・オクトーバー」2014年6月8日閲覧。
- ^ Shore, James. 「アジャイル開発の芸術: リファクタリング」www.jamesshore.com 。2014年6 月 14 日閲覧。
- ^ 「ステップ 4: スプリント計画 (タスク)」www.allaboutagile.com。 2014 年 6 月 29 日時点のオリジナルよりアーカイブ。2014 年6 月 14 日閲覧。
- ^ George, Claire (2014 年 3 月 3 日). 「進行中の作業を制限することがなぜ重要なのか」. leankit.com . 2014 年6 月 14 日閲覧。
- ^ 「スプリント計画会議」www.mountaingoatsoftware.com 。 2014 年6 月 14 日閲覧。
- ^ McMillan, Keith (2010 年 5 月 13 日). 「時間、リソース、範囲... および品質」www.adeptechllc.com . 2014 年6 月 15 日閲覧。
- ^ 「アジャイルの限界に関する最新研究」。Procedia Computer Science。78 : 291–297。2016年1月。doi : 10.1016 /j.procs.2016.02.056。
- ^ ab 「アジャイルの調達要請、それは何を意味するのか？」 2019 年 11 月 1 日。
- ^ モラン、アラン (2015)。アジャイルのマネジメント：戦略、実装、組織、人材。シュプリンガー。ISBN 978-3-319-16262-1。
- ^ 「プロジェクトに最適なライフサイクルはどれですか?」PMHut 2008 年 10 月 22 日2009 年10 月 23 日閲覧。
- ^ 「アジャイルプロジェクト管理」。VersionOne 。 2015年6月1日閲覧。
- ^ 「アジャイルマネジメントとは何か?」Project Laneways 。 2015年6月1日閲覧。
- ^ ベンソン、ジム、デ・マリア・バリー、トニアン（2011）。パーソナル・カンバン：仕事のマッピング、人生のナビゲート（第1版）。シアトル、ワシントン州：モダス・クーパーアンド・プレス。p. 38。ISBN 978-1-4538-0226-7。
- ^ USAID. 「ADS Chapter 201 プログラムサイクル運用ポリシー」Wayback Machineで 2019 年 10 月 23 日にアーカイブ。2017 年 4 月 19 日に閲覧
- ^ プロジェクトマネジメント協会、プロジェクトマネジメント知識体系ガイド（PMBOK ガイド）、第 6 版
- ^ リシェ、ジャン＝ルー (2013).アジャイルイノベーション。事例と応用研究、n°31。エセック-ISIS。ISBN 978-2-36456-091-8
- ^ スミス、プレストン G (2007)。柔軟な製品開発。ジョセイ・バス。p. 25。ISBN 978-0-7879-9584-3。
- ^ ニュートン・リー (2014)。「ビルボードチャートに載る：アジャイルソフトウェア開発としての音楽制作」、デジタル・ダ・ヴィンチ：音楽におけるコンピューター.シュプリンガーサイエンス+ビジネスメディア。ISBN 978-1-4939-0535-5。
- ^ モラン、アラン (2015)。アジャイルのマネジメント：戦略、実装、組織、人材。シュプリンガー出版。ISBN 978-3-319-16262-1。
- ^ バレット、M.; グッデル、J. (2022)、「リーンアジャイル開発ツール」、学習エンジニアリングツールキット、ラウトレッジ、pp. 269–278、doi :10.4324/9781003276579-16、ISBN 978-1-003-27657-9
- ^ 「アジャイルプログラミング - 家族向け」。
- ^ Larman, Craig; Bas Vodde (2009 年 8 月 13 日)。大規模なアジャイル導入における組織上の障害トップ 10。InformIT。
- ^ 「ハイブリッド プロジェクト管理入門」。2016 年 7 月 20 日。
- ^ Barlow, Jordan B.; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011). 「大規模組織におけるアジャイル開発の概要とガイダンス」Communications of the Association for Information Systems . 29 (1): 25–44. doi : 10.17705/1CAIS.02902 .
- ^ Kupersmith, Kupe (2011 年 7 月 4 日)。「アジャイルは一時的な流行」。
- ^ ab Kruchten, Philippe (2011 年 6 月 20 日)。「アジャイルの 10 代の危機?」InfoQ。
- ^ リチャード・ウッツ、「行政発言に反対」、クロニクル・オブ・ハイアー・エデュケーション、2020年6月24日。
- ^ コーン、マイク (2015)。アジャイルで成功する。ピアソン。pp. 5–10。ISBN 978-0-321-57936-2。
さらに読む
- Abrahamsson, P.; Salo, O.; Ronkainen, J.; Warsta, J. (2002). 「アジャイルソフトウェア開発手法: レビューと分析」 VTT Publications. 478. 2011年9月7日時点のオリジナルよりアーカイブ。 2012年2月20日閲覧。
- アシュモア、ソンドラ、ルニヤン、クリスティン (2014)。アジャイル手法入門。アディソン・ウェズリー。ISBN 978-0321929563。
- Barlow, Jordan B.; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011)。「大規模組織におけるアジャイル開発の概要とガイダンス」。Communications of the Association for Information Systems。29 ( 1): 25–44。doi : 10.17705/1CAIS.02902。
- Cohen, D.; Lindvall, M.; Costa, P. (2004)。「アジャイル手法入門」。Zelkowitz , Marvin (編)。ソフトウェア エンジニアリングの進歩。コンピュータの進歩。第 62 巻。Academic Press。pp. 1–66。ISBN 978-0-08-047190-7。
- Collier, Ken W. (2011)。アジャイル分析: ビジネスインテリジェンスとデータウェアハウスへの価値主導型アプローチ。ピアソン教育。ISBN 9780321669544
自己組織化チームとは何ですか
? - ディンソイル、トルゲイル;ディボー、トーレ。モー、ニルス・ブレーデ (2010)。アジャイル ソフトウェア開発: 現在の研究と将来の方向性。スプリンガー。ISBN 978-3-642-12575-1。
- ファウラー、マーティン (2001)。「デザインは死んだのか?」。ジャンカルロ・スッチ、ミシェル・マルケシ (編)。エクストリームプログラミングの検証。アディソン・ウェズリー。pp. 3–18。ISBN 978-0-201-71040-3。
- Larman, Craig; Basili, Victor R. (2003 年 6 月)。「反復的および漸進的開発: 簡単な歴史」IEEE Computer . 36 (3): 47–56. doi :10.1109/MC.2003.1204375. S2CID 9240477。
- Casagni, Michelle、Benito, Robert、Mayfield, Kathleen M.、Northern、Carlton (2013 年 9 月 8 日)。「国防総省の情報技術調達における Agile 導入ハンドブック」。The Mitre Corporation。MITRE。
- モラン、アラン（2015）。アジャイルのマネジメント：戦略、実装、組織、人材。シュプリンガー。ISBN 978-3-319-16262-1。
- Riehle, Dirk. 「適応型ソフトウェア開発とエクストリームプログラミングの価値体系の比較: 方法論が互いに学習する方法」スッチ＆マルケージ 2001
- ルビン、ケネス (2013)。エッセンシャル スクラム。最も人気のあるアジャイル プロセスの実践ガイド。Addison-Wesley。ISBN 978-0-13-704329-3。
- ショア、ジェームズ、ウォーデン、シェーン (2008)。アジャイル開発の芸術。オライリーメディア。ISBN 978-0-596-52767-9。
- プロジェクトマネジメント協会 (2021)。プロジェクトマネジメント知識体系ガイド (PMBOK ガイド)。プロジェクトマネジメント協会 (第 7 版)。ニュータウンスクエア、ペンシルバニア州。ISBN 978-1-62825-664-2。
{{cite book}}: CS1 maint: location missing publisher (link) - Stephens, M.; Rosenberg, D. (2003)。エクストリームプログラミングのリファクタリング: XP に反対するケース。Apress。ISBN 978-1-59059-096-6。
- Swamidass, PM 編 (2000)、「ヘビーウェイト プロジェクト組織」、Encyclopedia of Production and Manufacturing Management、ボストン、マサチューセッツ州: Springer US、pp. 261–262、doi :10.1007/1-4020-0612-8_400、ISBN 978-1-4020-0612-8、 2022年6月22日閲覧
- 竹内弘高、野中郁次郎（1986年1月1日）。「新しい新製品開発ゲーム」ハーバード・ビジネス・レビュー。ISSN 0017-8012 。 2021年7 月25日閲覧。
- 「ハイブリッド プロジェクト管理入門」。2016 年 7 月 20 日。
外部リンク
- アジャイル宣言
- Agile Alliance の Agile 用語集
- 新しい方法論 -マーティン・ファウラーによるアジャイル手法の背景の説明
- アジャイルパターン