用户故事与敏捷方法读后感（二）

接下来的几章就是优秀用户故事准则、估算用户故事、发布计划、迭代计划测量并监控速率、故事不是什么、故事的优势以及故事的不良征兆。主要将的就是在一个大型项目中，尤其是有许多用户角色的项目，确定用户故事有时让人无从下手。最好的办法是考虑每一个角色，了解用户使用我们软件的目的。当面临一个大的故事时，通常有许多方法将其分解为较小的故事。其原则是：每一故事都提供某种程度的完整性。封闭的故事是指：随着一个有意义的目标的实现，能让用户使用后觉得他完成了某个任务。什么是卡片约束？对于任何必须遵守而不需要直接实现的故事，在其故事卡上标注“约束”。这些约束，最终可能会转换为非功能需求。在估算用户故事中想要用好故事点，需要记住几个问题：你团队的故事点和我团队的故事点是不一样的，不必强求一个史诗的故事点，一定等于自古是故事点之和。在第九章发布计划中将为了计划一个发布，客户必须排列故事的优先级分别是必须有、应该有、可以有、这次不会有。敏捷方法旗帜鲜明地支持先做最有价值的部分，但在排列故事优先级时仍然要考虑风险。高风险的故事经常与基础性或非功能性需求相关。开发人员应该帮助客户识别出那些可以推迟实现，但越晚实现开发成本可能越高的故事。在迭代部分中整个团队通过举行迭代计划会议来为下一轮迭代做计划。客户以及团队的所有人要都要参加这个会议。团队将仔细研究用户故事，需要客户随时回答这些问题。有时候我们需要测量并监控速率。我们将项目分成一系列迭代来做发布计划，每轮迭代中安排一定故事点的任务。一轮迭代完成的故事点就是项目的速率。因为速率是非常重要的度量，所以怎么测量它变得很重要，而且速率在初期的迭代可能很不稳定，经过两三轮迭代后，才能获得一个长期的、比较稳定的速率。注意：对于尚未完成的故事，不应该把它算在速率里。通常，我们可以通过对比计划速率和实际速率，检测团队的速率。在书籍的最后讲述了故事的优势和故事的不良征兆。用户故事的不足：拥有大量用户故事的项目中，故事之间的关系可能错综复杂，难以捉摸。我们可以使用角色来淡化此问题，尽量保证用户故事不要过于细节化，直到团队开发这些故事时才开始细化。故事的不良征兆有故事太小、故事相互依赖、镀金、细节太多、过早考虑用户界面细节、故事划分太过频繁、客户很难为故事安排优先级等等。

用户故事为软件开发的过程提供了思路，通过不断增加信息以及细节来完善软件的功能。用户故事与敏捷方法的结合，用相对更短的时间、更高效的方式完成软件开发的流程。用户故事中高效的沟通使客户和团队成员都朝同一个方向前进，并且以更快的速度，更少的消耗来应对快速变化的需求。《用户故事与敏捷方法》这本书详细介绍了用户故事与敏捷开发方法的结合，诠释了用户故事的重要价值，用户故事的实践过程，良好用户故事编写准则，如何搜集和整理用户故事，如何排列用户故事的优先级，进而澄清真正适合用户需求的、有价值的功能需求。对于软件开发人员、测试人员、需求分析师和管理者，具有实际的指导意义和重要的参考价值。