理解敏捷开发准则

传说中在2001年2月的某一天，17位搞软件开发的老大哥们在一个叫Snowbird的有雪有鸟的胜地开会，自然，他们只能讨论软件，大概是觉得整天写文档太烦了，他们憧憬未来的轻量级开发方法，工程师都是实干型的，他们立即起草了《敏捷宣言》来表达他们的想法，宣布他们对以前开发方法的不满，并组建了敏捷联盟，从此一发不可收拾。他们提出的Twelve Principles of Agile Software引发了后来对于软件开发的很多争论与思考。

以下是对他们提出的12条敏捷开发准则的最后3条的理解：

 

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)，赶紧开发完就行了嘛。然而就像你要独自去一个陌生的地方，说一帆风顺永远都是安慰话~开发中不可避免的会遇到困难，进而导致与计划的不一致，团队成员间进度的不一致，理解的不一致等。定期进行集体的交流，探讨做的不好的地方，是什么原因，应该怎么弥补修正，然后吸取经验教训继续前行。也让整个团队的成员达成一致，互相有交流的基础。所谓心有灵犀一点通，在团队的级别上要达到这一点不可避免要通过一些有组织的“争论”、“思考”。每个成员都应该在思考的过程中争取把问题暴露出来，并坦诚接受有益的改变和建议，这样自己才能做得更好，从而团队才能表现得更好。

 

理解难免有不当的地方，请指出，期待与你交流^^