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