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

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

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

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

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

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

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

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

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

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

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

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

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

　　（试想一下，如果你做的东西很可能随随便便就被翻掉白费，你还会想做好吗？）

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

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

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

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

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

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

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

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