完美软件开发：变化永恒

软件是一种固化的思维→思维必然受到客观世界种种变化的影响，其自身也必然是不断变化的→需求开发自身乃至后续环节需要是容易应对变化的，即应对变化的成本要低。

从纯粹的技术人员的视角看，客户往往是“可恨”的。因为他们话说不清楚，并且说话不算数。但事实是这世上确实没有不变的需求，客户对此有一定程度的影响，但需求变更往往却并不是客户所能左右的。这也就反过来要求需求开发必然是能够适应变化的需求开发，设计编码等也要是能够适应变化的设计、编码。

在6.2.3节中我们曾经提到，需求开发自身不能无限制地做下去，要适可而止。但实际上，变化发生与此时需求开发停留在什么样的层次上无关。这种变化往往是全方位，多层次的。

比如说，我们在为特定浏览器开发Web页生成程序时，即使进行需求开发，也未必会注意到<p>和<ul>不能组合使用。但在原型出来后，这类需求则会被不断发现。

需求变化自身的特质对软件开发各个环节的冲击非常的大，我们来做点具体分析。

●已知的需求量越大、需求间关联性越强、需求自身的确定性越强、对应时间越长，越可以按部就班地开发软件。比如说，开发项目管理系统时，预先可能收集到了50页的原始需求，那么就可以针对这些需求写出比较详细的规格说明书、估算、做计划、写设计文档而后编码。测试的时候也可以设计比较全的Case对需求进行完整覆盖。

●需求碎片化越严重、对应期间越短，软件开发相关环节浓缩得越厉害，也就越需要敏捷式方法。比如说，项目管理系统发布后，用户可能提出了很多小的需求，这些需求间彼此并没有什么关联，散布在既有系统的各个模块之上，并且希望能够快速对应。这个时候，就很难给每个需求写规格说明、每个需求写设计文档。Release次数增加的同时，回归时候如何提高覆盖率也会变得比较困难。

上述两类情形事实上形成一种约束，开发方法等要在这种约束下改变自身，我们来看两个简单的例子。

●当我们谈及软件开发时，我们总会遇到很多争论，是不是需要单元测试、是不是需要CMMI，是不是用敏捷等，但事实上这些都是尺度问题，一旦脱离具体约束来考虑尺度问题往往是没有具体答案的。

比如说，当我们使用测试驱动开发的时候，一定是要付出代价的。试想一下，测试开发下，维护一份同步更新的测试代码怎么可能没有代价。关键是这种代价是否产生了足够的收益，而不是这种方法是否有收益。而需求是否碎片化严重，是否变化频度很多则是项目所需要面对的众多约束中极为关键的一个。

就上述情形而论，如果一个程序在可预见的生命周期内，其需求碎片化并不严重，那么维护一份完整的测试代码无疑收益较小，可能得不偿失，而一旦其需求碎片化程度非常严重，又需要频繁发布，那么缺乏完整的可自动回归的测试用例，就是致命的。(www.xing528.com)

●以需求开发自身而言，面对频繁变化时，有两个目标需要同时达成：一是产品究竟要做成什么样子要有清晰的概念，不能乱（概念完整性）；二是小的需求本身不能产生错漏。

从形式上来讲，体现概念完整性需要完整的文档来记述需求（RUP等都提供了需求规格说明书的文档模板），这类文档可以是Word或者Excel格式。但持续发生的小需求则使产品自身的概念片段化、凌乱化。从形式上来看，为追踪这类小需求（分析、实现、测试等环节），需要使用Web系统分别进行跟踪。同时需求文档大多时候是有一种层次结构的，但零散小需求却肯定不会按照文档的层次结构发生，把他们集成到文档里，一定程度上会破坏现有文档的层次结构。这就使需求有分化的趋势，项目组必须决定是以文档为准，还是以Web跟踪系统为准。

为使需求开发能够适应上述所说种种变化，那么至少有两个维度上的事情需要考虑。

（1）从组织形态来看，如果产品概念维护在多个人手中，那么是不利于应对变化的。

这就是《人月神话》中，经常提到的概念完整性。当这种完整性被破坏的比较彻底时，一旦变化发生，事实上没人知道这种变化对产品会产生怎么样的冲击。

（2）从文档化的角度看，如果文档自身过于厚重，那么是不利于应对变化的。

●比较常见的一个容易变的厚重的文档被称做机能规格说明书（Functional Specification）或者叫需求规格说明书（Requirement Specification）。这类文档的写法并不相同，常见的形式大概有两种：以UI为文档结构的基础，或者以用例为文档结构的基础。

●总体上来看是，如果文档细致程度不当是不利于应对变化的。其原因是，一个软件只应该对应一份文档，而在频繁变化下，上述这类文档无法应对。如果同时维护这份文档和Web系统中的Ticket信息，那么需求信息就需要同步，同时由于Ticket系统会成为日用平台，这类文档必然会被边缘化。如果不维护，那么以此为根基的测试和实现又不好组织。

●缓解的方法是，以文档为基线，一旦到达某类Milestone后则停止这类文档的更新，转以Ticket系统为主，如果需要在项目结束后统一更新。这也会导致不一致性问题，但程度会轻。

●以改善方向而论，似乎可以把整个需求的描述都搬到Web上，并构建一种层次关系。比如，一个UseCase和后续各种变化的层次关系。但很遗憾，就笔者自身而言，还没看到相应的工具和实践。