アジャイルソフトウェア開発

アジャイルソフトウェア開発とは、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. 価値あるソフトウェアを早期かつ継続的に提供することで顧客満足度を高めます。
  2. 開発後期であっても、要件の変更を歓迎します。
  3. 動作するソフトウェアを頻繁に（数か月ではなく数週間）提供します。
  4. ビジネスマンと開発者の間の密接な日常的な協力。
  5. プロジェクトは、信頼できる意欲的な個人を中心に構築されます。
  6. 対面での会話は、コミュニケーション（共存）の最良の形です。
  7. 動作するソフトウェアは進捗状況を測る主な指標です。
  8. 一定のペースを維持できる持続可能な開発。
  9. 技術的卓越性と優れたデザインへの継続的な配慮。
  10. シンプルさ、つまり、やらない仕事の量を最大化する技術が不可欠です。
  11. 最良のアーキテクチャ、要件、設計は、自己組織化されたチームから生まれます。
  12. チームは定期的に、より効果的になる方法を検討し、それに応じて調整します。

概要

反復的、漸進的、進化的

アジャイル開発手法のほとんどでは、製品開発作業を小さな増分単位に分割して、事前の計画と設計の量を最小限に抑えます。イテレーション、またはスプリントは、通常1週間から4週間続く短い期間（タイムボックス）です。 [ 26 ] 。 27 ：20 各イテレーションには、計画、分析、設計、コーディング、単体テスト、受け入れテストなど、すべての機能で作業する部門横断的なチームが関与します。イテレーションの最後には、動作する製品が利害関係者に示されます。これにより、全体的なリスクが最小限に抑えられ、製品は変更にすばやく適応できます。[ 28 ] [ 29 ]イテレーションでは、市場へのリリースを保証するのに十分な機能が追加されない可能性がありますが、目標は各イテレーションの終了時に（バグが最小限の）リリースを提供することです。 [ 30 ]増分開発を通じて、製品は最終リリース日に大幅に失敗する代わりに、各イテレーションフェーズを通して「頻繁に早期に失敗する」余地があります。[ 31 ]製品や新機能のリリースには複数回の反復が必要になる場合があります。実際に動作するソフトウェアが進捗の主要な指標となります。[ 25 ]

効率的で対面的なコミュニケーション

アジャイルソフトウェア開発宣言の第6原則は、「開発チーム内および開発チーム内で情報を伝達する最も効率的かつ効果的な方法は、対面での会話である」と述べています。ビデオ会議がまだ広く普及していなかった2001年に書かれたこの宣言は、情報伝達に関してこれを述べているものであり、必ずしもチームが同じ場所にいなければならないということではありません。

コロケーションの原則は、同じチームの同僚が一緒に位置することで、チームとしてのアイデンティティを確立し、コミュニケーションを改善するというものである。[ 32 ]これにより、理想的にはホワイトボードの前での対面でのやり取りが可能になり、電話、永続的なチャット、ウィキ、または電子メールを介して質疑応答が行われる場合に通常かかるサイクルタイムが短縮される。 [ 33 ] COVID-19パンデミック中のリモートワークの普及とツールの変更により、コロケーションと分散型ワークについての研究がさらに行われ、[ 34 ]コロケーションの重要性はますます低下していることがわかる。

どの開発手法を採用する場合でも、すべてのチームには顧客代表（スクラムではプロダクトオーナーと呼ばれる）が必要です。この代表はステークホルダーの同意を得て、ステークホルダーの代理として行動し、イテレーション全体を通して開発者の質問に答える責任を個人的に負います。各イテレーションの終了時には、プロジェクトのステークホルダーは顧客代表とともに進捗状況をレビューし、優先順位を再評価して投資収益率（ROI）を最適化し、顧客ニーズと企業目標との整合性を確保します。ステークホルダー満足度の重要性は、各フェーズの終了時に頻繁に行われる対話とレビューによって詳細に説明されるため、このアプローチは顧客中心の方法論と呼ばれることがよくあります。[ 35 ]

情報ラジエーター

アジャイルソフトウェア開発において、情報ラジエーターとは（通常は大型の）物理的なディスプレイ、付箋などが貼られたボードであり、開発チームの近くの目立つ場所に設置され、通行人の目につきやすい場所に設置されます。[ 36 ]これは、製品開発状況の最新の概要を表示します。[ 37 ]ビルドライトインジケーターを使用して、チームに製品開発の現在の状況を通知することもできます。

非常に短いフィードバックループと適応サイクル

アジャイルソフトウェア開発における共通の特徴は、デイリースタンドアップ（スクラムフレームワークではデイリースクラムと呼ばれる）である。短いセッション（例：15分）で、チームメンバーは目標達成に向けた進捗状況を集団でレビューし、アプローチの調整が必要かどうかを合意する。合意された時間制限を守るため、チームはしばしばシンプルなコード化された質問（前日に何を完了したか、当日何を達成しようとしているか、進捗を妨げる障害やリスクはあるかなど）を用い、詳細な議論や問題解決はスタンドアップ後に行う。[ 38 ]

品質重視

XPで使用されるアジャイル開発手法であるペアプログラミング

継続的インテグレーション、自動ユニットテスト、ペアプログラミング、テスト駆動開発、デザインパターン、ビヘイビア駆動開発、ドメイン駆動設計、コードリファクタリングなどの特定のツールやテクニックは、品質を向上させ、製品開発の俊敏性を高めるためによく使用されます。[ 39 ]これは、最初から品質を設計して構築し、いつでも、または少なくとも各イテレーションの最後に顧客にソフトウェアをデモンストレーションできることを前提としています。[ 40 ]

哲学

従来のソフトウェアエンジニアリングと比較して、アジャイルソフトウェア開発は主に、動的、非決定論的、非線形的な特性を持つ複雑なシステムや製品開発を対象としています。正確な見積もり、安定した計画、予測は、初期段階では得にくいことが多く、それらに対する信頼性も低い傾向があります。アジャイル実践者は、価値の証拠を得る前に必要な「飛躍的な信頼」を減らすために、自らの自由意志を活用します。 [ 41 ]要件と設計は創発的であると考えられています。このような場合、大規模な事前仕様は多くの無駄を生じさせる可能性があり、経済的に健全ではありません。これらの基本的な議論と、長年の成功と失敗から得られた過去の業界経験は、アジャイル開発が適応型、反復型、進化型開発を好む傾向を形成する上で役立ってきました。[ 42 ]

適応型と予測型

開発手法は、適応型から予測型まで連続体上に存在する。[ 43 ]アジャイルソフトウェア開発手法は、この連続体における適応型側に位置する。適応型開発手法の鍵の一つは、スケジュール計画におけるローリングウェーブアプローチである。これは、マイルストーンを特定しつつも、そこに到達するまでの道筋に柔軟性を残し、マイルストーン自体の変更も許容する。[ 44 ]

適応型手法は、変化する現実に迅速に適応することに重点を置いています。プロジェクトのニーズが変化すると、適応型チームも変化します。適応型チームは、将来何が起こるかを正確に説明することが困難です。日付が遠いほど、適応型手法はその日に何が起こるかについて曖昧になります。適応型チームは、来週に行うタスクを正確に報告することはできず、来月に計画している機能についてのみ報告できます。6ヶ月後のリリースについて尋ねられた場合、適応型チームはリリースのミッションステートメント、または期待される価値とコストの比較表のみを報告できるかもしれません。

対照的に、予測的手法は、将来を詳細に分析・計画し、既知のリスクに対処することに重点を置いています。極端な場合、予測チームは開発プロセス全体を通して計画されている機能とタスクを正確に報告できます。予測的手法は効果的な初期段階の分析に依存しており、これが大きく外れた場合、プロジェクトの方向転換が困難になる可能性があります。予測的チームは、最も価値のある変更のみを検討するために、 変更管理委員会を設置することがよくあります。

リスク分析は、適応型（アジャイルまたは価値主導型）と予測型（計画主導型）の手法を選択するために使用できます。[ 45 ]バリー・ボームとリチャード・ターナーは、連続体のそれぞれの側には、次のように独自のホームグラウンドがあると示唆しています。 [ 46 ]

さまざまな開発手法の拠点
価値主導型手法（アジャイル） 計画主導型手法（ウォーターフォール） 形式手法
重要度が低い 高い臨界性 極度の臨界
シニア開発者 ジュニア開発者(?) シニア開発者
要件は頻繁に変更される 要件は頻繁に変更されない 要件の制限、機能の制限、ヴィルトの法則を参照
開発者の数が少人数 多数の開発者 モデル化できる要件
変化に対応する文化 秩序を求める文化 極めて高い品質

アジャイル vs. ウォーターフォール

