|
武学当中有句话，“一寸长一寸强，一寸短一寸险”。真正的高手，并不在乎兵器的长短，只要运用得好，一样可以战胜敌人。 需求文档也是这样。 传统的软件开发，要求使用需求规格说明作为需求文档；敏捷软件开发，则使用产品需求列表（一般会以故事卡片作为辅助）作为需求文档。需求规格说明一般写得都很详细，文字加图表，洋洋千万字，动辄几百页；产品需求列表则比较简单，每个故事点只用很简略的文字描述。 你能说作为需求文档，需求规格说明就比产品需求列表更合适吗？ 当然不能。 产品需求列表虽然简略，但它有故事卡片作为辅助，有客户代表现场交流，有快速迭代的需求确认，它不会因为其简略就会影响开发进程；需求规格说明虽然详细，但它的形成需要花费更多的时间，而且也不能保证之后的开发过程当中就不会发生需求变更。 实际的项目当中，很多的软件需求规格说明书甚至没有起到产品需求列表的作用——比如，需求优先级不清晰，变更成本很高。 对于需求的优先级和关键程度，在GJB438B的需求规格说明的编写要求中是有专门要求的。但是，这一点并没有引起足够的重视。 一些组织的军软开发的工程师，常常会认为软件的所有功能迟早都要实现，排定这些优先级没有实际意义。但实际上，由于工程师们都是承担多个任务，他们几乎都没有时间一次专注于完成一个软件的开发，多个任务的交叉进行迫使他们不得不放下未完成的软件跑去开发另一个软件。但是，未完成的软件也要满足它所在的项目中与硬件联调、匹配、环境实验等进度要求，如果工程师们没有一个好的规划，就会顾此失彼、焦头烂额。而解决这个问题的一个方式就是排定需求的优先级。比如按照项目的进度要求，依据进行的各项调试、匹配、环境实验所需的功能排定开发的优先级，一步步满足项目各阶段的要求。 所以，如果你的需求规格说明没有明确需求的优先级，导致开发进度受到影响，那就说明它还没有起到产品需求列表的作用。那么，需求规格说明再详细，页数再多，也没有什么意义。 这正是： 一寸强来一寸险，需求文档皆亦然 只要开发无影响，文档形式不关键 参考书目：知行合一：实现价值驱动的敏捷和精益开发，作者：丛斌，出版社：人民邮电出版社 |
|
|
