拿什么来澄清需求

      今天在参加与吴穹博士的敏捷交流中不禁让我想起了目前正在进行的一个项目。

 

      项目是我们与国外的开发团队合作开发，说白了就是我们给出需求，他们来设计、开发、测试，且对方是严格的CMMI5。

 

      项目的初期是对方的SE与我们通过原型来收集需求，之后他们会根据对需求的理解整理出一个设计需求，实际上就是一个功能分解，然后根据设计需求进行项目估算（开发+测试），测试团队也会使用这个文档来写测试用例。另外对方还会准备一份软件需求规格。

 

过程中我发现，原型的制作大概耗费了我们一两个月时间（由于是第一次合作+时差问题，这点可以理解），之后的事情就让我感觉不是很爽了：

      之后他们就开始准备设计需求文档，需求文档的内容也是反反复复，review来review去，而且写需求设计文档的SE很少参与原型的讨论，折腾了几个星期设计文档终于出来了....

 

      按照他们的流程，测试小组后面会基于设计需求文档设计测试用例，结果他们的测试经理告诉我，还不够，设计需求中没有用户场景，这让他们很难设计有效的测试用例。想起来也是，设计需求文档里面都是一堆功能分解，光看这个文档我也不知道用户怎么用这个系统的。好吧，要求是我们得提前给他们用户接受测试（UAT）的测试用例，这样就可以了解更多的用户场景了。

 

      再后面，开始准备软件需求规格了，这份软件需求规格是由他们的开发团队分工写出来的，洋洋洒洒写了N页，完成后发给我们review，结果发现，这个软件需求规格实际就是前期原型制作的文字版，而且是由开发团队来写的，由于理解问题结果错误还不少，澄清来澄清去.....

 

 

      今天吴博士就讲到可以用user story+原型来给出需求，我觉得这个正好能解决我遇到的问题：

1、基于user story，我们应该是可以估算项目规模的，这样就不需要准备他们的设计需求文档了；

2、测试团队可以基于这两样交付件来编写测试用例，而且基于user story测试团队能真正了解功能的意图，这样才能设计出更好的测试用例并及时发现问题；

3、其实我觉得这时需求规格完全可以省掉不写了；

 

这样的话即解决了开发/测试团队不能真正理解系统使用的问题，也省了对方和我们的工作量。

但是如何使用user story挖掘并完整描述系统需求应该也不是一件简单的事情。