アジャイルソフトウェア開発手法とウォーターフォールの違いの一つは、品質とテストへのアプローチです。ウォーターフォールモデルでは、作業はソフトウェア開発ライフサイクル（SDLC）の各フェーズを経て進み、1つのフェーズが完了してから次のフェーズが開始されます。そのため、テストフェーズは独立しており、ビルドフェーズの後に続きます。一方、アジャイルソフトウェア開発では、テストはプログラミングと同じイテレーションで完了します。

テストはソフトウェアの小さな部分を開発するイテレーションごとに行われるため、ユーザーは新しいソフトウェアを頻繁に使用し、その価値を検証できます。更新されたソフトウェアの真の価値をユーザーが理解すれば、ソフトウェアの将来についてより適切な判断を下すことができます。スクラムのイテレーションは通常2週間ですが、各イテレーションで価値の振り返りとソフトウェアの再計画セッションを実施することで、チームは計画を継続的に調整し、提供する価値を最大化することができます。これは、作業が計画され、完了し、確認され（レビューと振り返りで）、合意された変更が実施されるという、計画・実行・確認・改善（PDCA）サイクルに似たパターンに従います。

この反復的なアプローチは、プロジェクトではなく製品というマインドセットをサポートします。これにより、開発プロセス全体を通して柔軟性が向上します。一方、プロジェクトでは要件が最初から定義され、固定化されるため、後から変更することが困難になります。反復的な製品開発により、ビジネス環境や市場要件の変化に応じてソフトウェアを進化させることができます。

コードとドキュメント

IEEE Computerへの手紙の中で、スティーブン・ラキティンはアジャイルソフトウェア開発について「ソフトウェアエンジニアリングの規律を弱体化させようとするもう一つの試み」と冷笑し、「包括的なドキュメントよりも動くソフトウェア」を「私たちはコーディングにすべての時間を費やしたいのです。本当のプログラマーはドキュメントを書かないことを忘れないでください」と訳した。[ 47 ]

これに対し、アジャイルソフトウェア開発の支持者たちは異論を唱えています。彼らは、開発者は関連する目標を達成するためにドキュメントを書くことが最善の方法であるならば書くべきだと主張しますが、静的なドキュメントを書くよりも良い方法があることが多いと主張しています。[ 48 ]スコット・アンブラーは、ドキュメントは「かろうじて十分な程度」（JBGE）であるべきだと述べています。[ 49 ]ドキュメントが多すぎたり、包括的すぎると通常は無駄が生じ、開発者は詳細なドキュメントを信頼することはほとんどなく、それはコードと同期していないことが多いためです。[ 48 ]また、ドキュメントが少なすぎると、メンテナンス、コミュニケーション、学習、知識共有に問題が生じる可能性があります。アリスター・コックバーンはクリスタルクリアメソッド について次のように述べています。

Crystalは開発を一連の協力型ゲームと捉え、次のゲームで勝利するために十分なドキュメントを作成することを目指しています。Crystalの成果物には、ユースケース、リスクリスト、イテレーション計画、コアドメインモデル、そして選択肢に関する情報を提供するための設計ノートなどが含まれます。ただし、これらのドキュメントにはテンプレートがなく、説明は必然的に曖昧になります。しかし、目的は明確で、次のゲームに必要なだけのドキュメントを作成することです。私はいつもチームに、これを「明日チームに加わったら、何を知りたいですか？」と問いかけています。

— アリスター・コックバーン[ 50 ]

方法

ソフトウェア開発ライフサイクルサポート[ 51 ]
アジャイル統合プロセス(AUP) は、統合プロセス(反復的かつ増分的なソフトウェア開発プロセス フレームワーク) に基づいています。

アジャイルソフトウェア開発手法は、ソフトウェア開発ライフサイクルの幅広い範囲をサポートします。[ 51 ]手法の中には、プラクティスに重点を置くもの（例：XP、プラグマティックプログラミング、アジャイルモデリング）もあれば、作業フローの管理に重点を置くもの（例：スクラム、カンバン）もあります。要件仕様と開発活動をサポートするもの（例：FDD）もあれば、開発ライフサイクル全体をカバーしようとするもの（例：DSDM、RUP）もあります。

注目すべきアジャイル ソフトウェア開発フレームワークには次のようなものがあります。

フレームワーク 主な貢献者
適応型ソフトウェア開発（ASD）ジム・ハイスミス、サム・ベイヤー
アジャイルモデリングスコット・アンブラー、ロバート・セシル・マーティン
アジャイル統合プロセス（AUP）スコット・アンブラー
規律あるアジャイルデリバリースコット・アンブラー
動的システム開発手法（DSDM）ジェニファー・ステイプルトン
エクストリームプログラミング（XP）ケント・ベック、ロバート・セシル・マーティン
機能駆動開発（FDD）ジェフ・デ・ルカ
リーンソフトウェア開発メアリー・ポッペンディーク、トム・ポッペンディーク
リーンスタートアップエリック・リース
カンバン大野耐一
迅速なアプリケーション開発(RAD)ジェームズ・マーティン
スクラムケン・シュワバー、ジェフ・サザーランド
スクラムバン

アジャイルソフトウェア開発の実践

アジャイルソフトウェア開発は、要件定義、設計、モデリング、コーディング、テスト、計画、リスク管理、プロセス、品質などの分野をカバーする多くの具体的なプラクティスによってサポートされています。注目すべきアジャイルソフトウェア開発プラクティスには以下が含まれます。[ 52 ]

練習する 主な貢献者
受け入れテスト駆動開発（ATDD）ケン・ピュー
アジャイルモデリングスコット・アンブラー
アジャイルテストリサ・クリスピン、ジャネット・グレゴリー
バックログ（製品とスプリント）ケン・シュワバー、ジェフ・サザーランド
行動駆動開発（BDD）ダン・ノース、リズ・キーオ
継続的インテグレーション（CI）グレイディ・ブーチ
クロスファンクショナルチーム
デイリースタンドアップ / デイリースクラムジェームズ・O・コプリエン
ドメイン駆動設計（DDD）エリック・エヴァンス
反復的かつ漸進的な開発（IID）
ペアプログラミングケント・ベック
プランニングポーカージェームズ・グレニング、マイク・コーン
リファクタリングマーティン・ファウラー
回顧展エスター・ダービー、ダイアナ・ラーセン、ベン・リンダース、ルイス・ゴンサルベス
スクラムイベント（スプリント計画、スプリントレビュー、振り返り）ケン・シュワバー、ジェフ・サザーランド
例による仕様
ストーリー主導型モデリングアルバート・ツンドルフ
テスト駆動開発（TDD）ケント・ベック
タイムボックス
ユーザーストーリーアリスター・コックバーン
速度追跡

受け入れテスト駆動開発

受け入れテスト駆動開発（ATDD）は、ビジネス顧客、開発者、およびテスト担当者間のコミュニケーションに基づいた開発方法論です。 [ 53 ] ATDDには、例による仕様記述（SBE）、[ 54 ] [ 55 ]行動駆動開発（BDD）、 [56 ]例駆動開発（EDD）、[ 57 ]ストーリーテスト駆動開発（SDD）とも呼ばれるサポート駆動開発と同じプラクティスの多くが含まれています。[ 58 ]これらのプロセスはすべて、開発者とテスト担当者が実装前に顧客のニーズを理解するのに役立ち、顧客が独自のドメイン言語で会話できるようにします。

アジャイルモデリング

アジャイルモデリング（AM）は、ベストプラクティスに基づいてソフトウェアシステムをモデリングおよびドキュメント化するための方法論です。これは、（アジャイル）ソフトウェア開発プロジェクトに適用できる価値観と原則の集合です。この方法論は従来のモデリング手法よりも柔軟性が高く、急速に変化する環境に適しています。[ 59 ]これは、アジャイルソフトウェア開発ツールキットの一部です。

アジャイルテスト

アジャイルテストは、アジャイルソフトウェア開発の原則に基づいたソフトウェアテスト手法です。アジャイルテストでは、クロスファンクショナルなアジャイルチームの全メンバーが参加し、テスターに​​よる専門知識を活かして、顧客が求めるビジネス価値を高い頻度で、持続可能なペースで提供することを目指します。望ましい動作と望ましくない動作の例を捉え、コーディングの指針とするために、 例による仕様記述が用いられます。

バックログ

アジャイルプロジェクトマネジメントにおいて、プロダクトバックログとは、製品に含まれるべき機能の優先順位付けされたリストを指します。これはToDoリストと呼ばれることもあり、[ 60 ] 、スクラムソフトウェア開発フレームワークでは「成果物」（ドキュメントの一種）とみなされます。[ 61 ]プロダクトバックログは、スクラムではプロダクトバックログ、[ 61 ] [ 62 ] 、ディシプリンドアジャイルでは作業項目リスト、[ 62 ] [ 63 ] 、リーンではオプションプールなど、プロジェクトマネジメントフレームワークによって呼び名が異なります。[ 62 ]スクラムフレームワークでは、プロダクトバックログの作成と継続的なメンテナンスはプロダクトオーナーの責任の一部です。[ 64 ]

