2008年1月3日星期四

软件开发方法浅谈(二)

上一篇文章浅谈(一)已经整理了我接触到的4种主要开发过程。这一篇文章就来仔细的整理一下软件开发中最重要的部分--需求获取和分析。

老实说,自己公司在这方面做的不是很好,大多数的实践方法是我从别的公司那里学来的,还有一些是自己看书和在网上与人讨论得来的知识。经过实践,祛除了一些我认为不是很好用的方法,改进了一些方法的实践步骤。

需求在很多人的眼里虽然重要,但是还是没有重要到能够和产出或者代码相提并论。但我觉得在整个开发环节中,需求是最重要的。我可以毫无疑问的说,需求是软件开发项目成功的首要条件。我们在开发过程中会遇到很多问题,比如最明显的就是不知道哪些要做,哪些不要做;做出东西之后客户不认可,性能没有达到要求,在部署之后客户发现软件和自己想要的完全不是一个东西等等,所有这些,都是没有搞清楚客户到底要什么所造成的。

那么,通过简单的询问就能得到客户的需求么?客户告诉你的就是他要的么?客户一天一个想法,哪个想法才是他真正想要的呢?这些问题不容易回答,我自己经验尚浅,但是经过了几个大型项目的锻炼,我也总结出一些粗糙的方法,这些方法在某种程度上可以解答这些问题。

1.从什么地方获取需求
首先可以从技术合同中获取需求。但是经验表明,那样的需求粒度太粗,只能用于提纲挈领,无法直接转换为软件需求。但是有了这些需求,就可以一条一条去确认,去核对,去细化。

通过和最终用户沟通获取需求。这里的最终用户一定要搞清楚,比如我们做地铁项目的,最终用户就是那些自动售票机的售票员,而不是地铁公司的领导。

通过和销售、售后人员沟通获得需求。对于产品项目,就会有销售,他们会告诉你客户想要什么,或者什么样的软件特性是卖点。售后人员会告诉你上一版的软件有什么问题,这一版需要改经等等。

通过分发试用版本获得需求。beta版的产品就可以分发给用户进行试用了。他们的反馈是非常珍贵的实际需求。

以上都是一些大分类,另外还有一些途径比如产品论坛,内部其他项目人员,技术支持等等。但是有些需求是会遗漏的,那就是来自自己老板的需求。这些需求大多和盈利指标挂钩,这些可是非常重要的。

2. 什么是真正的需求
“客户往往不知道自己要什么”,这句话一定要牢牢记住。一般来说,第一次和客户谈,他给出的信息都不是最终需求。为什么呢,因为他也没有经验,他没有使用过。所以他只能大概的说一些。而第一次,我们需要的也就是大概的东西。然后如果使用敏捷法,那就可以开始干活了,然后再让客户使用,获得正确的反馈。但是在一般开发过程下,我们需要做一些东西,比如原型系统、Storyboard等等,给用户一个能够使用的环境,让他切身体会一下。但是,一定要有场景。只有在某个通用的场景下面的试用活动才能挖出真正的需求。客户会兴致勃勃的把自己代入那个最终场景,然后你就能清清楚楚的知道他怎么来做的,他想怎么做。不要怕麻烦,这种方法绝对可以让你省去后面一大堆麻烦。

谈话的技巧很重要,我们时间有限,不能跟客户胡侃,必须要在有限的时间内尽量引导客户谈正题。因此在找客户谈之前,了解客户行业背景,做准备,列问题就很重要。实际上,这个时候我们就和一些谈话节目的主持人一样。因此对于需求分析工程师来说,学习行业知识远比技术知识重要得多。

尽量找行业经验丰富的客户了解需求。比如我们去一家公司为其定做一套软件,那我会找怎么样的人来了解需求呢?我不能直接跟对方客户说,我要找一个经验丰富的人。我会虚拟一类人,把他代入这个软件的使用者,给他尽量真实的生活经历和工作经历,然后向对方要最符合的一个人。

