分类: 敏捷, 组织运营变革

在这瞬息万变的环境里,企业的生存与发展状况取决于其快速响应变化的能力,而敏捷运作是构建该能力的核心。

敏捷和其他创新思想一样,需要时间传播。全世界不少企业都已迈向敏捷的运作模式,也有很多传统企业,还没有尝试敏捷,处于观望评估的阶段。从2001年公布敏捷宣言至今,经过十来年的时间,敏捷在中国可以算是已经跨越了鸿沟,逐渐成为主流。作为世界范围内敏捷运作的领袖,ThoughtWorks很自然地就会接触到实施敏捷的这些早期使用者企业。这些企业在实施敏捷的过程中获得了明显的改进,也遇到不少困难。

与其独自探索,不如向行业的先行者学习。在敏捷逐渐成为主流的这十几年间,行业也一定为后来者积累了可参考的经验,这对于还在观望评估的企业来说,无疑会是宝贵的财富。ThoughtWorks在2017年6月至7月期间进行了一项针对中国企业的敏捷实施调查,了解这些早期采纳敏捷的企业:

  • 为什么要实施敏捷?
  • 面临哪些挑战,经历了哪些困难?
  • 采用了哪些敏捷实践?
  • 采取了哪些实施措施应对那些挑战和困难?

希望通过这个调查的结果,能为后来者提供有价值的参考。

当前实施敏捷企业的特征

本次调查的范围主要是ThoughtWorks中国所接触的行业人士,多是敏捷在中国的早期实施者。调查参与者总共229名。调查参与者来自全国各地,40%北京、9%上海、17%深圳广州、19%成都杭州武汉西安。调查不可避免有局限性,但我们仍相信结果具有一定代表性。

 

受访者来自不同行业,其中来自互联网企业的26%、信息科技21%、通信16%、金融17%。这些行业面临激烈的市场竞争和技术变革,必须走向更敏捷的运作方式,很自然地就会实施敏捷。

调查的参与者主要是敏捷教练(25%)和项目经理(17.6%)。这些角色都有提升开发团队交付能力的职责。调查参与者也包括开发(15%)、测试(14%)、产品经理(7%)、需求分析师(4%)。也有不少中层与高管参与调查,其中部门经理占10%,高管占4%。非研发人士也逐渐认识到敏捷的意义,参与了我们的调查。

敏捷实施规模大部分在100人以内

企业敏捷实施的团队规模大部分(79%)在100人以内。其实,这是一个趋势,随着技术和工具的发达,一个人能做的事越来越多,所以团队规模也自然变小。更重要的是,自主小团队和网络式组织结构,更灵活、更能够产出成绩。这也符合敏捷理念。只有特别复杂的系统,才需要大规模100人以上的团队。我们仔细分析了500人以上的敏捷实施团队,他们大部分实际上是多个独立产品线并行交付。单产品的交付,大部分还是100人以内。

敏捷实施的主要目的: 缩短周期、提高质量和满意度

企业实施敏捷不是为了敏捷,而是要达到效果。

有69%的受访者表示他们企业实施敏捷最主要的目的是缩短开发周期。这是通过更快的迭代节奏来达成的。贯彻和运作精益思想、减少浪费、解除瓶颈也是重要手段。所以,很多企业会同时实施敏捷和精益。有些人误以为敏捷会导致质量下降。其实,敏捷是有保障质量的理念和实践,有60%的受访者认为“提升质量”也是实施敏捷的目的,49%的受访者把“客户满意度”也设为重要改进目标。

其他实施敏捷的目的如下:

  • 缩短开发周期(69%)
  • 提高质量(60%)
  • 提升用户满意度(49%)
  • 提高人员的能力(30%)
  • 增强协作(43%)
  • 减少工作量,提高产能(32%)
  • 产品创新(17%)
  • 改变管理方式,让成员更有参与感(34%)
  • 其他(4%)

敏捷实施周期与效果:坚持6个月,必有效果

