敏捷开发怎么真正实现落地

Posted 2021-04-25 可持续开发

首次接触敏捷开发是在2000年初，当时学习的开发模式是XP，最近又流行起来Scrum，敏捷开发虽然听起来非常诱人，但还没有听说国内哪家软件公司真正实现敏捷开发的。敏捷开发是针对现代软件需求多变性而提出的，通过敏捷管理模式来降低软件开发的管理成本，提升软件开发效率。现在网上的关于敏捷的阐述都是基于理论战法层面的，没有具体讲怎么样落地的，没有落地方案的战略很容易就变成了纸上谈兵，这里我就谈谈对敏捷的看法，以及怎么样才能落地。

敏捷需要解决的问题

现代软件需要变得越来越多样化和快速化，敏捷是为了适应这种新时代需求的变化。需求调整导致很多BUG，很多BUG需要程序员加班加点，团队经常加班，容易犯更多的错误， 核心团队疲于应对需求、技术开发和老系统维护，没时间指导新同事技术学习，而新同事因为技术不过关导致更多BUG产生和任务经常延期，整个就是一个恶心循环，大家在解决BUG的同时不断的创造着新的BUG。敏捷就是需要跳出这个恶性循环，重新获得新生，当然获得新生的过程是一种煎熬和考验。

人员素质是敏捷开发实现的前提条件

敏捷开发的管理模式类似现代军队里面的快速反应部队，快速反应部队不单单是一种战法，而且还包括高素质的战斗成员。试想，给一些普通士兵在课堂上讲解快速反应战法，就能建成快速反应部队吗？如果能，快速反应部队就不会那么让人钦佩和具有价值了。敏捷中的一个要点就是要提升团队成员沟通的效率，沟通顺畅的前提条件是团队成员之间的互相了解，否则，任何沟通模式就变成了一种摆设。

Scrum里面有个站会，就是大家站着开会讲解自己工作的进展情况，实际情况是，因为前后台相互不了解对方的情况，而且只会强调自己调整的难度，往往导致讨论变成了一种相互抬杠。越是复杂的软件，越需要进行全局平衡和考量，因为现代软件往往涉及到很种类设备，多种访问模式，多种技术混合使用，而且使用场景也更加复杂多样，就和一场战斗和一场战争考虑的问题完全不可相提并论。所以，开发人员的素质，即开发人员要有产品和测试思维，是实现敏捷的前提条件，关于具体的产品和测试思维的论述，请您参看”程序员要有产品和测试思维”。当然，这种能力也是需要经过不断训练逐步提升的，也就是说敏捷的实现是需要一个过程的，而且随着团队单兵能力和协同能力的提升，敏捷的程度也会不断提升，敏捷不是单点目标，是一条自我完善之路。

实现敏捷必须建立和执行必要的规范

在电视上的快速反应部队，队员之间交流常常通过手势语，简洁而高效，软件开发也涉及到团队成员之间的沟通和配合，建立和执行必要的规范是实现敏捷的基础条件。具体的开发规范方面的讨论，请您参看文章”。这些规范的制定和真正落实到位，再真正产生效果也是需要团队培训和实战的。

通过结构设计和适当的重构提升代码的复用率

最近20年信息化技术发展非常快，移动端出现，大数据出现，人工智能出现，而且商业环境变得越来越多样化，随之软件的形态也变得越来越复杂，如果以前是50年代的螺旋桨小型客机的化，现在已经变成了环球飞行的大型喷气式客机，很多软件系统的边界再不断的衍生，小团队的协同变成了大团队的协作。怎么样来应对这种快速变化的业务需求，而且同时保持低成本呢？软件开发必须走向模块化和组件化，通过底层的标准化的组件来满足上层的多样化的需求，这是符合自然界的规则的。例如，底层的元素表，更像一种标准化的东西，而单单碳和氢为主要组成的有机物，以及再上层的基因的变化，就已经很难统计了，当然软件结构的复杂度还赶不上自然界这种复杂度，但这种发展的思路是可以相同的。

软件的组件化的目标就是实现代码最大可能的重用，代码的重用意味着成本的降低和反应灵活度的提升，而软件组件化的过程不是一个简单的过程，而是一个不断归纳和演绎的持续过程。归纳的前提是对现有业务逻辑的全面深入理解，通过抽象分析发现其中的统一性，同时参数化变化性，再通过演绎应用到新的业务当中，在应用过程中需要不断的调整和修正，直到组件具备真正的普适性，和导弹一样，在接近目标的过程中需要不断的反馈和修正，组件应用的反馈来自开发团队，产品团队和软件用户，修正过程就是软件组件的代码重构过程，每次重构都是对目标的不断接近。

软件组件归纳的过程是需要设计者具备全面的知识技能，技术方面需要懂前后端各种开发，产品，测试和运维，业务上需要具有优秀的洞察能力和独立思考能力，更重要的是创新能力和执行能力。在执行过程中也需要规范的建立，在之前的组件化实践当中，常常遇到程序员没有按照设计意图来使用组件，得到的反馈有两类。第一，不会使用组件，觉得网上有代码拷贝，做起来快；第二，觉得组件不能满足 需求。这时候我就跟他们讲，如果不会用就去学习，公司有全局的战略，不能因为局部方便就是不顾全局，如果大家都各自为战，代码不可能规范起来；如果组件不满足需求，要提出来，不要什么都不讲，组件发展需要大家的积极反馈，没有反馈，组件化过程就会成发源地干涸的河流。