行動駆動開発

動作駆動開発(BDD) では、ドメイン言語を使用してソフトウェア テストに名前を付け、コードの動作を記述します。

継続的インテグレーション

継続的インテグレーション（CI）とは、ソースコードの変更を頻繁に統合し、統合されたコードベースが動作可能な状態であることを保証する手法です。通常、開発者は変更を統合ブランチにマージし、自動化されたシステムがソフトウェアシステムをビルドおよびテストします。[ 65 ] 多くの場合、自動化されたプロセスはコミットごとに実行されるか、1日に1回などのスケジュールに従って実行されます。Grady Boochは1991年に初めてCIという用語を提唱しましたが、[ 66 ]彼は1日に複数回の統合を推奨していませんでした。しかし、後にCIにはその側面も含まれるようになりました。[ 67 ]

クロスファンクショナルチーム

クロスファンクショナルチーム（XFN）は、マルチディスシプリナリーチームまたはインターディスシプリナリーチームとも呼ばれ、共通の目標に向かって働く、異なる機能的専門知識を持つ人々のグループです。[ 68 ]財務、マーケティング、オペレーション、人事部門の人材が含まれる場合があります。通常、組織内のあらゆる階層の従業員が含まれます。また、組織外（特にサプライヤー、主要顧客、コンサルタント）からメンバーが加わることもあります。

毎日のスタンドアップ

スタンドアップミーティング（スタンディングミーティング）とは、参加者が立ったまま参加するミーティングで、通常は午前10時頃に行われます。長時間の立ちっぱなしによる不快感を軽減することで、ミーティングを短時間で終わらせることを目的としています。

方法の調整

文献では、メソッド適応の概念は「メソッドテーラリング」「メソッドフラグメント適応」「状況に応じたメソッドエンジニアリング」など、様々な用語で表現されています。メソッドテーラリングは以下のように定義されています。

コンテキスト、意図、メソッドの断片間の応答的な変化や動的な相互作用を通じて、人間のエージェントが特定のプロジェクト状況に対するシステム開発アプローチを決定するプロセスまたは機能。

— メフメット・ナフィズ・アイディン他「アジャイル情報システム開発手法の活用」[ 69 ]

状況適切性は、アジャイル手法と、より計画主導型のソフトウェア開発手法とを区別する特徴として考えられるべきであり、アジャイル手法では、製品開発チームが個々の製品のニーズに応じて作業慣行を適応させることができます。[ 70 ] [ 69 ]潜在的に、ほとんどのアジャイル手法は、 CMMコンテキストで調整されたDSDMなど、手法の調整に適している可能性があります。[ 51 ] [ 71 ]およびルール記述プラクティス（RDP）テクニックで調整されたXP 。[ 72 ]しかし、すべてのアジャイル支持者が同意するわけではなく、シュワバーは「問題は完璧な方法論を持っていないことだと考えたために、私たちはそもそも困ったことになったのです。努力は、企業内で必要な変更に集中すべきです」と述べています。[ 73 ] Bas Vodde はこの観点を補強し、要素を取捨選択する必要がある従来の大規模な方法論とは異なり、Scrum は基礎を提供し、その上に要素を追加することで、その使用をローカライズおよび文脈化できると示唆しました。[ 74 ]実践者は、システム開発手法、特にアジャイル手法を教科書どおりに使用することはめったになく、社内用の方法を作成するために、手法の一部を省略またはカスタマイズすることを選択することがよくあります。[ 75 ]

実際には、様々なツールを用いて手法をカスタマイズすることができます。統一モデリング言語（UML）などの汎用プロセスモデリング言語は、ソフトウェア開発手法のカスタマイズに使用できます。また、 SEMATのソフトウェア工学のエッセンス理論のような手法エンジニアリング専用のツールも存在します。[ 76 ]

大規模、オフショア、分散型

アジャイルソフトウェア開発は、グリーンフィールドプロジェクトに取り組む専門家の小規模チームなど、特定のタイプの環境に非常に適していると広く考えられてきました。 [ 46 ] [ 77 ]また、レガシーインフラストラクチャを持つ大規模組織でアジャイルソフトウェア開発手法を導入する際に直面する課題と限界は、十分に文書化され、理解されています。[ 78 ]

これに応じて、大規模な開発作業（20人以上の開発者）[ 79 ] [ 80 ]や分散型（同じ場所に配置されていない）開発チーム[ 81 ] [ 82 ]などの課題を克服するためのさまざまな戦略とパターンが進化しており、現在ではこれらの課題を軽減または回避しようとするいくつかの認知されたフレームワークが存在します。

これらすべてが効果的であるか、あるいはアジャイル開発の定義に実際に適合しているかについては多くの相反する見解があり、これは現在も活発に研究が続けられている分野です。[ 79 ] [ 83 ]

アジャイルソフトウェア開発が分散環境（複数の事業拠点にチームが分散している環境）で適用される場合、一般的に分散アジャイルソフトウェア開発と呼ばれます。それぞれのアプローチが持つ独自のメリットを活用することが目標です。分散開発では、組織は戦略的に世界各地にチームを配置し、事実上24時間体制でソフトウェアを構築できます（一般的にはフォロー・ザ・サン・モデルと呼ばれます）。一方、アジャイル開発は透明性の向上、継続的なフィードバック、そして変更への対応における柔軟性の向上をもたらします。

規制対象ドメイン

アジャイルソフトウェア開発手法は当初、重要度の低い製品開発に最適であると考えられていたため、医療機器、製薬、金融、原子力システム、自動車、航空電子工学などの規制対象分野での使用は除外されていました。しかし、ここ数年、これらの分野にアジャイル手法を適用するための取り組みがいくつか行われてきました。[ 84 ] [ 85 ] [ 86 ] [ 87 ] [ 88 ]

規制対象領域に適用される規格は数多くあり、その中にはISO 26262、ISO 9000、ISO 9001、ISO/IEC 15504などがある。規制対象領域においては、特に重要な懸念事項がいくつかある。[ 89 ]

  • 品質保証(QA): 管理された専門的なプロセスと製品の信頼性および正確性を支える体系的かつ固有の品質管理。
  • 安全性とセキュリティ: ユーザーの安全上のリスクを軽減し、意図しない悪意のある誤用からユーザーを安全に保護するための正式な計画とリスク管理。
  • トレーサビリティ: 規制遵守の監査可能な証拠を提供し、トレーサビリティと問題の調査を容易にするドキュメント。
  • 検証と妥当性確認(V&V): ソフトウェア開発プロセス全体に組み込まれます (例: ユーザー要件仕様、機能仕様、設計仕様、コードレビュー、単体テスト、統合テスト、システムテスト)。

経験と採用

アジャイルソフトウェア開発手法は、実際にはあらゆるプログラミングパラダイムや言語で使用できますが、もともとSmalltalk、Lisp、そして後にJava、C#といったオブジェクト指向環境と密接に関連していました。アジャイル手法を最初に採用したのは、通常、前例のないシステムに取り組んでいた小規模から中規模のチームでした。これらのチームは、要件の確定が難しく、開発中に変更される可能性がありました。このセクションでは、組織がアジャイルソフトウェア開発手法を導入する際に直面する一般的な問題と、アジャイルチームの品質とパフォーマンスを測定するための様々な手法について説明します。[ 90 ]

敏捷性の測定

内部評価

アジリティ測定指標は、製品開発の5つの側面（期間、リスク、新規性、労力、相互作用）に基づいて開発を評価する指標です。[ 91 ]測定可能な目標に基づく手法もあります。 [ 92 ]また、ある研究では、速度がアジリティの指標として使用できることが示唆されています。チームがアジャイルソフトウェア開発手法を採用しているかどうかを判断するためのアジャイル自己評価ツールもあります（ノキアテスト、[ 93 ]カールスクルーナテスト、[ 94 ] 42ポイントテスト）。[ 95 ]

公共調査

アジャイルソフトウェア開発手法の使用による品質、生産性、ビジネス満足度の向上を報告した初期の研究の1つは、2002年11月から2003年1月にかけてシャインテクノロジーズが実施した調査である。[ 96 ]

同様の調査である「アジャイルの現状」は、2006年から毎年、ソフトウェア開発コミュニティ全体から数千人の参加者を対象に実施されている。この調査では、アジリティのメリット、得られた教訓、優れた実践方法の認識傾向を追跡している。各調査で、アジャイルソフトウェア開発によってソフトウェアの提供が迅速化され、変化する顧客の優先順位を管理する能力が向上し、生産性が向上すると回答する人が増えていると報告されている。[ 97 ]また、調査では、従来のプロジェクト管理と比較して、アジャイル製品開発手法の方が一貫して優れた結果を示している。[ 98 ] [ 99 ]一方、アジャイル開発手法はまだ初期段階であるため、その成功に関する広範な学術研究を行うには不十分だと感じる人もいるという報告もある。[ 100 ]

