软件方法学的战略性思维

David Stevens在他的著作《战略性思维》一书中，为我们揭示了大型（非）商业项目成功的秘密。其中的要点可以总结为：群体解决问题、价值管理、风险管理、结成战略伙伴和事后分析。现在的软件项目规模越来越大，技术复杂度和管理复杂度越来越高，具备大型（非）商业项目的特点。所以，如果我们用战略性思维的观点来分析软件开发方法学，就会有一些有意思的发现。

群体解决问题

很早以前，人类就认识到群体解决问题是利用人的思想的一种行之有效的方法，而人的思想是人的最大资产。2000多年前，希腊人已意识到挑选一批有经验的人解决某一疑难问题的好处。这批人暂停个人判断，先听取全部观点，经过再三斟酌之后，再对有问题的地方做出最终决定。短语“informative decision”也有这方面的意思，大家先充分了解相关信息，尽量避免在信息不完整的情况下做出决定。而且，在了解到新的信息之后，要对已有的决定进行调整。

项目计划过程是说明群体解决问题的一个好例子。曾经有一个CMM 3级软件公司的SEPG组长和我谈起过计划的困惑：项目经理花了很多时间制定计划（画甘特图），然后每天再花不少的时间来调整计划。关于计划，艾森豪威尔曾有过精辟论述：“计划本身什么都不是，而编制计划的过程就是一切。”我认为，艾森豪威尔所说的过程，是指什么人参与了计划制定，收集分析了哪些信息。上面提到的软件公司，其项目计划的问题在于，它不是群体解决问题的产物，也不是一个“informative decision”。公司历史统计数据或业界平均统计数据只是一方面的信息，根据这些数据来制定计划是不充分的。

敏捷方法学制定计划的过程与传统的计划制定有相当大的差异。敏捷方法专注于团队在较短的时间内，能够交付怎样的客户价值。用Scrum创始人之一Ken Schwaber的话来说，这是“最大可能性的艺术”。因为对未来进行计划（特别是长期计划）所需的信息似乎总是不能完全确定，且处于不断变化之中，敏捷方法学倾向于只对较短时间内的工作（如一个月）进行计划，在这段时间的工作完成之后，再规划下一段时间的工作。按照Kent Beck的比喻，开发软件就像开车，不能设定好方向就一直朝前开，需要不断调整方向。

Scrum会在每个冲刺（Sprint，通常是一个月时间）开始时用一天时间来做计划。在每次计划时，会关注三个问题：
 项目的总体目标是否有变化？
 这个冲刺将取得哪些进展？
 这些进展将提供怎样的投资回报（ROI）？如何证明？

重要的是，这种计划有两个特点：一是短期，二是共同参与。大家会着重讨论接下来的一个月中要做的事情及其意义，并达成共识。这充分体现了群体解决问题的原则，所做的计划也是基于准确而充分的信息。

另外，敏捷方法学还非常注重进行进度监控和报告，让进度可见，并以实现的业务价值作为项目进展的里程碑。Burndown图和特征驱动开发（FDD）的停车场图（Parking Lot Diagram）就是服务于这一目的的。围绕计划执行的过程同样也很重要。

团队是另一个说明群体解决问题的好例子。敏捷方法学强调自组织团队，即团队中的每个人都认同团队的使命，并愿意为这个使命主动贡献出自己的智慧和力量。团队的每一个成员都是团队目标的管理者。在Scrum的每日会议上，每个人都会向其他团队成员说明自己遇到的困难，寻求帮助。从团队作为一个有机整体的观点来看，只有当个人对团队目标的实现做出贡献时，个人才有价值。

FDD在业务整体建模阶段，会有一个业务架构师团队，与领域专家一起，设计系统的整体业务模型。这同样是一个信息充分的群体解决问题的过程。

XP的实践是全体拥有代码，而FDD的实践是每个类有特定的代码拥有者。在这两种完全相反的实践背后，不变的是群体解决问题的原则。

项目进行过程中需要设计一些机制，让每个利益相关人的观点得到充分沟通和尊重。中学时学过的“邹忌讽齐王纳谏”告诉我们，广开言路，就能够“战胜于朝庭”。

价值管理

人们因所处位置不同，出发点不同，所以价值观也不同。在坚持自己价值观的同时，要尊重他人的价值观。我们需要依据群体解决问题的原则，对软件项目的价值进行动态管理。

客户（业务人员）价值是首先要关注的价值。客户需要利用要开发的软件来帮助他们的工作，软件需要能够减少他们的工作量、降低他们的工作强度、提高他们的工作效率。敏捷方法学总是很强调客户价值的实现。

笼统一点来说，项目出资人也可以算在客户之内。出资人关注的是投资回报。从投资回报的角度来分析，假设投入的成本一样，10个月之后交付10项价值的投资回报，比不上10个月中每个月交付1项价值的投资回报。敏捷方法学的“早交付、常交付”正好符合这方面的要求。

开发人员希望工作轻松并且高效。开发人员不希望遇到有二义性的需求。开发人员希望在遇到困难时获得团队成员的帮助。开发人员希望在项目中学到知识，为将来的工作积累经验。方法学中“有活力的工作”、“在现场的客户”、“每日开发会议”、“结对编程”等实践，都是尊重这些价值的表现。

