敏捷的用户故事方法
一、起步
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
5.13 职责
5.13 职责
客户团队职责
如果你不是软件的用户,则要负责了解自己属于哪类用户代理。
负责理解自己会将哪些偏见导入到项目中,如何克服这个问题,无论是依靠别人还是其他方法。
开发人员职责
负责帮助组织机构为项目物色合适的客户。
负责了解不同类型的用户代理怎么考虑你们正在开发的系统,他们的背景如何影响交互。
results matching "
"
No results matching "
"