在雅虎的极限编程组有个很有趣的讨论，Gary Brown 带出了一个耐人寻味的问题：几年来，我们教育和开导我们的客户使用敏捷，可是如果突然有一天，客户明显开始抵触敏捷开发了，我们的团队该如何应对？
尽管敏捷软件开发非常强调客户的交互和反馈，而讨论组成员的跟贴也很有意思，都偏向用户。大多数成员好像都同意：“客户是评判从软件中得到哪些业务价值的最佳人选，他可以选择是否用敏捷方法来达成他们的业务价值。 Ron Jeffries 提到：
我们的客户不应该在意敏捷开发。我们的客户对业务责任，但并不仅仅只限于软件开发。他们应该感兴趣的是 -- 得到真正需要的软件；
– 能可靠工作的软件；
– 尽快交付的软件；
– 对他们的影响尽可能地小 ;
– 软件以其最容易最自然的方式运行。
Ron 认为，作为软件开发人员，团队应该集中精力做正确的软件，并确保用户高兴。他建议，如果团队已经花足够的时间来向用户介绍敏捷，而客户还是不感兴趣的话，那么团队就应该别在用户面前鼓吹敏捷了。他也提到这丝毫不意味着团队应该为此惶恐不安，他们应该确定哪些实践可以很好的发挥作用，哪些不能。以后再一点儿一点儿地改进。 Zhon Johansen 建议要以巧妙的方式向客户展显敏捷的好处，从而让他感觉敏捷并不是强加于他的，比如用户故事的优先级，因为这事对客户来说是极其重要的。如果客户对优先级这事不感兴趣，那么团队应该给他一份团队根据自己的判断列出的一张优先级列表，并问客户是否认可这些。这要比没有优先级要好得多。
似乎 J. B. Rainsberger 建议的方法是正确的。他提到
我会邀请他们参加回顾会议（如果叫“回顾”会把他们吓走的话，就换个名呗），向他们灌输一个主题：“我们如何更好地一起合作”。我的目标就是发现三个他们最希望从我们这里期望的事，并告诉他们，我们最希望从他们那里得到的三件事。让我们看看这么做六个月后，是否有助于关系的改进。
根据过去以及现在正在进行的软件项目，不难想像客户是很难全心投入团队中的，然而，就像上面讨论中建议的那样做，不用给他们详细地解说敏捷，事情也一样可以办到。讨论组的成员好像都一致同意：客户知道什么是最好的，开发团队不应该将敏捷强加于客户。客户应该能按他们喜欢的方式工作，而开发团队应该想尽一切办法让客户获得成功。 查看英文原文： Should the Customer Care about Agile?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论