【方法论】 敏捷 & 精益开发落地指南原创

大家好，我是陈君彤，来自腾讯云coding团队的解决方案架构师。今天我给大家分享的内容是如何使用coding落地敏捷与精益开发。为了让大家知其然并知其所以然，今天的课程会从以下这几个方面入手，分别是敏捷与SC基础知识介绍敏捷看板基础知识介绍coding对这两大方法论的理解与产品设计，最后使用coding项目协同做最佳实践的演示。在这一节，让我们先简单了解一下敏捷与SP的基础知识。随着时代的发展，人们在软件工程这个领域做出了前赴后继的努力。软件工程定义是将工程方法应用于软件开发中，近些年来最受欢迎的要求敏捷了。围绕着敏捷开发的发展历程，我们梳理了这样的一段时间线，下面挑重点讲。

九三年，Jeff发明了SC框架，在九五年的一场大会上进行了正式发布。九九年，Camp发表了极限编程说明，也就是今天常讲的叉P框架。01年17位软件开发大师齐聚一堂，已在他们各自不同的开发方法中寻求共识。此次会议的产物就是敏捷软件开发宣言。后来的几位会议成员继续合作，成立了敏捷联盟。敏捷宣言的四大价值观、使用原则开始广泛影响着软件工程。零一年，J在其文章规模化敏捷中首次给出了scd of sc的描述，标志着safe框架的诞生。零三年K出版测试驱动开发一书，标志着TDD的诞生。零五年大规模strong框架Les被发明，后续还有诸如bdd探索性测试、故事地图、monk敏捷测试等方法论不断诞生着。

这一页我们简单总结一下零一年诞生的敏捷宣言，很简洁的这几句。第一句，个体与互动高于流程和工具。这意味着虽然流程和工具很重要，尤其在大型组织内，但是他们无法替代有能力的个体与高效的互动。个体的技能和他们之间的互动才是最关键的。当我们开发产品、解决问题或改进工作方式时，我们要持续的去寻找改进互动与提高能力的方法。工作的软件高于详尽的文档，意味着以集成，已测试潜在准备发布的产品才是关键度量，它能够有效的跟踪项目进度和对发布做出决策。要以小步增量的方式构建产品，做一些分析设计，然后就可以开始编码了，再进行测试以验证设计。大家都知道，好架构是持续开发产品的关键，而架构是设计出来的，建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移，架构和引进，所以追求卓越技术和好设计能够增强产品的敏捷性。

客户合作高于合同谈判，意味着我们应该超越谈判，并尝试提升与客户合作。我们还应该建立以合作为基础的关系，而不只是只依靠公司内的正式渠道与接口。响应变化高于遵循计划，意味着欢迎需求变化，哪怕是在开发后期。当然，我们知道现在的程序员最怕需求变更了。这里其实强调的是一种平衡的艺术。首先，预先知道所有的需求是不可能的。我们承认计划的不确定性，要做的是建立流程和工作方式，使得计划适应变化。要有足够的计划水平来评估业务需求和对其长期影响的判断。

敏捷宣言价值观的字数不多，但字字珠玑。这里我想强调的是中间高于这两个字。这并不是说右边的这一列就不需要了，而是说从价值的角度，我们更重视左向的价值。这一页罗列的是敏捷宣言的16大原则，也简单总结一下价值。第一项原则强调的是快速并有节奏的交付有价值的东西，从而满足客户的需求，第二项强调的是拥抱变化，第三项强调的是缩短交付周期，第四项倡导业务人员能够和开发团队始终在一起办公，提高效率。第五项强调的还是对人的尊重与信任。说到底，软件开发的核心还是人，一起工作都是围绕着人来展开的，所以在这条原则里就重复体现了对人的关注与信任。

第六项很好的体现了敏捷，价值观里的个体和互动胜过流程和工具，因为面对面沟通是所有沟通方式中最高效的一种方式。第七项强调及时交付，但是交付产品的衡量标准是可以工作的软件，而不是其他一切过程产物。第八项提到的可持续开发一直是敏捷所强调的软件开发节奏。敏捷不只是一昧强调快速交付，而是强调一个开发节奏，这个节奏能让项目管理人员和客户对这个团队充满信心，也就是我们交付给这个团队的开发任务，他们能够在在固定的时间段内有连续产出，并且是保证质量的。第九项原则里面包含了两点，一是追求技术卓越，二是不断完善设计。这里的设计既可以是产品方案的设计，也可以是技术架构的设计，这两者的不断改进都将促进团队领先能力的提升。

