【IT168 分析评论】

    尽管敏捷软件开发非常强调客户的交互和反馈，而讨论组成员的跟贴也很有意思，都偏向用户。大多数成员好像都同意：“客户是评判从软件中得到哪些业务价值的非常好的人选，他可以选择是否用敏捷方法来达成他们的业务价值。Ron Jeffries提到：我们的客户不应该在意敏捷开发。我们的客户对业务责任，但并不仅仅只限于软件开发。他们应该感兴趣的是：

    ◆得到真正需要的软件；

    ◆能可靠工作的软件；

    ◆尽快交付的软件；

    ◆ 对他们的影响尽可能地小；

    ◆ 软件以其最容易最自然的方式运行。

    Ron认为，作为软件开发人员，团队应该集中精力做正确的软件，并确保用户高兴。他建议，如果团队已经花足够的时间来向用户介绍敏捷，而客户还是不感兴趣的话，那么团队就应该别在用户面前鼓吹敏捷了。他也提到这丝毫不意味着团队应该为此惶恐不安，他们应该确定哪些实践可以很好的发挥作用，哪些不能。以后再一点儿一点儿地改进。

    Zhon Johansen建议要以巧妙的方式向客户展显敏捷的好处，从而让他感觉敏捷并不是强加于他的，比如用户故事的优先级，因为这事对客户来说是极其重要的。如果客户对优先级这事不感兴趣，那么团队应该给他一份团队根据自己的判断列出的一张优先级列表，并问客户是否认可这些。这要比没有优先级要好得多。

    似乎J. B. Rainsberger建议的方法是正确的。他提到我会邀请他们参加回顾会议（如果叫“回顾”会把他们吓走的话，就换个名呗），向他们灌输一个主题：“我们如何更好地一起合作”。我的目标就是发现三个他们最希望从我们这里期望的事，并告诉他们，我们最希望从他们那里得到的三件事。让我们看看这么做六个月后，是否有助于关系的改进。

    根据过去以及现在正在进行的软件项目，不难想像客户是很难全心投入团队中的，然而，就像上面讨论中建议的那样做，不用给他们详细地解说敏捷，事情也一样可以办到。讨论组的成员好像都一致同意：客户知道什么是最好的，开发团队不应该将敏捷强加于客户。客户应该能按他们喜欢的方式工作，而开发团队应该想尽一切办法让客户获得成功。