就“敏捷的迷思与真实”一文答读者问

拙作“敏捷的迷思与真实”于《程序员》杂志2005年第7期发表之后，深蒙读者不弃，提出中肯意见良多。今择其上者，略作解答。为避免这位读者的批评意见被有意无意篡改或删除，特此存照，以供对照参考。

拙作原文：“XP 很可能是最为严格的一种 ... 有很多种方法提出“迭代”的理念，但从来没有一种方法把迭代的周期精确到一天 ... 很多方法要求定期 ... 提交源代码，但从来没有一种方法把 checkin/check out 的频率规定到每半小时。”

读者问：这基本上属于胡扯。说 XP “把迭代的周期精确到一天”，确是闻所未闻。 通常我们知道 XP 等敏捷迭代方法（如 UP、Scrum 等）推荐的迭代周期为 1-6 周之间，最小迭代的长度起码为 1 周（5 个工作日）， 迭代的计量通常也以周（weeks）为单位。 1 天的迭代究竟能做些什么，这大概需要比较高的智商才能理解。

举个日常的例子：当我们说“短跑的成绩精确到百分之一秒”，我们并不是指刘翔只用0.01秒就跑完110米，而是说我们可以在0.01秒的精度上度量他的成绩。这位读者指出“ XP 等敏捷迭代方法（如 UP、Scrum 等）推荐的迭代周期为 1-6 周之间”，that's exactly true。那么，对于一个整体长度仅为1周或2周的迭代，用“1天”作为计量单位不是很合理的吗？实际上，我在ThoughtWorks University了解到，某些office的某些项目正在以“quarter a day”为单位来度量迭代。

这位读者同时又说“ 迭代的计量通常也以周（weeks）为单位”，这就让我有些费解：用“1周“为单位度量长度为1周的迭代，那么度量的结果不是就只有0或者100%了吗？这样的度量有何意义，还有待该读者赐教。

读者问： 至于说什么 XP 把检入的频率规定为每半小时，我看也是瞎扯。

大体与前一问题类似。另一个值得一体的重点是：软件开发通常以团队（而非单人）的形式进行，持续集成发生在配置管理的中央服务器（而非各个开发者的本地机器）上。读者可以想象如下情形：一支XP团队由8个pair组成，每个pair每半天check-in一次代码，请问针对持续集成服务器而言check-in的频率是多少？

拙作原文：但有趣的是，很多冠冕堂皇的软件工程方法在涉及到单元测试、集成这类 纯粹工程化的问题时却大而化之语焉不详，导致很多甚至通过了 CMM 5 级的软件企业却连基本的配置管理、集成策略都不具备 ，这不得不说是对“工程”二字的巨大反讽。

读者问：我们的透明大作家 ，你能不能告诉大家“很多甚至通过了 CMM 5 级的软件企业却连基本的配置管理、集成策略都不具备”具体是指国内外的哪些软件企业？……如果你不敢公开或者拿不出有效的证据，那我们只好认为你透明大作家又在瞎掰了。

我相信每位曾经撰写过有一定真实价值的科技论文的理工科学生都知道，出于各种各样的原因，写作者对消息来源有义务保密，对读者有权利保密。因此，对于该读者的合理请求，我的答复是：如果有人将我告上法庭，我会考虑提供消息来源；对于没有司法效力的请求，我只能抱歉恕难从命了。

最后，是我对读者的致歉：由于《程序员》杂志面向专业软件开发者社群，我在行文之前已经假设读者具备一些基本的知识基础，譬如知道“迭代周期”与“度量迭代周期的精度”之间的区别，譬如知道科技论文写作中基本的保密原则。但事实证明，我的这种假设很可能是不恰当的，因此我的文章也很可能对部分读者造成不必要的误导。然而有鉴于《程序员》给我的版面实在有限，因此我暂时还没有找到解决这个困难的办法，因此只好向上述读者诚挚道歉了。