大部分(56%)受访者回复他们企业实施敏捷不到一年。这可能是受访者范围的局限性——敏捷在中国的推广已经有10年了,那些前几年实施敏捷的企业应该是早期领先者,敏捷已经逐渐受到认可,这是再次崛起的一波新浪潮。实施敏捷的企业,不管是刚起步还是实施多年,43%表示有所改进,18%表示获得了显著的改进。敏捷实施就是持续改进、系统性地解决问题,如果能够坚持半年以上,效果必然大增。

敏捷实施要解决的问题

实施敏捷是一个富有挑战的变革。敏捷本身要解决的也是个复杂问题。我们向受访者询问了这些挑战的影响程度:

  • 不涉及
  • 没有遇到这个问题
  • 偶尔遇到这个问题,没有影响
  • 偶尔遇到这个问题,影响不大
  • 遇到这个问题,对我们有影响
  • 经常遇到,影响很大
  • 就是它搞得我们特别累

我们按照挑战的影响程度分为三大组。每个企业的成长旅途都不同,所以它们面临的挑战也不同。然而这其中存在着规律,它们所面临的挑战的影响程度或许能够被粗略的归纳为“需求与架构、流程治理、以及企业文化”三大组。

第一组挑战:需求与架构不良

第一组挑战对企业影响最大。这些基本都是和需求、产品相关的问题,也包括架构和团队能力的问题。具体包括:

  • 需求变化多、工作量过载、需求工作拆分不够细
  • 需求不合理、定位不稳定、架构不良、团队能力不足

敏捷体系当中有不少实践都是为了解决这些问题。需求流程前端的实践,如设计思维、产品画布、用户故事等都是为了让开发团队更聚焦在有价值的需求上,以最少的投入快速产生价值。然而,敏捷虽然可以提供快速验证产品的机制,但是并不能指定产品方向。这还是依赖于有智慧、有眼光的产品负责人。有能力的产品经理,加上一个有效的敏捷运作机制是一个完美的组合。

关于架构问题,组织需要有策略地进行优化或改造遗留系统,清除过去的技术债务。这不是一夜之间能够解决的事,不是喊着敏捷的口号就能解决的,解决是需要规划和投入的。敏捷设计方法,例如领域设计、持续重构、结对编程、自动化测试,能够防止后续的腐化。不管是需求还是架构,这都是软件工程师本身该有的专业能力。系统快速增量的演进,暴露了这些能力的缺失。企业必须有系统性的能力培养和人才的引入。

第二组挑战:笨重的流程治理

第二组挑战对企业有不少影响。这些大部分是流程治理的问题。具体包括:

  • 治理不敏捷、团队之间协作、流程笨重
  • 涉众意见不合、绩效考核不敏捷、第三方合作

这些问题不是纯软件工程的问题。任何行业的企业在敏捷实施的过程中都可能遇到。实施敏捷的企业应该投入时间来分析已有的流程并进行简化。在这方面,精益思想非常重要。通过对精益价值流的分析,重新梳理团队职责、其贡献的价值和绩效导向的关系,就能够很快识别问题的根因。但是如果要彻底解决问题,还是需要上下的合作,制定新的流程。

第三组挑战:企业文化

第三组挑战的影响程度在不同企业中的表现并不集中,因为我们的问题是通过印象程度组合的,而不是它们所属的领域。然而,我们发现这大部分都是与人相关的问题。敏捷实施的持续性,最终必须要考虑人性。

  • 团队不愿意学习新东西、公司文化不敏捷
  • 开发测试和开发运维协作不好、需求实现复杂、团队分散

就像第二组问题一样,大部分问题不是跟软件工程有关,而在于文化和协作。有效协作的动力来自两方面:首先是成员本身的态度,有些成员本来就热爱学习,愿意为企业的长期利益着想。有些成员更多的考虑个体的利益,很难跳出舒适区。要改变企业文化是不简单的。所以,实施敏捷的时候,首先要先从一批意愿比较强的成员入手,同时也要考虑当前的绩效管理体系是否会促进或阻碍协作。领导的积极参与、以身作则,也是非常重要的。如前所述,敏捷实施是一项长期的变革,是需要坚持的。

