标签：为我 总结 重写 bsp 客户 领导 交流 调整 开发
第13章 用户故事的优势
从上一章我们得知，处理需求的方法多种多样，但是我们为什么要选择用户故事？因为它会带来多种好处：
①用户故事强调口头沟通：自古以来，口头表达是十分重要的。而且相比于书面书写的易产生歧义，口头表述更见简单明了，需求文档也是如此。
②人人都可以理解用户故事：相比于一些墨守成规的软件需求里的技术术语，用户故事使用的语言更容易使用户理解，简洁明了，同时更能增强用户对故事的记忆。
③用户故事的大小适合做计划：其他类型的需求分析关联性太强，并且还比较笼统，大小不能称得上是易实现的适合需求。
④用户故事适合于迭代开发：由于用户故事的特性，使得开发者可以根据当前需要，按照想要的进度实施开发。
⑤用户故事鼓励延迟细节：用户故事允许我们先设定一个目标层面的故事，之后实际开发的时候，再将其细节化，加快整个团队的进度。
⑥用户故事支持随机应变的开发：由于用户的不可控性，需求常常会变动。在以往从上到下的需求分析方法中，这简直就是噩梦，它会让我们前期定下的所有需求全部作废。用户故事则很好的解决了这一点。
⑦用户故事鼓励参与性设计：用户故事本身不像其他需求方法都是专业术语，用户可以完全理解，他们也就更愿意参与设计他们所需要的软件。在这个过程中，我们就能更好的了解用户的需求，做出更优质的分析。
⑧用户故事传播隐性知识：隐性知识指的是目标系统的既有属性，用户在工作时习以为常，认为我们应该知道，但是我们因为不熟悉流程无从知晓的知识。由于用户可以参与设计，这就有利于我们挖掘出用户的潜在需求，缩短我们的开发周期。
尽管如此，用户故事仍但会存在一些不足：在大型项目中，用户故事数量增长，导致其间的关系可能错综复杂，不易掌控（解决方案：增加用户，降低细节数量）；开发过程如果需要可追溯性，额外文档还是不可避免（每轮迭代产生故事文档，其中写入该轮迭代的工作，保持文档的更新）；不适合特大规模多团队的结构（还是需要进行相关的交流记录）。
第14章 用户故事的不良征兆一览
用户故事虽好，但是使用起来也不简单，如果使用不善，还是会出现各式各样的问题。下面就是一些常见的不良征兆（症状，解决方案）：故事太小（经常需要调整估算，将相关的故事进行合并）、故事相互依赖（很难做迭代计划，如果因为故事小就相应合并或者是看一看故事划分是否得当）、镀金（实现功能超出计划需要、开发者因此浪费额外精力，规定好每次迭代计划的每人工作尽量减少冗余）、细节太多（浪费过多时间写故事而非讨论收集故事，使用小卡片记录用户故事）、过早考虑用户界面细节（编写的故事中包括界面细节，避免或者修改成具体的功能描述）、想的太远（由于种种原因导致故事难以整理总结，让开发者学会收集用户故事）、故事划分太过频繁（多次划分，扫描剩余故事找到真正需要划分的故事）、客户很难为故事安排优先级（故事太大或者用户故事无商业价值，更换小故事、让客户努力重写）、客户不愿意写故事，也不愿意为故事安排优先级（不愿承担相应责任，和用户私下讨论交涉）。解决这些问题，用户故事才能更健壮，开发也就更加流畅。
第15章 Scrum与用户故事
Scrum也是一种迭代递增的软件过程。迭代指的是持续改进，在迭代中，软件才能够逐步完善；增进指的是团队按照功能点开发和发布软件，这就可以使得项目稳步前进，减少返工几率。实施Scrum过程的项目常以30天为周期迭代，这一过程称为Sprint。ScrumMaster相当于传统的项目经理，但更像是领导者和组织者，他与开发者的关系比经理更近。一般的Scrum团队包括4~7个开发人员。产品Backlog是一个待开发的功能需求列表，里面的条目都是尚未进行实现或计划的。Sprint Backlog是一个团队承诺在当前Sprint完成的任务列表。Scrum里的产品负责人相当于极限编程里的客户，他负责给Backlog排列优先级。每次Sprint开始时，软对都要在尚未实现或计划的列表中选择要进行的任务。每日的简会中，每个团队成员需要自我三省：已完成、要完成、问题。在每个周期中都要有实际的产品功能增量，这样项目才能健康有序的向前进行。在最后Sprint结束时，阮队要在审评会议上演示完成的功能。这就是一个Scrum的相关内容与流程。
标签：为我 总结 重写 bsp 客户 领导 交流 调整 开发
原文地址：http://www.cnblogs.com/Daddy/p/6036493.html
