Lessons

What is Agile? The Manifesto and Principles

Level: Beginner Module: Agile Foundations 4 min read Lesson 1 of 52

Overview

  • What you’ll learn: The origin story of Agile, the four core values of the Agile Manifesto, the twelve guiding principles, and why they matter in modern software development.
  • Prerequisites: None — this is where it all begins.
  • Estimated reading time: 15 minutes

Introduction

In February 2001, seventeen software developers gathered at the Snowbird ski resort in Utah. They were not there to ski (mostly). They were there because the software industry was drowning in documentation, rigid processes, and projects that consistently failed to deliver what customers actually needed.

What emerged from that meeting was the Manifesto for Agile Software Development — a document so brief it fits on a single page, yet so powerful it redefined how the world builds software. These seventeen developers didn’t agree on much (they practiced different methodologies), but they agreed on four values and twelve principles that would become the foundation of modern project management.

The Four Values of the Agile Manifesto

The Manifesto declares four value statements, each framed as “X over Y” — not that Y is worthless, but that X is valued more:

We Value More Over
Individuals and interactions Processes and tools
Working software Comprehensive documentation
Customer collaboration Contract negotiation
Responding to change Following a plan

The critical subtlety: “while there is value in the items on the right, we value the items on the left more.” This is not permission to throw away documentation or ignore planning. It is a priority statement — when forced to choose, lean left.

Why These Values Matter

  • Individuals and interactions: The best process in the world is useless if people don’t talk to each other. A whiteboard conversation between two developers often solves more than a 50-page specification document.
  • Working software: The ultimate measure of progress is software that works. Not documents about software. Not slide decks about software. Actual, running, usable software.
  • Customer collaboration: Contracts create adversarial relationships. When the customer and the development team are on the same side, the product wins.
  • Responding to change: Requirements will change. The market will shift. New competitors will appear. The question is not “will change happen?” but “how fast can we respond?”

The Twelve Principles

Behind the four values stand twelve principles that provide more specific guidance:

  1. Customer satisfaction through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. Face-to-face conversation is the most efficient and effective method of conveying information.
  7. Working software is the primary measure of progress.
  8. Sustainable pace. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. Self-organizing teams produce the best architectures, requirements, and designs.
  12. Regular reflection: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts.

Common Misunderstandings

  • “Agile means no planning” — False. Agile means continuous planning, not no planning. You plan frequently in small increments rather than once upfront in massive detail.
  • “Agile means no documentation” — False. Agile means sufficient documentation, not no documentation. Document what adds value; skip what doesn’t.
  • “Agile is a methodology” — Agile is a mindset and a set of values. Scrum, Kanban, and XP are methodologies (or frameworks) that embody Agile values.

Key Takeaways

  • The Agile Manifesto was created in 2001 by seventeen practitioners who agreed on values, not specific practices.
  • Four values prioritize people, working software, collaboration, and adaptability — without discarding the alternatives.
  • Twelve principles provide actionable guidance: deliver frequently, embrace change, work sustainably, reflect regularly.
  • Agile is a mindset, not a methodology. Frameworks like Scrum implement Agile values.

What’s Next

In Lesson 2, you will explore how Agile compares to the traditional Waterfall approach, when each is appropriate, and why the shift happened.

繁體中文

概述

  • 學習目標：敏捷的起源故事、敏捷宣言的四大核心價值觀、十二項指導原則，以及為什麼它們在現代軟體開發中至關重要。
  • 先決條件：無——一切從這裡開始。
  • 預計閱讀時間：15 分鐘

簡介

二〇〇一年二月，十七位軟體開發者齊聚猶他州雪鳥滑雪度假村。他們來此並非為了滑雪（大部分不是）。他們來此是因為軟體產業正淹沒在文件、僵化流程和持續無法交付客戶真正需要的東西的專案中。

那次會議誕生了敏捷軟體開發宣言——一份簡短到可以放在一頁紙上的文件，卻強大到重新定義了全世界建造軟體的方式。這十七位開發者在很多事情上意見不同（他們實踐不同的方法論），但他們在四項價值觀和十二項原則上達成了共識，這些成為了現代專案管理的基石。

敏捷宣言的四大價值觀

我們更重視 勝過
個人與互動 流程與工具
可運作的軟體 詳盡的文件
客戶協作 合約談判
回應變化 遵循計劃

關鍵的微妙之處：「雖然右邊的項目也有價值，但我們更重視左邊的項目。」這不是允許你丟掉文件或忽略規劃的許可證。這是一個優先順序聲明——當被迫選擇時，偏向左邊。

