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年に登場したスクラム、1996年に登場したクリスタルクリアとエクストリームプログラミング（XP）、 1997年に登場したフィーチャ駆動開発（FDD）などがあります。これらはすべてアジャイルマニフェストの発表以前に生まれたものですが、現在ではまとめてアジャイルソフトウェア開発手法と呼ばれています。[ 3 ]
1991年以来、リーンマネジメントから派生した製造業[ 18 ] [ 19 ]や経営思想[ 20 ]において、同様の変化がすでに進行していた。
2001年、17人のソフトウェア開発者がユタ州スノーバードのリゾートに集まり、軽量な開発手法について議論した。彼らは、ケント・ベック（エクストリームプログラミング）、ワード・カニンガム（エクストリームプログラミング）、デイブ・トーマス（プラグマティックプログラミング、Ruby）、ジェフ・サザーランド（スクラム）、ケン・シュワバー（スクラム）、ジム・ハイスミス（アダプティブソフトウェア開発）、アリスター・コックバーン（Crystal）、ロバート・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 ]これにより、理想的にはホワイトボードの前で対面でのやり取りが可能になり、電話、常時チャット、Wiki、または電子メールを介して質問と回答を仲介する場合に通常かかるサイクルタイムが短縮されます。[ 33 ] COVID-19パンデミック中のリモートワークの普及とツールの変更に伴い、共同配置と分散ワークに関するより多くの研究が行われており[ 34 ]、共同配置の重要性がますます低下していることを示しています。
どの開発手法を採用する場合でも、すべてのチームには顧客代表（スクラムではプロダクトオーナーと呼ばれる）を含める必要があります。この代表者は、ステークホルダーの代理として行動することに合意し、イテレーション全体を通して開発者からの質問に答えるためにいつでも対応できるという個人的な約束をします。各イテレーションの終わりに、プロジェクトのステークホルダーは顧客代表とともに進捗状況を確認し、投資収益率（ROI）を最適化し、顧客のニーズと会社の目標との整合性を確保するために優先順位を再評価します。各フェーズの終わりに頻繁なやり取りとレビューによって詳細に説明されるステークホルダーの満足度の重要性から、このアプローチはしばしば顧客中心の方法論と呼ばれます。[ 35 ]
アジャイルソフトウェア開発では、情報ラジエーターは、開発チームの近くに目立つように設置され、通行人が見ることができる、（通常は大型の）物理的なディスプレイ、付箋紙などのボードです。 [ 36 ]これは、製品開発状況の最新の概要を示します。[ 37 ]また、ビルドライトインジケーターを使用して、チームに製品開発の現在の状況を知らせることもできます。
アジャイルソフトウェア開発の共通の特徴は、デイリースタンドアップ（スクラムフレームワークではデイリースクラムと呼ばれる）です。短いセッション（例えば15分）で、チームメンバーは目標に向かってどのように進んでいるかを共同で確認し、アプローチを調整する必要があるかどうかについて合意します。合意された時間制限を守るために、チームはよく簡単なコード化された質問（前日に完了したこと、その日に完了しようとしていること、進捗を妨げる障害やリスクがあるかどうかなど）を使用し、詳細な議論や問題解決はスタンドアップの後まで延期します。[ 38 ]
継続的インテグレーション、自動単体テスト、ペアプログラミング、テスト駆動開発、デザインパターン、ビヘイビア駆動開発、ドメイン駆動設計、コードリファクタリングなどの特定のツールやテクニックは、品質を向上させ、製品開発の俊敏性を高めるためによく使用されます。[ 39 ]これは、最初から品質を設計および構築し、いつでも、または少なくとも各イテレーションの最後に顧客にソフトウェアをデモンストレーションできることを前提としています。[ 40 ]
従来のソフトウェアエンジニアリングと比較して、アジャイルソフトウェア開発は主に動的、非決定論的、非線形特性を持つ複雑なシステムと製品開発を対象としています。初期段階では正確な見積もり、安定した計画、予測を得ることは困難であることが多く、それらに対する信頼度は低い傾向があります。アジャイルの実践者は、価値の証拠が得られる前に必要となる「飛躍的な信頼」を減らすために、自由意志を使用します。 [ 41 ]要件と設計は創発的であると考えられています。このような場合、大規模な事前仕様は多くの無駄を生む可能性が高く、つまり経済的に健全ではありません。これらの基本的な議論と、長年の成功と失敗から学んだ過去の業界経験は、適応的、反復的、進化的開発を支持するアジャイル開発の形成に役立っています。[ 42 ]
開発手法は、適応型から予測型まで連続的に存在します。[ 43 ]アジャイルソフトウェア開発手法は、この連続体の適応型側に位置します。適応型開発手法の重要な要素の1つは、スケジュール計画に対するローリングウェーブアプローチです。これは、マイルストーンを特定しますが、それらに到達するまでの経路に柔軟性を持たせ、マイルストーン自体も変更できるようにします。[ 44 ]
適応型手法は、変化する現実に迅速に適応することに重点を置いています。プロジェクトのニーズが変われば、適応型チームも変化します。適応型チームは、将来何が起こるかを正確に説明するのが困難です。日付が遠ければ遠いほど、適応型手法ではその日に何が起こるかについて曖昧になります。適応型チームは、来週行うタスクを正確に報告することはできず、来月に計画している機能しか報告できません。6か月後のリリースについて尋ねられた場合、適応型チームはリリースのミッションステートメント、または期待値とコストに関するステートメントしか報告できないかもしれません。
一方、予測型手法は、将来を詳細に分析・計画し、既知のリスクに対応することに重点を置いています。極端な場合、予測型チームは開発プロセス全体を通して計画されている機能やタスクを正確に報告することができます。予測型手法は効果的な初期段階の分析に依存しており、この分析がうまくいかないと、プロジェクトの方向転換が困難になる可能性があります。予測型チームは、最も価値のある変更のみを検討するために、変更管理委員会を設置することがよくあります。
リスク分析は、適応型（アジャイルまたは価値主導型）手法と予測型（計画主導型）手法のどちらを選択するかを決定するために使用できます。[ 45 ]バリー・ボームとリチャード・ターナーは、連続体の両側にそれぞれ独自のホームグラウンドがあると示唆しています。以下はその通りです。[ 46 ]
アジャイルソフトウェア開発手法とウォーターフォール開発手法の大きな違いの一つは、品質とテストへのアプローチです。ウォーターフォールモデルでは、ソフトウェア開発ライフサイクル（SDLC）の各フェーズを経て作業が進められ、前のフェーズが完了してから次のフェーズが開始されます。そのため、テストフェーズはビルドフェーズとは別個のものとして扱われ、ビルドフェーズの後に実施されます。一方、アジャイルソフトウェア開発では、テストはプログラミングと同じイテレーション内で実施されます。
テストはソフトウェアの小さな部分を開発する各イテレーションで行われるため、ユーザーは新しいソフトウェアを頻繁に使用してその価値を検証できます。更新されたソフトウェアの真の価値をユーザーが理解した後、ソフトウェアの将来についてより良い意思決定を行うことができます。各イテレーション（スクラムでは通常2週間）で価値の振り返りとソフトウェアの再計画セッションを行うことで、チームは提供する価値を最大化するために計画を継続的に調整することができます。これは、作業が計画され、実行され、（レビューと振り返りで）チェックされ、合意された変更が実行されるという、PDCAサイクルに似たパターンに従います。
この反復的なアプローチは、プロジェクト思考ではなく製品思考をサポートします。これにより、開発プロセス全体を通して柔軟性が向上します。一方、プロジェクトでは要件が最初から定義され固定されるため、後から変更することが困難になります。反復的な製品開発により、ソフトウェアはビジネス環境や市場ニーズの変化に応じて進化することができます。
IEEE Computerへの手紙の中で、Steven Rakitin はアジャイルソフトウェア開発について懐疑的な見方を示し、「ソフトウェアエンジニアリングの規律を弱体化させようとするまた別の試み」と呼び、「包括的なドキュメントよりも動作するソフトウェア」を「私たちはすべての時間をコーディングに費やしたい。覚えておいてほしいのは、真のプログラマーはドキュメントを書かないということだ」と解釈した。[ 47 ]
アジャイルソフトウェア開発の支持者はこれに異議を唱え、関連する目標を達成する最善の方法であれば開発者はドキュメントを作成すべきだが、静的なドキュメントを作成するよりも、それらの目標を達成するためのより良い方法がある場合が多いと述べている。[ 48 ]スコット・アンブラーは、ドキュメントは「かろうじて十分な程度」であるべきだと述べている（JBGE）[ 49 ]。ドキュメントが多すぎたり包括的すぎたりすると通常は無駄が生じ、開発者は詳細なドキュメントを信頼することはめったにない。なぜなら、ドキュメントは通常コードと同期していないからである[ 48 ]。一方、ドキュメントが少なすぎると、保守、コミュニケーション、学習、知識共有に問題が生じる可能性がある。アリスター・コックバーンは、クリスタルクリアメソッドについて次のように書いている。
Crystalは開発を協力型ゲームの連続と捉え、ドキュメントは次のゲームで勝利するのに役立つだけのものであるべきだと考えています。Crystalの成果物には、ユースケース、リスクリスト、イテレーションプラン、コアドメインモデル、設計上の選択を参考とする設計ノートなどが含まれます。ただし、これらのドキュメントにはテンプレートはなく、説明は必然的に曖昧ですが、目的は明確で、次のゲームに必要なだけのドキュメントを作成することです。私はいつもチームメンバーにこう説明しています。「もしあなたが明日チームに加わるとしたら、何を知りたいですか？」
—アリスター・コックバーン[ 50 ]
アジャイルソフトウェア開発手法は、ソフトウェア開発ライフサイクルの幅広い範囲をサポートします。[ 51 ]一部の手法はプラクティスに焦点を当てており（例：XP、プラグマティックプログラミング、アジャイルモデリング）、一部は作業の流れの管理に焦点を当てています（例：スクラム、カンバン）。要件仕様と開発の活動をサポートするものもあれば（例：FDD）、開発ライフサイクル全体をカバーしようとするものもあります（例：DSDM、RUP）。
注目すべきアジャイルソフトウェア開発フレームワークには以下のようなものがある。
アジャイルソフトウェア開発は、要件、設計、モデリング、コーディング、テスト、計画、リスク管理、プロセス、品質などの分野を網羅する多くの具体的なプラクティスによって支えられています。注目すべきアジャイルソフトウェア開発プラクティスには、次のものがあります。[ 52 ]
アジャイルモデリング（AM）は、ベストプラクティスに基づいてソフトウェアシステムをモデリングおよび文書化するための方法論です。これは、（アジャイル）ソフトウェア開発プロジェクトに適用できる価値観と原則の集合体です。この方法論は、従来のモデリング方法よりも柔軟性が高く、変化の速い環境により適しています。[ 59 ]これは、アジャイルソフトウェア開発ツールキットの一部です。
アジャイルテストは、アジャイルソフトウェア開発の原則に基づいたソフトウェアテスト手法です。アジャイルテストでは、クロスファンクショナルなアジャイルチームの全メンバーが参加し、テスターの専門知識を活かして、顧客が求めるビジネス価値を持続可能なペースで頻繁に提供することを目指します。仕様記述は、望ましい動作と望ましくない動作の例を収集し、コーディングをガイドするために、例を用いて行われます。
アジャイルプロジェクト管理において、プロダクトバックログとは、製品に含めるべき機能の優先順位付けされたリストを指します。これは、ToDoリストと呼ばれることもあり、[ 60 ]スクラムソフトウェア開発フレームワークでは「アーティファクト」（ドキュメントの一種）とみなされます。[ 61 ]プロダクトバックログは、プロジェクト管理フレームワークによって異なる名称で呼ばれます。例えば、スクラムではプロダクトバックログ、[ 61 ] [ 62 ]ディシプリンドアジャイルではワークアイテムリスト、[ 62 ] [ 63 ]リーンではオプションプールなどです。[ 62 ]スクラムフレームワークでは、プロダクトバックログの作成と継続的なメンテナンスは、プロダクトオーナーの責任の一部です。[ 64 ]
文献では、メソッド適応の概念を表す用語として、「メソッドテーラリング」、「メソッドフラグメント適応」、「状況に応じたメソッドエンジニアリング」など、さまざまな用語が用いられている。メソッドテーラリングは次のように定義される。
人間主体が、状況、意図、および方法の断片間の動的な相互作用とそれに応じた変化を通じて、特定のプロジェクト状況に対するシステム開発アプローチを決定するプロセスまたは能力。
— Mehmet Nafiz Aydin 他、「アジャイル情報システム開発手法の活用」[ 71 ]
状況への適合性は、アジャイル手法とより計画主導型のソフトウェア開発手法を区別する特徴として考慮されるべきであり、アジャイル手法では、製品開発チームが個々の製品のニーズに応じて作業方法を適応させることができる。[ 72 ] [ 71 ]潜在的に、ほとんどのアジャイル手法は、CMM のコンテキストに合わせて調整されたDSDM [ 73 ]や、ルール記述プラクティス(RDP) テクニックに合わせて調整されたXP [ 74 ]など、メソッドのカスタマイズに適している可能性がある。しかし、すべてのアジャイル支持者が同意しているわけではなく、シュワバーは「そもそも、完璧な方法論がないことが問題だと考えていたことが、問題の原因だった。努力は、企業で必要な変更に焦点を当てるべきだ」と述べている。[ 75 ]バス・ヴォッデはこの見解を裏付け、要素を選び取る必要がある従来の大規模な手法とは異なり、スクラムは基本を提供し、その上に要素を追加して使用をローカライズし、文脈に合わせることができると述べている。[ 76 ]実務者はシステム開発手法、特にアジャイル手法を教科書通りに使うことはほとんどなく、社内手法を作成するために、手法の実践の一部を省略したり、カスタマイズしたりすることが多い。[ 77 ]
実際には、さまざまなツールを使用してメソッドをカスタマイズできます。統一モデリング言語などの汎用プロセスモデリング言語を使用して、ソフトウェア開発メソッドをカスタマイズできます。ただし、 SEMATのソフトウェアエンジニアリングの本質理論などのメソッドエンジニアリング専用のツールも存在します。[ 78 ]
アジャイルソフトウェア開発は、新規プロジェクトに取り組む専門家の小規模チームなど、特定のタイプの環境に非常に適していると広く認識されています[ 46 ] [ 79 ] 。一方、レガシーインフラストラクチャを持つ大規模組織でアジャイルソフトウェア開発手法を採用する際に遭遇する課題と制限は十分に文書化され、理解されています[ 80 ] 。
これに対応して、大規模開発（20人以上の開発者） [ 81 ] [ 82 ]や分散型（非同一拠点）開発チーム[ 83 ] [ 84 ]などの課題を克服するためのさまざまな戦略やパターンが進化してきました。そして現在では、これらの課題を軽減または回避しようとする、いくつかの認知されたフレームワークが存在します。
これらすべてが効果的であるか、あるいは実際にアジャイル開発の定義に合致するかどうかについては、多くの相反する見解があり、これは現在も活発かつ継続的な研究分野である。[ 81 ] [ 85 ]
アジャイルソフトウェア開発を分散環境（複数の事業拠点にチームが分散している環境）に適用する場合、一般的に分散型アジャイルソフトウェア開発と呼ばれます。その目的は、それぞれの開発手法が持つ独自のメリットを最大限に活用することです。分散型開発では、組織は世界各地に戦略的にチームを配置することでソフトウェアを開発でき、事実上24時間体制でソフトウェア開発を行うことができます（一般的にはフォロー・ザ・サン・モデルと呼ばれます）。一方、アジャイル開発は、透明性の向上、継続的なフィードバック、そして変化への対応における柔軟性の向上を実現します。
アジャイルソフトウェア開発手法は当初、重要度の低い製品開発に最適であると考えられていたため、医療機器、医薬品、金融、原子力システム、自動車、航空電子機器などの規制対象分野での使用は除外されていました。しかし、ここ数年で、これらの分野にアジャイル手法を適用するための取り組みがいくつか行われています。[ 86 ] [ 87 ] [ 88 ] [ 89 ] [ 90 ]
規制対象領域に適用される可能性のある規格は多数あり、ISO 26262、ISO 9000、ISO 9001、ISO/IEC 15504などが含まれます。規制対象領域では、いくつかの重要な懸念事項が特に重要です。[ 91 ]
アジャイルソフトウェア開発手法は実際にはあらゆるプログラミングパラダイムや言語で使用できますが、元々はSmalltalk、Lisp、そして後にJava、C#などのオブジェクト指向環境と密接に関連していました。アジャイル手法を最初に採用したのは、通常、要件の確定が難しく、システムの開発中に変更される可能性が高い、前例のないシステムに取り組む中小規模のチームでした。このセクションでは、組織がアジャイルソフトウェア開発手法を採用しようとする際に遭遇する一般的な問題と、アジャイルチームの品質とパフォーマンスを測定するためのさまざまな手法について説明します。[ 92 ]
アジリティ測定指標は、とりわけ、製品開発の 5 つの側面 (期間、リスク、新規性、労力、相互作用) に基づいて開発を評価します。[ 93 ]他の手法は測定可能な目標に基づいています[ 94 ]、ある研究では、ベロシティをアジリティの指標として使用できることが示唆されています。チームがアジャイルソフトウェア開発プラクティスを使用しているかどうかを判断するためのアジャイル自己評価もあります (Nokia テスト、[ 95 ]、Karlskrona テスト、[ 96 ] 、 42 ポイント テスト[ 97 ] )。
アジャイルソフトウェア開発手法の使用により品質、生産性、ビジネス満足度が向上することを報告した初期の研究の1つは、Shine Technologiesが2002年11月から2003年1月にかけて実施した調査である。[ 98 ]
同様の調査である「 State of Agile」は、2006年から毎年実施されており、ソフトウェア開発コミュニティの数千人の参加者がいます。これは、アジャイルのメリット、教訓、およびベストプラクティスに関する傾向を追跡しています。各調査では、アジャイルソフトウェア開発によってソフトウェアをより迅速に提供でき、変化する顧客の優先順位を管理する能力が向上し、生産性が向上すると回答した人が増えていることが報告されています。[ 99 ]また、調査では、アジャイル製品開発手法は従来のプロジェクト管理よりも一貫して優れた結果を示しています。[ 100 ] [ 101 ]一方で、アジャイル開発手法はまだ新しすぎて、その成功に関する広範な学術研究を行うには時期尚早だと感じている人もいるという報告もあります。[ 102 ]
アジャイルソフトウェア開発を導入する組織やチームは、ウォーターフォール開発などの従来型の手法から移行する際に、チームにアジャイルプロセスが強制されるといった困難に直面することがよくあります。[ 103 ]これらは、アジャイルアンチパターン、あるいはより一般的にはアジャイルスメルと呼ばれることが多いです。以下に、一般的な例をいくつか示します。
アジャイルソフトウェア開発の目標は、ドキュメント作成よりも動作するソフトウェアの作成に重点を置くことです。これは、プロセスが厳密に管理され、システムのわずかな変更でもサポートドキュメントの大幅な改訂が必要となるウォーターフォールモデルとは対照的です。しかし、だからといって、分析や設計を全く行わないことが正当化されるわけではありません。設計に注意を払わないと、チームは最初は迅速に進めることができますが、システムを拡張しようとしたときに大幅な手戻りが必要になる可能性があります。アジャイルソフトウェア開発の重要な特徴の1つは、反復的であることです。正しく行えば、アジャイルソフトウェア開発は、システムの開発中に設計が出現することを可能にし、チームが共通点や再利用の機会を発見するのに役立ちます。[ 104 ]
アジャイルソフトウェア開発では、通常、要件を定義するためにストーリー（ユースケース記述に類似）が使用され、イテレーションはチームが特定の目標に取り組む短い期間です。[ 105 ]進行中のイテレーションにストーリーを追加することは、作業の流れを阻害します。これらはプロダクトバックログに追加し、次のイテレーションで優先順位を付けるか、まれにイテレーションをキャンセルする必要があります。[ 106 ]
これは、ストーリーが拡張できないという意味ではありません。チームは新しい情報に対応する必要があり、それによってストーリーに追加のタスクが発生する場合があります。新しい情報によってイテレーション中にストーリーを完了できない場合は、次のイテレーションに持ち越すべきです。ただし、新しい情報によってストーリーの当初の優先順位が変わっている可能性があるため、残りのすべてのストーリーよりも優先順位を高くする必要があります。
アジャイルソフトウェア開発は、開発プロセスを最適化し、ソフトウェア開発ライフサイクルの一貫性を確保しようとするソフトウェア開発チームによって、組織内で草の根的な取り組みとして導入されることが多い。スポンサーのサポートがない場合、チームはビジネスパートナー、他の開発チーム、経営陣から困難や抵抗に直面する可能性がある。さらに、適切な資金やリソースがないために苦労することもある。[ 107 ]これにより、失敗の可能性が高まる。[ 108 ]
VersionOneが行った調査によると、回答者はアジャイル実装の失敗の最も重要な原因として不十分なトレーニングを挙げた[ 109 ]。
プロダクトオーナーは開発活動においてビジネスを代表する責任を負い、多くの場合、最も要求の厳しい役割を担います。[ 110 ]
よくある間違いは、プロダクトオーナーの役割を開発チームのメンバーに任せることです。これにより、チームはビジネスからのフィードバックなしに優先順位付けについて独自の決定を下す必要が生じます。彼らはビジネス上の問題を内部で解決しようとしたり、チーム外に指示を求めて作業を遅らせたりします。これはしばしば注意散漫やコラボレーションの崩壊につながります。[ 111 ]
アジャイルソフトウェア開発では、チームが製品のコミットメントを果たすことが求められるため、その製品の作業のみに集中する必要があります。しかし、余剰能力があるように見えるチームメンバーは、他の作業を引き受けることが期待されることが多く、その結果、チームがコミットした作業を完了させるのが難しくなります。[ 112 ]
チームは、準備や計画に時間をかけすぎるという落とし穴に陥りがちです。これは、アジャイルソフトウェア開発に慣れていないチームによく見られる落とし穴で、すべてのストーリーを完全に理解し、仕様を策定しなければならないという義務感にとらわれてしまうのです。チームは、自信のあるストーリーのみを進め、イテレーション中に次のイテレーションのための作業を発見し、準備していくべきです（これはバックログの洗練や整理と呼ばれることが多いです）。
毎日のスタンドアップミーティングは、チームメンバー全員が情報を共有する、集中したタイムリーなミーティングであるべきです。問題解決が行われる場合、特定のチームメンバーのみが関与することが多く、チーム全体の時間の最適な使い方ではない可能性があります。毎日のスタンドアップミーティング中にチームが問題解決に取り掛かり始めた場合は、サブチームが話し合うことができるまで、通常はスタンドアップミーティングの終了直後に、問題を脇に置いておくべきです。[ 113 ]
アジャイルソフトウェア開発の意図された利点の1つは、問題に最も近いチームが意思決定を行えるようにすることです。さらに、意思決定にタイムリーな情報を使用するために、できるだけ実装に近い段階で意思決定を行うべきです。チームメンバーが他の人からタスクを割り当てられたり、プロセスの早い段階で割り当てられたりすると、局所的でタイムリーな意思決定の利点が失われる可能性があります。[ 114 ]
また、仕事が割り当てられると、チームメンバーは特定の役割に縛られ（例えば、チームメンバーAは常にデータベース作業を行わなければならない）、異分野研修の機会が制限される。[ 114 ]チームメンバー自身は、自分の能力を伸ばし、異分野研修の機会を提供するタスクを引き受けることを選択できる。
アジャイルの価値観と原則に合致するとされるスクラムフレームワークでは、スクラムマスターの役割は、スクラムプロセスが遵守されていることを確認し、そのプロセスを通じてスクラムチームをコーチングすることです。よくある落とし穴は、スクラムマスターが貢献者として行動することです。スクラムフレームワークでは禁止されていませんが、スクラムマスターはまずスクラムマスターとしての役割を果たす能力があることを確認し、開発タスクに取り組まないようにする必要があります。スクラムマスターの役割は、製品を作成することではなく、プロセスを促進することです。[ 115 ]
スクラムマスターがマルチタスクを行うと、コンテキストスイッチが多すぎて生産性が低下する可能性があります。さらに、スクラムマスターはチームが前進できるように障害を取り除く責任があるため、個々のタスクが前進することで得られるメリットは、キャパシティ不足のために延期された障害を上回らない可能性があります。[ 116 ]
アジャイル開発は反復的な性質を持つため、多くの場合、複数回のテストが必要になります。自動テストは、繰り返し行われる単体テスト、統合テスト、回帰テストの影響を軽減し、開発者とテスターがより価値の高い作業に集中できるようにします。[ 117 ]
テスト自動化は、反復的なソフトウェア開発に必要な継続的なリファクタリングもサポートします。開発者がテストを迅速に実行して、リファクタリングによってアプリケーションの機能が変更されていないことを確認できるようにすることで、作業負荷を軽減し、クリーンアップ作業によって新たな欠陥が発生していないという確信を高めることができます。
新機能の提供に注力すると、技術的負債が増加する可能性があります。チームは、欠陥の修正とリファクタリングのための時間を確保する必要があります。技術的負債は、本番環境の欠陥によってチームがそれ以上の進捗から注意をそらされるため、予定外の作業量が増加し、計画能力を阻害します。[ 118 ]
システムが進化するにつれて、リファクタリングが重要になります。[ 119 ]時間の経過とともに、継続的なメンテナンスの欠如は、欠陥の増加と開発コストの増加につながります。[ 118 ]
アジャイルソフトウェア開発では継続的な変更が可能であるという誤解がよくありますが、イテレーションバックログは、イテレーション中に完了できる作業についての合意です。[ 120 ]進行中の作業 (WIP)が多すぎると、コンテキストスイッチングやキューイングなどの非効率性が発生します。[ 121 ]チームは、追加の作業を引き受けるようプレッシャーを感じないようにする必要があります。[ 122 ]
アジャイルソフトウェア開発では、時間（イテレーション期間）、品質、そして理想的にはリソースを事前に固定しますが（開発者が本番環境のインシデントに対応するためにタスクから頻繁に引き離される場合、固定リソースを維持することは困難になる可能性があります）、スコープは可変のままです。顧客またはプロダクトオーナーは、イテレーションの固定スコープを求めることがよくあります。しかし、チームは、固定された時間、リソース、スコープ（一般的にプロジェクト管理の三角形として知られています）にコミットすることには慎重であるべきです。アジャイルソフトウェア開発の固定された時間とリソースにスコープを追加しようとすると、品質が低下する可能性があります。[ 123 ]
アジャイルプラクティスの集中したペースと継続的な性質のため、デリバリーチームのメンバーの間で燃え尽き症候群のリスクが高まります。[ 124 ]
アジャイルプロジェクト管理は反復的な開発プロセスであり、適切なユーザーエクスペリエンスを作成するために、ユーザーとステークホルダーからフィードバックが継続的に収集されます。アジャイルプロセスを実行するために使用できるさまざまな方法には、スクラム、エクストリームプログラミング、リーン、カンバンなどがあります。[ 125 ]アジャイル管理という 用語は、アジャイルソフトウェア開発マニフェストで表明された原則に基づいて、非常に柔軟でインタラクティブな方法で新しい製品またはサービスの開発を提供することを目的とした、エンジニアリング、情報技術、およびその他のビジネス分野の設計および構築活動を管理する反復的で漸進的な方法に適用されます。[ 126 ] アジャイルプロジェクト管理の指標は、混乱を減らし、弱点を特定し、開発サイクル全体を通してチームのパフォーマンスを測定するのに役立ちます。サプライチェーンの俊敏性とは、供給と需要の不確実性と変動に対処するサプライチェーンの能力です。アジャイルなサプライチェーンは、その能力を迅速に増減できるため、急速に変化する顧客の需要に適応できます。最後に、戦略的俊敏性とは、組織が環境の変化に応じて行動方針を変更する能力です。戦略的俊敏性の鍵は、外部の変化を早期に認識し、これらの変化する環境に適応するためにリソースを割り当てることである。[ 125 ]
アジャイル X 手法は、エクストリーム プロジェクト マネジメントとも呼ばれます。これは、成果物が段階的に提出される反復型ライフサイクル [ 127 ] の一種です。アジャイル開発と反復型開発の主な違いは、アジャイル手法では各デリバリー サイクル (イテレーション) で成果物の小さな部分を完成させるのに対し [ 128 ]、反復型手法では成果物全体を時間をかけて進化させ、プロジェクトの終盤近くで完成させる点です。反復型手法とアジャイル手法はどちらも、より逐次的なプロジェクト組織の形態で発生したさまざまな障害への対応として開発されました。たとえば、テクノロジー プロジェクトが複雑化するにつれて、エンド ユーザーは、段階的なプロトタイプを確認できないと、長期的な要件を定義することが難しくなる傾向があります。反復で開発されるプロジェクトでは、フィードバックを継続的に収集して、要件を洗練させることができます。
アジャイル管理は、チームメンバー間のコミュニケーションと過去の作業の振り返りを促進するシンプルなフレームワークも提供します。 [ 129 ]従来のウォーターフォール計画を使用していたチームがアジャイル開発方法を採用すると、通常は変革フェーズを経ることになります。多くの場合、チームがよりスムーズな変革を行えるよう支援するアジャイルコーチの助けを借ります。アジャイルコーチングには、プッシュ型とプル型の2つのスタイルがあります。ここで「プッシュシステム」とは、スクラムなどでよく見られるように、スプリントに組み込めるタスクを事前に見積もること（プッシュ作業）を指します。一方、「プルシステム」とは、キャパシティが利用可能な場合にのみタスクを実行する環境を指します。[ 130 ]アジャイル管理アプローチは、ビジネスおよび政府部門でも採用され、適応されています。たとえば、米国連邦政府では、米国国際開発庁（USAID）が、プログラミングを反復および適応させるために、コラボレーション、学習、適応（CLA）戦略の組み込みに焦点を当てたコラボレーションプロジェクト管理アプローチを採用しています。[ 131 ]
アジャイル手法は、『プロジェクトマネジメント知識体系ガイド（PMBOKガイド第6版）』の製品開発ライフサイクルの定義の中で言及されています。
プロジェクトのライフサイクルには、一般的に製品、サービス、または成果物の開発に関連する 1 つ以上のフェーズがあります。これらは開発ライフサイクルと呼ばれます (...) 適応型ライフサイクルは、アジャイル、反復型、または漸進型です。詳細なスコープは、反復の開始前に定義され、承認されます。適応型ライフサイクルは、アジャイルまたは変更主導型ライフサイクルとも呼ばれます。[ 132 ]
ジャン＝ルー・リシェ（ ESSEC戦略イノベーション・サービス研究所の研究員）によれば、「このアプローチは、ソフトウェア以外の製品や、特にイノベーションや不確実性の分野におけるプロジェクト管理全般に効果的に活用できる」とのことです。その結果、現在の顧客ニーズに最も適した製品やプロジェクトが、最小限のコスト、無駄、時間で提供され、企業は従来のアプローチよりも早く収益の向上を実現できます。[ 133 ]
アジャイルソフトウェア開発手法は、ソフトウェア製品の開発に広く用いられており、その一部はオブジェクト技術などのソフトウェアの特定の特性を利用している。[ 134 ]しかし、これらの手法は、コンピュータ、医療機器、食品、衣料、音楽などの非ソフトウェア製品の開発にも適用できる。[ 135 ]アジャイルソフトウェア開発手法は、非開発のITインフラストラクチャの展開や移行にも用いられている。アジャイルソフトウェア開発のより広範な原則の一部は、ビジネスアジリティまたはアジャイルビジネス管理という用語で、一般的な管理[ 136 ]（戦略、ガバナンス、リスク、財務など）にも適用されている。アジャイルソフトウェア手法は、学習者とその発達を支援するために人間中心設計とデータに基づく意思決定を適用する反復的なデータに基づくプロセスである学習エンジニアリングプロセスにも採用されている。 [ 137 ]
アジャイルソフトウェア開発パラダイムは、子育てなど、生活の他の分野にも応用できます。子育てにおけるその成功は、コミュニケーション、適応、意識といった基本的な管理原則に基づいているのかもしれません。TEDトークで、ブルース・ファイラーは、基本的なアジャイルパラダイムを家庭管理や子育てにどのように応用したかを語りました。[ 138 ]
アジャイル手法は、大規模組織や特定の種類の開発においては非効率である可能性があると指摘されている。[ 139 ]多くの組織は、アジャイルソフトウェア開発手法は極端すぎると考え、アジャイルソフトウェア開発と計画主導型アプローチの要素を組み合わせたハイブリッドアプローチを採用している。[ 140 ]動的システム開発手法（DSDM ）などの一部の手法は、基本原則を犠牲にすることなく、規律ある方法でこれを試みている。
アジャイルプラクティスの普及が進む一方で、既存の優れたプラクティスを新しい専門用語で説明するだけの経営上の流行であり、開発戦略に対して画一的な考え方を助長し、結果よりも方法を誤って重視しているという批判も受けている。[ 142 ]
アリスター・コックバーンは、2011年2月12日にユタ州スノーバードでアジャイルソフトウェア開発マニフェスト10周年記念の祝賀会を企画し、最初の会議以降に関わった30人以上を集めた。議論できないアジャイルのトピック/問題（「議論できない」問題）約20項目がリストアップされ、その中には、アジャイルソフトウェア開発の実践とコンテキスト（考えられる原因：商業的利益、文脈からの逸脱、失敗に基づいて進歩する明確な方法がない、客観的な証拠が限られている、認知バイアスと推論の誤謬）、政治、文化といった側面が含まれていた。[ 143 ]フィリップ・クルーテンは次のように書いている。
アジャイルムーブメントは、ある意味ではティーンエイジャーに少し似ています。非常に自己意識が強く、常に鏡で自分の容姿をチェックし、批判をほとんど受け入れず、仲間といることにしか興味がなく、過去の知恵は過去のものだという理由だけで一括りに拒否し、流行や新しい専門用語を取り入れ、時には生意気で傲慢です。しかし、私はそれがさらに成熟し、外部世界にもっと開かれ、より内省的になり、ひいてはより効果的になることを確信しています。
—フィリップ・クルヒテン[ 143 ]
「マニフェスト」は高等教育の経営とリーダーシップに悪影響を与えた可能性があり、管理者に対して、時間のかかる伝統的な熟慮型のプロセスをより「機敏な」プロセスに置き換えるべきだと示唆した。この概念は大学教員の間ではほとんど受け入れられなかった。[ 144 ]
もう一つの批判は、アジャイルマネジメントと従来のマネジメント手法は、多くの点で互いに相反するものになってしまうという点です。この手法に対する一般的な批判は、潜在的なメリットがあるにもかかわらず、その手法を学び、導入しようとするのに費やす時間がコストがかかりすぎるという点です。従来のマネジメントからアジャイルマネジメントへの移行には、アジャイルへの完全な服従と、組織のすべてのメンバーがプロセスを最後までやり遂げるという確固たるコミットメントが必要です。組織全体で結果が不均等になる、従業員が対応しきれないほどの変化、あるいは変革の最後に保証がないといった問題は、ほんの一例にすぎません。[ 145 ]
「アジャイルソフトウェア開発: イノベーションのビジネス」というタイトルの記事は、ソフトウェアエンジニアリングの分野を弱体化させようとするまた別の試みです... 私たちはすべての時間をコーディングに費やしたいと思っています。覚えておいてください、真のプログラマーはドキュメントを書かないのです。
%が効果なしまたはコスト削減があったと回答
…93%が生産性が向上した、または大幅に向上したと回答
…88%が品質が向上した、または大幅に向上したと回答
…83%がビジネス満足度が向上した、または大幅に向上したと回答
生産性が低下したと回答したのはわずか6%でした
... 回答者の34%は生産性に変化がないと報告し、60%は生産性が向上したと報告しました
... 66%は品質が向上したと回答しました
... 組織の58%は満足度が向上したと報告し、満足度が低下したと報告したのはわずか3%でした。
自己組織化チームとは何ですか？
{{cite book}}: CS1メンテナンス: 場所の発行元が見つかりません (リンク)