注意大量隐藏的需求。比如我们地铁行业,一条线路的客户只会考虑本线路的要求,但是多条线路会共同运营,乘客会换乘,我们就需要考虑一些客户没有考虑到的问题。另外比如我们观察到北京地铁使用自动售票机的最终用户都是年纪比较大的大妈,大婶级人物,那么一个隐藏的需求就是字体要大些,对比度高些,能让他们看得清楚。这些往往是生活常识,因此不太可能从别人嘴里得来,要靠自己的观察。

不要光靠自己。一个人的力量永远是渺小的。在获得需求的时候,可以使用头脑风暴之类的方法,让客户和己方不同人员共同参与,各抒己见,这样往往能获得很多需求,但是筛选也是个麻烦事。

并不是所有需求都接受!在谈需求之前,我们要记住项目的范畴,客户往往会认为自己是甲方,所以漫天开价,什么都想要,对于不在范畴里面的需求,可以拒绝。但有时候为了打开市场等目的,对于无理等要求也只能接受。对于有些需求,本身在范围之内,但是和开发与测试讨论后发现这个需求开发时间非常长,或者根本无法测试的,这些需求也要和客户商量修改。

3.怎么样确定需求
一个需求分析到什么程度能够算行。这是仁者见仁,智者见智的问题。但是一般来说,如果一个需求能够写出一个用例(use case),那么这个需求也差不多可以了。用例需要有进入条件,退出条件(结果)和核心价值。进入条件指这个case是怎么触发的。结果就是这个case是怎么结束的,这两个都很好理解。那么核心价值是什么?核心价值是指该用例满足了用户哪个明确的需求。

需求就是我们要开发的东西。这个开发涉及到很多人,不光是需求分析人员的事情。很多公司上层人员获得需求,但是却不让开发和测试人员知道,这些上层人员以为自己同意就行了,这种做法是错误的。因为真正开发的人是开发和测试人员,只有他们认可的、知道的需求才有意义。当然,上层人员可以命令他们做,但是告诉别人怎么做和自己知道怎么做,要做什么将会产生完全不同的结果。因此,在需求定下来之前,要一条一条获得开发与测试人员的同意。每个需求要和开发、测试人员要提出对这条需求的看法,是否能开发,是否可测等等。对于不能开发或者不能测试的需求,一律拒绝或者修改。一旦同意,则他们就要签字,这样也能形成连带责任。

需求的获取也有迭代,一开始的几次迭代只要把一部分核心功能的需求搞清楚即可,对于这部分的需求描述,粒度要细;而对于后面几次迭代的需求只要大致知道有这几个需求即可。那么,粒度要细到什么程度呢?简单的说,一个需求一个用例,一个到多个用例合起来形成一个用户场景即可。在写用例的时候,不涉及任何技术或者系统内部的表现,只有系统外部的表现和给用户的反馈。

比如说,用户在线买本书。用户看到了一本要买的书,然后点击加入购物车,然后去网上支付,完成交易。这是一个完整的场景,而核心价值就是用户买到了书。因此无须写多个用例。一个用例即可。同时在用例里面加入可能的分支情节,比如用户未登录等等。

再举个例子,用户进入地铁站。那用户首先要去买票,他可以在自动售票机那里买,也可以在人工售票机那里买。然后他在闸机那里刷卡进入车站。那这种情况下,就是一个场景多个用例了。买票是就有两个用例,然后进站整个是一个用例。两个买票的用例从属与进站这个用例。但是对于客户来说,因为他最终目的是为了进站,所以买到票在进站是一个完整的需求。

总结一下,需求分析的目的就是要获得客户真正想要的东西,也是我们能够真正开发的要求。很多项目的失败都是因为没有搞清楚这点。做出来的东西和别人要的不一样,别人当然不肯给钱。然后再进行修改,变更,成本也随之上升。千里之行,始于脚下。眼睛不要看得太远,而忽略了身边的事情。

没有评论: