Naresh Jain谈敏捷在印度的发展趋势

本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/cn/news/2013/02/agile_india_2013

近日，InfoQ采访了Agile India 2013的Naresh Jain以了解敏捷在印度的发展趋势。Naresh谈到了印度这个环境下的产品识别、精益创业、持续交付等话题。

InfoQ：去年以来，敏捷在印度的使用状况发生了哪些变化？

Naresh Jain：从组织行为改变这个角度来说，一年的时间其实很短暂。因此，我并未看到有什么明显的变化，但显然，我在去年所拜访的很多组织都超越了Scrum，并很认真地探索XP实践，有些组织甚至还在试用看板。精益创业的影响倒是不太大。我听说很多公司大佬们都在谈论经过验证的学习、价值与成长假说，有时甚至还会谈论枢纽。他们将团队推向持续交付，然后发现了反向的测试金字塔问题。大多数大型组织都有自身的习惯，但他们依然在不屈不挠地在打破这些习惯。当我们谈“变得敏捷”而不是“追随敏捷”时，有些组织甚至发现自己被自己搞的一团糟。

我所看到的另一件有趣的事情是客户要求项目在确定的价钱、确定时间的敏捷方式下进行。公司也在竞相掌握这种新的趋势。表面上看，这有些自相矛盾，但我觉得这是件好事，它让企业对现有的业务模型提出了质疑。

最后，我发现印度的很多Scrum认证公司开始变得安静下来，极少数大公司，如PMI、APMG及ICAgile等加入了竞赛当中。从认证的角度来看，我们对2013年的发展拭目以待。

InfoQ：在印度，是有越来越多的项目团队在开发过程中开始采用持续交付了么？他们一般会遇到什么挑战？

Naresh Jain：事先声明，我并没有足够的数据从整体上进行介绍。但我会根据过去一年中所接触到的一些公司的情况来尝试回答你的问题。

我看到印度的软件产业使用了各种各样的工作模型，这些模型对持续交付实践也产生了不少影响：

• 固定价格（新的开发、增强与测试项目）
• 时间与材料（研发、定制化、实现、完全的第三方测试、维护与支持项目）
• 人力资源扩充（随机的任务）
• 保持（小的增强与Bug修复）
• 快速解决（构建电子商务、移动应用、Web应用、集成项目与网站等的初创公司）

上面所有这些，只有最后两种模型有可能应用某些持续交付实践。

现有项目的团队在考虑持续交付时会遇到一些头疼的问题，原因如下：

• 他们不相信持续交付，也看不到持续交付的价值所在
• 管理者觉得持续交付风险太高
• 对于很多公司来说，持续交付会破坏现有的业务模型
• 管理者缺乏对团队能力的信任
• 团队的结构依然是瀑布模型，不同的职能部门（销售、业务分析、架构、UI、开发、测试、数据库管理员、发布、运维）处理项目生命周期的不同部分
• 即便组织想要尝试，反向的测试金字塔也会成为严重的瓶颈
• 大多数客户都不希望频繁的软件部署，因为过去的情况表明这会制造混乱

InfoQ：作为大型的离岸与外包中心，我们很难在印度的项目中应用精益创业原则么？

Naresh Jain：传统上，离岸团队不必关心客户开发或是价值假说。他们从来不去关注“我们是否在构建正确的产品”这一问题。他们的关注点都放在了“正确地构建软件”这一问题。几十年来，我们相信我们可以分离这两个关注点、将其顺序化、然后独立完成。也就是说，我们可以首先花费足够的时间明确需求，然后通过便宜的团队根据规范通过离线的方式准确构建出来即可。

哎，让每个人都感到惊讶的是，我们认识到这种模式从根本上来说就是有缺陷的。这两个关注点是定义与构建一个成功产品不可分割的有机整体。

精益创业原则完完全全击中了我们的痛处。现在，我们认识到了真正短小的构建——度量——精益周期（或是Kent Beck所说的学习——度量——构建周期）的价值，枢纽与持续交付的重要性。我发现在这个模型下工作时，协作的频度、双赢的力度以及团队的效率都会变得异常的高。

甚至连产品识别（以用户为中心的设计）实践（如角色模型、用户目标、故事图、低保真原型等）都被证明对离岸团队具有非常高的价值。

因此，应用精益创业原则确实很难，但对于离岸（无论是不是外包）环境来说它确实非常重要。