关于软件组件化开发的思路，您可以参看我的其它文章，会举例来阐述组件的产生和持续的演化，以及带来的巨大的效率回报。

通过自动化测试提升测试效率

实现自动化测试是敏捷当中关键的一环，只有实现自动化测试才能加速迭代的速度，加快问题反馈的速度，在快速迭代中保证产品质量和降低研发成本。真正的实现自动化测试不是一件容易的事情，自动化测试需要在多个方面实现自动化，数据产生，数据和问题分析，过程的监控，这些方面头部互联网公司已经付出实践，而且自研了自动化全链路压力测试的系统。但在功能测试的自动化上面还不完善，例如APP和WEB这种GUI的自动化测试，如果能够实现GUI的功能测试自动化，则可以免去接口测试上面的人力和物力，现在接口自动化测试一般还是通过测试团队的编程开发来实现的。如果对GUI的自动化测试有兴趣，请您参看文章”APP的UI自动化测试”。不过这里的思路，不是适合任何公司的，GUI自动化测试的前提是GUI开发的组件化和测试框架的组件化，而且对程序员和测试人员的要求也是比较高的，这个思路在公司里面也付出了实践，得到了非常好的效果。

如果能够实现GUI的功能自动化，再加上性能的自动化测试，则可以形成强大的自动化测试体系，当然自动化测试体系也软件本身一样也是需要持续自我完善的。自动化测试不能完全带头人工测试，但自动化化测试无疑是可以提升测试效率的。

优秀的自动化测试流程是开发团队，测试团队和运维团队的完美协作，对技术管理者的全局掌控能力有着很高的要求。敏捷意味着这种管理不能是单纯基于宏观的，必须是有能力考虑到很多执行中的细节的，就像关键战役的失败，可能就是对一些细节的误判，或者关键位置用错人。

使用提升效率的工具软件

现在DevOps变得流行起来，把这些工具使用起来也是需要开发团队，测试团队和运维团队的协作配合的。这些工具是重器，但真正使用到位还是需要团队自身的能力的，据我所知，国内真正实现的团队并不多。

敏捷可以处理适度的变化，但不是任何变化

即使结构设计最优秀的软件也是应对软件的适度变化，而不是全部无条件的变化，好坏结构设计的区别是能够适应变化的程度，差的耦合度高的软件可以说适应能力接近0，导致一调整就产生很多不可预测的BUG。前面讲到，敏捷是一种持续完善的过程，应对变化的能力也是一个持续增强的过程，不能敏捷不能处理一些变化，就全面否定敏捷的努力，对敏捷必须有客观性的认识。

敏捷必须建立有效的培训体系

文章前面提到，敏捷不是通过几堂课程培训就能实现的，一流的球队都是经过层层选拔，然后经过持续的训练和实战磨练出来的。这个培训过程，人员，教官，老板，业务需求，都必须到位，缺一不可。

业务场景规模大而且复杂，才能从敏捷中获得巨大收益，敏捷前期是需要一定成本的，不是任何公司都适合敏捷的，而且即使开始执行敏捷，也是需要有个短期，中期和长期规划的，不能期望一步到位的。

人员素质前面也讲了是非常关键的，特种部队都是从各个部队的尖子中选拔出来的，具有一个规模的公司，在人员选拔上面会有一定的优势，对于规模小的创业公司相对难度大些。很多程序员的开发习惯是非常难改变的，而且很多程序员都是相对比较固执的，真正的让大家改变思路换一种打法是需要一定的耐心和沟通艺术的。在敏捷实践过程中出现问题，需要具体分析是什么问题，如果是程序员的习惯问题，就需要多次督促和提醒，让他明白这规范的重要性。建立规范的开始阶段，就和给一般散兵游勇进行整改训练一样，如果都是兵油子了，就需要找到突破口，需要先拉拢能完成阶段目标的典型，通过典型来教育其他人。

教官，即技术带头人是一个关键的角色，和球队的教练一样，是团队凝聚的核心，也是团队内在矛盾解决的核心人物，在敏捷实践过程中，新旧的流程和思想必然会产生矛盾，解决不好，团队人心涣散，无法达到终点。教官在技术上需要能够服人，眼光必须有前瞻性，沟通和用人必须做到知人善任和人尽其才。

公司管理层的支持也是至关重要的，敏捷实践的初期是需要多付出成本的，很多老板觉得对开发人员进行培训，好像是企业吃亏了，总是希望开发人员不断战斗战斗，如果管理层有这种思想，团队就只能维持现状了。而且敏捷实践的同时，系统可能还需要持续维护，人员没有足够的培训和锻炼时间，怎么可能出成果呢。进行敏捷开发实践，很可能会触及部分守旧人的利益，这些人出来搅局，管理层是否能够坚持也是个问题。组件的优化方向是和业务息息相关的，框架是为业务服务的，如果公司的业务层面忽东忽西，技术发力也就迷失了方向。有些公司的系统技术债太重，在一个烂地基上面实现敏捷是几乎不大可能的，这时候就考验着管理层是否有系统重造的决心和勇气，当然这种重造也可以采取分步走的策略。