十二項原則

  1. 透過早期且持續交付有價值的軟體來滿足客戶。
  2. 歡迎需求變更，即使在開發後期。敏捷流程利用變更為客戶創造競爭優勢。
  3. 頻繁交付可運作的軟體，從幾週到幾個月，傾向較短的時間週期。
  4. 業務人員和開發人員必須在整個專案期間每天一起工作。
  5. 圍繞有動力的個人來建構專案。給予他們所需的環境和支援，並信任他們完成工作。
  6. 面對面交談是最有效率的資訊傳遞方式。
  7. 可運作的軟體是衡量進度的主要指標。
  8. 可持續的步調。贊助者、開發者和使用者應該能夠無限期地維持恆定的步調。
  9. 持續關注技術卓越和良好設計可增強敏捷性。
  10. 簡單——最大化不需要做的工作量的藝術——是至關重要的。
  11. 自組織團隊產生最佳的架構、需求和設計。
  12. 團隊定期反思如何更有效，然後調整和調適。

常見誤解

  • 「敏捷就是不做計劃」——錯。敏捷是持續規劃，不是不規劃。
  • 「敏捷就是不寫文件」——錯。敏捷是寫足夠的文件，不是不寫文件。
  • 「敏捷是一種方法論」——敏捷是一種心態和價值觀。Scrum、Kanban 和 XP 才是方法論（或框架）。

重點摘要

  • 敏捷宣言由十七位實踐者於 2001 年創建，他們就價值觀達成共識，而非具體實踐。
  • 四項價值觀優先考慮人、可運作的軟體、協作和適應性。
  • 十二項原則提供可行的指導：頻繁交付、擁抱變化、可持續工作、定期反思。
  • 敏捷是心態，不是方法論。Scrum 等框架實現敏捷價值觀。

下一步

在第 2 課中，您將探討敏捷與傳統瀑布流方法的比較，各自適用的場景，以及為什麼轉變發生了。

日本語

概要

  • 学習内容：アジャイルの起源、アジャイルマニフェストの4つの価値観、12の原則、そしてなぜそれらが重要なのか。
  • 前提条件：なし——すべてはここから始まる。
  • 推定読了時間：15分

はじめに

2001年2月、17人のソフトウェア開発者がユタ州のスノーバードスキーリゾートに集まった。スキーをしに来たわけではない（ほとんどは）。ソフトウェア業界がドキュメント、硬直したプロセス、そして顧客が本当に必要としているものを提供できないプロジェクトに溺れていたからだ。

その会議から生まれたのがアジャイルソフトウェア開発宣言——1ページに収まるほど短く、しかし世界のソフトウェア構築方法を再定義するほど強力な文書である。

アジャイルマニフェストの4つの価値観

より重視するもの よりも
個人と対話 プロセスとツール
動くソフトウェア 包括的なドキュメント
顧客との協調 契約交渉
変化への対応 計画に従うこと

重要な微妙さ：「右側の項目にも価値があるが、左側の項目をより重視する。」これはドキュメントを捨てたり計画を無視する許可ではない。優先順位の宣言である。

12の原則

  1. 価値あるソフトウェアの早期かつ継続的な提供による顧客満足。
  2. 開発の後期であっても要求の変更を歓迎する。
  3. 数週間から数ヶ月の間隔で動くソフトウェアを頻繁に提供する。
  4. ビジネス側の人間と開発者はプロジェクト全体を通じて毎日一緒に働く。
  5. 意欲のある個人を中心にプロジェクトを構築し、信頼する。
  6. 対面での会話が最も効率的な情報伝達方法である。
  7. 動くソフトウェアが進捗の主要な尺度である。
  8. 持続可能なペースを無期限に維持できるべきである。
  9. 技術的卓越性と良い設計への継続的な注意がアジリティを高める。
  10. シンプルさ——やらなくてよい仕事を最大化する技術——が不可欠である。
  11. 自己組織化チームが最良のアーキテクチャ、要求、設計を生み出す。
  12. チームは定期的に振り返り、より効果的になる方法を調整する。

よくある誤解

  • 「アジャイルは計画しない」——誤り。アジャイルは継続的に計画する。
  • 「アジャイルはドキュメントを書かない」——誤り。十分なドキュメントを書く。
  • 「アジャイルは方法論」——アジャイルはマインドセット。Scrumなどがフレームワーク。

重要ポイント

  • アジャイルマニフェストは2001年に17人の実践者により作成された。
  • 4つの価値観は人、動くソフトウェア、協調、適応性を優先する。
  • 12の原則：頻繁に提供、変化を歓迎、持続可能に働く、定期的に振り返る。
  • アジャイルはマインドセットであり、方法論ではない。

次のステップ

レッスン2では、アジャイルとウォーターフォールの比較、それぞれが適切な場面、そしてなぜ転換が起きたかを探ります。

You Missed