第十项原则倡导以价值为中心，减少浪费，与经济思想异曲同工。第11项原则在表达。敏捷相信最好的架构、需求和设计都是出自自主织的团队。敏捷的目标之一就是能够打造一个自组织团队，该团队能够通过高效协作完成需求分析、架构设计、开发交付、产品运维等工作。第12项原则就针对如何反省来提升成效。在敏捷开发过程中，团队随时随地都在通过各种反馈来进行反思和回顾，一直在实践着PDCA循环。敏捷是一种新型软件开发方法，代表性框架有SCLASC等等。九五年诞生的SC是目前最流行的框架。现在说到敏捷没有特质的话，一般就是指SC。

是一个轻量级的框架，可帮助人员、团队和组织通过针对复杂问题的自适应解决方案来创造价值。SC有两条理论基础，第一条，SC基于经验主义和经济思维。经验主义主张知识源自实际经验以及根据当前观察到的事物做出判断所获得经济思维，减少浪费，专注于根本。第二条SC采取一种迭代和增量的方法来优化对未来的预测性并控制风险，同时倡导让一群共同拥有所有技能和专长的人员参与进来完成工作，并根据需要分享或者习得所需技能。SC有三大支柱，分别是透明、检视与适应。如这里所写，透明使检视成为可能，没有透明和共识的检视会产生误导和浪费。

过程和工作成果对参与工作的人员来说都是要可见与一致理解的。在SC中，重要的决策是基于其三个正式弓箭的感知状态。透明度较低的弓箭可能导致做出降低价值并增加风险的决策。检视使适应成为可能。没有适应的检视是毫无意义的。SC事件只在激发改变。为了目标的进展，团队必须经常性的检视，以便发现潜在的不良性的差异或者问题。为了帮助解释，SC以五个事件的形式提供了稳定的节奏。在适应这一块，如果过程的任何方面超出可接受的范围或所得的产品不可接受，就必须对当下的过程或者过程处理的内容加以调整，调整工作必须尽快执行，以最小化进一步的偏差。

这是SP的完整流程图，涉及到很多知识，比较复杂，不过也正常。管理是一门学问，需要系统性的学习，无法凭借生活经验摸索出来。首先是管理学知识。管理跨度，即一个人能有效直接管理的下属人数是有限的，有个说法是七个人。亚马逊CEO贝索斯提出了两个披萨团队的理论，如果一个团队吃两个披萨还不够，说明人太多了。SC框架建立，一个团队应该有六至十人。所以一个公司如果想搞敏捷，首先要进行组织架构调整，拆分成一个个的小团队，分别负责独立的模块或者产品线。每个小团队都有三种角色，第一是产品负责人，注意不止是产品经理，而是有决策权的，决定一个需求做还是不做，先做还是后做，这样才能做价值排序。

第二个是sc master，也就是敏捷教练，需要系统性的学习敏捷知识，可以考取对应的敏捷教练证书，带领大家实践下面的流程。第三是开发团队要掌握故事点的评估方式，单元测试的写法等啊，一样可以调取敏捷开发者证书。在SC团队中是没有子团队或者层级结构的，它是专业人士的凝聚力单元，一次专注于一个目标。对于SP活动或者事件来说，一共有五类，分别是spring会议、spring计划会议、每日SP会议、spring庭审会议以及spring回顾会议。在这里，Spring是所有其他事件的容器。对于SC工件来说，它代表工作或者价值，只在最大程度的提高关键信息的透明度。一共有三类，分别是product backlock spring backlock以及产品增量。

最后是SC价值观，一共有五项，分别是承诺、专注、开放、尊重以及勇气。在这一节，让我们看看coding在敏捷方面的产品设计与实现。这一页讲的是三个角色，通过项目设置中的用户角色权限配置，可以完成SC的三个角色和对应权限分配。通过把用户添加到对应的用户组，为用户组分配对应的权限，即可实现精细化的角色权限控制。这一页讲的是三个工件之producto。第一点，敏捷中采用故事点进行估算。我们在创建用户故事的时候，可以设置用户故事的故事点数，产品上支持非波大器数列和T恤尺码两种方式进行故事点估算。第二点，用户故事采用高优先级驱动方式，在product Di中可以设置用户故事的优先级。

