敏捷始于用户角色，成于技术实践

《用户故事与敏捷方法》从用户角色建模、故事搜集、故事编写、优先级排列、故事估算、故事冲刺执行、故事监控、故事验收等方面对用户故事进行了全面、详尽地叙述。通过一个完整的实例，使读者对用户故事的编写、估算、发布、验收测试有了更深刻的理解。

通过头脑风暴识别用户角色，然后整合、提炼用户角色，从而实现用户角色建模。随着用户角色建模的完成，产品路线图也逐渐清晰。产品路线图展示了产品关注的重点、产品的发展方向、市场定位等。

用户访谈、问卷调查、观察和故事编写工作坊是创建故事最有用的方法。随着互联网的发展，还可采用大数据舆情分析、用户体验、行业产品分析等方式搜集故事。

用户故事既是管理需求的方法也是技术实践。用户故事具有便于沟通、易于理解、适合做计划、迭代开发、支持随机应变等优势；然而编写一个优秀(INVEST)的用户故事并不是一件容易的事情。对于大的、复杂的需求，需要从不同的维度进行切分，如何找到合适的切分点则因经验、对项目了解程度不同而不同。用户故事不仅要体现用户价值，同时更要大小合适具有可实施性。从这个方面来说，编写好的用户故事是需要不断的实践，从而提高编写优秀故事的能力。

基于不同的用户角色编写了好的用户故事，项目实施Scrum过程，那是否该组织就是敏捷型组织？

如果团队使用Scrum来开发软件，团队成员务必熟练掌握软件开发技术实践。但这不并是指高深难懂的技能，而是一些基本的、决定Scrum成败的基础技能，如：测试驱动开发、重构、简约设计、持续集成、集体代码所有权、编码标准、隐喻等。

不重视单元测试，开发团队很快会慢下来，随着技术债务的积累，也面临着越来越大的风险。事实上单元测试不仅是一种验证行为而且还是一种设计行为，编写单元测试将使我们从调用者观察、思考，特别是要先考虑测试，这样就可把程序设计成易于调用和可测试的，并努力降低软件中的耦合，还可以使编码人员在编码时产生预测试，将程序的缺陷降低到最小；单元测试还具有回归性。同样的，如果没有自动化集成测试，需要每个迭代需要重新对之前开发的特性进行回归测试。如果团队选择不在每个迭代运行所有手工测试，就会导致缺陷往前传递，系统的技术债越积越多。

用户故事从用户角色开始，能否走上敏捷的“康庄大道”取决于团队是否实施敏捷技术实践。