阅读《敏捷软件开发（Agile Software Development——The Cooperative Game）》

        前两天在《程序员》这本杂志上看到一篇讲敏捷开发中的需求分析的文章。仔细看了一下，似乎略有所悟。自己理解它的意思主要是：需求文档要尽可能简略、尽可能用故事来说明。这和我之前所在通过CMMI4的公司的软件工程中所作的不太一样。在那里，我们尽可能详细编撰需求文档、概要设计文档、详细设计文档以及单元测试案例。以便于在各个关键里程碑将产出物提交给评审委员会或项目管理委员会。如果按照我所理解到的敏捷开发思想，我们在里程碑时刻没有完整和正式的产出物。这不是不符合CMMI的要求吗？仔细阅读该文得知，敏捷开发的指导原则是为了应付频繁的需求变更，用多重迭代来应付软件开发过程中的所有变化。这种思想天然的适应开发的变化以及系统的扩展性。因为，之前没有什么东西是确定和定死的。任何东西都可变。这于传统软件管理的变更控制是相反的方向。传统的软件管理，将变化看作是质量管理的大忌，是需要严格控制的；而敏捷则将之视为自然的，可随时发生的。从我的理解来讲，应该是各有各的道理吧。严格控制是为了避免系统结构大的变化，而变化是无法避免的。只不过需要在两者之间找到一个合适的平衡点。

        不过敏捷的思想还是给了我一些思维火花。之前我所听到和理解的敏捷，只是关于结对编程、测试驱动开发等片面的东西。现在发现，它远远不是我之前所了解的那样。于是，正好课室的书籍中有这本书，我就借过来阅读了。目前刚好读完第一章。感觉这一章讲了很多自己理解不了的东西，但我只了解了它所要表达的意思：沟通总是不完美的。所谓的沟通，其实就是想办法在两个具有完全不同经验的人之间建立经验的相似性，使其产生共鸣。

        其他的深入理解等我阅读更多后再总结。