敏捷开发12原则新理解
五年前在学校的时候被要求翻译这12条原则。当时干活基本一个人搞定一切。所以没法理解这些原则们。现在参加工作几年后有点见恨晚的感觉。。。分享给刚工作的同学们~
1: Our highest priority is to satisfy the customer 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 for 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: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
面对面的交谈才能感受到用户的真实需求。通过不断的交互才能让抽象的需求具体化。
文字经常造成误解，导致不必要开发。
7: Working software is the primary measure of progress.
能用的软件是最主要的进度衡量标准。
很多问题描述起来很费事，也很难说清楚。
淘出手机，打开网站，对着现有的功能说哪个功能有问题，需要在哪个网页加哪个功能。能消除一大波误会。
这要求我们有一直有一个能用的软件。
8: Agile processes promote sustainable development. 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.
**保持简明，尽可能简化工作量的技艺，极为重要 **
过度设计是很多开发人员的通病。明确业务人员的需求。一个月太久，没准这个功能下周就下线。
也不要太关注性能问题。因为项目中只有20%的代码才影响性能。
所以，简明，才是我们写代码时最需要考虑的。
简单，即只实现现在需要的功能。用最简单的方法实现。用最少的改动来实现功能。
明了，即代码很好诠释了你要做的事情。
11: The best architectures, requirements, and designs emerge from self-organizing teams.
只有能自我管理的团队才能创造优秀的架构, 需求和设计.
不要想着应付老板的任务，也不要盼着高人来指点。努力自己去完成这些。只有这样，才能不断成长。也只有这样干活才有成就感，不累。
这也要求自己有一颗上进心，不断追求美好的事情。
12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
团队定时总结如何提高效率, 并付诸行动。
提高工作效率是员工和公司双赢的事情，只不过需要挤出一些时间。
