敏捷了,而且还是离岸敏捷,是自找麻烦吗?

  • Amr Elssamadisy
  • 乔梁

2008 年 10 月 12 日

话题:敏捷文化 & 方法

Kevin Coleman 讲述了他与某声称自己敏捷的离岸开发团队合作的故事,并提及其中的痛苦与烦恼。该文章已经发布在 Agile Journal 的九月刊上。几位读者也用他们自己的经历证实了 Kevin Coleman 的说法。那么,就在现今的业务现实中,敏捷方法能够成功地用于离岸团队吗?

其中,Kevin 所述的一个重要的假设是:

大多数离岸开发组织以传统瀑布开发方法做为组织的标准开发方法;使用这种传统方法,就要定义一些需要很大规模才能完成的任务,是典型的组织化的项目。这些传统开发技术与敏捷的基本观念背道而驰。

在这样的前提下,Kevin 谈到一堆很常见(且昂贵的)问题:

离岸开发团队拿到一份清单,然后分析需求,评估其大小及复杂性,以及每个条目需要多少努力才能完成。基于这些评估以及在岸与离岸开发团队的规模,定义并推 敲哪些功能可以在这个 Sprint 中交付。一旦确认了这些交付物,开发过程就开始了。问题也就开始出现了…… 随着演示以及概念确认等这些敏捷过程中所说迭代式发掘过程,新需要也就不断被发现了。而随着重写代码、评估这些新需求,以及计划的变更,都会增加成本。

但是

这种情况在好转。很多混合型(敏捷与传统)项目使用时间盒管理技术,并称之为“敏捷”。时间盒技术就是指在固定的时长中完成一件或一系列任务。一旦确定了 时间盒,开发人员将在这段时间里尽其所能进行工作。因此,与典型瀑布项目中那种一直工作到某(些)任务完成不同的时,此时离岸团队只工作某个固定时长(比 如说,五天)。而五天后,要么那些初始计划的工作被完成了,要么就被放回到 Backlog 中以后再完成,或者完成了那些替代了原有这个 Sprint 中所计 划的工作。之所以说这个 Sprint 结束了,是因为实现这些功能的成本已经发生了变化,需要由在岸团队重新评估。

另一种混合方法就是使用功能演示代替了传统的 Reviews。在工作过程中,离岸团队得到来自在岸团队、业务人员 /SME 和关键项目干系人的反馈。而这些 反馈要么被加入到这个 Sprint 中,要么会因明显增加工作量而推迟实现,将其放回 Backlog 中,等待在后来的 Sprint 中实现。如果这个反馈需要 在某个特定时间内完成,那么你只能猜测,并将其放到这个 Sprint 的任务列表中,对其进行评估,并安排其优先级,还要调整你的开发计划。

根据 Kevin 所述,当一个敏捷团队与一个非敏捷的离岸团队合作时,几乎任何事情的成本都提高了,而其根源似乎是:很多离岸团队并非真正的敏捷。该文所有的评论者似乎都有相似的经历:

非常赞同“在两个公司合作完成一个或两个项目并建立信任之前,结合这两种方法的风险很大”这一观点。我还没看到过哪个传统瀑布型组织很顺利地完成敏捷项目。通常,你不得不决定采用哪些两公司各自所坚持的方法,从而创造出一种混合型过程。

还有,

提醒那些使用敏捷方法的离岸开发者,你要确保开发人员认识到:离岸开发人员消耗的是你的事业、金钱和时间。当开发者开始干活时,全面的计划就要出台。而此时如果你被排除在外,还没有持续沟通机制的话,那么你的麻烦就来了。

还有人提到,

此时此刻,我正遇到这个问题——很高兴我不是唯一的一个。

InfoQ 的读者,你有同样的经历吗?如果有,提醒您留意的是,该文中对于敏捷离岸开发的大部分内容是持肯定态度的。——这是个错误的信息呢,还是 Kevin 落到了不幸的少数派中?

查看英文原文:Agile and Offshore: Asking for Trouble?
敏捷文化 & 方法