进度与交付的那些事儿——持续沟通、持续反馈
说起进度和交付,我想起一个和客户开发人员共同完成的项目。ThoughtWorks为客户提供敏捷教练的服务,而带领大家完成一个项目,才是检验大家各种敏捷实践的试金石。在项目中,这个团队需按客户要求,在三个迭代的时间内交付一个符合用户期望的数据转换插件。参加项目的是已有6个月以上敏捷实践经验的团队。这样的“敏捷”团队在项目中的表现又如何呢?作为敏捷团队,每个迭代是不是都能按时交付用户想要的特性呢?
迭代一,铩羽而归
团队在第一个迭代中,埋头苦干,计划完成尽可能多的需求。把各种脏活累活抗在自己肩上,甚至出现了加班。然而,最终客户却并不满意。痛定思痛,大家总结了如下问题:
- 团队开始开发的时候,没有与客户确认需求,很多需求不清晰。这导致开发人员根据自己的假设做事。为了满足后期各种可能发生的需求变化,插件被做到可以配置,以致于最终的插件无比复杂 。
- 团队在开发结束之后才给用户看成品,修改成本非常高。而从用户角度看,团队只有在项目开始的时候询问需求,在迭代结束时给用户看成品,其间没有任何交流。最后插件的功能和界面对用户来说,是莫大的“惊悚”,而并非“惊喜”。
- 有两个需求是互相冲突的。团队没有和用户确认,就任选一个做了,用户并不认可。
由上面的问题,我们发现,这个典型项目中发生的问题,并不仅仅该项目的问题,各个项目都存在。然而要避免或者减轻这些问题带来的后果,团队要做的就是沟通,找用户要到真实的需求,要到反馈,对工作方式和产品做出改进。
迭代二,硕果累累
团队在第二个迭代中,从做估算到做计划、再到开发、客户验收,全程和用户保持沟通。任何一个决定都要客户给出反馈。由于任一阶段,任一决策和设计都经过客户把关,最终插件自然也就和用户想要的八九不离十。团队成员们非常开心,他们又做了如下改进:
- 不熟悉插件的宿主软件的同事,要多学习,多去写一写。例如在开发之余,可以做些练习。等到正式开发时,就可以很快上手了。
- 除了和用户沟通功能上的需求,还需要和客户沟通质量上的需求(项目中的非功能性需求,例如性能。该项目需转换Gigabytes级数据,性能有一定的要求) 在这些问题中,我们发现:
- 同事不熟悉插件的宿主软件,但是在第一迭代中,并没有人提出这个问题。然而到了第二个迭代,当团队交付顺利的时候,他们勇敢地提出要求抽时间学习,以提高效率。我们可以想到,任何项目,都会有同事对现有技术和框架不熟悉。那么我们是不是也可以为他们提供一些时间去上手呢?
- 团队对自己和客户之间的沟通有进一步的要求——非功能需求。这在项目的分析阶段是经常被忽略的。大多数情况是:对该满足非功能性需求的时候,没有满足。没有要求更高质量或者性能的地方,反而被做得非常强大。为了改进,团队觉得在平时的交流中加入此类问题的沟通。
迭代三,成员突变
迭代三中,由于部门经理希望团队间的知识可以分享,所以对不同组的成员进行了替换以达成知识传递。具体做法是:团队成员中只能留下一半“老成员”。在这个迭代中,我们预期插件的交付速度会下降。而结果确实如此,参与替换的三个团队中,两个团队的速度下降非常明显。而另一个团队的速度却不降反升,这是为什么呢?
团队针对突来的“替换”,总结了如下问题:
- 有的团队成员之前没有参与太多交付工作,对技术和框架不熟悉。而有的团队成员非常强,一直在自己做开发,和用户交流,别的同事只有很少的机会参与开发,而长此以往,他们了解的项目知识越来越少,开发能力越来越差。
我们特别注意到这个差异化现象:有的团队成员对技术和框架不熟悉。这不应该出现在当前团队中,因为他们每人都至少有两年以上的开发经验。然而当我们了解到,有一个同事是项目组中的“超人”时,我们明白了其中的缘由。这个“超人”和其他“不熟悉技术”的同事以前是同一个团队的,而这个“超人”在项目中是项目经理兼技术经理的角色。这次替换暴露了这个问题。随后,他和他们团队的成员也意识到这个问题的严重性,回去制定了知识分享的计划。
到此为止,插件开发的项目就讲完了。我们再来看看其中的问题:
- 和客户沟通少,客户反馈少。(功能和非功能需求)
- 和客户沟通晚,反馈太晚导致修改成本高。
- 团队成员有时也不会对对项目提出反馈。例如在压力状态下,没有去熟悉工具和框架。
- 团队成员之间有时也不会对问题提出反馈。例如替换后项目经理的知识传递问题。
而这一切都是关于沟通和反馈。我们肯定技术在进度和交付中的重要性,同时我们也应认识到:进度和交付不是一个独立的问题,而是一个系统问题。系统中的非技术因素对交付的影响可能是致命的,而沟通和反馈是保证交付的重要方法。
感谢 张凯峰对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至 [email protected]。也欢迎大家通过新浪微博( @InfoQ)或者腾讯微博( @InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。