不久前发了一篇关于敏捷宣言的翻译及理解，详情参见http://www.cnblogs.com/codingcrazy/archive/2010/12/02/1894010.html#1975500。
对于最后三条宣言的内容，我们收到了很多关注和意见，其中包括邹欣老师和余晟老师的非常好的建议。结合之前我们的理解以及专家给出的意见，我们对原先的内容进行了加深理解和修正，下面是新的版本：
Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential.
翻译：精简——将未竟之工作量尽可能减少的技能——是极为重要的
除去中间的插入语，剩下的部分就是很直接的“Simplicity is essential.”，具体翻译来说就是“精简极为重要”。细想之下，发现这个原则在软件开发中却是很有道理。于是乎，我想到了一个关于效率efficiency的基础原则：KISS Principle—Keep it Simple, Stupid.这是一个很关键的概念，但是很多人都总是忽略遗忘它。不要给自己添加额外的工作，要找到针对某个问题的最简单的解决方法。Work smarter, not harder. 就我个人看来，在很多事情上可以去做到维持工作最简化。首先就是使用类型和模板，知道什么样的模板是可用的可以为我们节省很多时间；其次，尽量写简短简单的模块化的东西，用概念，任务和引用来组合不同的内容。把要实现的任务分成小块，就能够很容易地完成添加、删除和重构；尽量避免使用那些很复杂的分支和过程，否则不仅是用户，大概连构建者本人都会觉得很混乱吧；最后就是我觉得最重要的做到“maximize the amount of work not done”的方法就是不要包含任何用户并不需要的信息在你的工程里，要始终把他们的需求和任务记在脑海。否则，即使你实现了这样那样酷炫的功能，对用户而言没有任何吸引力，不是偷鸡不成蚀把米么？所以，我们要尽可能地减少工作量，不但对于我们本身，甚至于用户而言也是有利无害的。
Principle 11：The best architectures, requirements, and designs emerge from self-organizing teams.
翻译：最优秀的架构，最明确的需求和最杰出的设计的源头活水是能有效自我组织的团队
团队合作的有效性和活力是一切开发工作的基础。然而，有效合作的团队并不是想当然的，首先团队的组建就需要仔细考虑，宁缺勿滥应该是比较好的准则吧，毕竟这里面如果来了南郭先生就不像乐队一样听不出来了，这种潜在的矛盾源（请允许我这样说吧）必须扼杀在萌芽阶段，恩。另外，团队有效的自我组织能力还来源于成员们的默契，互相尊重，以及互相的了解。所以，项目中大家适量地出去玩，胡侃，腐败等是必须而且需要注意利用的哦。
Principle 12：At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
翻译：团队内部应定期反思如何提高效率，并据此来修正及优化自身的行为。
定期的审查可以使成员对当前的团队状态达成统一认识，这样才能更好地制定下一步计划。可能有人会说不是敏捷开发吗？不是应该刷刷刷开到极致（extreme-programming)，赶紧开发完就行了嘛。然而就像你要独自去一个陌生的地方，说一帆风顺永远都是安慰话~开发中不可避免的会遇到困难，进而导致与计划的不一致，团队成员间进度的不一致，理解的不一致等。定期进行集体的交流，探讨做的不好的地方，是什么原因，应该怎么弥补修正，然后吸取经验教训继续前行。也让整个团队的成员达成一致，互相有交流的基础。所谓心有灵犀一点通，在团队的级别上要达到这一点不可避免要通过一些有组织的“争论”、“思考”。每个成员都应该在思考的过程中争取把问题暴露出来，并坦诚接受有益的改变和建议，这样自己才能做得更好，从而团队才能表现得更好。
