敏捷该有“两条腿”——Rally重新定义敏捷思维

　　敏捷也有自己的“生命周期”，且随着市场需求的变化而不断进化。Rally重新定义的敏捷已经进化出了“两条腿”：一条由开发敏捷和业务敏捷组合而成的企业级敏捷，另一条则由ALM(生命周期管理工具)支撑的敏捷思想构成。“两条腿”起着相辅相成的作用。

　　“敏捷”对企业来说绝不是新概念，在Rally Software亚洲区高级技术顾问钟顺发看来，如果把传统的开发敏捷定义为1.0版本，Rally倡议的企业级敏捷就是2.0版。

　　“技术开发上的敏捷实际上十年前就已经被业内提出了，软件的敏捷开发思维其实是从制造业的敏捷思维嫁接过来的，而怎么能够串联业务的敏捷、团队的敏捷，达到端到端、从头到底的敏捷，是2.0版的敏捷，最终实现的是从业务到软件开发团队的整体敏捷。”钟顺发对记者如是说。

　　从企业敏捷开发“病例”说起

　　敏捷开发的项目，成功的案例有很多，失败的案例也有很多。但在笔者看来，失败的敏捷开发案例通常会具有以下特征。

　　第一是败于为人诟病的“公司政治”，也即公司管理出于“不信任”的缘故，不允许真正主导项目敏捷开发的角色存在，或者安排一个没有实权的人来充当最终决策人或者“总设计师”，这种场景常见于大公司，最后的结果是让每个参与该项目的团队都认为“我们不是主人，我们只是帮忙的，所以我们不会对愿景是否能够实现负责”。当出现问题时，没人能找到对的人来咨询该怎么做。当项目继续推进时，即便出现了应该做出愿景调整的情形，也不会有人主动站出来调整。

　　第二是败于迭代周期被愚蠢地“标准化”了。一种很令人“惊奇”的情况是，敏捷项目经常会被一些企业很随意地规划成“3天一次迭代”或“一星期一次迭代”而不给出任何原因，这意味着企业只是在刻意地提高迭代开发的速度，而并非在真正地使用迭代这种方法。事实上，迭代应当尊重产品的进化过程，这个过程包括开发、进化、反馈(这个过程是循环发生的)，而错误的迭代周期规划，会导致产品进化的畸形。

　　第三是对于愿景的实现过程分解得不够细。一个最朴素的道理是，越小的事情就越容易完成，但在企业内部却经常事与愿违。企业经常面对的是规模庞大的项目，项目的规划者常会出于对项目完成困难的畏惧而不愿花更多的时间将一个庞大的项目分解成足够细小的项目，于是当一部分容易完成的项目更早地被完成时，项目整体的完成时间会因为那些具有难度的项目还未被完成而延误。

　　第四是需求提交和被满足的过程出现了问题。笔者此前听说过一种场景，这一场景是发生在敏捷开发过程中的。当企业的一个开发团队要做迭代开发，来自客户的需求也不断地被提交过来时，就涉及需求权重的排列问题，简单说就是，先满足哪个需求。对此，产品经理、开发团队、销售或市场人员都会有不同的排序原则。如何解决权重安排时的冲突问题？这难住了很多的企业。

　　当然，上述文字并不能涵盖失败的敏捷开发案例所具有的一切特征，但至少能够摆出企业在敏捷开发中遇到的一些关键性问题，而对于解决上述问题，Rally独善其道。

　　业务与开发都要敏捷

　　无论什么样的企业，无论这家企业从事什么业务，要想更快、更好地发展，都可以考虑采用Rally提出的敏捷思维。

　　在Rally提出的敏捷思维中，包含五个层次的规划。最高层是愿景规划，是指企业从市场上获得灵感后，将这些灵感通过愿景的方式提交出来，愿景的提交频率一般情况下不会受到限制。往下一层是目标层，因为有了愿景就需要制定目标来完成。当企业有了目标，就能根据愿景把目标分解为一些特性，这就是第三层。实现了所有的特性，就等于实现了目标，于是企业又需要制定一个计划去安排在什么时间段去发布，并且有了发布计划之后，也需要让团队以迭代的方式继续实现交付，这是第四层。在最底层，需求被提交给团队后会被拆分成不同的任务，这些任务在Rally被称为故事(User Story)。这五层就像一颗洋葱一样层层相扣，从下到上是产生故事、发布计划、分解特性、完成目标，最终实现愿景。

　　在具体执行的过程中，企业该如何应用Rally提出的敏捷思维解决问题呢？