敏捷实践落地步伐:团队、端到端、企业

企业要实施敏捷时,需要考虑实施的范围和要引入的敏捷实践。以及如何把这些改变有效的落地和生根。在我们的经验中,企业通常会先从小范围做起,有了一些成果之后再逐渐铺开到整个交付流程,从需求到交付上线,然后再考虑如何将敏捷精神扩散到整个组织。此次调查结果确认了我们的观点。我们向受调查者询问他们敏捷实践的落地情况:

  1. 已决定不会尝试
  2. 不知道这是什么
  3. 还没开始尝试
  4. 刚开始尝试(3个月以内)
  5. 已实施一段时间,有挑战但是会坚持
  6. 实施成功了,已经是习惯性的做法

我们按照他们有意愿尝试的实践进行了排序,并将其划分为三个组合。所谓“有意愿”就是包括他们认为自己还没开始尝试、刚开始尝试、已实施一段时间、以及实施成功的实践。

我们发现,这些实践组合正好和我们之前建议的开发测试敏捷、端到端需求交付敏捷、以及企业级敏捷,这三个实践组合一致。

第一组实践组合:开发测试敏捷

第一组实践组合包含最普遍的基础敏捷实践,包括Scrum和看板,也包含一系列的自动化实践,如自动化测试、持续集成、持续发布、以及敏捷管理工具(例如JIRA)。 团队如果不实施这些实践,就不能说他们是敏捷的。如果一个团队说他们很敏捷,但是没有站会,没有工作跟踪,没有自动化测试,更没有持续集成,你觉得他们能够敏捷起来吗?这些都是必备因素。然而,即使有了这些实践也可能只是流于形式。更重要的是团队有敏捷的学习心态。

第二组实践组合:端到端敏捷

第二组实践组合包含的都是开发团队以外和周边的协作,包括开发运维、业务人员、团队各角色的协作。它们存在于需求从概念形成到完成交付的各个环节,包括:设计思维、前期需求管理、微服务、特性团队、测试驱动开发、验收测试驱动开发、DevOps。有效协作的前提是开发测试的实践已经有效落地。如果稍微一动代码就崩溃,开发测试不能够迭代交付,那么就谈不上什么端到端的敏捷。

第二组实践组合本身不是特别难,但是一旦牵扯到不同职能,就难免有利益冲突。教练可以采用逻辑一个个地说服各职能的成员。一个行之有效的办法就是在各职责成员中共享产品愿景和目标。产品一旦能够有明确的发展发向,并且能有效的传达到每个成员,每个成员理解他对产品成功的贡献,那么各职能成员的参与度就更有可能提高。敏捷是一个很好的工具,但它的有效落地还是需要方向的。

第三组实践组合:企业敏捷

第三组实践组合包括:项目组合管理、预算与绩效管理、其他职能的敏捷、大规模敏捷、精益创业。

这些实践大部份都是软件交付以外的实践,是一系列很不同的专业。这里有财务人员、有人力资源、有企业战略、有业务负责人等。要有效的开展敏捷协作,首先必须理解他们的观点以及他们面临的挑战和矛盾。他们大部分都不是IT出身,不理解IT的术语。传统敏捷实践和术语不能够解决他们的问题。

企业治理需要另一套崭新的实践。其中,超越预算是一个开始受人关注的体系。它提供了一套财务办公室、人力资源办公室、以及战略办公室的协作理念和机制。有不少企业开始在这方面进行尝试。企业治理的敏捷事关重大。领导层,以及这层职能的敏捷,完全决定了企业上下的敏捷。企业级的敏捷实践还是在演化中。我们期待这方面的发展。

不要忘记代码质量

我们也发现,受调查的企业对代码设计方面的关注比较缺失,这包括领域设计、UML、结对编程。其中最有争议的实践就是测试驱动开发(TDD)以及结对编程。有不少企业决定不尝试这些实践,对它们的效果有所怀疑。这或许是由于受访者对这些实践的理解不足,或者是他们的落地比较困难。我们的观点是这些实践都是非常重要的。代码质量决定系统的质量。即使实施有所困难,企业应该在这方面更加专注。