アジャイルソフトウェア開発のよくある落とし穴

アジャイルソフトウェア開発を導入する組織やチームは、ウォーターフォール開発などの従来の開発手法から移行する際に、アジャイルプロセスを強制されるなど、しばしば困難に直面します。[ 101 ]これらはしばしばアジャイルアンチパターン、あるいはより一般的にはアジャイル臭と呼ばれます。以下に一般的な例を挙げます。

全体的な製品デザインの欠如

アジャイルソフトウェア開発の目標は、動作するソフトウェアの開発に重点を置き、ドキュメント作成には重点を置かないことです。これは、プロセスが高度に管理され、システムの小さな変更にも関連ドキュメントの大幅な改訂が必要となるウォーターフォールモデルとは対照的です。しかし、これは分析や設計を全く行わないことを正当化するものではありません。設計に注意を払わないと、チームは最初は迅速に作業を進めることができますが、システムの拡張を試みる際に大幅な手直しが必要になる可能性があります。アジャイルソフトウェア開発の重要な特徴の一つは、反復的な開発であることです。適切に実施されれば、アジャイルソフトウェア開発はシステムの開発が進むにつれて設計を浮き彫りにし、チームが共通点や再利用の機会を発見するのに役立ちます。[ 102 ]

進行中のイテレーションにストーリーを追加する

アジャイルソフトウェア開発では、ストーリー（ユースケース記述に類似）は通常、要件定義に使用され、イテレーションとはチームが特定の目標にコミットする短い期間を指します。[ 103 ]進行中のイテレーションにストーリーを追加すると、作業の流れが悪くなります。これらのストーリーはプロダクトバックログに追加し、後続のイテレーションで優先的に使用する必要があります。稀なケースでは、イテレーションをキャンセルすることもできます。[ 104 ]

これは、ストーリーを拡張できないという意味ではありません。チームは新しい情報に対処しなければならず、それによってストーリーに追加のタスクが発生する可能性があります。新しい情報によってイテレーション中にストーリーを完了できない場合は、次のイテレーションに持ち越す必要があります。ただし、新しい情報によってストーリーの元の優先度が変更されている可能性があるため、残りのすべてのストーリーよりも優先させる必要があります。

スポンサーのサポート不足

アジャイルソフトウェア開発は、組織内の草の根的な取り組みとして、ソフトウェア開発チームが開発プロセスの最適化とソフトウェア開発ライフサイクルの一貫性確保を目指す中で導入されることが多い。スポンサーの支援がない場合、チームはビジネスパートナー、他の開発チーム、経営陣からの困難や抵抗に直面する可能性がある。さらに、適切な資金とリソースが不足することで、開発に支障をきたす可能性もある。[ 105 ]これは、失敗の可能性を高める。[ 106 ]

不十分なトレーニング

VersionOneが実施した調査によると、回答者はアジャイル実装の失敗の最大の原因としてトレーニング不足を挙げている[ 107 ]。

プロダクトオーナーの役割が適切に果たされていない

プロダクトオーナーは開発活動においてビジネスを代表する責任があり、最も要求の厳しい役割を担うことが多い。[ 108 ]

よくある間違いは、開発チームの誰かがプロダクトオーナーの役割を担うことです。こうすると、チームはビジネス部門からの実質的なフィードバックなしに、優先順位を独自に決定せざるを得なくなります。彼らはビジネス上の問題を社内で解決しようとしたり、チーム外に指示を求めて作業を遅らせたりします。これはしばしば、集中力の低下や連携の崩壊につながります。[ 109 ]

チームは集中していない

アジャイルソフトウェア開発では、チームは製品へのコミットメントを果たすことが求められます。つまり、チームはその製品の開発作業のみに集中すべきです。しかし、余裕があるように見えるチームメンバーは、他の作業も引き受けることが求められることが多く、チームがコミットした作業の完了に貢献することが困難になります。[ 110 ]

過剰な準備・計画

チームは準備や計画に時間をかけすぎてしまうという罠に陥りがちです。これは、アジャイルソフトウェア開発にあまり馴染みのないチームによくある罠で、チームはすべてのストーリーを完全に理解し、仕様を明確にしなければならないという義務感を感じてしまいます。チームは、自信を持って取り組めるストーリーのみで前進する準備をし、イテレーション期間中は、後続のイテレーションに向けた作業（バックログのリファインメントまたはグルーミングと呼ばれることが多い）を継続的に発見し、準備していく必要があります。

毎日のスタンドアップでの問題解決

デイリースタンドアップは、チームメンバー全員が情報を共有する、集中的かつタイムリーなミーティングであるべきです。問題解決が必要な場合、多くの場合、特定のチームメンバーのみが関与することになり、チーム全体の時間を有効活用できない可能性があります。デイリースタンドアップ中にチームが問題解決に取り組み始めた場合は、通常はスタンドアップ終了後すぐにサブチームが議論できるまで、そのミーティングを一旦保留にしておくべきです。[ 111 ]

タスクの割り当て

アジャイルソフトウェア開発の意図された利点の一つは、問題に最も近いチームに意思決定の権限を与えることです。さらに、意思決定においてよりタイムリーな情報を活用するために、実装に可能な限り近い段階で意思決定を行うべきです。チームメンバーが他者からタスクを割り当てられたり、プロセスの早期段階でタスクが割り当てられたりすると、局所的かつタイムリーな意思決定のメリットが失われる可能性があります。[ 112 ]

仕事が割り当てられると、チームメンバーは特定の役割に制約され（例えば、チームメンバーAは常にデータベース作業を行わなければならない）、クロストレーニングの機会が制限されます。[ 112 ]チームメンバー自身が、能力を伸ばし、クロストレーニングの機会を提供するタスクを引き受けることを選択することができます。

貢献者としてのスクラムマスター

アジャイルの価値観と原則に合致していると主張するスクラムフレームワークにおいて、スクラムマスターの役割は、スクラムプロセスが確実に遵守され、そのプロセスを通してスクラムチームを指導する責任を負います。よくある落とし穴は、スクラムマスターが貢献者として行動することです。スクラムフレームワークでは禁止されていませんが、スクラムマスターはまずスクラムマスターの役割を果たす能力があり、開発タスクには関与しないことを確認する必要があります。スクラムマスターの役割は、製品を作成することではなく、プロセスを促進することです。[ 113 ]

スクラムマスターがマルチタスクをこなすと、コンテキストスイッチが多すぎて生産性が低下する可能性があります。さらに、スクラムマスターはチームが前進できるよう障害を取り除く責任を負っているため、個々のタスクを前進させることで得られる利益が、能力不足のために延期される障害を上回らない可能性があります。[ 114 ]

テスト自動化の欠如

アジャイル開発は反復的な性質を持つため、複数回のテストが必要となることがよくあります。自動テストは、ユニットテスト、統合テスト、回帰テストの繰り返しによる影響を軽減し、開発者とテスターがより価値の高い作業に集中できるようにします。[ 115 ]

テスト自動化は、反復的なソフトウェア開発に必要な継続的なリファクタリングもサポートします。開発者がリファクタリングによってアプリケーションの機能が変更されていないことを確認するためのテストを迅速に実行できるようにすることで、作業負荷を軽減し、クリーンアップ作業によって新たな欠陥が発生していないという確信を高めることができます。

技術的負債を蓄積させる

新機能の提供に重点を置くと、技術的負債が増加する可能性があります。チームは欠陥の修正とリファクタリングのための時間を確保する必要があります。技術的負債は、本番環境の欠陥によってチームの作業が滞り、予定外の作業量を増加させ、計画能力を阻害します。[ 116 ]

システムが進化するにつれて、リファクタリングが重要になります。[ 117 ]時間の経過とともに、継続的なメンテナンスの欠如は欠陥と開発コストの増加を引き起こします。[ 116 ]

反復で多くのことをやろうとする

アジャイルソフトウェア開発では継続的な変更が可能であるというのはよくある誤解ですが、イテレーションバックログとは、イテレーション中に完了できる作業についての合意です。[ 118 ]進行中の作業（WIP）が多すぎると、コンテキストスイッチやキューイングなどの非効率が生じます。[ 119 ]チームは、追加の作業を引き受けるプレッシャーを感じないようにする必要があります。[ 120 ]

固定された時間、リソース、範囲、品質

アジャイルソフトウェア開発では、時間（イテレーション期間）、品質、そして理想的にはリソースを事前に固定します（ただし、開発者が本番環境のインシデント対応のために頻繁にタスクから引き離される場合、固定リソースの維持は困難になる可能性があります）。一方、スコープは変動可能です。顧客やプロダクトオーナーは、イテレーションのスコープを固定することを求めることがよくあります。しかし、チームは、固定された時間、リソース、スコープ（一般にプロジェクトマネジメントのトライアングルとして知られています）にコミットすることには慎重であるべきです。アジャイルソフトウェア開発の固定された時間とリソースにスコープを追加しようとすると、品質の低下につながる可能性があります。[ 121 ]

