标签：沟通 依赖 优点 ... 方式 天都 nbsp 软件开发过程 商业
《用户故事与敏捷开发》阅读笔记04
今天抽出了两个小时读了《用户故事与敏捷开发》的第十二、十三、十四以及十五章并写了这篇阅读笔记。第十二章标题为“故事不是什么”。IEEE 830是一本关于如何编写软件需求规格的指南，最突出的特征是使用短语“系统应该.....”，但作者认为以这种方式编写系统的所有需求实际是一个不可能的任务。因为用户看到正在开发的软件时总会有有效和重要的反馈循环。他们会改变之前的想法，而且每个需求的成本是不可见的，会造成分析师以及开发人员对一个需求所估算的时间上有很大的差距所以作者提出用户故事不是IEEE830。用户故事也不是用例。两者都以交付商业价值为目标，但故事的范围更小，而且用例是永久性存在，而故事一般不会超过他们的迭代。用户也不是场景，场景包含更多细节，他们的范围往往包含多个故事。
第十三章“用户故事的优势”，作者在这一章简要介绍了用户故事的优点，总的来说就是如下几条：用户故事强调口头沟通；人人都可以理解用户故事；用户故事的大小适合做计划；用户故事适合于迭代开发；用户故事鼓励延迟细节；用户故事支持随机应变的开发；用户故事鼓励参与性设计；用户故事传播隐性知识。
第十四章“用户故事不良征兆一览表”，作者在这一章列出了使用用户故事时的一些不良征兆。经常需要调整估算一般是因为故事太小；如果故事之间有依赖，就会很做迭代计划；还有一种叫做“镀金”，也就是指开发人员实现了不需要的功能，在迭代中实现了计划外的功能；除此之外还有细节太多，过早考虑用户界面细节、想的太远、故事划分太过频繁、客户很难为故事安排优先级、客户不愿意写用户故事，也不愿意为故事安排优先级。对于这些不良征兆，我们必须及时发现并且找到相应的解决方案。
第十五章 “Scrum”与用户故事,“Scrum”是一种迭代递增的软件过程。在软件开发过程中每天都会有一个Scrum简会，要求成员回答三个问题：你昨天做了什么？你今天打算做什么？有什么困难？。作者在后文中分别介绍了在Sprint评审会议中使用用户故事，在每日Scrum简会中使用用户故事，这些在今后软件开发中故事的使用，对我们是有很大帮助的。
标签：沟通 依赖 优点 ... 方式 天都 nbsp 软件开发过程 商业
原文地址：http://www.cnblogs.com/jinpeigang/p/6159126.html
