ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。近年、アジャイルソフトウェア開発手法が数多く考案されている。ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。アジャイルソフトウェア開発手法を推進している。呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。1つの機能を開発する(⇒反復型開発)。この反復のサイクルを継続して行うことで、1つずつ機能を追加的に開発してゆくのである。各々の反復は、小規模なソフトウェア開発プロジェクトに似ている。(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行うからである。アジャイル開発手法では、各反復が終了するごとに、機能追加された新しいソフトウェアをリリースすることを目指す。各反復が終了するごとに、プロジェクトチームは、プロジェクトにおける優先度を評価し直す。アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする。(ここでの顧客とは、開発対象のソフトウェアが何であるかを定義する人々である。「顧客」は、時としてプロジェクト管理者である場合があるし、ビジネスアナリストや本物の顧客である場合もある)。この作業場所では、テスト担当者、ユーザインタフェース設計者、テクニカルライタ、管理職も一緒に作業する場合がある。アジャイル開発手法では、実際に動くソフトウェアこそが最重要なプロジェクト進行尺度であることを強調する。この「実際に動くソフトウェア」という進行尺度の採用と、直接顔を合わせた意思疎通の重視とがあいまって、アジャイル開発手法で作成する文書の量は、他の開発手法と比較すると、非常に少ない。アジャイルソフトウェア開発宣言[編集]アジャイルソフトウェア開発手法とは、一群のソフトウェア開発手法の総体を意味する言葉であり、単一の開発手法を指す言葉ではない。分野において名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な部分を統合することについて議論した。アジャイルソフトウェアの原則)。この宣言には、著者として次の17人が名前を連ねている。「計画重視」手法までの連続線上において、典型的な適応的開発手法に位置づけられる。従来の開発手法との違いは、適応的開発手法から計画重視手法までの連続線上に、各開発手法を位置づけることによって、適切に説明できる。他の開発手法のプロジェクトと同様に、アジャイル開発手法のプロジェクトでは、計画を立て、統制を行う。「統制された」手法の反対側に位置づけられると言及されることがあるが、これは誤りである。開発手法では、現実世界で生じた変更にすばやく適応することに主眼を置く。プロジェクトで変更が必要となった場合、適応的手法のプロジェクトチームは、即座に変更に対応することができる。その一方で、将来起こりうる変更を正確に文書化することは困難である。そのため、長期的予測になるほど、予測の不確実性は大きくなる。次の週に行うべき作業は正確に文書化することができるが、次の月に行うべき作業は正確に文書化することはできない。したがって、6か月後のリリースについて質問を受けた場合、適応的手法のチームにできることは、6か月後のリリースに向けた課題を文書化することや費用対効果の予測を文書化することぐらいである。開発手法では、適応的手法とは対照的に、詳細な開発計画を立てることに主眼を置く。したがって、計画重視手法のチームは、開発プロセスの全期間にわたって、注意点と作業を正確に計画することができる。その一方で、プロジェクト中に生じた変更に対応することは困難である。計画立案時点を基準として、計画が最適化されているからである。そのため、プロジェクト中に変更が生じると、すでに完了した作業の一部は無駄になり、やり直さなければならないことになる。そこで、重要な変更だけを管理するために、変更管理委員会を設けることが多い。反復型開発との比較[編集]アジャイルソフトウェア開発手法の多くは、反復型開発手法と同様に、短い期間を単位として、リリース可能なソフトウェアを開発することを強調する。反復型開発手法ではリリースの期間単位が月単位であることが多いのに対し、アジャイル開発手法では週単位であることが多い。アジャイル開発手法では、高度に洗練された共同作業のもとで作業を行うことを強調する。アジャイル開発手法の多くでは、反復型開発手法よりも、厳密な期間単位のもとで作業を行う。ウォーターフォールモデルとの比較[編集]アジャイルソフトウェア開発は、ウォーターフォールモデルによる開発との共通点が少ない。ウォーターフォール開発はもはや信頼を失っていると考える人もいる。ウォーターフォール開発手法は、数あるソフトウェア開発手法の中でも、最も計画重視であると位置づけられる手法である。テストの各工程を、予め計画された順序に厳格に従って行う。テスト計画コードレビューなどウォーターフォールモデルは、一連の工程の大規模な統合であり、数か月から数年の長い期間単位を採用し、その期間単位の終了に向けてテストが行われる。この統合とテストの規模が大きくまた困難であることは、ウォーターフォールモデル開発のプロジェクトが失敗する際に、その原因の一つとなっていることが多い。(ここでの機能とはシステム全体のごく小さなサブセットである)。アジャイル開発手法では、雑ではあるが利用可能なシステムを早期に構築し、継続的に改良を行ってゆくことを強調する。一部のアジャイル開発チームでは、小規模なウォーターフォールモデルが採用されている。この場合、反復ごとに完全なウォーターフォールのサイクルを繰り返す。ウォーターフォールモデルの各工程を、同時並行して行う。カウボーイコーディングはアジャイル開発とは異なる[編集]カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うことである。好ましくない状態を指すのに使う言葉であり、特定の開発手法を指す言葉ではない。職人的な個人技に依存するカウボーイコーディングには、明確な手法が欠如している。カウボーイコーディングで開発を行うチームのメンバーは、自分たちがそれぞれ正しいと感じた作業を行う。アジャイルソフトウェア開発には、計画の頻繁な再評価、直接顔を合わせた意思疎通の重視、比較的少ない文書化などの特徴がある。以上のような特徴がアジャイル開発にはあるため、アジャイル開発とカウボーイコーディングを混同されることがある。した混同は正確ではない。アジャイル開発チームは明確なプロセスに従って作業する。このプロセスは、統制され厳格である場合が少なくない。この点でアジャイル開発とカウボーイコーディングは異なっている。アジャイルソフトウェア開発手法をいつ使うか[編集]アジャイルソフトウェア開発は、10人以下の小規模なチームが1か所で作業を行うプロジェクトの場合に効果的であると説明されることが多い。アジャイルソフトウェア開発は、予測困難な要件や頻繁に変更される要件に直面するチームにとって、特に有効な手法であると指摘される。以上に述べた状況以外においても、アジャイル開発を採用して成功したチームの体験報告がいくつか存在する。2005年4月の時点では、企業においてアジャイル開発を採用した報告は少ない。次に列記する状況に対して、アジャイル開発手法を適用できるかということについては、議論の対象となっている。開発手法と計画重視の開発手法のどちらを選択すべきかという問題に対する指針として、リスク分析手法を提案した。ベームとターナは、適応的開発にも計画重視開発にもそれぞれ得意分野があると、述べている。秩序を重視する組織的文化ベームとターナの主張によると、以上のような要素を指針としてプロジェクトを分析することで、アジャイル開発か計画重視開発かを検討する際の判断材料とすることができる。歴史[編集]近年のアジャイルソフトウェア開発の定義は、1990年代半ばに、「重量ソフトウェア開発手法」への反対運動の一部から発展して形成されてきた。重量開発手法の特徴は、ウォーターフォール開発モデルを適用した場合に多くみられる、厳格な規律と統制、管理不足などである。そのためソフトウェア技術者が効果的に作業を進めるという観点と矛盾していた。今日で言うアジャイルソフトウェア開発手法は、以前は「軽量ソフトウェア開発手法」と呼ばれていた。先述したとおり、2001年に軽量開発手法において名声のある人々がスノーバードに会し、「アジャイルソフトウェア開発手法」と呼称を変えた。設立し、アジャイル開発を推進する活動を行っている。2000年以前に開発された比較的歴史の長いアジャイル開発手法には次のようなものがある。最初のアジャイル開発手法ではなかったようだが、数あるアジャイル開発手法の中で抜きん出た評判を確立した。プロジェクトを立て直す際に、実践した。公開議論と、ケント・ベックのさらなる改訂を経て、1999年に書籍として出版された[2]。基にしているようである。ヨーロッパで最初に確立されたアジャイル開発手法であると考えられている。アジャイルソフトウェア開発手法の実例[編集]広く知られたアジャイルソフトウェア開発手法の一部を示す。あるとして、批判されることがある。ような賛否両論のある実践原則は、特に批判の対象となった[3][1]。Refactored)。アジャイルソフトウェア開発に対しては、構造的な批判と文書化に関する批判がある。不十分な設計や少ない文書という批判に対して、解決するべく取り組んでいる。おいても行われていくとみられる。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。Cookieに関する声明モバイルビュ。