第三点，为了满足企业和团队对用户故事的广泛定义和需求，产品上支持根据实际需要自定义用户故事的属性。这一页讲的是三个弓箭师splo。第一点，在springlock中会自动统计SP中的事项数，有助于团队了解本次SP需要完成的事项。第二点，SC中的spring采用固定时间和的方式，在holding产品中可以设置spring开始时间和截止时间，并在迭代详情中显示，有助于团队了解本次SP的时间期限。第三点，在coding sprinto中可以查看spring的状态，提供未开始进行中、已完成三种初始状态。第四点，Coding sprint beo中能显示本次spring的总故事点数，有助于了解本次spring工作量大小，同时也反映团队的spring产能。

这一页讲的是三个工件师产品增量，在coding迭代看板模式中，可以在一个迭代内按需持续交付，通过多次增量交付，将已发布的用户故事移动到迭代看板已发布阶段中可视化产品增量。这一页讲的是SC的五个事件，借助coding的知识管理，将这些活动进行知识沉淀，在会议中进行使用。通过rint计划会议，用户故事从productlo移动到sprintlo，通过sprint每日战会结合coding迭代看板，及时同步项目进度，识别问题和瓶颈并持续改进。在spring结束时，通过评审会议对本次spring产品增量，也就是迭代开码中已发布的用户故事与项目干系人进行分享和验收。评审会议结束后对进行回顾会议总结本次迭代的进步和不足，并提出解决方案，以便在下一个spring中做的更好，实现持续改进和精益求精。

最后总结一下coding项目协同的敏捷模式，左边是，也就是需求池，右边是spring迭代，里面的需求都是有顺序的，下面的重要需要先做，下面的相对不重要，这就是敏捷的核心价值。排序右边的横框里有个数字26，它是下面数字的总和，叫做故事点。也就是说一个团队一次spring迭代中只做这么多事情，如果有紧急需求插队没关系，放弃别的需求，让故事点总则保持不变即可。如果最后还是没做完，剩下的都是相对不重要的，丢回左边重新参加排序，也许下次迭代也不会做他们，因为有更重要的事情要做。

每次迭代都要开反思会，找到没做完的原因，比如预估错误，经过几轮迭代的磨合，找到良好的工作节奏，把故事点明确下来。这一节开始，我们介绍近年来也很流行的理念精益。精益软件开发是精益制造原则和实践在软件开发领域的变体，它基于上世纪50年代至70年代的丰田生产方式，野生TPS由敏捷社区引入并发展，这段时间轴展示的是精益的发展历程。九零年改变世界的机器这本书籍的书版让精益制造广为人知。九六年经济思想的出实现了精益从实践到思想的升华。零一年丰田之道的出版，让丰田模式成为各行各业的争相学习的对象，并将精益从思想升华到价值观。零三年精益软件开发书籍的书馆，标志着精益思想和敏捷一样成为软件开发的新型方法，敏捷软件开发大量吸收和借鉴的精益思想原则。一七年精益产品开发的出版，标志着经济思想在软件开发领域已经成熟并深入人心。

我们先介绍丰田生产系统，也就是TPS，又称精益生产，它的目标是低成本、高效率、高质量的进行生产，最大限度的是顾客满意。它有一大基础是指改善，英文是improvement。改善是丰田式生产管理的基础，具体包含三个要点。第一点，从局部到整体永远存在着改进与提高的余地，在工作操作方法、质量、生产结构和管理方式上要不断的进行改进与提高。

第二点，消除一切浪费。丰田式生产管理哲理认为，不能提高附加值的一切工作，其中包括生产过剩、库存、等待、搬运、加工中的某些活动、多余的动作、不良品的返工等等，这些都是浪费。这些浪费必须经过全员努力不断消除。第三点，持续改善。它是指以消除浪费和改进提高的思想为依托，对生产与管理中的问题，采用从易到难的原则，不断的改善、巩固、提高方法，经过不懈的努力，以求长期的积累，获得显著效果。在基础之上有两大支柱，分别是准时化与自动化。准时化又被称为just in time，是指仅在需要的时间生产需要数量需要的产品，目的是灵活应对变化，消除生产过剩的浪费，以缩短前置时间。

在自动化这里呢，要注意这个动的写法是由人字偏旁的选，这个字是强调人机结合，而不是单单的纯粹用机械代替人力的自动化。它的含义是指生产系统能够自动发现异常，当异常发生时能够停止生产，并现时现地的解决问题，也就是说根据异常发生的时间点和地点去解决问题。分析问题，而且要解除发生异常的根本原因。这一页我们介绍的是经历从实践到思想的升华。经验思想具体来说有五项，第一项是定义价值经验实践的关键出发点是价值，而价值只能由客户来确定，而提供错误的产品或者服务都是一种浪费。请注意，经历不是制造系统的目标，价值才是制造系统的目标。客户的价值认知和我们的成本与努力无关。

