大咖直播-鸿蒙原生开发与智能提效实战!>>> 了解详情
写点什么

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

  • 2013-02-05
  • 本文字数:3181 字

    阅读完需:约 10 分钟

近日,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

2013-02-05 06:05838
用户头像

发布了 88 篇内容, 共 272.8 次阅读, 收获喜欢 9 次。

关注

评论

发布
暂无评论
发现更多内容

CloudPosse 的 Terraform 最佳实践

大可不加冰

DevOps 基础设施即代码 IaC Terraform HashiCorp

小谈startup类ConfigureServices方法的作用

喵叔

11月日更

深入学习 SAP UI5 框架代码系列之一:UI5 Module 的懒加载机制

汪子熙

JavaScript SAP 签约计划第二季 ui5 技术专题合集

深入学习 SAP UI5 框架代码系列 | 内容合集

汪子熙

JavaScript SAP 内容合集 签约计划第二季 技术专题合集

深入学习 SAP UI5 框架代码系列之四:SAP UI5 控件的元数据实现

汪子熙

JavaScript SAP UI5 签约计划第二季 WebIDE 技术专题合集

EasyRecovery,重新找寻丢失的文件

淋雨

EasyRecovery

深入学习 SAP UI5 框架代码系列之二:UI5 控件的渲染器

汪子熙

SAP 签约计划第二季 ui5 渲染器 技术专题合集

深入学习 SAP UI5 框架代码系列之三:HTML 原生事件 VS UI5 Semantic 事件

汪子熙

JavaScript SAP 签约计划第二季 HTML原生事件 技术专题合集

视野数科借助 SAE + Jenkins 打造云原生 DevOps,运维效率提升 60%!

阿里巴巴云原生

阿里云 Serverless DevOps 云原生 SAE

盘点Flutter领域的点点滴滴 【专题合集】

坚果

flutter 内容合集 签约计划第二季 技术专题合集

工业3D视觉,为智能制造打开新视域

脑极体

转型中的学习型组织 ——阅读《第五项修炼》有感

研发管理Jojo

系统性思考 企业转型

音视频理论(1)- 音频格式之 Monkeys Audio(APE)

liuzhen007

签约计划第二季

Flutter 中的手势【Flutter 专题10】

坚果

flutter 签约计划第二季

Linux安装mysql

犟马骝

CPU的流水线指令设计

JavaEdge

会日语的开发工程师看过来~

马农驾驾驾

Java c++ php .net 日语

【死磕Java并发】-----J.U.C之Condition

chenssy

11月日更 死磕 Java 死磕 Java 并发

Redis持久化策略——RDB

蝉沐风

redis redis持久化 rdb RDB 快照

深入学习 SAP UI5 框架代码系列之七:控件数据绑定的三种模式 - One Way, Two Way 和 OneTime 实现原理比较

汪子熙

JavaScript 数据绑定 SAP UI5 签约计划第二季 技术专题合集

不改一行代码,轻松拥有企业级微服务治理|MSE微服务治理专业版重磅发布

阿里巴巴云原生

阿里云 云原生 微服务治理 MSE

模块五作业

doublechun

「架构实战营」

深入学习 SAP UI5 框架代码系列之六:SAP UI5 控件数据绑定的实现原理

汪子熙

JavaScript SAP SAP UI5 签约计划第二季 技术专题合集

深入学习SAP UI5框架代码系列之八:谈谈 SAP UI5 的视图控件 ID,以及 SAP UI5 视图和 Angular 视图的异同

汪子熙

JavaScript 大前端 SAP UI5 签约计划第二季 技术专题合集

新成就!OceanBase 入选 Forrester 首份分布式数据库报告

OceanBase 数据库

数据库 开源 新闻 oceanbase 荣誉

Flutter自定义日历【Flutter 专题 11】

坚果

flutter 签约计划第二季

Flutter 2.5 的新特性【Flutter专题12】

坚果

flutter 签约计划第二季

畅聊分布式体系架构

吴脑的键客

分布式架构

Exchange漏洞分析:SSRF RCE

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 安全漏洞

深入学习 SAP UI5 框架代码系列之五:SAP UI5 控件的实例数据修改和读取逻辑

汪子熙

JavaScript SAP UI5 签约计划第二季 控件 技术专题合集

小程序电商微服务拆分和框架选择

云里雾花

Naresh Jain谈敏捷在印度的发展趋势_研发效能_Anand Vishwanath_InfoQ精选文章