读书笔记-用户故事与敏捷方法02

第5章 与用户代理合作

1. 用户代理的角色

• 用户的经理： 提供错误信息，但需要验证这些信息与实际用户一致。
• 开发经理： 不适合担任用户代理，可能导致不准确的用户需求。
• 销售团队： 作为中转站，能提供高层次的指导，但不能提供具体细节。
• 领域专家： 重要资源，但可能导致软件只适用于与专家水平相似的用户。
• 以前的用户： 良好的选择，但需要确保目标和动机与实际用户一致。
• 培训师和技术支持： 培训师只能使系统易于培训，技术支持只能使系统易于维护。

2. 选择用户代理的原则

• 实际用户总是优于用户代理。
• 如果无法访问实际用户，设立客户代理团队。
• 不要仅仅依赖于用户代理，要以了解实际用户的角度。

第6章 用户故事验收测试

1. 流程概述

• 使用测试来充实用户故事的细节。
• 测试流程包括将测试要点记录在故事卡背面，并将其转化为全面的测试，用于演示故事实现的正确性和完整性。

2. 测试验收的基本标准

• 提供了确认故事是否被完整实现的基本标准。
• 审视每个故事，询问关键问题，如程序员需要了解的信息、特殊情况和可能的错误情况。

3. 客户定义测试

• 验收测试应由客户定义。
• 客户应持续编写测试，为故事增加价值和清晰度。
• 优秀的开发团队会为详细的测试编写单元测试。

第7章 优秀用户故事准则

1. 确定用户故事的方法

• 在大型项目中，尤其是多用户角色项目，考虑每个角色并了解用户使用软件的目的。
• 切蛋糕原则：将大的故事分解为较小的故事，每个都提供某种程度的完整性。

2. 编写封闭的故事

• 封闭的故事是实现有意义目标后，让用户感觉完成了某个任务的故事。
• 例子：招聘者可以审核发给他的简历，更改广告的过期日，删除不适合的申请。

3. 卡片约束

• 在故事卡上标注约束，即必须遵守但不需要直接实现的规定。
• 例子：软件要易于国际化、使用现有订单数据库、能在所有Windows系统上运行、无故障运行时间达到99.99%。

这些原则和准则有助于在项目中更好地理解用户需求、确保故事完整性，并提供明确定义的验收标准。

第8章 估算用户故事

故事点

故事点是对故事复杂度的模糊测量。不同团队可以有不同的标准，但要保证2个故事点的复杂度约为1个故事点的2倍。这是一种相对估算的方法，而不是精确的度量。

团队估算

故事估算应该由整个团队集体完成。这有助于融合不同团队成员的经验和视角，以更准确地估算故事的复杂度。

三角测量

三角测量是在做了几个估算后，对估算结果进行验证和调整的过程。通过对比不同故事点的故事，确保它们的复杂度符合预期。这有助于团队更好地理解和调整他们的估算。

使用故事点

在一轮迭代结束时，团队计算已完成的故事点数。这个点数可以作为下个迭代完成的故事点数的预测，帮助团队更好地规划和管理工作量。

第9章 发布计划

优先级排列

客户必须根据以下优先级排列故事：

1. 必须有：系统的基本功能。
2. 应该有：重要但短期内有替代方法的功能。
3. 可以有：可以在发布中不予考虑的功能。
4. 这次不会有：可以在后续发布中交付的功能。

这有助于确定在发布中首先实现的功能，以便尽早提供最有价值的部分。

第10章 迭代计划

迭代计划会议

迭代计划会议是整个团队通过讨论故事、分解任务、任务分配和任务估算来为下一轮迭代做计划的过程。客户和团队的所有成员都参与其中。

1. 讨论故事： 客户从最高优先级的故事开始，向开发人员讲解故事，并进行初步的讨论。

2. 从故事中分解出任务： 团队通过与客户交互，从故事中识别并分解出具体的任务。

3. 开发人员承担任务的职责： 开发人员明确承担各个任务的职责，确保每个任务都有对应的负责人。

4. 任务估算： 开发人员对自己承担的任务进行估算，以确保他们的承诺是可实现的。

这一过程有助于团队规划下一轮迭代的工作，同时确保任务的合理分配和估算。

总的来说，这些章节强调了团队协作、优先级制定、风险考虑和灵活度等敏捷开发的核心原则。通过这些方法，团队可以更有效地规划、估算和完成项目。