第二是识别价值流，第三是流动，第四是拉动，第五是尽善尽美。这张图展示的是精密思想在软件开发领域的应用及精益产品开发，它的目的是顺畅和高质量的交付有用的价值，两大支柱分别是探索和发现有用价值以及聚焦和提升流动效率。在管理实践上包含三大实践，分别是精益创业和创新、精益需求分析和管理、精益看板方法。接下来主要针对获奖者做详细的讲解和介绍。在经济需求分析和管理中，包含目标、原则与实践。他的目标是通过在组织、团队、个人层面的经济需求发现、管理、沟通和协作实践来提升组织的响应力和创新力。原则包含主动驱动业务变化，真正以客户为中心的核心，实践包含探索其实践与拓展其实践新意。看板管理主要包含五个方面，分别是可视化、价值流动、显示化、流程规则、控制在制品数量。

管理、价值流动以及建立反馈持续改进。在这一节，让我们看看coding在经营方面的产品设计与实现。这一页左图展示的是用分割线进行需求规划与细化，右图展示的是高优先级驱动展值交付，这一页作图展示的是规范化经营需求编写。右图展示的是需求关联缺陷、测试用例、代码、仓库等等。在这里，我们通过coding仪表盘能够对需求进行广泛、客观的数据收集与分析，为减少浪费、暴露问题、持续改进提供基于数据而非经验的科学反馈。

这一页左图展示的是仪表盘，可以直观显示近期需求的变化趋势，让我们了解价值的加速趋势和团队资源的利用率。右图展示的是查看需求和停留的时长，将问题和瓶颈可视化出来，为改进提供基础与方向。这一页左图展示的是查看团队或项目的关键活动及过程资产，能够了解团队活动和资产数据，右图示的是通过对需求的可视化和流动管理，可轻松高效的实现经济需求的科学管理。这一张图总结了今年看完的五大实践。Visual life work就是可视化价值流动的体现，在每个阶段定义DOD就是显示化流程规则的体现，Li work in progress就是控制在制品数量的体现，采用拉式的用户价值管理方式，并专注于业务价值流程，图中的或not push activities就是拉动方式工作流的体现。

图中的needtime和several time的问题瓶颈暴露、分析和解决是对持续改进的体现。Coding经义看板按照看板方法论和原则进行了产品设计与实现。在定义价值流时，Coding工作流的配置能够提供简单灵活的价值流配置视图，用户可以轻松高效的完成价值的定义和配置。在可视化价值流动中一共包含三种，第一是可视化用户价值。在图中的coding实例看板中，可以看到所选的所有用户价值，包括用户故事、需求、缺陷等他们的状态和数量的分布，用户价值对所有团队成员透明。

第二是可视化用户价值通道关的过程。将用户价值的所有步骤如图所示的是待开发、开发中以开发、待测试、测试中已测试、待验证、已验证、待发布已发布等，这些过程都可视化出来，实现端到端的流动可见性。第三是可视化问题和瓶颈。coding看板可以清楚的将问题和瓶颈暴露出来。例如，以开发带测试，这列中如果存在过多的在制品，说明该列存在制积压，则意味着遇到的阻塞，该列的资源处于负载状态。又如，如果测试中的在制品过少，则意味着测试资源处于空闲状态，那么无论是过载还是空闲，都不满足均衡生产的要求，都会造成不同程度的浪费。针对这些现象，都应该视为问题和瓶颈，并可以对其加以分析，为团队改进提供基础和依据。

显示化流程规则是指明确价值流转和团队协作的规则，并达成共识。显示化的流程规则是团队协作的依据，更是团队改进的机械。我们可以看到，在coding配置中提供了这几种能力，分别是限制步骤权限、附加属性、更改处理人以及更改属性值。通过coding看板，可帮助用户轻松实现业务价值的均衡生产、匀速流动、小批量交付。在均衡生产方面，可通过扣Ding看板有效控制每列的事项数量，每列事项数量均衡化是高效流动的必备条件。在匀速流动方面，流动过快或者过慢都不利于资源利用率的最大化，通过每日站会查看Co开的流动速率，使其流动尽可能的匀速。在小批量交付方面，敏捷中倡导价值的小批量快速交付，通过coding看板结合coding c icd实现迭代开发，持续增量发布。如图所示，在以发布列中，价值以增量形式持续的去进行发布。管理工作流的目的是使用户价值流畅、高质量的流动。

