【软件开发】user story的两种写法(上)
之前参加了C.C Agile的活动
我觉得那次活动内容不错,只是很可惜的是时间掌控得不是很好
那次活动提到了user story的撰写,这让我发现我之前对user story的理解有问题
我之前对user story没甚么感觉,感觉只是一个形式上的格式
觉得那不过就是身为甚么角色,我想要甚么
很抽象、很模糊,可能还是需要use case来描述细节
如果有好好写过系统分析文件与规格的话,你可能会发现到一件事情
要写好SPEC,花的时间非常可能比工程师实作花的时间更多
如果访谈对象很搞不清自己要甚么或无法描述清楚的时候,很可能SPEC一直大翻
而且依照公司分工情况,搞不好还得去想对于系统与结构上的影响(没有SD时)
我是认为即使如此,有把系统分析做好也是有价值的,
因为如果SPEC描述的内容够确实,准确度够高
能够减少实作上的白工,进而避免开发的士气低落
(试想一下,如果你做的东西很可能随随便便就被翻掉白费,你还会想做好吗?)
而且也能够避免对系统架构的影响,进而提升程序质量
但对于不理解的人,仍然会觉得很怪,「不过就写个系统文件,花的时间是开发的好几倍,花那么多时间做啥?直接开发不就好了吗?」
他们可能会无法理解与认同写SPEC比开发时间多很多这种事情
User Story算是另一种描述需求的做法,我当初去上课时,学的就只是要写下身为甚么角色与想要甚么而已
这很抽象,让我一直在想这样描述会不会变成需求不明确
参加完活动之后,比较好的写法有两种,拿想征求有英文能力的系统分析师来举例好了
1.身为主管,我想要一个具有能够进行英文对话与书信往来的系统分析师,这样就能让他跟外国人进行需求访谈与合作
2.为了跟外国人进行需求访谈与合作,身为主管,我想要一个具有能够进行英文对话与书信往来的系统分析师