敏捷的用户故事方法
一、起步
1. 背景
1.1. 什么是用户故事?
1.2. 细节在哪里?
1.3. “必须多长时间完成”
1.4. 客户团队
1.5. 使用故事的过程是怎么样的?
1.6. 规划发布和迭代
1.7. 什么是验收测试?
1.8. 为什么要变成用户故事?
1.9. 小结
2. 编写故事
2.1. 独立的
2.2. 可讨论的
2.3. 对用户或客户有价值的
2.4. 可评估的
2.5. 小的
2.6. 可测试的
2.7. 职责
2.8. 小结
3. 用户角色建模
3.1. 用户角色
3.2. 角色建模的步骤
3.3. “虚构人物”和“极端人物”
3.4. 如果有现场用户该如何?
3.5. 职责
3.6. 小结
4. 收集故事
4.1. 用“拖网”来收集需求
4.2. 够用就行,不是吗
4.3. 方法
4.3.1. 用户访谈
4.3.2. 问卷调查
4.3.3. 观察
4.3.4. 故事编写工作坊
4.4. 职责
4.5. 小结
5. 与用户代理合作
5.1 用户的经理
5.2 开发经理
5.3 销售人员
5.4 领域专家
5.5 市场营销团队
5.6 以前的用户
5.7 客户
5.8 培训师和技术支持
5.9 业务分析师或系统分析师
5.10 与用户代理合作时,做些什么?
5.11 可以自己来吗?
5.12 建立客户团队
5.13 职责
5.14 小结
6. 用户故事验收测试
6.1. 在写代码之前写测试
6.2. 客户定义测试
6.3. 测试是过程的一部分
6.4. 多少测试才算多?
6.5. 验收测试
6.6. 测试类型
6.7. 职责
6.8. 小结
7. 优秀的用户故事准则
7.1. 从目标故事开始
7.2. 切蛋糕
7.3. 编写封闭的故事
7.4. 卡片约束
7.5. 根据实现时间来确定故事规模
7.6. 有些需求并不是故事
7.7. 在故事里包含故事角色
7.8. 只为一个用户编写
7.9. 以主动语态编写
7.10. 有客户编写
7.11. 不要忘记意图
7.12. 小结
Published with GitBook
6.7. 职责
6.7. 职责
客户团队职责
负责编写验收测试
负责执行验收测试
开发人员职责
若团队觉得有需要,则负责实现自动化验收测试
开始开发一个新的故事时,负责考虑更多的验收测试
负责为代码做单元测试,是验收测试不必顾及故事的每个细节
results matching "
"
No results matching "
"