アジャイル ソフトウェア開発宣言の歴史
アジャイル ソフトウェア開発宣言とアジャイル ソフトウェアの 12 の原則は、1990 年代の業界のフラストレーションから生まれたものです。 ビジネス要件 (顧客が要求するアプリケーションや機能) と、そのニーズに応える技術の提供には大きなタイム ラグがあり、多くのプロジェクトが中止に追い込まれました。 このラグタイムの間にビジネスや要件、顧客の要望が変化し、最終製品がその時点でのニーズを満たしていなかったのです。 ウォーターフォール モデルに代表される当時のソフトウェア開発モデルはスピードに対する要求を満たしておらず、ソフトウェアの変更の速さを生かすことができませんでした。
2000 年、Jon Kern、Kent Beck、Ward Cunningham、Arie van Bennekum、Alistair Cockburn ら 17 人の「ソート リーダー」のグループが、オレゴン州のリゾート地で出会い、2001 年にはユタ州のスキー ゾート、The Lodge at Snowbird で会合を開きました。 アジャイル ソフトウェア開発宣言と 12 の原則が正式に書かれたのは、第 2 回目のミーティングにおいてでした。 宣言には、次のように書かれています。
「私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。
すなわち、左記のことがらに価値があることを認めながらも、
私たちは右記のことがらにより価値をおく」
次のアジャイル プロジェクト用の無料のアジャイル テンプレートの幅広い選択肢は、ベスト アジャイル プロジェクト管理 Excel テンプレートでご確認ください。
A better, more agile way to plan, track, and manage your projects with Smartsheet
Smartsheet is a cloud-based platform that allows teams and organizations to plan, manage, and report on projects, helping you iterate more effectively and achieve more. See Smartsheet in action.
Agile Project Management E-book
How can Agile PM help you do more with less?
Agile project management empowers teams to adapt to change with increased speed and flexibility. Learn how to implement Agile PM and get the most out of the methodology.
アジャイル ソフトウェア開発宣言の 4 つの価値
アジャイル ソフトウェア開発宣言は、ソフトウェア開発におけるアジャイル アプローチを導く 4 つの基本的な価値観とそれを支持する 12 の原則で構成されています。 それぞれのアジャイル開発手法では、4 つの価値の適用方法は異なりますが、いずれも高品質で動くソフトウェアを開発・提供するための指針となっています。
１. プロセスやツールよりも個人と対話を
アジャイル ソフトウェア開発宣言の 1 つ目の価値は、「プロセスやツールよりも個人と対話を」です。 プロセスやツールよりも人を大切にすることは、ビジネスのニーズに応え、開発プロセスを推進するのが人であることからも理解できます。 プロセスやツールによって開発が進められてしまうと、変更へのチームの対応力が低下し、顧客のニーズを満たすことができなくなります。 コミュニケーションは、個人を重視するか、プロセスを重視するかの違いの一例です。 個人の場合、コミュニケーションは流動的で、必要に応じて行われます。 プロセスの場合は、コミュニケーションが予定されており、具体的な内容が求められます。
２. 包括的なドキュメントよりも動くソフトウェアを
歴史的に、開発や最終的な納品のために製品をドキュメント化することに膨大な時間が費やされてきました。 技術仕様書、技術要件、技術目論見書、インターフェイス設計ドキュメント、テスト計画、ドキュメント化計画、そしてそれぞれに必要な承認。 そのリストは膨大なもので、開発の大幅な遅延の原因となっていました。 アジャイルはドキュメントをなくすものではなく、仕事をするのに必要なものを、瑣末なことに煩わされずに開発者に提供できるような形でドキュメントを合理化します。 アジャイルでは、要件を、ソフトウェア開発者が新しい機能を構築するタスクを開始するのに十分なユーザー ストーリーとしてドキュメント化します。
アジャイル ソフトウェア開発宣言ではドキュメントを重視していますが、それ以上に働くソフトウェアを重視しています。
３. 契約交渉よりも顧客との協調を
交渉とは、顧客とプロダクト マネージャーが納品の詳細を詰めていく期間であり、途中で詳細を再交渉することもあります。 共同作業は、まったく別の生き物です。 ウォーターフォールのような開発モデルでは、作業開始前に顧客が製品の要件を詳細に交渉することが多くあります。 つまり、開発が始まる前と完了後のプロセスには顧客が関与していましたが、プロセス中には関与していませんでした。 アジャイル ソフトウェア開発宣言には、顧客が開発プロセス全体に関与し、協力することが記載されています。 これにより、開発側が顧客のニーズに応えることがはるかに簡単になります。 アジャイル手法では、定期的に顧客にデモをしてもらうことがありますが、プロジェクトでは、エンド ユーザーが日常的にチームの一員として参加し、すべてのミーティングに出席して、製品が顧客のビジネス ニーズを満たしていることを確認することも可能です。
４. 計画に従うことよりも変化への対応を
従来のソフトウェア開発では、変更は費用と見なされ、避けられていました。 意図していたのは、定義された一連の機能を備え、一般的にすべてのものが他のすべてのものと同じくらい高い優先度を持ち、チームがパズルの次のピースに取り組めるように一定の順序で納品することに多くの依存関係があるような、詳細で精巧な計画を立てることでした。
アジャイルでは、イテレーション (反復) の期間が短いため、イテレーションごとに優先順位を変えたり、次のイテレーションに新機能を追加したりすることができます。 アジャイルの考え方では、変更は常にプロジェクトを改善し、 変更は付加価値を提供します。
変更に対するアジャイルの前向きなアプローチを最もよく表しているのは、An Agile Information Systems Development Method で次のように定義されている「メソッド調整 (Method Tailoring)」の概念でしょう。 「人間のエージェントが、コンテキスト、意図、手法の断片のレスポンシブな変更や動的な相互作用を通じて、特定のプロジェクトの状況に応じたシステム開発アプローチを決定するプロセスまたは能力」 アジャイル手法により、アジャイル チームはプロセスを修正して、逆にチームに合わせることができます。
アジャイル ソフトウェア開発宣言の 12 の原則
12 の原則は、「アジャイル ムーブメント」というタイトルに含まれている方法論の指針となる原則です。 これは、変化を歓迎し、顧客が仕事の中心であるという文化を説明しています。 また、アジャイル ソフトウェア開発宣言の署名者の一人である Alistair Cockburn 氏が述べた「開発をビジネス ニーズと一致させる」という運動の意図も示しています。
アジャイル開発の 12 の原則は以下のとおりです。
- 早期かつ継続的なソフトウェアの提供による顧客満足度の向上 - ソフトウェアのリリースを長期間待つのではなく、一定期間ごとに動くソフトウェアを受け取る方が、顧客は満足します。
- 開発プロセス全体で変化する要件に対応 - 要件や機能要求が変更された場合に、遅延を回避することができます。
- 動くソフトウェアの頻繁な提供 - スクラムでは、チームがソフトウェア スプリントやイテレーションで作業し、動くソフトウェアの定期的な提供を保証するため、この原則に対応しています。
- プロジェクト全体でのビジネスの関係者と開発者間の共同作業 – ビジネス チームと技術チームが連携することで、より良い意思決定が行われます。
- 関係者をサポートし、信頼し、モチベーションを高める - モチベーションの高いチームは、不幸なチームよりも最高の仕事をする可能性が高くなります。
- 対面でのコミュニケーションを可能にする - 開発チームが同じ場所にいると、コミュニケーションはよりうまくいきます。
- 動くソフトウェアが進歩の第一の尺度 - 機能的なソフトウェアを顧客に提供することは、進歩を測る究極の要因です。
- 一貫した開発ペースをサポートするアジャイル プロセス - チームは、動くソフトウェアを提供するために、反復可能で維持可能なスピードを確立し、リリースごとにそれを繰り返します。
- 技術的なディテールとデザインへのこだわりがアジリティを高める- 適切なスキルと優れたデザインにより、チームはペースを維持し、製品を常に改善し、変化を持続することができます。
- シンプルさ - 今の仕事をこなすのに必要なだけの開発を行います。
- 自己組織化されたチームは、優れたアーキテクチャ、要件、デザインを促進する - 意思決定権を持ち、オーナーシップを発揮し、他のチーム メンバーと定期的にコミュニケーションをとり、アイデアを共有することで、質の高い製品を提供することができる、スキルとモチベーションの高いチーム メンバー。
- より効果的になるための定期的な考察- 自己改善、プロセス改善、スキルの向上、技術の向上は、チーム メンバーがより効率的に働くのに役立ちます。
アジャイルの意図は、開発をビジネス ニーズに合わせることであり、その成功は明らかです。 アジャイル プロジェクトは、顧客を重視し、顧客の指導と参加を促します。 その結果、アジャイルはソフトウェア業界全体のソフトウェア開発に対する包括的な見解となり、それ自体がひとつの産業となりました。
Smartsheet を使ってアジャイルを始める
Smartsheet は、スプレッドシートにヒントを得たタスクおよびプロジェクト管理ツールで、アジャイル プロジェクト管理に欠かせない強力な共同作業およびコミュニケーション機能を備えています。 リアルタイムで更新を行い、新しい変更点をチームに知らせることができます。また、社内外の関係者と計画を共有することで、透明性を高め、全員が共通認識を持つことができます。
Smartsheet はクラウドベースなので、プロジェクト要件の追跡、ドキュメントへのアクセス、タイムラインの作成、アラートの送信などをほぼどこからでも行うことができます。 グリッド、カレンダー、ガント、ダッシュボードなど、幅広いスマートなビューから選択して、思いどおりにプロジェクトを管理することができます。 さらに、最新のビューであるカード ビューを使えば、チームはより視覚的な方法で Smartsheet で作業、コミュニケーション、共同作業を行うことができます。 カード ビューでは、豊富なカードを使って注意を集中させたり、柔軟なビューで見通しを立てたり、仕事の優先順位や調整をより視覚的に行うことができます。 視覚的なカードをドラッグ アンド ドロップするだけで、タスクへのアクションや作業ステータスの変更を行い、決定事項を即座にチーム全体で共有することができます。