【软件开发】user story的两种写法(上)

  之前参加了C.C Agile的活动

  我觉得那次活动内容不错,只是很可惜的是时间掌控得不是很好

  那次活动提到了user story的撰写,这让我发现我之前对user story的理解有问题

  我之前对user story没甚么感觉,感觉只是一个形式上的格式

  觉得那不过就是身为甚么角色,我想要甚么

  很抽象、很模糊,可能还是需要use case来描述细节

  如果有好好写过系统分析文件与规格的话,你可能会发现到一件事情

  要写好SPEC,花的时间非常可能比工程师实作花的时间更多

  如果访谈对象很搞不清自己要甚么或无法描述清楚的时候,很可能SPEC一直大翻

  而且依照公司分工情况,搞不好还得去想对于系统与结构上的影响(没有SD时)

  我是认为即使如此,有把系统分析做好也是有价值的,

  因为如果SPEC描述的内容够确实,准确度够高

  能够减少实作上的白工,进而避免开发的士气低落

  (试想一下,如果你做的东西很可能随随便便就被翻掉白费,你还会想做好吗?)

  而且也能够避免对系统架构的影响,进而提升程序质量

  但对于不理解的人,仍然会觉得很怪,「不过就写个系统文件,花的时间是开发的好几倍,花那么多时间做啥?直接开发不就好了吗?」

  他们可能会无法理解与认同写SPEC比开发时间多很多这种事情

  User Story算是另一种描述需求的做法,我当初去上课时,学的就只是要写下身为甚么角色与想要甚么而已

  这很抽象,让我一直在想这样描述会不会变成需求不明确

  参加完活动之后,比较好的写法有两种,拿想征求有英文能力的系统分析师来举例好了

  1.身为主管,我想要一个具有能够进行英文对话与书信往来的系统分析师,这样就能让他跟外国人进行需求访谈与合作

  2.为了跟外国人进行需求访谈与合作,身为主管,我想要一个具有能够进行英文对话与书信往来的系统分析师


联系我们

13751415268

853408942

:853408942@qq.com

:9:30-22:30

QR code