　　钟顺发以解决需求排序问题为例解释称，因为开发团队会做敏捷开发，业务团队也导入了敏捷的思维，在排序时开发团队会以技术优先，业务团队也会有自己的排序原则，二者之间会存在“冲突”。这时，中间就需要一层接口，即在业务上进行一个定期的规划，把开发敏捷和业务敏捷串联起来。具体的做法是，项目负责人每个星期或者每个季度把所有与项目存在利益关系的角色成员召集起来，先宣布这个星期或者季度的重点目标是什么，再给出这个季度或这个星期搜集上来的需求(用户故事)，然后根据需求列出十大特性，让所有角色都参与做排序，最后一起对排序做公正的表决。表决后的结果在一定期间内不可以改动，即便是客户也不能。

　　“用户关注的是目标而不是特性，业务团队只关心发布周期，开发团队只关注要实现哪些特性，在排序时就不会出现冲突，排序的结果出来后也会很容易被一致认同。更重要的是，在这个过程中，需求的描述是从客户的角度给出的，而不是工程师的角度，所以开发出来的产品一定会满足用户和市场的需求。敏捷不光要应用到开发上，也要应用到业务，企业只有将业务的敏捷综合了开发的敏捷，才能释放潜能。”钟顺发如是说。

　　ALM可与敏捷共存

　　敏捷思维会帮助企业实现对市场变化的快速响应，而ALM(生命周期管理)工具会严格控制企业中不适应业务需求变化的那些流程，二者是否能够共存？

　　钟顺发认为在Rally可以实现二者的共存。

　　传统的ALM工具是管控型的，但Rally提供的ALM工具完全没有管控，并且不注重流程，而注重沟通和减少浪费。企业采用传统的ALM工具会浪费很多资源，比如时间，从企业决定实施一个项目开始，到项目实施完毕，中间的流程可能会耗时好几个月。

　　可为什么企业还需要ALM工具？

　　软件开发在30年前没有一个很合适的生命周期管理方法，所以只能借鉴传统行业中比如造车、盖房的方法。而因为房子造错了，拆了重建代价很大，因此不允许在规划中有错误出现。但在软件开发环境中，即使是出错了，也允许修改代码，纠错的成本和风险会低很多。

　　所以，传统的ALM工具是以一种不允许犯错误的思维或者是先预知问题，再预防问题的思维去做策划和编排。

　　可导入了敏捷思维之后，就可以鼓励企业“尽早”犯错，并希望企业在犯错中学习，在学习中“尽早”更正。

　　“Rally提供的ALM工具不会帮助企业做一个严谨的、闸门式的审批，而是允许企业做不断的规划和调整。以前的ALM工具都会规划一个固定的、很长的周期，然后所有的团队都要按照这个周期计划去做，即使半途出现差错也没有办法。

　　但Rally的ALM工具只会规划眼下短期内要做的事，然后短期内再规划一次，并以波浪的形式持续地发布和持续性地开发，这也是Rally的ALM工具与其他ALM工具的不同之处。”钟顺发如是说。

　　对话钟顺发：实现敏捷需工具与思维结合

　　中国计算机报：IT发展很快，应用在企业中所处的地位也越来越重要。ALM工具为企业生产和交付应用起到了怎样的作用？

　　钟顺发：因为移动互联网的兴起，用户对应用的需求和使用方式发生了变化，比如应用的交付速度越来越快，发布周期也越来越短。在采用传统软件开发模式时，不同的企业会感觉到不同程度的压力。企业在开发软件时很重视速度，认为产品上市一定要快，但在寻求快的过程中他们发现，之前的开发模式在运转过程中会产生资源的浪费，比如流程的审批和审核会浪费时间资源。为什么敏捷会兴起？因为敏捷的概念很实用，是实现产品快速交付的方法之一。但当交付速度达到了企业的要求后，交付的产品是不是市场所需要的产品？这时就需要“第二步”的敏捷，即注重业务的敏捷。

　　中国计算机报：谈到生命周期，比如一个人，他的生命周期会分成不同的发展阶段，每个发展阶段，他遭遇的挑战都不一样。当下企业的应用生命周期管理正处于怎样的生命周期阶段，这个阶段正面临着怎样的挑战？

　　钟顺发：其实，企业跟人一样，要不断地改进。为什么很多企业在思考如何快速地适应市场变化？很多传统的行业比如银行业等，有着严格的规范，但这些规范也局限了它们的发展速度，因为它们要规范，要有一定的流程和一定的管理方式，可这些管理方式和流程往往阻碍了创新。当企业失去了创新的动力时，适应市场的速度就会变慢。很多企业的流程，都是瀑布式的流程，而为了适应市场需求，就需要一种新的机制。Rally一直倡导的是业务上的敏捷，即怎么把业务上的敏捷跟开发团队的敏捷结合在一起。

