用户故事与敏捷方法笔记---与用户代理合作

如有问题请留言

---

前言

对于一个项目来说，如果客户团队包含了一个或多个用户是非常好的。但是实际情况是客户团队很难包含用户。这时候我们就需要用户代理了。他们可能不是实际用户，但是这些人可以在项目里代替用户。

---

提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。

文章概览

1. 用户经理

	a. 用户经理可能并不能够完全代理实际用户，因为经理可能会按照自己的意志陈述意见。

2. 开发经理

	a. 让开发经理代替用户经理是最坏的选择之一，因为有时候技术人员会将技术优先级和应用优先级混到一起，或者与企业的商业目标不一致。

3. 销售人员

	a. 让销售人员充当用户代理是危险的，对于销售人员来说，最重要的故事是那些如果没有实现会导致他丢单的故事。

4. 领域专家

	a. 领域专家，是非常重要的资源，但他们是否能够帮助我们，这要看这个专家是否目前或曾经使用过我们正在开发的这种软件。另一个潜在的问题就是，领域专家可能会把软件开发引导到将来只针对专家层次的使用水准。

5. 市场营销团队

	a. 他们会更注重产品特性的数量而不是质量，他们缺少好的洞察力并无法提供故事的具体细节。

6. 以前用户

	a. 这是一个好的选择，但要考虑清楚他所提出的是否还具有有效性。

7. 客户

	a. 很重要，因为是否购买软件完全由他们决定，所以要清楚具体的期望值。

8. 培训师和技术支持

	a. 不是很好，这样可能导致最终系统只能成为一个容易培训的系统。

9. 业务分析师和系统分析师

	a. 这是一个不错的选择，只不过有时候他们遇到问题喜欢空想而不是调查。

10. 自己来可以吗？

	a. 可以，但尽可能不要陷入思维误区。

11. 设立客户团队

	a. 邀请真实用户加入
	b. 在客户团队中确立一个项目负责人
	c. 确定项目成功的必要因素

总结

提示：如有问题请留言
下一篇 “用用户故事验收测试”

参考书籍《用户故事与敏捷方法》