The Manifesto of the Agile Alliance
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value.
l Individuals and interaction over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- That is, while there is value in the items on the right, we value the items on the left more.
敏捷强调以人为本，发挥人的主观能动性。经常有这种场景，我们在一个项目上走了弯路，为了吸取经验教训，防止再走弯路，我们就创造了process来规范我们的活动。我们希望这样可以避免之前的失败。However, projects are not so simple that a few documents and artifacts can reliably prevent error. 当错误再次发生时，我们创建更多的流程来进行规范，结果就是流程越来越多，大家不堪重负，极大的限制了大家能力的发挥。
Individual and interaction over process and tools.
A strong player is not necessarily an ace. A Strong player maybe an average programmer, but someone who works well with others. Don’t assume that bigger and better tools will automatically help you do better. Remember, building the team is more important than building the environment.
好的组员不一定是高手，而是能与全组合作的组员。记住，团队建设比环境建设重要。工具是必要条件，不是充分条件。工具的确可以大幅提高工作效率，而且优秀的程序员一定是工具高手，而且会自己开发实用的工具，好的团队在发展过程中也会开发或获取自己实用的工具。但不要有工具情结，如果你做某件事情的原因是因为可以使用某个工具，就要注意了。
Working software over comprehensive documents.
文档是必须的，但文档太多比文档太少更可怕。It’s always a good idea for the team to write and maintain a rationale and structure document, but that document needs to be short and salient. 文档应该精简，20~30页足矣，文档应该介绍基本的设计思想，系统的high level structure.
没有足够详细的文档，如何培训新员工？答案是human to human. The two documents that are the best at transferring information to new team members are the code and the team. Code是唯一没有歧义的文档，团队成员熟悉系统的整个变迁过程，面对面交流是最高效的传输方式。
Martin’s first law of documentation: Produce no document unless its need is immediate and significant.
如果你的代码做到了自注释，写文档就没必要了；如果没有做到，对不起，文档还是必要的。
Customer collaboration over contract negotiation.
这一条没啥说的，敏捷注意人与人之间的互动交流，与客户的交流也一样，不应该仅仅限于合同，多于用户交流也容易培养开发人员从用户角度思考问题的习惯
Responding to change over following a plan.
首先，需求变更是无法避免的。1）The business environment is likely to change; 2) customers are likely to alter the requirement once they see the system start to function; 3) we are not very good at estimating how long it will take to develop them. 既然无法避免，我们能做的就是接受变化。
对于新手软件经理，制定一份详细的Gantt chart，往往觉得是一件了不起的事情，甚至为之着迷，同时也天真的认为通过这份计划可以控制软件开发进度。
实际情况呢！随着开发人员技能和知识的增长，随着客户对自身需求的进一步认为，有些任务是不需要的，有些任务则被挖掘出来，原来的chart会变得面貌全非。
解决方案：A better planning strategy is to make detailed plans for the next two weeks, very rough plans for the next three months, and extremely crude plans beyond that.
敏捷原则：
- 通过尽可能早和持续的发布有价值的软件来满足客户需求是我们的最高优先级任务
- 即使在开发晚期，仍然欢迎需求变更。Agile processes harness change for the customer’s competitive advantage. 利用变更来提高客户的竞争力。They view changes to be the requirements as good things, because those changes mean that the team has learned more about what it will take to satisfy the market. An agile team works very hard to keep the structure of tis software flexible so that when requirements change, the impact to the system is minimal. 通过提供软件架构的可扩展性来降低需求变化对系统的冲击
- 周期性的发布可以工作的软件
- 项目期间，客户和开发人员应该在一起工作
- 人是最重要的，消除环境、流程等对人员产生障碍的因素，给与开发人员充分的信任
- 团队内部最有效的传递信息方式是面对面交流
- 可以工作的软件是开发过程中最主要的财富。Agile projects measure their progress by measuring the amount of software that is currently meeting the customer’s need.
- 提倡以一种平稳的节奏进行开发。敏捷项目不是跑百米，是马拉松。
- 不容忍坏味的产生，持续关注代码的质量和整洁
- 不做过度设计，保持简洁
- 最好的架构、需求和设计来自于自组织的团队。团队共同决定如何承担责任，团队中每个成员都可以，且有责任承担各个部分的工作，包括架构、设计、编码和测试。
- 团队定期反馈如何进一步提高效率，然后相应的调整自身的行为