续写【软件开发】user story的两种写法（上）本篇为上下两篇接这往下看

　　第1种写法增加了目的，让人更明白为什么要这么作与朝这个目的前进

　　如果不写，可能会让人想说，该不会是为了要看技术文件写程序吧？

　　又或者让人想说，这是一种压薪水的手段吗

　　还是这可能只是公司就是想要而已，没有任何理由

　　第2种写法虽然只是把目的写在前面，却带来了另一种意义

　　就是整个实现是着重于实现目的而非方法

　　以这例子来说，这会变成也能改成说：「为了跟外国人进行需求访谈与合作，身为主管，我想要一个具有能够进行英文对话与书信往来的翻译人员」

　　搞不好找翻译人员更好

　　每个功能的实现与开发通常都是为了某种目的

　　Use Case是使用者的操作过程就是这样，做就对了

　　User Story是给开发者们去实现目的，要使用者采取甚么样的操作还有调整空间

　　如果是一般项目，尤其是政府项目，我想user story很可能不适合（要看使用时机点）

　　如果是产品研发，那user story会很适合

　　因为user story是采取价值驱动，价值会比规格更加重要

　　我觉得user story的用法如果是一般开发方法的话，SA在跟提需求的人确认需求时会比较好用（估时程前）

　　这可以有利于SA进行规划与设计

　　但如果要当规格开给PG的话，变质的可能性很高

　　因为一般开发时，项目的时程与PG的时程都是定下来的

　　你要PG思考怎么实现目的，又要掌控开发时间，其实并不合理，结果一定是能简单好实现就往好实现的方式实作

　　这就偏离了使用user story该有的目的

　　但如果使用scrum的话，因为scrum本身就是一种不太受限于时程的开发做法，甚至连估时程都是不实作的人都不能干涉的，至于有多少管理者能够接受不掌控时程这件事情，那就另一回事了。

　　虽然无法理解user story map怎么使用有些遗憾，但我觉得理解user story与价值驱动对我帮助还是蛮大的

　　题外话：

　　那天因为讲者想拿拼凑的事情做举例说明，所以问有没有人看过科学怪人

　　我本来想说我有看过科学怪人-驱魔大战

　　不过还好没说，不然讲者应该接不下去吧XD

　　?