客户应该在意敏捷吗？

作者 Vikas Hazrati 译者 乔梁 发布于 2008年3月18日

领域

架构 & 设计,

过程 & 实践

主题

敏捷 ,

质量交付 ,

客户及需求

标签

计划 ,

评论 ,

回顾 ,

争论

在雅虎的极限编程组有个很有趣的讨论，Gary Brown带出了一个耐人寻味的问题：几年来，我们教育和开导我们的客户使用敏捷，可是如果突然有一天，客户明显开始抵触敏捷开发了，我们的团队该如何应对？

尽管敏捷软件开发非常强调客户的交互和反馈，而讨论组成员的跟贴也很有意思，都偏向用户。大多数成员好像都同意：“客户是评判从软件中得到哪些业务价值的最佳人选，他可以选择是否用敏捷方法来达成他们的业务价值。Ron Jeffries提到：

我们的客户不应该在意敏捷开发。我们的客户对业务责任，但并不仅仅只限于软件开发。他们应该感兴趣的是

   -- 得到真正需要的软件；
   -- 能可靠工作的软件；
   -- 尽快交付的软件；
   -- 对他们的影响尽可能地小;
   -- 软件以其最容易最自然的方式运行。

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

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

似乎J. B. Rainsberger建议的方法是正确的。他提到

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

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

 

查看英文原文：Should the Customer Care about Agile?

译者 乔梁 有十多年软件开发及项目管理经验，专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。

• 更早的 >