测试人员不希望在项目后期，承受着很大的进度压力加班工作。测试人员不希望像机器一样每天做重复的工作。敏捷方法学的“早交付、常交付”和持续集成让测试人员不用在项目后期加班。自动化的测试工具和测试脚本大大减轻了测试人员的工作量，提高了他们的工作效率。
虽然有开发者测试，敏捷方法学并不排斥独立的测试小组。开发小组和测试小组有更密切的合作和更好的互动。

运维人员希望软件易于运营、维护和升级。“编码规范”、“重构”等实践关注代码品质，反映了运维人员的价值。

软件需求管理是价值管理的重要体现，我们可以在软件需求规格说明书中检查各类人员的价值是否得到了反映。例如，每项需求是否包含了验收标准（客户价值、开发人员价值和测试人员价值）。又如，是否包含了降低运维成本方面的需求。

由于我们已知的信息处于不断变化之中，所以价值管理是一个动态的过程,是遵循群体解决问题原则的。Scrum允许产品所者有（客户）在每个冲刺的计划会议上重新调整需求及其优先级，这是对客户和开发者价值的尊重：既允许客户调整开发需求，又让开发者在相当长的一段时间内不受打扰地进行开发。

总之，开发方法学中的每项实践都是对一些利益相关人的价值的考虑。当我们未采用这些实践时，应该考虑是否有一些替代实践关注了相应的价值，还是我们根本忽略了那方面的价值。

风险管理

软件开发是一项风险事业。确定了要实现的价值之后，必须依据群体解决问题的原则，对项目风险进行管理，因为这些风险可能会妨碍团队实现前面提到的种种价值。

Edward Yourdon曾把那些明显会失败的项目比喻为“死亡行进（Death March）”。这种项目的特征很明显：项目的进度计划、预算和人手只有所需的一半。计划的特征集是不切实际的。大家每天工作14个小时，每周工作6天或7天，压力造成了重大损失。这种项目失败的风险很高，但管理层却视而不见，不采取任何行动来改变这种状况。

船会沉掉，老鼠先知道，船长较晚知道。当项目出现这种或那种风险时，总是有人会在很早的时候就察觉到。如果团队在这时候就关注这些风险，执行一些缓解方案，准备应急预案，就能有效地预防这些风险变成灾难。你不知道的东西对你的伤害最大。

实际上风险不是坏事，因为风险往往和回报是正相关的。如果我们能够控制好风险，就能得到相应的回报。设想我们只用一半的时间、预算和人手就完成了项目，那岂不是很妙？软件开发是“最大可能性的艺术”，我们要做的就是对种种可能性给予充分的关注，其中就包括各种风险的可能性。

由于情况处于不断变化之中，所以我们需要某种机制来动态地维护风险列表。在Scrum中，每日开发会议就是报告风险的好时候。每个团队成员每天都有机会报告自己遇到的困难或发现的风险，提交给整个团队共同考虑并寻求解决方法。

不例外，风险管理也遵循群体解决问题的原则。群体报告风险；群体监控风险；群体寻找风险缓解方案，或准备风险预案。

结成战略伙伴

合作共赢是人生主旋律。《高效能人士的七个习惯》中的三个习惯（知已解彼、双赢思维、统合综效）直接与结成战略伙伴有关。敏捷宣言说，协作的价值超过合同规定。

相识是缘，能共同参加一个项目更是缘。业务人员、开发人员、测试人员和运维人员是战略伙伴，人们通过支持伙伴实现其价值来实现自身的价值。在自组织、自管理的敏捷开发项目中，我们常常看到不同职能人员之间有更密切的协作。

开发商应与供应商、客户结成战略伙伴。大家是同一价值链上的不同环节，如果能够协同作战，一定能够降低交易成本，创造更大的价值。

甚至竞争对手也是战略伙伴。伟大的成就源自于强大的对手。在20世纪70年代末，当施乐公司遭遇佳能、NEC等日本公司的竞争挑战时，发起了向竞争对手学习的“竞争标杆管理方法”，从而重新建立竞争优势，夺回市场份额。福特公司也曾向马自达学习，实现了业务过程再造。竞争是合作的一种形式，而不是合作的对立面。

一旦合作各方能在结成战略伙伴这一点上达成共识，各方的价值能得到统一，合作的效果就会让人惊讶。

事后分析

事后分析和自省可能是最重要的一项实践。所有实践一律平等，但有些实践更平等。在事后分析时，我们探讨做对了什么，哪些方面还做得不够，是否还有一些其他可选方案能够尝试。如果您刚好会下围棋，那么马上就能发现对应的实践：复盘。

在事后分析时，我们可以采用约束理论（ToC）作为指导。首先，我们明确目标。其次，我们识别出妨碍实现目标的主要瓶颈。最后，我们改进瓶颈，并在未来不断重复这个三个过程，持续改进。

《学习的革命》中说，如果你只想学一个日文单词，那就应该是“Kaizen”，它意思就是持续改进。

事后分析同样需要在群体解决问题原则指导下进行。和围棋复盘的比喻对照一下就可以知道，哪些人可以参与事后分析。第一是项目当事人。第二是水平j明显高于项目当事人的专家。第三是和项目当事人水平差不多，对项目有兴趣的非项目人员。

没有最好，只有更好。软件开发是可能性的艺术，而这种可能性没有极限。这正是软件开发的魅力所在。