用户故事与敏捷开发 读书笔记 02

第5章 与用户代理合作

对一个项目来说，客户团队里包括一个或多个真实用户是极其重要的。遗憾的是，我们很难与实际用户一起工作。我们期望与尽可能多的用户接触，这些用户代表了产品的不同角度，当我们无法接触到他们时，我们就需要求助各种用户代理，他们不是用户，但在项目中扮演用户角色。

• 用户的经理：不要得罪用户的经理，但是为了项目的成功，在令其满意的同时，也要想办法接触终端用户。用户的经理有时时错误信息的来源，只要有可能需要与实际用户来交流求证这些信息。
• 开发经理：让开发经理担任用户代理，是最坏的选择之一。
• 销售团队：销售人员是非常好的中转站，应该通过他们接触客户。他们可以为故事的优先级提供高层级的指导意见，但是无法提供具体细节。
• 领域专家：非常重要的资源，但是存在一个潜在的问题：最终开发出来的软件可能仅仅针对那些与领域专家有类似水平的用户。
• 以前的用户：非常好的选择，但是应该考虑他的目标和动机是否与实际用户完全一致。
• 培训师和技术支持：如果你只让培训师做用户代理，你的系统只会变得容易培训；如果是技术支持人员做代理，系统只会变得容易维护。

首先，请记住，在任何时候，实际用户总是优于用户代理。只要可能，就要邀请实际用户加入客户团队。如果无法访问到实际用户，就设立客户代理团队，要以为你自己知道客户的想法，就可以忽略你的用户代理。

第6章 用户故事验收测试

比起写冗长的需求列表，可以用测试来充实很多用户故事的细节。测试是一个两步走的流程：第一，将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面；第二，将测试要点变成全面的测试，这些测试可以用来演示故事已正确、完整地实现。

测试验收提供了确认故事是否被完整实现的基本标准。有了这个标准，我们就知道什么时候某件事算是做完了。比较好的做法是，考虑每一个故事，然后问类似下面的问题：

• 关于这个故事，程序员还需要知道什么？
• 有没有一些特殊情况会使这个故事有不一样的行为?
• 这个故事在什么情况下回出错？

客户定义测试

既然软件是用来实现用户的愿景，验收测试当然应当由客户来定义。只要这些测试还在继续为故事增加价值使它更加清晰，客户就应该继续写测试。同时，一个优秀的开发团队会为很多详细的测试写单元测试。

第7章 优秀用户故事准则

在一个大型项目中，尤其是有许多用户角色的项目，确定用户故事有时让人无从下手。最好的办法是考虑每一个角色，了解用户使用我们软件的目的。

切蛋糕

当面临一个大的故事时，通常有许多方法将其分解为较小的故事。其原则是：每一故事都提供某种程度的完整性。例如：“求职者可以发布简历”，这个故事可以做如下拆分:

• 求职者可以提交简历，简历上包括诸如名字、地址和教育背景等基本信息。
• 求职者可以提交简历，简历上包括雇主想看到的所有信息。

编写封闭的故事

封闭的故事是指：随着一个有意义的目标的实现，能让用户使用后觉得他完成了某个任务。例如：“招聘者可以管理她发的招聘广告”者不是一个封闭的故事，而是一个持续进行的活动。这个故事应该更好的被拆分如下：

• 招聘者可以审核发给他的简历。
• 招聘者可以更改招聘广告的过期日。
• 招聘者可以删除不适合的申请。

卡片约束

对于任何必须遵守而不需要直接实现的故事，在其故事卡上标注“约束”，例如：

• 设计的软件要便于今后的国际化
• 新系统必须使用我们现有的订单数据库
• 该软件必须能在所有的Windows系统上运行
• 该系统的无故障运行时间要达到99.99%

这些约束，最终可能会转换为非功能需求。

第8章 估算用户故事

• 故事点：故事复杂度的模糊测量，不同的团队可以有不同的标准，只要保证2个故事点的复杂度约为1个故事点的2倍即可。
• 以团队估算：故事估算应该由整个团队集体完成。
• 三角测量：在做了几个估算后，我们必须对估算做三角测量。具体的做法就是拿出一些故事，大家要同意4个故事点的故事大约是2个故事点故事2倍的复杂度，3个故事点的故事介于两者之间。这些都不用太过精确，但会帮助团队检验他们的估算。
• 使用故事点：在一轮迭代结束时，团队计算已完成的故事点数。这个点数可以作为下个迭代完成的故事点数的预报。

想要用好故事点，请记住以下几个问题：

• 你团队的故事点和我团队的故事点时不一样的。
• 不必强求一个史诗的故事点，一定等于子故事故事点之和。

第9章 发布计划

为了计划一个发布，客户必须排列故事的优先级：

• 必须有：系统的基本功能。
• 应该有：很重要但短期内有替代方法的功能。如果没有时间约束，是必须要上的功能。
• 可以有：如果没有时间，可以在发布中不予考虑的功能。
• 这次不会有：客户希望有，但承认可以在后续发布中交付的功能。

敏捷方法旗帜鲜明地支持先做最有价值的部分，但在排列故事优先级时仍然要考虑风险。高风险的故事经常与基础性或非功能性需求相关。开发人员应该帮助客户识别出那些可以推迟实现，但越晚实现开发成本可能越高的故事。

第10章 迭代计划

整个团队通过举行迭代计划会议来为下一轮迭代做计划。客户以及团队的所有人要都要参加这个会议。团队将仔细研究用户故事，需要客户随时回答这些问题。迭代会议的内容一般如下：

• 讨论故事
• 从故事中分解出任务
• 开发人员承担每个任务的职责
• 讨论过所有故事，并且分配完任务后，开发人员单独估算他们承担的任务，以确保他们不会做出过于乐观的承诺。

讨论故事

团队获得一个已经排好优先级的故事集合，以此作为迭代计划会议的输入。迭代会是客户为团队调整故事优先级最佳的时机。会议开始时，客户从最高优先级的故事开始，讲给开发人员听。然后由开发人员提问，直到他们充分理解故事，能从中分解出任务。没有必要理解故事所有的细节，过分深入会让会议变得冗长、低效。再会议过后开发人员任然可以和客户一起清理故事的细节。

第11章 测量并监控速率

我们将项目分成一系列迭代来做发布计划，每轮迭代中安排一定故事点的任务。一轮迭代完成的故事点就是项目的速率。因为速率是非常重要的度量，所以怎么测量它变得很重要，而且速率在初期的迭代可能很不稳定，经过两三轮迭代后，才能获得一个长期的、比较稳定的速率。注意：对于尚未完成的故事，不应该把它算在速率里。

通常，我们可以通过对比计划速率和实际速率，检测团队的速率。