精彩的敏捷开发建议
网络上流传了很多关于敏捷开发的具体建议，加起来可能超过上百条，有些内容很精彩，而有些说法比较片面，值得商榷。收集和整理这些至理名言是我的一项工作。
这些建议的分析和评论，供大家参考、拍砖。
* 完整地做完第一件事后再开始第二件。软件开发的一个大问题就是同时做几件事情，这将不可避免地使得某些工作被废弃从而造成浪费。用厨房来比喻就是：“先上这道菜，再开始烧下一个。”
不一定。并行工作还是必要的，但是要有限度。
* 不要害怕做决定；不要害怕改变先前的决定。最大可能地延迟决策，直到必须做决定的时候。一旦有新的信息了，不要害怕改变先前的决定。
不错，这是敏捷精神所在。
* 度量、度量、度量。敏捷开发帮助处理了未来不确定性的问题。但是对于过去，应该没有不确定的事。
说得非常好！
想一想 NBA 梦之队的实时技术统计，就可以知道度量的最高境界了。
* 设计是为了人，而不是系统。太多的程序员偏离了设计的目的，而更关注技术本身。软件最终的成功取决于让人们有效合作并增加商业价值。
说得太好了！
提供业务价值的业务建模绝对重要。
* 过早地进行优化是万恶之源。仅仅基于对代码的静态理解就直觉地判断什么对整体性能最为重要，结论几乎总是错误的。相反，应该衡量整个系统的行为，随后来识别性能问题。
很好的建议！
* 决不过度强调功能的通用性。这也就是著名的“YAGNI——你不会需要它的（You Aren’t Going to Need It）。”
对！
* 不要用代码行数来度量代码。完成特定任务所需的代码行数，不同的程序员之间和编码风格之间差异很大。应该去统计功能用例的数目。
绝对正确！
* 软件是可塑的。不像实体制造业，软件可以很容易地获得显著改变。
不全对，虽然是很容易，但可能也是高成本的。
* 不要去发明新的语言。XML的出现引领了无休止的专门订制“脚本语言”的潮流，想来应该会让软件开发更加趋同。这种推理的缺陷在于，离开某个特定实施的环境，几乎从来都没能很好地精确定义操作行为。
片面。可以去发明新的语言，比如 DSL。