恕我直言，对于想要拥抱这些原则与实践的团队来说，最大的障碍在于缺乏认知与公开。我曾与组织一同来实现这些实践，他们告诉我从这些原则与实践上获益颇丰。有些组织甚至表示这些实践所带来的价值要超过Scrum和敏捷。

InfoQ：在过去几年中，看板的使用率是不是有了提升。对于分布式或是离岸团队来说应该如何扩展呢？

Naresh Jain：过去几年，印度公司使用看板的方式压根儿就不对。我记得在2003年曾领导过一个维护项目，那时我们刚开始实践XP，经过几个“检查与适应”周期后，我们的过程逐步演化成为了一个简单的看板风格的工作方式。我们在过程中限制工作，聚焦在一个流程中，保持一切可视化，对度量进行了自动化并改进了流程，我们有了服务类的概念，凡此种种。

我相信这是众多离岸项目的本质，特别是维护、支持与实现项目。他们的严格程度不尽相同，思维过程可能会落后于过程的演进，但最后的结果却是一样的，就是因为这是工作的本质。

我说了这么多，就是想表示短周期中的协作工作被漏掉了。我们并没有将这些原则应用到新的产品开发或是主要的增强项目上。在过去两年间，我看到有很多公司在对流程进行合理化梳理，形成了跨职能的团队，聚焦在自底向上的流程改进上。敏捷，特别是Scrum，应该能够承担起这种变化。

现在，团队与公司都认为看板是其流程改进的下一个逻辑步骤。

过去的印度，看板并没有形成品牌化与认知度。但很多当地的工具公司都在营销其工具，并且非常强调对看板的支持。这逐步增加了人们对看板的认知度。

关于在分布式与离岸团队中扩展看板，我并未看到有什么特别的问题。不少工具都可以填平之间的沟壑。此外，现在也有了一些经验，这有助于大家更好地认识看板。

InfoQ：在Agile India 2012大获成功之后，你现在在组织Agile India 2013。今年的大会与去年相比有何不同呢？

Naresh Jain：基于Agile India 2012的一些经验，下面是值得关注的一些改进：

• 去年的会议计划完全通过开放的提交系统实现的。虽然经过4个月不懈的努力，还有开放的评审系统，但一些议题的质量还是很差。此外，由于使用了开放的提交系统，我们无法吸引很多知名人士。这次，我们会邀请25个来自于全球的敏捷/精益大家；每个人都会有2到3个最擅长的话题。这次会议会支付演讲者报酬。为了鼓励其他从业者展现其第一手经验，我们还会通过开放的提交系统接受约20%的话题。这确保了会议计划的高质量。我们相信，这次的大会将会成为有史以来最棒的一次。
• 根据参与者的反馈，我们发现3天的会议时间有点长。他们觉得会议涵盖的范围太广。因此，我们将大会分成了两部分。前两天重点关注管理与领导力，后两天重点关注技术与交付。这样，与会者就会更加明确，也会吸引更多的参与者。
• 此外，我们今年还会召开GuruPLoP，这是印度举办的首届模式与程序模式语言大会，将在今年3月的3到4日举办。
• 有很多人希望能有更加具体的手把手课程。因此，我们将会举行14场讲座，这与大会本身是独立的。
• 我们上次有7个并行的会场，分布在不同的楼层，这导致参会者有点晕。这次，我们将会有4个并行的会场和一个开放空间。所有房间都位于中央区域的同一楼层。相比上次来说，这次的房间要大很多，确保与会者能更加舒服地参会。
• 我们期望每天的参会者能有650——700人。此外，还有100个与会者能够参加付费的课程。因此，在这4天当中，我们会有1500个与会者。相比于去年的会议，与会人数将会翻番。
• 与上届大会不同的是，这次的赞助商场地将会位于中央区域。吃饭的地方与上届一样，开放空间地点也计划不变。这样可以确保赞助商能够与参会者有更好的交流和沟通。
• 每天的大会都安排了晚宴，可以让与会者之间及与讲师有更好的交流。
• 除了会场的布局外，大多数与会者都很喜欢上次的会议地点。今年，我们将在Sheraton酒店举办大会，这是家新的五星级酒店，比上次的还要好。

总的来说，我们希望与会者能有最棒的参会体验，这种体验将会伴随他们很多年。

查看英文原文：Interview with Naresh Jain on emerging Agile trends in India