三个危险滑坡

Slippery slope是一个美式常用的俚语，打滑的斜坡，代表会越来越糟。许多朋友在学习5000A/CMMI的时候，看着一个个PA，一条条实践，在字面上打圈，貌似明白了其实没真的懂。每当朋友问关于某个具体实践问题时，我都会提醒他想想这条实践的目的，希望规避的问题和场景。这也是2.0出现频率最高的词——Intent，想表达的意思。换句话说，我们在学习模型PA时，必须琢磨一下它们想避免的Slippery slope是什么？

Slippery slope的定义

Rierson在其DO-178C书里提了3个常见的slippery slopes, 进度压力往往是走向湿滑斜坡的诱因。这些实践在国内软件公司具有一定普遍性，我觉得有必要聊聊它们带来的潜在危害。也许再看CMMI2.0的RDM（1.3和5000A的REQM+RD）和TS时，你会有“原来如此”的感慨。

Slippery slope 1：过早开始设计

工程师是解决问题的，软件工程师也不例外。接到一个任务，他们恨不得第一时间就能找到解决问题的办法，也就是设计工作。当然进度压力往往会让他们在没有完全梳理清楚到底要开发什么时就开始着手设计。这样的做法的风险是显而易见的。充分理解复杂软件项目意味着平衡各种约束(trade-offs),只有做了充分的需求分析后，我们才能做到这一点。

过早设计会带来两个危害：一是不合理的架构和解决方案，给系统埋下了长期隐患。二是后期的大量返工。有人曾在通信领域做过调查，需求投入低于8%的项目所花总时间大大高于在需求投入超过15%的项目，真可谓欲速则不达！

  需求和设计在过程和组织上的分离是常见避免这个问题的做法，做好了RDM中的实践，会让我们远离这个危险的滑坡。

敏捷设计法则 （点击阅读原文）

Slippery slope 2：仅有一层需求 （one level of requirement）

多年前在一家著名军工所做诊断时，看到的所有项目的需求都只有一层描述。顿时明白为什么新工程师需要两三年时间才能独立开展工作，因为真正看懂这些需求，做好开发或测试工作太难了。CMMI和5000A没有明确建议两层需求，但其实践要求往往需要我们跳出单层需求分析。

  DO-178C明确要求两层需求：high-level requirement和low-level requirement。 我很认同这个要求，因为将其合二为一的项目往往让模糊前期持续到项目后期，导致各种问题。如后期测试很难做到结构覆盖（structure coverage），这是高级别安全软件（如航空软件）的验证要求。就是敏捷实践也要求多层次的需求澄清、分析，如Epic和User story就可以认为是简单的2层需求。那本被我自己提了无数遍的非畅销书“知行合一：价值驱动的敏捷和精益开发”一书中提到的敏捷四级产品计划，就对应了不同层次的需求及其细化。

软件本质、敏捷、CMMI、精益 —— 知行合一

Slippery slope 3：一上来就编程

开发团队在仅看到了部分需求就开始编码的现象几乎是行业通行做法，不合理的进度要求逼着团队别无选择。这样走捷径会背上极重的质量、技术债务，其实得不偿失。大家心知肚明，只不过还是会选择规避眼前的短痛再说。让我再以站着说话不腰疼的姿态，捧着良心规劝一下吧。

  在这种情况下写的代码不会有深思熟虑的算法，代码往往遵循的是brute-force（好听点叫简单匹配算法，难听些叫蛮力算法）的套路，这样的代码不可能是合理安全的，也很难保障和最终需求全面一致性，比如，会遗漏一些异常情况处理功能等。

这样的代码可读性极差，大大增加了后期维护成本。一旦需要有较大的升级，团队成员需要花巨大的投入做逆向工程，去理解最初的设计思路和可能的遗漏需求。

  这些开发过程中的危险滑坡是完全可以避免的，这不是技术问题，而是选择问题。如果我们清楚走向滑坡的后果，那么就选康庄大道前行吧！指出了远离危险滑坡的方法，才是5000A/CMMI的真正价值所在。