開発者の燃え尽き症候群

アジャイルプラクティスは集中的なペースと継続的な性質を持つため、デリバリーチームのメンバーが燃え尽きてしまうリスクが高まります。[ 122 ]

アジャイル経営

アジャイルプロジェクト管理は反復的な開発プロセスであり、ユーザーと利害関係者からフィードバックを継続的に収集して、適切なユーザーエクスペリエンスを生み出します。アジャイルプロセスを実行するために、スクラム、エクストリームプログラミング、リーン、カンバンなど、さまざまな方法を使用できます。[ 123 ]アジャイル管理 という用語は、アジャイルソフトウェア開発宣言で述べられている原則に基づいて、非常に柔軟かつインタラクティブな方法で新しい製品やサービスの開発を提供することを目的とした、エンジニアリング、情報技術、およびその他のビジネス分野の設計および構築活動を反復的かつ増分的に管理する方法に適用されます。[ 124 ] アジャイルプロジェクト管理の指標は、混乱を減らし、弱点を特定し、開発サイクル全体を通してチームのパフォーマンスを測定するのに役立ちます。サプライチェーンのアジリティとは、サプライチェーンが供給と需要の不確実性と変動性に対処する能力です。アジャイルサプライチェーンはキャパシティを迅速に増減できるため、急速に変化する顧客の需要に適応できます。最後に、戦略的アジリティとは、環境の変化に応じて組織が行動方針を変える能力です。戦略的敏捷性の鍵は、外部の変化を早期に認識し、変化する環境に適応するためのリソースを割り当てることです。[ 123 ]

Agile X 技法は、エクストリーム プロジェクト管理とも呼ばれます。これは、成果物が段階的に提出される反復ライフサイクル [ 125 ] の変形です。アジャイル開発と反復開発の主な違いは、アジャイル手法では各配信サイクル (反復) で成果物の小さな部分を完了するのに対し、[ 126 ] 反復手法では成果物のセット全体を時間の経過とともに進化させ、プロジェクトの終わり近くに完了することです。反復手法とアジャイル手法はどちらも、より順次的な形式のプロジェクト組織で発生するさまざまな障害への対応として開発されました。たとえば、技術プロジェクトが複雑になるにつれて、エンドユーザーは、プログレッシブなプロトタイプを確認できずに長期的な要件を定義することが困難になる傾向があります。反復で開発されるプロジェクトでは、それらの要件を洗練するためにフィードバックを継続的に収集できます。

アジャイルマネジメントは、チームメンバー間のコミュニケーションと過去の仕事の振り返りを促進するシンプルなフレームワークも提供します。 [ 127 ]従来のウォーターフォール型計画を採用していたチームがアジャイル開発手法を採用した場合、通常は変革フェーズを経て、よりスムーズな変革を導くアジャイルコーチの支援を受けることがよくあります。アジャイルコーチングには、プッシュ型とプル型の2つのスタイルがあります。ここで「プッシュシステム」とは、スクラムなどで典型的な、スプリントに組み込めるタスクを事前に見積もること（プッシュ作業）を指します。一方、「プルシステム」とは、キャパシティに余裕がある場合にのみタスクを実行する環境を指します。[ 128 ]アジャイルマネジメントのアプローチは、ビジネスおよび政府部門にも採用され、適応されてきました。例えば、米国連邦政府では、米国国際開発庁（USAID）が、プログラミングの反復と適応に、コラボレーション、学習、適応（CLA）戦略を取り入れることに重点を置いた、協調型プロジェクトマネジメントアプローチを採用しています。[ 129 ]

アジャイル手法は、『プロジェクトマネジメント知識体系ガイド』（PMBOK ガイド第 6 版）の製品開発ライフサイクルの定義に記載されています。

プロジェクトライフサイクルには、通常、製品、サービス、または成果物の開発に関連する1つ以上のフェーズが含まれます。これらは開発ライフサイクルと呼ばれます。（…）適応型ライフサイクルは、アジャイル、反復型、または増分型です。詳細なスコープは、反復の開始前に定義され、承認されます。適応型ライフサイクルは、アジャイルまたは変更駆動型ライフサイクルとも呼ばれます。[ 130 ]

ソフトウェア開発以外のアプリケーション

アジャイルブラジル2014カンファレンス

ジャン＝ルー・リシェ（ ESSEC戦略イノベーション・サービス研究所研究員）によると、「このアプローチは、ソフトウェア以外の製品やプロジェクト管理全般、特にイノベーションと不確実性の分野において効果的に活用できます。」その結果、現在の顧客ニーズに最も適した製品やプロジェクトが、最小限のコスト、無駄、時間で提供され、企業は従来のアプローチよりも早く収益を上げることができます。[ 131 ]

アジャイルソフトウェア開発手法は、ソフトウェア製品の開発に広く利用されており、その一部はオブジェクト技術など、ソフトウェアの特定の特性を利用している。[ 132 ]しかし、これらの手法は、コンピュータ、医療機器、食品、衣料、音楽など、ソフトウェア以外の製品の開発にも適用できる。[ 133 ]アジャイルソフトウェア開発手法は、開発以外のITインフラストラクチャの導入や移行にも利用されてきた。アジャイルソフトウェア開発のより広範な原則の一部は、ビジネスアジリティやアジャイルビジネスマネジメントという用語で、一般的な経営[ 134 ]（戦略、ガバナンス、リスク、財務など）にも応用されている。アジャイルソフトウェア方法論は、学習工学プロセスにも採用されている。学習工学プロセスは、人間中心設計とデータに基づく意思決定を適用した反復的なデータに基づくプロセスであり、学習者とその発達を支援するために用いられている。[ 135 ]

アジャイルソフトウェア開発パラダイムは、子育てなど、生活の他の分野にも応用できます。子どもの発達における成功は、コミュニケーション、適応、そして気づきといった基本的な管理原則に基づいていると言えるでしょう。TEDトークで、ブルース・フェイラーは、基本的なアジャイルパラダイムを家庭管理と子育てにどのように応用したかを語りました。[ 136 ]

批判

アジャイルプラクティスは、大規模な組織や特定の種類の開発では潜在的に非効率的であると指摘されてきました。[137] 多くの組織は、アジャイルソフトウェア開発方法論は極端すぎると考え、アジャイルソフトウェア開発と計画駆動型アプローチの要素を組み合わせたハイブリッドアプローチを採用しています。[138 ]動的システム開発法（ DSDM ）などの一部の方法は、基本原則を犠牲にすることなく、規律ある方法でこれを試みます 。

アジャイル手法の採用が増えていることは、既存の優れた手法を新しい専門用語で表現しただけの経営上の流行であり、開発戦略に対して画一的な考え方を推進し、結果よりも方法を誤って強調しているとして批判されている。[ 140 ]

アリスター・コックバーンは2011年2月12日、ユタ州スノーバードでアジャイルソフトウェア開発宣言10周年記念式典を開催し、最初の会議から現在に至るまでの30名以上の関係者を集めました。約20の「議論の余地のない」アジャイル関連の話題や問題（ゾウファント・イン・ザ・ルーム、Elephant in the Room：議論の余地のないアジャイル関連のトピックや問題）のリストが集められました。その中には、アジャイルソフトウェア開発の実践における提携、失敗、限界、そして文脈（考えられる原因：商業的利益、文脈からの乖離、失敗に基づいて前進する明確な方法がない、客観的な証拠の不足、認知バイアス、推論の誤り）、政治、文化といった側面が含まれていました。[ 141 ]フィリップ・クルヒテンは次のように書いています。

アジャイル運動は、ある意味ではティーンエイジャーに似ています。非常に自意識過剰で、常に鏡で自分の姿を確認し、批判をほとんど受け入れず、仲間といることにしか関心がなく、過去の知恵をただ過去のものだという理由だけで一括りに拒絶し、流行や新しい専門用語を取り入れ、時に生意気で傲慢です。しかし、アジャイル運動が今後さらに成熟し、外の世界に対してより開かれ、より思慮深くなり、ひいてはより効果的になることに私は疑いの余地がありません。

— フィリップ・クルヒテン[ 141 ]

「マニフェスト」は高等教育の管理とリーダーシップに悪影響を及ぼした可能性がある。管理者に対し、従来の緩慢で審議的なプロセスを、より「機敏な」プロセスに置き換えるべきだと示唆したのだ。この考え方は大学教員の間でほとんど受け入れられなかった。[ 142 ]

もう一つの批判は、アジャイル経営と従来の経営手法が多くの点で相反するものになってしまうという点です。この手法に対するよくある批判は、潜在的なメリットがあるにもかかわらず、その習得と導入に費やす時間はコストがかかりすぎるというものです。従来の経営手法からアジャイル経営への移行には、アジャイルへの完全な服従と、組織全体のメンバーによるプロセスの完遂への確固たるコミットメントが必要です。組織全体で成果にばらつきがあること、従業員が対応しきれないほどの変化が起こっていること、変革完了時の保証がないことなどは、ほんの一例です。[ 143 ]

