OOPAA

跟同事聊天，他原先是在一著名手机厂商研发中心工作，主要是做该厂商手持终端设备上的系统软件，于是自然聊到“摩托，也要骡拉”上来。近几年该厂的发展很不景气，好几年也没见一款拿得出手的手机，在中国的市场占有率从前三降到排名之外，连在国贸的冠名大厦都卖掉了。同事说起来也是颇多无奈，讲述了他看到的情况。

据他观察，该公司内部是出现了这个几个问题：
1. 基础平台不稳定，大量功能被任意加到平台里面，导致越来越复杂，后期维护扩展完全不可能
2. 产品设计部的设计到产品研发，中间经历太长时间，不能响应市场需求
3. 产品研发到最后才发现功能缺陷或者性能缺陷，最后只能 cancel

这些问题的产生原因相信见仁见智。撇开管理层和多部门间合作的问题，个人觉得这是传统软件开发模式下出现的典型问题，特别是基于瀑布模式的软件开发。不能很快地响应变化，前期环节很难得到后面环节的反馈。由于开发模型是线性的，只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。这样就会导致很多启动初期信心满满都看好的项目最后只能前赴后继地陷入“焦泥坑”。实际过程中会加入更多的开发人员，使用更多的先进开发工具试图解决问题，但对于开发问题的解决，这些都是作用不大的，甚至是帮倒忙的。Brooks' law 告诉我们，“Adding manpower to a late software project makes it later.”

“开发过程中变数太多了！”同事感慨到，于是又说到敏捷方法的拥抱变化。其实敏捷何尝能减少变化。软件开发的过程就是将问题域映射到软件系统，然后提供软件层面的解决方案。这里面天然存在两个“再创造”的过程：问题域的分析建模，软件的实现运行。任何一个环节的复杂性都会被放大累积进整个过程的复杂性，那么有没有一劳永逸的办法来解决这两个问题？同样是 Fred Brooks 告诉我们 “there is no Silver Bullet.”

软件开发的复杂性可以分为两种：本质复杂性和附加复杂性。其中附加复杂性包括人的复杂、工具技术的复杂，外部的复杂等。这些附加复杂性都是希望被限制到最小限度，可能造成的影响被限制在最小范围内。这也是各种软件开发方法试图解决的主要问题。至于本质复杂性，主要是问题域本身的业务复杂，这是社会、组织，甚至各种因素造成的不可逃避的问题，是任何软件方法都不可能抹掉的。因此，如何减少附加复杂性，尽可能解决本质复杂性，就是软件开发方法的使命，也是判断软件方法是否有效的唯一标准。可悲的是，传统的软件开发大多是着眼于通过增加附加复杂性来解决本质复杂性，或者通过文档、或者通过层层审批、或者通过freeze code base等等，但最后都被证明是刻舟求剑、缘木求鱼。

与传统方法不同，敏捷方法就是试图解决软件开发过程中的附加复杂性，把对解决本质复杂性的关注重新放到舞台的中央，并提供应对本质复杂性的足够可能。对于解决附加复杂性，敏捷宣言有“可工作的软件胜于详尽冗繁的文档”，也有很多相关的实践来保持对附加复杂性的不侵入，就不赘述了。那么敏捷是如何拥抱本质复杂性呢？那就是保持简单和客户 involved。

简单，于是可以足够轻量来调整原来的实现；简单，于是团队内部容易达到领域知识共享；简单，于是开发过程透明性大大增强......这一切的结果都指向“响应变化”。user case 简单了，就很容易来进行确认，包括前期和客户的需求确认，也包括后期开发结果的确认。代码简单了，就很容易进行重构，增进设计，逐步兼容添加问题域中的复杂性。开发计划简单了，现在不用关心几个月后的事情，只需要关注到下一个迭代和当前 release 涉及的需求。“简约，而不简单”，大家都轻松了，有时间培养自己的业余兴趣了。

这是从开发团队的角度来看到响应变化。客户 involved 就使得这些变化能被客户感知和认同，让客户尽可能主动思考现实问题域中的复杂性是否有改进的地方，规避了可能的风险，也有利于培养出长期积极的合作关系。这是一个很良性的互动过程，也是一个逐步走向双赢的过程。这也是项目管理层和公司决策层会喜欢看到的结果。

“这些都很美好，但执行起来还得看人”，同事又抛出了这样的论点。我默然，世界上最复杂的莫过于人了。不管方法理论上多么完美，实践起来多么容易，只有真正有合适的人，让合适的人去做合适的事，才能不致于明珠暗投，徒然神伤了。呜呼