敏捷实施措施:流程、自动化、领导力、组织文化

企业敏捷实施基本上是一个组织的变革,所以必须按照变革项目来对待。变革项目必须要有全面的考虑。如果不够全面的话,实施会受到一些阻碍。我们将敏捷实施措施按照它们的必要性和投入排序。

第一组措施:流程变更,自动化投入

这些措施都是企业觉得有必要并进行了合适的投入、是大家默认最基本的事实策略。首先,必须要建立一个敏捷实施工作组、调整运作流程。另外,自动化这方面是需要有额外的人力投入的,否则会对研发团队的交付速度有所冲击。

  • 调整运作流程、敏捷实施工作组
  • 建立内部自动化测试、持续集成、持续交付能力

第二组措施:领导参与,建立改进目标

敏捷变革基本上是一个组织发展工作。必须有领导以及外部顾问的积极参与。顾问会带来他们的经验,避免团队走冤枉路。另外,企业必须例行跟进和分享,确保实施敏捷的团队受到关注。敏捷的实施也必须敏捷。

  • 领导积极参与、雇佣外部教练
  • 把敏捷改进作为团队目标
  • 例行敏捷实施会议、组织敏捷相关的分享

第三组措施:组织文化、绩效管理

这些措施是受访者觉得必要、但是没足够投入的。如果要有效可持续的敏捷落地,不仅仅要考虑团队的辅导,也要考虑其他方面。这或许会涉及到系统架构、组织结构的演进。一般来说,遗留系统是妨碍企业敏捷的原因。除此之外,也要建立内部教练机制、实践社区,要让员工持续的学习。最重要的,也要考虑企业的绩效管理。已有的绩效考核是否正在阻碍敏捷文化的推进,还是能够促进敏捷文化的建立。

  • 系统架构改造
  • 实践社区、内部教练
  • 改造绩效管理制度

敏捷实施有套路

敏捷已经拥有将近20年的历史。对于软件开发这样一个迅速发展的领域来说,这是一个很长的时期,在这个时期中,敏捷有了很大的进步。事实上,企业可能面临的任何问题似乎都与敏捷相关。问题不在于解决方案不存在,而在于企业采用这样的解决方案的态度过于谨慎和保守。企业害怕实施敏捷时所带来的变化对组织的冲击太大。企业需要系统地将敏捷整合到他们的工作方式中,并转向敏捷的思维方式。

企业在这敏捷实施旅程中并不孤单。有很多企业的经验可以参考,而我们这次的调查就系统地收集了许多企业的经验,总结了一些通用可借鉴的实施措施。首先,企业必须克服以下几个方面的挑战:需求和架构、笨重的流程、以及企业文化。我们发现企业采用的步伐通常都是先实施团队级的敏捷,然后端到端交付敏捷,最终实现企业级敏捷 。这与我之前在《企业敏捷转型道路》所描述的完全一致。

最后,敏捷企业应考虑采取以下措施:

  • 简化流程
  • 投入自动化
  • 确保领导参与
  • 建立改进目标
  • 让组织文化和绩效管理更符合敏捷理念

在当今的商业环境中,不敏捷的工作方式已经不再是企业的选择。实施敏捷不是为了时尚,不是为了跟上“最新和最伟大”的潮流。“企业不实施敏捷是等死,错误实施敏捷是找死。” 实施敏捷是一个生存的根本动作。没有敏捷,就难以执行任何其他战略举措,例如数字化转型。

希望我们的这些总结和反思,能给正在实施敏捷或将要实施敏捷的企业,提供有价值的参考和指导,让大家少走一些弯路,早日实现企业级敏捷。也期待大家留言分享各自的观察和思考。

附:《中国企业敏捷实施情况调查-2017》(请用手机打开链接)

Share

发表评论

评论