软件开发其实就像工兵扫雷

张恂提出的太极敏捷有一个重要观点：

风险管理是软件项目管理的第一管理

与之相关的有一个推论和比喻：

软件开发、软件工程（或者软件项目管理）其实就像工兵扫雷

当心这些家伙，不要让它们成为你的项目杀手！

在软件开发和软件工程中我们一直大量地使用“比喻”、“类比”来阐释概念、说明道理，而这个比喻过去被我们忽视了，国内外大师和专家们好像都鲜有提及，因此我把它提出来。

在软件项目管理中，首先会有一个 scope 的概念，伴随着 scope 有广度和深度的概念。也就是说，软件需求有一个范围，理想的情况是，我们既不要多做，也不要少做，做的内容也正好是客户所需要的，即 just enough。

现在假设给你 1 平方公里（1000 * 1000 米）的地域，部队要从上面通过，下面可能存在着威力不同的地雷、炸弹等各种爆炸物，只要任何一颗具有一定杀伤力的地雷发生爆炸都可能造成人员伤亡，导致任务失败。作为担负重要使命的工兵，你会怎么处理br>
地雷代表了任何可能导致软件工程项目失败的风险，它们具有一些共同的特点，比如隐蔽性，不经过仔细的探查，往往很难被发现，而且一旦没有被排除，在人员没有防备的情况下被触发、引爆，就可能造成较大的损失。典型的地雷包括，客户提出的需求在技术上根本无法实现，或者成本很高，或者会严重拖滞工期，软件设计和代码中存在着严重的质量缺陷 … 等等。我们应该根据各种地雷/炸弹的“杀伤力”进行排序。

在软件开发中，最怕的是 Fail Last/Blast Last，也就是 99% 的地面似乎都检查过了，而最后就剩下那么一丁点儿的地方下面，有那么一颗威力巨大的地雷没被检查到，它偏偏是在部队通过的时候发生爆炸，即便没有导致项目的彻底失败，也会让其遭受严重的挫折。

在经典软件工程教材中，有很多这样的案例。而在过去的 10 多年中，张恂耳闻目睹的国内类似事例也不在少数。

所以，软件工程希望 Fail Early/Blast Early，希望威力大、有杀伤力的地雷都能在项目的早中期能够尽早被发现、引爆和排除掉，让部队能安然顺利通过。在这 1 平方公里的地面下没有地雷当然最好，即便有，也希望它们早点炸，在人们有所防备、对其后果有所控制的情况下发生，以把损失减少到最小。

对付隐蔽地雷的手段

那么，作为担负重要使命的软件工程项目的工兵，我们应该如何快速有效地排雷、扫雷呢

当代软件工程有许多有效的应对和防范风险的举措，T 型开发、迭代开发、用例（Use Case）分析、OOAD*UML 建模等等都是被实践证明行之有效的手段，而它们也是张恂在过去 10 多年来在学习 U3（Use Case、UML、UP）和敏捷迭代开发、敏捷项目管理的过程中所掌握的风险防范技术，这些技术对于我们完成工兵扫雷使命具有哪些好处，下面我打算逐一向大家作个简单的介绍。

T 型开发

我们知道，在用户需求里面埋藏着项目地雷，我们希望尽快、有效地把雷区的范围、分布情况摸查清楚，这就需要广度和深度的结合 —— T 型开发。T 的一横代表广度，T 的一竖代表深度。首先是广度，然后是深度。

不管需求分析还是架构设计，其实都需要 T 型开发，做到广度和深度的结合。

为什么必须要有广度面提到，如果 99% 的地面你都检查过了，没问题，没什么风险，那么万一漏掉的 1% 下面有地雷，而且正好有人从上面走过，怎么办以，理论上应该全部都摸查一遍，至少要大致地扫描一下。

扫雷的时候还必须要有深度，不能光看表面的浮雷、绊雷，必须要拿起扫雷仪对地下几米深的地方进行探测（如果你要过大型装备，比如坦克），而且发现地雷、炸弹之后，还要马上采取措施解除它们的危险，人工切断引信，用扫雷车/坦克引爆或移走地雷等等。这代表着，在软件开发中我们不能光做表面的抽象模型的分析设计（用来探查、发现风险和地雷），还应该编写出实际可执行的架构代码和测试程序，有时候这些代码涉及到很多深度的关键技术细节，只有它们运行和测试通过了才算数（真正地排除了地雷，解决了隐患问题）。

演进式的用例分析

由于软件需求分析是软件项目的上游工作，需求错误就会导致下游的设计、编码和测试工作出现错误和返工，因此需求风险往往是软件项目中最主要的风险。

工兵扫雷这个比喻意味着，我们在做用户需求分析的时候一定要细致和全面。想一想，如果漏掉了关键的需求，可能会有什么后果与扫雷不彻底相当。

Use Case 与传统的特性（Feature）/用户故事等其他简略、简易的需求描述方法相比，有许多优势，最大的差别在于由于用例采用了系统化、结构化的分析技术，它在需求分析的完备性、准确性和精度方面都明显要优于其他方法，因而也能帮助我们更好地发现需求风险。

在用例分析中，我们采用格式模版，除了描述基本流之外，还要分析、探查项目风险地雷常常隐匿之处，包括扩展条件、扩展流、约束、假定等各种意外和特殊情况，以及与用例绑定或公共的非功能需求等等，显然这是一种非常有效的防范需求风险的做法。

遗憾的是，据张恂观察，多年来国内许多本土的软件研发组织和机构在需求分析的细致、全面性方面一直做得不太好，他们所作的需求分析结果，在粒度、精度和准确度等方面常常是不够的，加上传统上软件测试工作在国内也是一个薄弱环节，因而存在着很多的需求漏洞和项目风险/地雷。

当然，在迭代敏捷开发中，用例分析也是通过多次迭代、测试，根据风险优先级，逐步完成的，达到全面、细致的要求，这是演进式的需求分析，与国内许多人所熟知的传统瀑布软件工程的瀑布式需求分析阶段做法有着显著不同，在迭代敏捷开发模式中，我们取消了“需求阶段”或“需求分析阶段”，不再有这样的称谓。

（待续）

相关资源：小兵软件安装程序破解版-其它工具类资源-CSDN文库