敏捷的用户故事方法
一、起步
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
2.7. 职责
2.7. 职责
客户团队职责
编写故事,这些故事要能提醒你们同开发人员交谈,而不是记录详细的需求定义,它们对用户或你们自己是有价值的,它们时独立的、可测试的、大小合适的。
开发人员职责
负责帮助客户团队编写故事,这些故事要能提醒你们同客户团队交流,而不是记录详细的需求定义,故事应该对用户和客户有价值,它们是独立的、可测试的、大小合适的
如果被问及实现故事所用的技术或基础架构信息,应该使用对用户或可以有价值的术语来描述
results matching "
"
No results matching "
"