　　中国计算机报：1.0的敏捷和2.0的敏捷有何不同？

　　钟顺发：1.0和2.0是对敏捷的两种诠释。因为面向不同的对象，对敏捷的诠释是不一样的。比如面向开发团队的敏捷，是指开发团队要具备一些跨职能的能力，要在很短的时间实现迭代开发。面向管理层的敏捷，是指管理层要及时地感受到市场的变化，并做出运营策略调整。技术开发上的敏捷实际上十年前就有人提出来了，是把从前制造业的敏捷思维嫁接过来的。而能够串联业务的敏捷和团队的敏捷，达到端到端、从头到底的敏捷，是敏捷2.0的诠释。

　　中国计算机报：如今市场上也有很多ALM工具，Rally是否也有相应的工具？Rally的工具与其他工具相比有怎样的特色？

　　钟顺发：其他的ALM工具比较侧重公司管理，而当导入敏捷的思维后，你会发现企业会受到很多局限，比如很多人都试图把传统的流程套在敏捷的流程上，结果发现格格不入。而Rally是要让企业把流程的“包袱”丢掉，重新以敏捷的思维使用工具。传统的ALM工具有很多的分类：规划类的工具、需求管理的工具、开发管理的工具和持续集成的工具(或者叫变更的工具)。但实际上整个ALM工具的使用是在一种不信任的前提下的。比如管理层认为团队会出错，才使用了ALM工具。但Rally的ALM工具是把各种类型的工具都轻巧地集成在了一起。管理者会发现Rally的ALM工具是个非常开放的平台，从最原始的想法开始，到规划、开发、测试，都会有一个全面的、视觉化的体验。同时，Rally不排除企业使用原来的工具，因为Rally有接口，如果企业采用了传统的工具，Rally会用接口来导入传统工具的数据。并且Rally不光专注于提供工具，也提供咨询服务，Rally不主张用户只关注工具，而是建议用户通过接受培训完成思维的转变。Rally也不会要求用户一夜之间把之前使用的工具都丢掉，因为有些工具比如开发工具、测试工具，企业还是需要的，只是用法需要改变，思维需要改变。Rally会提供很多的培训，告诉用户什么需要保留，什么需要去除，以及要从什么样的角度看待开发流程。

　　中国计算机报：如果一个企业原来在本地开发应用，并使用了某个ALM工具，现在这个应用要转到云上去开发，ALM也要随之迁移到云。在这种情况下，需要做哪些准备，注意哪些问题，实施的过程大致是怎样的？

　　钟顺发：有很多ALM工具已经迁移到云端了，Rally的ALM工具也是其中之一。但实际上这个过程在技术上不是问题，测试也不是问题，讨论最多的是安全问题。因为大家都怀疑，数据在云端安全么？有一些规范的企业，比如银行，它们被引导到私有云上，因为这是大势所趋。但私有云也好，公有云也好，迁移到云是观念教育的问题，是安全的问题。很多企业都会有防备心理，因为管理层对安全风险有恐惧感，所以需要进行观念教育。比如一些管理平台上的测试案例，或者一些用户的需求报告，这些是高等机密吗？我认为，随便去市场做个问卷都能搜集到用户需求，所以这些不是很高等级的机密，即使被盗用问题也不大。另外，一些开发数据很可能在某个时间段有用，等产品开发完毕后就没用了。

　　中国计算机报：有关移动应用ALM工具的选型，在原则和技巧方面，您有何建议？

　　钟顺发：当企业管理层用传统的敏捷思维去使用工具时，除了能实现对手下的管控，其实对公司来说一点帮助都没有，反倒会对公司发展起到阻碍作用。所以，如果要选型的话，不止要考虑工具是否能带来团队生产力的提高，也要考虑是否能为客户带来价值的提高，而不只是考虑要实现透视团队。当Rally提供的ALM工具跟传统的ALM工具放在一起的时候，会给人一种苹果跟橙子放在一起的感觉，这是因为Rally认为，自己面临的最大挑战或者竞争，不是市场上那些其他做ALM工具的公司，而是用户没有认识到使用新的敏捷思维去发挥工具长处的现状。所以，Rally每进入一个新的市场时，根本不会在乎企业用户正在用什么ALM工具，而是在乎企业是否已从思维上发生了转变。这个时候，Rally的咨询团队就变得非常重要，因为他们能够提供一个端到端的解决方案，他们也希望能够告诉用户，敏捷不光是开发上的敏捷，也包括业务的敏捷，也只有企业业务的敏捷综合了开发的敏捷，才能释放企业的全部潜能。

　　本报记者 于杰

关注读览天下微信， 100万篇深度好文， 等你来看……