软件开发活动是软件开发团队一起合作为客户解决一个有价值的问题。这个问题往往很大，而且很复杂。好的策略是“小步快走”，从复杂的问题域中“抠”出一部分不是那么复杂的小问题，然后在迭带中去实现一个客户可以接受的“便宜”方案。在这个过程中，很重要的技巧是用户故事（“用户故事与敏捷开发”）的使用。用户故事是一个客户问题的描述，而不是一个方案的描述（参见“用户故事的智慧” ）。因此一个好的用户故事的标准是精确地描述了一个问题，但是与此同时又不涉及到具体方案。举一个简单例子：

 

用户故事1：作为一个经常使用手机的用户，我能够快速给我的手机充电，因此我可以随时打电话。

 

很多人觉得这应该是一个不错的用户故事，采用了推荐的模板（As a <Who>, I want <What>, So that <Why>），也在一定程度上满足INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)标准。那它的问题在哪里？看一下修改过后的新用户故事：

 

用户故事2：作为一个经常使用手机的用户，我希望我的手机能够保持长时间在线，因此我可以随时打电话。

 

与第一个用户故事相比，第二个用户故事更多的是关注于于问题，客户希望的最终状态，而第一个用户故事则是提供了一个方案 － “快速充电”，而客户深层次的真正的问题是“长时间在线”。而“快速充电”仅仅是解决这个问题的一个方案，解决这个问题还可能有很多种其他方案，比如：

• 超长待机时间，超过一个星期
• 多送一块电池
• 使用太阳能，核能
• 将人们活动时候机械动能转化为电能

一个常见的使用用户故事的陷阱是过度关注于方案，或者暗示了某个方案。而这会极大地压制开发团队的想象力和创造性。关注问题，开发团队就可以重新发挥想象力，激荡出既便宜有好的方案来解决问题。作为Product Owner当然就是在这些方案中作出取舍（根据性能、价格、时间等），决定采用什么样的方案。因此团队和PO之间要不停地讨价还价（INVEST中的N, Negotiate）。

 

尽管用户故事是关于问题的，可能的方案集合还是有其边界的。比如还是上面这个例子，方案3&4，使用太阳能、核能以及将机械动能转换为电能明显超出了我们的边界，开发团队根本不会去考虑采用这些方案。

 

因此较好的使用用户故事的方法应该是：

关注于客户的问题，把用户故事推到(Push)问题解决方案集合边界，鼓励开发团队在边界内部激荡出和PO一起找到并给出“刚刚好”的解决方案。