用户故事与敏捷方法阅读笔记1

　引言中作者提到固化呆板的文档及精确的语言的想法是否为错误的方向。开发前的举措是要简单还是要复杂；是要在前期定义出细节还是要及时响应，做到随需而动。对这个话题，我很有感触。在上学期分组的开发中，很多问题没有事先考虑到，以至于在后期的改进中受到了很大的阻力，甚至有些好想法不得不因此以及时间的限制搁浅了。其实，在表面看来，开发文档是一个不推进进度有无聊的环节，不过那句话：在此阶段犯下的错误，要在维护阶段偿还百倍的时间确实不是糊弄人的。我可以想象的到，却板不住自己在当前阶段能省就省的冲动。另一方面，我觉得，就个人开发来说，做到随需而动也不是不可以的，修改任务没有那么沉重，但也要花好大一分功夫。

　　看来大家对开发文档的恐惧是差不多的。开发文档有需求规格，要表达客户的真实意图，又要满足公司的格式和用词，而且脑中还时刻问自己，这东西有用有人看么？这些感觉我感同身受。

　　事先写好开发文档也不是万无一失得，即使做到巨无巨细，记录语言也是不准确的。在生活中这方面，我也很恐怖。在大家看来只有一个意思的话，在我看来有两个或以上的意思。确实，语言在传递中是有衰减的，人都会主观臆断的增加自己的理解或忽略原有的意思。这样一来，开发文档固然重要，但是也不能忽视交流。

　　用户故事这一章，让我看到了设计人员与开发人员之间的“鸿沟”。两者之间交流不得不以文档的形式呈现，设计人员将用户故事描述的粗糙不行，开发人员不理解，派不上用场。描述的细致不行，有这些心思来表述还不如当面谈一谈。开发文档并不能像契约一样束缚着两头，文档是交流的方式，不是事后出现差错的借口。

　　期望却是是个神奇的词汇，它解释了很多我小时候被“训斥”的原因。我也经常问一些“时间”，“原因”的问题，以把握别人对我所做之事的期望，但得到的往往是，少问多做。期望确实应该像目的那样被显式的提出来。

　　测试在开发不久后就在进行了，开发人员和测试人员是相互影响的。开发靠前的项目可能是因为优先级较高，也可能是因为成本较高。相对于开发之后再测试，这样容错率会高很多。