管理价值流动主要包含管理价值流动的输入、管理价值流动过程、管理价值流动输出三个方面。输入指的是就绪队列填充活动。就绪队列是看马系统输入和价值流动的源头，我们可以通过coding项目协同中的需求管理功能来管理价值流动的输入，通过coding需求页面的快速腾讯会议实现需求讨论和澄清，将需求纳入到就绪队列spring backlock中。在管理价流动过程方面，我们采用看板战会，战会是管理价值流动过程的活动，看板从右往左读取，即用户价值拉动。

通过coding看板和SC每日会议进行高效沟通，反馈问题，瓶颈无处可逃，轻松实现价值流动管理实现过程持续改进。在管理价值流动的输出方面，我们采用发布评审，它是需求发布前的计划活动，决定上线或发布哪些需求，以及相对应的发布策略等。Coding与腾讯会议打通，通过快速腾讯会议对需求进行评审，将业务价值进行快速交付。这一页我们将最后的建议反馈持续改进反馈的类型，其中有一类关于流动是否顺畅的反馈，借助coding可以进行相当程度上的实现。举例说明。第一点是多种度量指标，客观洞察问题瓶颈。德鲁克说，如果你无法度量，那么你就无法改进。度量是改进的前提，改进是度量的目的。通过对研发数据的收集与分析，发现研发过程中的问题和瓶颈，为改进提供机会。

第二点是APP相关人员迅速对齐，及时、准确、有效是高效沟通的前提和基础，也是团队高效协作的基石。在holding中，通过艾相关人员是想干系人，能够迅速了解上下文，迅速的对其共识与内容其实针对问题进行沟通与协作，促进团队高效合作。第三点是多种surface book即时高效通知。国内企业主要是基于钉钉、企业微信、飞书等I'm进行企业级的日常沟通与协作，Coding surface book支持web book、企业微信、钉钉、飞书等多种主流的企业级I'm工具的通知机制，主动与企业I'm工具融合，实现研发效能与企业I'm的无缝集成，提升通知的及时性、友好性与使用惯性。

第四点是邮件提醒，代办风险一网打尽。通过每日邮件提醒，团队成员可以更加聚焦于代办事项的范围，专注于待办事项的完成。通过邮件提醒，暴露出来的风险可以及时有效的进行风险评估，尽早给出风险处理措施，及时处置风险，将风险可能带来的损失降低到最低。反馈的类型除了刚才介绍的流动是否顺畅以外，另外一类是关于质量问题的反馈，借助coding一样可以进行相当程度上的实现。举例说明，第一点是保护分支规范代码提。我们说无规矩不成发源，规范代码提交是代码质量保证的重要关卡。coding提供保护分支规则和代码评审能力，通过规范代码提交和code review机制，有效保障代码的可读性、可理解性、可维护性和透明性。

第二点是质量，门禁保障代码质量。质量无法通过外部进行改善，只能内建。其中内建质量是deo的重要原则之一。coding提供代码扫描和质量门禁能力，通过设置质量门禁将不满足质量要求的代码拒之门外，通过工具确保代码在规范、安全、质量等方面满足企业的目标要求。第三点是自动化测试提高测试效率。自动化测试有助于帮助团队成员从繁重的、重复的、低价值的活动中解放出来。coding提供接口自动化测试和UI自动化测试能力，通过自动化测试能极大的解放团队成员特别是测试人员的生产力，大幅降低测试的人力成本。自动化测试能够保障测试的低成本、持续性和稳定性，并显著提高测试的效率。第四点是SSC助力软件依赖安全，SSCG软件主权分析。

既通过对软件依赖，例如Java项目中的me本依赖等的扫描和分析来发现有安全问题的依赖。coding制品扫描基于CA原理，与腾讯七大安全实验室之一的云顶实验室深度合作，提供业界最全、最新的漏洞特征库，能够高效、及时、准确的识别c be，确保企业软件依赖的安全可靠。那么本次课程就到此结束，感谢大家的收看，Coding项目协同内基于敏捷与精密的完整演示视频，将有高级解决方案架构师何文强为大家进行演示与解说。由于时长原因，演示部分将在三个工作日内同本视频一起上传至视频号，感兴趣的同学可以关注本视频号进行观看与学习。同时欢迎截图并微信扫码添加coding官方小助手，加入公开课专属群聊以及讨论技术，交流观点，了解coding并获取本次课程的课件以及下次课程的通知，让我们下次课程再见。