这是敏捷开发一千零一问系列的第三十三篇。（在这里提问，之一，之二，之三，问题总目录）
（续前文）
4. 不会满足于现状
对野路子而言，一般不相信“有最好的方法”。其实敏捷也不相信。那么两者有什么区别呢？
野路子相信：反正也没有最好的方法，为什么要费劲不断改进？我们这样的野路子也挺好的啊。
敏捷开发相信：由于没有最好的方法，所以一定还有比现在更好的方法，要不断改进进行寻找。
这里的野路子相信的事情，也是做敏捷开发中最常见的误解之一。两种思想都相信没有最好的方法，听起来都很敏捷，但结果却大相径庭。
如果经常听到有人因为“世界上没有最好的方法，现在这个就不错”，那么多半已经陷入到只顾个体（至少我的情况没有那么糟）或只顾眼前（现在情况还不太糟，以后再说吧）。这也是问题1和2的衍生品。
5. 对技术卓越性的追求不同
技术卓越性体现在很多地方，个人感觉有两点是最重要的，其他的则主要是为了支撑两点。
5.1 在开发过程中，生产率很高
要做到这一点有这么几个细节：
a. 很少生产无用的东西
包括生产完成后客户不用，或客户看了之后发现与实际需要相差很大而进行了改动
b. 很高的复用率
由积木直接搭建整体，节省时间
c. 很高的质量
很多人认为质量与进度（或生产率）不可调和，其实本人的经验是，只有质量高到一定程度，才有生产率可谈。否则时间都花费在测试和改Bug上了。
日后会有一篇文章详细介绍我见过的几个项目的实际情况，以及对质量与进度关系平衡的几个方法。
5.2 在修改和维护过程中，生产率很高
a. 很高的可维护性
可维护性可以细分为很多因素，最基本的包括：简洁的代码，不重复的代码，封装的代码（指只暴露接口），内聚的代码（指有限的功能）等。
有很多人问简洁的代码是否难以读懂。实际上多数商业产品的代码，都可以在几乎不增加单行长度、单行复杂度（变量和运算符）的情况下压缩到现在尺寸的1/5～1/20。这个数字十分惊人，但10年以上开发经验且经历过多个大项目重构的开发人员，可能会立刻点头同意。
b. 很高的可读性
有必要注释的代码，包括自解释的代码，分层的代码，封装的代码等。
c. 很高的质量
质量的影响无处不在，在一个摇摇欲坠的产品上面增加或改变功能，都是一件很费时的事情。
d. 很高的复用率
如果代码像是由对众多已有函数的调用，而非一行一行似曾相识的代码组成的，修改过程会变得相对简单。
把积木推倒重来是一件令人愉悦的事情，而把沙雕推倒重来是个灾难。
我们刚刚花两个月推倒了产品中的一半的功能，但只修改和增加了1/10左右的代码。
对技术卓越性的要求，是敏捷12原则之一。野路子往往重视敏捷中提到的max the undo（尽量能不写就不写）的概念来抵制文档，但很少提及对技术卓越性的追求。
技术卓越性的追求，可以认为是敏捷开发对问题2（长期与短期利益的平衡）的响应。也就是技术卓越虽然未必能加快现在的开发（其实这是个偏见，正确答案是“能”，否则只能说技术还不够卓越），但对未来的修改和维护往往至关重要，否则就难以重构。
上面这些总结，多数在敏捷12原则中都有描述，有些不在，但多数包含在本系列的之一无我（问题1/2/5），之二无住（问题3/4），具体可以在本文第一行的链接中查找。
下面顺便抄一个敏捷12原则，及与文章中提到的5个问题的对应：
问题1/2：
1。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
2。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3。经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
7。工作的软件是首要进度度量标准。
8。敏捷过程提 可持续的开发速度 。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
正如问题1中分析的，敏捷开发的“无我”或“团队”的概念实际上包括了客户、企业。这几个做法其实对客户的益处超过团队。
只有真正做到无我，并把客户受益作为自己能受益的基础之一，才能做到，做好。在非零和博弈中，客户受益和团队受益不会完全矛盾的，这毕竟不是抢劫。
问题3/4：
6。在团队内部，最具有效果并且富有效率的传递信息的方法，就是 面对面的交谈 。
12。每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
问题5：
9。不断地关注优秀的技能和好的设计会增强敏捷能力。
11。最好的构架、需求和设计出自与自组织的团队。
这几个和问题2有交叉。
不在5个问题中的原则，不过，这只是说明它们和“敏捷开发与野路子”无关，或比较牵强。
5。围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
10。简单----使未完成的工作最大化的艺术----是根本的。