参照

参考文献

  1. ^ 「アジャイルとは何か？」アジャイルアライアンス、2015年6月29日。 2024年7月16日閲覧。
  2. ^ a b c 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日閲覧。
  3. ^ a bラーマン、クレイグ (2004).アジャイル開発と反復開発：マネージャーのためのガイド. アディソン・ウェズレー. p. 27. ISBN 978-0-13-111155-4。
  4. ^ Rally (2010). 「大文字の「A」のアジャイル vs. 小文字の「a」のアジャイル. 2016年1月5日時点のオリジナルよりアーカイブ。2015年9月9日閲覧。
  5. ^コリアー 2011 .
  6. ^ 「アジャイルソフトウェア開発とは何か？」アジャイルアライアンス、2013年6月8日。 2015年4月4日閲覧。
  7. ^ Dybå, Tore; Dingsøyr, Torgeir (2008年8月1日). 「アジャイルソフトウェア開発の実証研究：体系的レビュー」. Information and Software Technology . 50 ( 9–10 ): 833–859 . doi : 10.1016/j.infsof.2008.01.006 . ISSN 0950-5849 . S2CID 2244031 .  
  8. ^ Lee, Gwanhoo; Xia, Weidong (2010). 「アジャイルに向けて：ソフトウェア開発のアジリティに関する定量的・定性的な現場データの統合分析」MIS Quarterly . 34 (1): 87– 114. doi : 10.2307/20721416 . JSTOR 20721416 . S2CID 26477249 .  
  9. ^ Kroll, J.; Richardson, I.; Prikladnicki, R.; Audy, JL (2018). 「サン指向ソフトウェア開発における実証的証拠：体系的なマッピング研究」 .情報ソフトウェア技術. 93 : 30–44 . doi : 10.1016/j.infsof.2017.08.011 . hdl : 10344/6233 .
  10. ^ジェラルド・M・ワインバーグ、ラーマン＆バシリ（2003年）、47～56ページで引用：「我々は1957年という早い時期から、 IBMサービス・ビューロー・コーポレーションのバーニー・ディムズデールの指揮の下、ロサンゼルスで漸進的開発を行っていました。彼はジョン・フォン・ノイマンの同僚だったので、おそらくそこで学んだか、あるいはごく自然なものとして捉えていたのでしょう。私が覚えている限りでは、ハーブ・ジェイコブス（主にジェイコブスですが、私たち全員が参加していました）がモトローラ向けの大規模シミュレーションを開発していたのを覚えています。そこで使用された手法は、私の知る限り… 私たち全員が、私が覚えている限りでは、大規模プロジェクトにウォーターフォールを適用するのは愚か、あるいは少なくとも現実を無視していると考えていました。ウォーターフォールの説明によって、私たちが何か別のこと、つまり「ソフトウェア開発」以外に名前のつかない何かをやっていることに気付いたのだと思います。」
  11. ^ 「進化型プロジェクトマネジメント（オリジナルページ、外部アーカイブ）」。Gilb。2016年3月27日時点のオリジナルよりアーカイブ。2017年4月30日閲覧。
  12. ^ 「進化型プロジェクトマネジメント（新ページ）」 graphMetrix Gilb 2017年4月30日閲覧。
  13. ^ Edmonds, EA (1974). 「適応型システムとしての非技術者向けソフトウェア開発プロセス」『一般システム』19 : 215–18 .
  14. ^ Gilb, Tom (1981年4月1日). 「進化的開発」. ACM SIGSOFT ソフトウェアエンジニアリングノート. 6 (2): 17. doi : 10.1145/1010865.1010868 . S2CID 33902347 . 
  15. ^ Swamidass, PM編 (2000) 「ヘビーウェイト・プロジェクト組織」『生産・製造マネジメント百科事典』 、ボストン、マサチューセッツ州：Springer US、pp.  261– 262、doi：10.1007/1-4020-0612-8_400、ISBN 978-1-4020-0612-8、 2022年6月22日閲覧
  16. ^マーティン、ジェームズ（1991年）『ラピッドアプリケーション開発』マクミラン社、ISBN 978-0-02-376775-3。
  17. ^カー、ジェームズ・M、ハンター、リチャード（1993年）『RADの真髄：90日以内に完全機能システムを構築する方法』マグロウヒル社、p.3、ISBN 978-0-07-034223-1。
  18. ^アイアコッカ研究所 (1991). 「21世紀の製造業戦略：業界主導の視点」 アイアコッカ研究所、リーハイ大学、ペンシルベニア州ベスレヘム。
  19. ^ Presley, A., J. Mills, D. Liles (1995). 「アジャイル航空宇宙製造」. Nepcon East 1995, ボストン.
  20. ^サンチェス、ルイス（2010年11月）「アジャイル製造システムのレビュー」 International Journal of Production Research（39(16):3561-3600）。
  21. ^アンダーソン、デイビッド (2005). 「相互依存宣言」 . 2018年1月27日時点のオリジナルよりアーカイブ。 2018年10月4日閲覧。
  22. ^ McDonald, Kent (2016年11月1日). 「Agile Allianceの支援を受ける方法」 . Agile Alliance Blog . 2017年7月4日閲覧。
  23. ^ 「アジャイル宣言の検証」 Ambysoft Inc. 2011年4月6日閲覧。
  24. ^ Jim Highsmith (2001). 「歴史：アジャイル宣言」 . agilemanifesto.org.
  25. ^ a b 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 Manifesto の背後にある原則」 Agile Alliance. 2010年6月14日時点のオリジナルよりアーカイブ。 2010年6月6日閲覧。
  26. ^ Project Management Institute 2021、2.3.3開発アプローチ。
  27. ^ルビン 2013 .
  28. ^ Project Management Institute 2021、§3.12 想定される将来の状態を実現するための変更の実現。
  29. ^ Moran, A. (2014).アジャイルリスクマネジメント. Springer Verlag. ISBN 978-3319050072。
  30. ^ Beck, Kent (1999). 「エクストリームプログラミングによる変化の受容」. Computer . 32 (10): 70– 77. Bibcode : 1999Compr..32j..70B . doi : 10.1109/2.796139 .
  31. ^ Mergel, Ines (2016年7月). 「政府におけるアジャイル・イノベーション・マネジメント：研究課題」 .政府情報季刊誌. 33 (3): 516– 523. doi : 10.1016/j.giq.2016.07.004 .
  32. ^ Preuss, Deborah Hartmann (2006年10月13日). 「調査：共同勤務チーム vs. キュービクルファーム」 InfoQ . 2018年10月23日閲覧。
  33. ^ Cockburn, Alistair (2007). 「アジャイルソフトウェア開発：協力ゲーム」 . www.pearson.com (第2版). Addison-Wesley Professional . 2018年10月23日閲覧。
  34. ^ 「マネジメントの変革 | リサーチ」。
  35. ^ 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 .
  36. ^ Project Management Institute 2021、§2.7.3.2 情報ラジエーター。
  37. ^アンブラー、スコット（2002年4月12日）『アジャイルモデリング：エクストリームプログラミングと統合プロセスのための効果的な実践』ジョン・ワイリー・アンド・サンズ、12、164、363頁。ISBN 978-0-471-20282-0。
  38. ^ Vasiliauskas, Vidas (2014). 「アジャイルプロジェクトのタスクとチーム管理の実践の開発」 Eylean. 2014年9月15日時点のオリジナルよりアーカイブ。 2014年9月15日閲覧。
  39. ^ Jeffries, Ron; Anderson, Ann; Hendrickson, Chet (2001). Extreme Programming のインストール. Addison-Weslsy. pp.  72–147 . ISBN 978-0201-70842-4。
  40. ^ Lisa Crispin、Janet Gregory (2009). 『アジャイルテスト：テスターとアジャイルチームのための実践ガイド』 Addison-Wesley.
  41. ^ミッチェル、イアン (2016).アジャイル開発の実践. タマレハウス. p. 11. ISBN 978-1-908552-49-5。
  42. ^ラーマン、クレイグ (2004).アジャイル開発と反復開発：マネージャーのためのガイド. アディソン・ウェズレー. p. 27. ISBN 978-0-13-111155-4。
  43. ^ボーム、B.、R.ターナー（2004年）『アジリティとディシプリンのバランス：困惑した人のためのガイド』ボストン、マサチューセッツ州：アディソン・ウェズリー、ISBN 978-0-321-18612-6。付録A、165～194ページ
  44. ^ラーマン、クレイグ (2004). 「第11章 実践のヒント」 .アジャイル開発と反復開発：マネージャーのためのガイド. アディソン・ウェズリー・プロフェッショナル. 253ページ. ISBN 9780131111554. 2013年10月14日閲覧。
  45. ^スライガー、ミシェル、ブロデリック、ステイシア (2008). 『ソフトウェアプロジェクトマネージャーのアジリティへの架け橋』アディソン・ウェズリー、p. 46. ISBN 978-0-321-50275-9。
  46. ^ a bボーム、B.、R.ターナー（2004年）『アジリティと規律のバランス：困惑した人のためのガイド』ボストン、マサチューセッツ州：アディソン・ウェスレー、pp.  55– 57. ISBN 978-0-321-18612-6。
  47. ^ 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. 「アジャイルソフトウェア開発：イノベーションのビジネス」と題された記事は…ソフトウェアエンジニアリングの分野を弱体化させようとする試みに過ぎません…私たちはコーディングにすべての時間を費やしたいと思っています。真のプログラマーはドキュメントを書かないことを忘れないでください。 
  48. ^ a bスコット・アンブラー (2023年4月16日). 「アジャイル/リーン・ドキュメンテーション：アジャイルソフトウェア開発のための戦略」 .
  49. ^スコット・アンブラー. 「Just Barely Good Enough Models and Documents: An Agile Best Practice」 . 2014年10月8日時点のオリジナルよりアーカイブ。 2014年1月24日閲覧。
  50. ^ Geoffrey Wiseman (2007年7月18日). 「アジャイル手法にはドキュメントが必要か？」 InfoQ.イアン・クーパー（2007年7月6日）「スタッカートシグナル：アジャイルとドキュメンテーション」WordPress.comより引用。
  51. ^ a b c Abrahamson P, Salo O, Ronkainen J, Warsta J (2002).アジャイルソフトウェア開発手法：レビューと分析(PDF) (技術レポート). VTT . 478.
  52. ^ 「アジャイルプラクティスガイド」アジャイルアライアンス。 2014年2月9日時点のオリジナルよりアーカイブ。
  53. ^ Pugh, Ken (2011). 『リーン・アジャイル・アクセプタンス・テスト駆動開発：コラボレーションによるソフトウェア改善』Addison-Wesley. ISBN 978-0321714084。
  54. ^ Adzic, Gojko. (2009)コミュニケーションギャップを埋める: 例示による仕様とアジャイル受け入れテスト、Neuri Limited、
  55. ^ Adzic, Gojko (2011).例による仕様定義：成功するチームはどのようにして適切なソフトウェアを提供するのか. Manning. ISBN 978-0-321-27865-4。
  56. ^ Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North. The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends. The Pragmatic Bookshelf.
  57. ^ 「例に基づく設計」 。 2013年4月15日閲覧。
  58. ^ 「ストーリーテスト駆動開発」(PDF) . 2013年4月15日閲覧。
  59. ^アジャイルモデリング（AM）ホームページ、モデリングとドキュメント作成の効果的な実践
  60. ^ Atlassian. 「プロダクトバックログ：究極のToDoリスト」 . Atlassian . 2021年12月19日閲覧。
  61. ^ a b「プロダクトバックログとは何か？」 Scrum.org . 2021年12月19日閲覧。
  62. ^ a b c「アジャイルコアプラクティス：優先順位付けされた要件」agilemodeling.com . 2021年12月19日閲覧。
  63. ^ 「アーティファクト：作業項目リスト」 . www.utm.mx. 2021年12月19日閲覧。
  64. ^ “製品製造 | Digitaliseringsdirectoratet” . 2020年8月10日のオリジナルからアーカイブ。2021 年11 月 15 日に取得。
  65. ^ Fowler, Martin (2006年5月1日). 「継続的インテグレーション」 . 2014年1月9日閲覧。
  66. ^ブーチ、グレイディ(1991).オブジェクト指向設計：応用編ベンジャミン・カミングス. p. 209. ISBN 9780805300918. 2014年8月18日閲覧。
  67. ^ Beck, K. (1999). 「エクストリームプログラミングで変化を受け入れる」. Computer . 32 (10): 70– 77. doi : 10.1109/2.796139 . ISSN 0018-9162 . 
  68. ^ Krajewski, LJ、L.P. Ritzman. 2005. 『オペレーションズ・マネジメント：プロセスとバリューチェーン』Pearson Education、アッパーサドルリバー。
  69. ^ a b Aydin, MN; Harmsen, F.; Slooten; Stagwee, RA (2004). 「アジャイル情報システム開発手法の活用」. Turk J Elec Engin . 12 (2): 127– 138.
  70. ^ Morris, David (2015).アジャイル変革のパラドックス：アジャイル化に熱心になりすぎると、組織が真のアジャイル化を阻む理由 ニュージーランド：オークランド大学. doi : 10.13140/RG.2.2.32698.08640 .
  71. ^ Abrahamsson, P., Warsta, J., Siponen, MT, & Ronkainen, J. (2003). 「アジャイル手法の新たな方向性：比較分析」 ICSE'03 論文集, 244-254
  72. ^ 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 .
  73. ^ Schwaber, K (2006) Scrum は難しくて破壊的である。
  74. ^ Vodde, B (2016) LeSSのストーリー。閉会基調講演。Scrum Australia、メルボルン。2016年4月。
  75. ^ Lagstedt, A., Dahlberg, T. (2018). ISD法選択の希少性を理解する ― 限定合理性と機能的愚かさ. PACIS 2018 Proceedings. 154. https://aisel.aisnet.org/pacis2018/154 .
  76. ^ Park, JS, McMahon, PE, Myburgh, B. (2016). Scrum Powered by Essence. ACM SIGSOFT ソフトウェアエンジニアリングノート, 41(1), pp. 1–8.
  77. ^ Beck, K. (1999). 『エクストリームプログラミング入門：変化を受け入れる』ボストン、マサチューセッツ州：Addison-Wesley. ISBN 978-0-321-27865-4。
  78. ^イアン・エヴァンス「ブリティッシュ・テレコムにおけるアジャイル・デリバリー」2011年2月21日閲覧。
  79. ^ a b W. Scott Ambler (2006) Supersize Me、 Dr. Dobb's Journal、2006年2月15日。
  80. ^ Schaaf, RJ (2007). Agility XL Systems and Software Technology Conference 2007 Archived 13 March 2016 at the Wayback Machine , Tampa, FL
  81. ^ 「Bridging the Distance」 . Sdmagazine.com . 2011年2月1日閲覧。
  82. ^ Fowler, Martin. 「オフショア開発におけるアジャイルソフトウェアプロセスの活用」 Martinfowler.com . 2010年6月6日閲覧。
  83. ^アジャイルプロセスワークショップII 複数の同時アジャイルプロジェクトの管理。ワシントン：OOPSLA 2002
  84. ^ Cawley, Oisín; Wang, Xiaofeng; Richardson, Ita (2010). 「規制環境におけるリーン/アジャイルソフトウェア開発方法論 ― 現状」. Abrahamsson, Pekka; Oza, Nilay (編). Lean Enterprise Software and Systems . Lecture Notes in Business Information Processing. Vol. 65. pp.  31– 36. doi : 10.1007/978-3-642-16416-3_4 . hdl : 10344/683 . ISBN 978-3-642-16415-6。
  85. ^ 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。
  86. ^ 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 .
  87. ^ "セーフスクラム - SINTEF" .シンテフNo. 2019 年3 月 26 日に取得。
  88. ^ 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、2022 年 6 月 27 日にアーカイブウェイバックマシン
  89. ^ 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 .
  90. ^ベック、ケント (2000). 『エクストリームプログラミング入門』 . アディソン・ウェズレー. pp.  1–24 . ISBN 978-0201616415。
  91. ^ Datta, Subhajit (2006). 「アジリティ測定指標：ソフトウェア開発方法論の岐路における指標」ACM-SE 44 Proceedings of the 44th annual Southeast regional conference . p. 271. doi : 10.1145/1185448.1185509 . ISBN 1595933158。
  92. ^ Peter Lappo; Henry CT Andrew. 「Assessing Agility」（PDF） . 2009年9月15日時点のオリジナル（PDF）からアーカイブ。 2010年6月6日閲覧。
  93. ^ Joe Little (2007年12月2日). 「Nokiaテスト：スクラム特有のテスト」 . Agileconsortium.blogspot.com . 2010年6月6日閲覧。
  94. ^ Mark Seuffert、スウェーデン、マイベリ。「Karlskronaテスト：汎用的なアジャイル採用テスト」 Mayberg.se 。 2014年4月5日閲覧。
  95. ^ 「あなたはどれくらいアジャイルですか？（この42ポイントのテストを受けてください）」 allaboutagile.com/。2014年5月5日時点のオリジナルよりアーカイブ。 2014年4月3日閲覧。
  96. ^ 「アジャイル手法調査結果」（PDF）。シャイン・テクノロジーズ。2003年1月。2010年8月21日時点のオリジナル（PDF）からアーカイブ。 2010年6月3日閲覧。95 %が効果なし、またはコスト削減があったと回答。93%が生産性が向上した、または大幅に向上したと回答。88%が品質が向上した、または大幅に向上したと回答。83%がビジネス満足度が向上した、または大幅に向上したと回答。
  97. ^ 「2013 State of Agile report: Why Agile?」 stateofagile.com. 2014年1月27日. 2014年8月28日時点のオリジナルよりアーカイブ。2014年8月13日閲覧。
  98. ^ Status Quo Agile Archived 18 March 2018 at the Wayback Machine , アジャイル手法の成功と利用形態に関する第2回調査。2015年7月1日閲覧。
  99. ^ Ambler, Scott (2006年8月3日). 「調査結果：アジャイルの実践」 . Dr. Dobb's . 2010年6月3日閲覧.生産性が低下したと回答した企業はわずか6%でした…回答者の34%は生産性に変化はないと回答し、60%は生産性が向上したと回答しました…66%は品質が向上したと回答しました…58%の組織は満足度が向上したと回答しましたが、満足度が低下したと回答したのはわずか3%でした。
  100. ^ 「「アジャイル手法が機能するという証拠はどこにあるのか」という疑問への回答」 Agilemodeling.com、2007年1月19日。 2010年4月2日閲覧。
  101. ^ショア＆ウォーデン 2008、47ページ
  102. ^ベック、ケント (2000). 『エクストリームプログラミング入門』 . アディソン・ウェズレー. pp.  48–49 . ISBN 978-0201616415。
  103. ^ Rouse, Margaret. 「スプリント（ソフトウェア開発）の定義」 searchsoftwarequality.techtarget.com . 2015年10月2日閲覧。
  104. ^ Goldstein, Ilan (2011年10月11日). 「スプリントの問題 – スプリントが遅々として進まなくなるとき」 . www.axisagile.com.au . 2014年6月8日閲覧。
  105. ^ 「プロジェクトの役割と責任の分配」agile-only.com . 2014年6月15日閲覧。
  106. ^ Bourne, Lynda. 「プロジェクトスポンサーは実際に何をするのか？」 blogs.pmi.org . 2014年6月7日時点のオリジナルよりアーカイブ。 2014年6月8日閲覧。
  107. ^ 「第9回アジャイルの現状レポート」。アジャイルの段階に関する調査。VersionOne。2015年1月12日時点のオリジナルよりアーカイブ。 2014年6月8日閲覧。
  108. ^ Sims, Chris; Johnson, Hillary Louise (2011年2月15日). 『スクラムの要素』（Kindle版）. Dymaxicon. p. 73.
  109. ^ Rothman, Johanna Rothman (2011年8月25日). 「プロダクトオーナーがいないとき」 . www.jrothman.com . 2014年6月8日閲覧。
  110. ^ Fox, Alyssa (2014年4月8日). 「複数のアジャイルチームでの作業」 . techwhirl.com/ . 2014年6月14日閲覧。
  111. ^ 「Daily Scrum Meeting」 . www.mountaingoatsoftware.com . 2014年6月14日閲覧。
  112. ^ a b May, Robert. 「効果的なスプリント計画」 www.agileexecutives.org . 2014年6月28日時点のオリジナルよりアーカイブ。 2014年6月14日閲覧。
  113. ^ Berczuk, Steve. 「Mission Possible: ScrumMaster and Technical Contributor」 www.agileconnection.com . 2014年6月14日閲覧。
  114. ^ 「アジャイルスクラムの実装方法」 。 2022年1月4日閲覧。
  115. ^ Namta, Rajneesh. 「アジャイルにおけるテスト自動化に関する考察」www.infoq.com。2014年8月18日時点のオリジナルよりアーカイブ。 2014年6月14日閲覧。
  116. ^ a b Band, Zvi (2014年3月22日). 「技術的負債 + レッド・オクトーバー」 . Zvi Band . 2014年7月14日時点のオリジナルよりアーカイブ。 2014年6月8日閲覧。
  117. ^ Shore, James. 「アジャイル開発の芸術：リファクタリング」 www.jamesshore.com . 2014年6月14日閲覧。
  118. ^ 「ステップ4：スプリント計画（タスク）」www.allaboutagile.com。2014年6月29日時点のオリジナルよりアーカイブ。 2014年6月14日閲覧。
  119. ^ George, Claire (2014年3月3日). 「進行中の作業を制限することがなぜ重要なのか」 leankit.com . 2014年6月14日閲覧。
  120. ^ 「スプリント計画会議」www.mountaingoatsoftware.com . 2014年6月14日閲覧。
  121. ^ McMillan, Keith (2010年5月13日). 「時間、リソース、範囲…そして品質」 . www.adeptechllc.com . 2014年6月15日閲覧。
  122. ^ 「アジャイルの限界に関する最新の研究」 . Procedia Computer Science . 78 : 291–297 . 2016年1月. doi : 10.1016/j.procs.2016.02.056 .
  123. ^ a b「アジャイルの調達要請とはどういう意味か？」 2019年11月1日。
  124. ^モラン、アラン (2015).アジャイルのマネジメント：戦略、実装、組織、そして人材. シュプリンガー. ISBN 978-3-319-16262-1。
  125. ^ 「プロジェクトに最適なライフサイクルはどれか？」PMHut、2008年10月22日。 2009年10月23日閲覧。
  126. ^ 「アジャイルプロジェクトマネジメント」VersionOne . 2015年6月9日時点のオリジナルよりアーカイブ。 2015年6月1日閲覧。
  127. ^ 「アジャイルマネジメントとは何か？」 Project Laneways. 2015年6月2日時点のオリジナルよりアーカイブ。 2015年6月1日閲覧。
  128. ^ベンソン、ジム、デ・マリア・バリー、トニアンヌ (2011). 『パーソナル・カンバン：仕事のマッピング、人生のナビゲーション』（第1版）シアトル、ワシントン州: モダス・クーパーランディ・プレス、38ページ。ISBN 978-1-4538-0226-7。
  129. ^ USAID.「ADS Chapter 201 プログラムサイクル運用方針」Wayback Machineで2019年10月23日にアーカイブ。2017年4月19日閲覧。
  130. ^プロジェクトマネジメント協会、「プロジェクトマネジメント知識体系ガイド（PMBOKガイド）」第6版
  131. ^リシェ、ジャン＝ルー (2013).アジャイルイノベーション。事例と応用研究、n°31。エセック-ISIS。 ISBN 978-2-36456-091-8
  132. ^スミス、プレストン G (2007).柔軟な製品開発. ジョセイ・バス. p. 25. ISBN 978-0-7879-9584-3。
  133. ^ニュートン・リー (2014). 「ビルボードチャートに載る：アジャイルソフトウェア開発としての音楽制作」『デジタル・ダ・ヴィンチ：音楽におけるコンピューター』. シュプリンガー・サイエンス+ビジネス・メディア. ISBN 978-1-4939-0535-5。
  134. ^モラン、アラン (2015).アジャイルのマネジメント：戦略、実装、組織、そして人材. Springer Verlag. ISBN 978-3-319-16262-1。
  135. ^バレット、M.; グッデル、J. (2022)、「リーンアジャイル開発ツール」、学習工学ツールキット、ラウトレッジ、pp.  269– 278、doi : 10.4324/9781003276579-16、ISBN 978-1-003-27657-9
  136. ^「アジャイルプログラミング - 家族のために」。
  137. ^ Larman, Craig; Bas Vodde (2009年8月13日).大規模アジャイル導入における組織的阻害要因トップ10. InformIT.
  138. ^ 「ハイブリッドプロジェクト管理入門」。Collaboration Corner 。2016年7月20日。 2020年1月7日時点のオリジナルよりアーカイブ。 2018年1月16日閲覧。
  139. ^バーロウ、ジョーダン・B、ジャスティン・スコット・ギボニー、マーク・ジェフリー・キース、デビッド・W・ウィルソン、ライアン・M・シュッツラー、ポール・ベンジャミン・ローリー、アンソニー・ヴァンス (2011). 「大規模組織におけるアジャイル開発の概要とガイダンス」 . Communications of the Association for Information Systems . 29 (1): 25– 44. doi : 10.17705/1CAIS.02902 .
  140. ^ Kupersmith, Kupe (2011年7月4日). 「アジャイルは一時的な流行」 .
  141. ^ a b Kruchten, Philippe (2011年6月20日). 「アジャイルの10代の危機？」 InfoQ.
  142. ^リチャード・ウッツ、「Adminspeakに反対」、 Chronicle of Higher Education、2020年6月24日。
  143. ^コーン、マイク（2015年）『アジャイルで成功する』ピアソン、  5～ 10頁、ISBN 978-0-321-57936-2。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Agile_software_development&oldid=1330905812#The_Manifesto_for_Agile_Software_Development」より取得