推荐语
充电桩项目采用敏捷模式，可以直观地感受到交付效率的提升。作为一个从0到1的、且涉及到硬件厂商、物联网的项目，在短时间内成功地完成了业务迫切需要的功能，并做到了大规模的稳定运营。在此过程中，产品和技术同学通过日常、早会和周会等形式沟通协作，研发工程师也积极参与到业务需求沟通、方案设计与研发计划制定等活动中，确保能够迅速应对一线需求的变化，并倾听一线终端用户的声音，以提升用户体验。
——空间数字化部-产品总监 李岳
有幸全程参与了充电桩项目敏捷团队的成长，见证了小伙伴们从敏捷项目初期的跌跌撞撞，到后期每个人都有能力担任团队敏捷教练的角色。在敏捷项目迭代和交付的过程中，所有成员都对敏捷理念有了更深入的理解，整个团队的敏捷实践能力得到显著提高。
——企业架构与安全部-架构专家 刘刚
有幸在2024年1月跟着充电桩项目体验了敏捷交付模式，不仅感受到团队的和谐团队氛围，也体验到了敏捷研发带来的显著交付效益。
敏捷“五大会”是研发过程的灵魂节点：每日站会让团队成员清晰交付进度和当前问题，对站会时间的把控可以间接地体现项目负责人的管控能力；回顾会通过匿名的形式提交“做的不好”的事项，可以更有效地帮助团队进步；项目架构师和技术负责人在版本管理、架构设计和部署发布这几个方面的规范性是充电桩项目优秀性能的坚石；合理的提测和部署流程让项目组在快节奏敏捷模式下保障交付质量。
希望敏捷研发模式能尽快的在科研项目中推广，也希望有能力的敏捷教练能将敏捷能力辐射至中心每一位研发同事。
——平台数字化部-体系流程高级主任 何佩红
产品与开发之间清晰的工作分工边界，开发内部高效的团队协同与交付，始终坚持“敏捷宣言12条原则”，是充电桩敏捷团队给我的主要印象，非常值得点赞，也值得各个项目参考学习。
充电桩敏捷实施高效地执行了敏捷开发流程框架中的五大会议：产品需求梳理会、迭代计划会议、每日站会、迭代评审会及迭代回顾会，每个会议都有专属的会议目标，不同的角色成员在会前都准备充分，保障了会议的高效沟通与决策，这也是敏捷团队高效协同的基础。
充电桩敏捷团队最成功的是不停机无感交付，“ScrumMaster”亲自负责代码分支管理，完美地实现版本火车管理，快速交付的同时确保了系统可用性。超赞！
——平台数字化部-体系流程高级主任 韦冬梅
充电桩项目在敏捷模式下，团队中的每个人不管是不是处于领导者的职位，都会从团队拥有者的角度去考虑问题，关注各项活动质量并及时反馈。目前，充电桩敏捷项目已实现组织管理，团队内有完善的规则，大家按照规则办事，不为职责范围争吵。产品产研团队高协作，在时间紧、目标重的情况下，快速迭代交付，积极响应一线反馈问题及业务需求。通过交付更高的内建质量，促使开发效率和质量得到提升，减少传统模式验收交付环节，大大提升效率的同时，平台稳定性也达99.99%。
——空间数字化部-产品专家 张雪晴
前言
敏捷开发是应对快速变化需求的一种软件开发能力。以用户的需求进化为核心，采用迭代、循序渐进的方式，适用于需求不明确或者很容易变化且可以逐步交付功能产品。敏捷开发对需求的变化具备极大的灵活性，能够更快交付价值，主动拥抱变化。
目前，充电桩项目敏捷实践已落地，支持敏捷发布火车模式的同时，帮助产品研发团队完成业绩和效率的双向提升。
敏捷开发概述
1、敏捷宣言
敏捷宣言提出的12条原则：
1、最高优先级：通过尽早和持续交付有高价值的软件，满足客户。
2、拥抱需求变化：即使是在开发阶段的后期，敏捷流程就是用变化来为企业获得竞争优势。
3、频繁交付可工作的软件：从数周到数月，交付周期越短越好。
4、在项目过程中，业务人员、开发人员必须每天在一起工作。
5、以受到激励的个体为核心构造项目，为他们提供所需的环境和支持，信任他们可以把工作做好。
6、最有效的、最高效的沟通方法是面对面的交谈。
7、可工作的软件是衡量进度的首要标准。
8、敏捷流程倡导可持续开发。客户、开发人员与用户要能够共同、长期维持步调（节奏）、稳定向前。
9、持续地追求技术卓越和良好的设计，以此增强敏捷的能力。
10、简单--最大可能减少不必要的工作，简单是敏捷流程的根本。
11、最佳架构、需求和设计，来自组织型的团队。
12、团队定期反思如何提升效率，并调节和调整自己的工作方式。
2、敏捷开发流程框架
3、敏捷团队角色
敏捷开发实践
充电桩项目于2023年5月在上海成立敏捷团队，该团队在最初阶段面临着团队协作与跨地域沟通等挑战，经过半年多的磨合，团队逐步适应了敏捷流程和工具，经历了从敏捷开发和流程工具试用到团队成长、成熟的转变。这一过程促进了敏捷团队成员间的合作默契，敏捷开发模式也逐渐显现出其成效。
下面，将通过五个重要的会议（产品需求梳理会、迭代计划会议、每日站会、迭代评审会以及迭代回顾会）来介绍充电桩项目敏捷开发的日常运作流程。
1、产品需求会
在迭代开始前2-3天, 敏捷教练、产品与架构师/技术专家参与产品需求梳理会（会议时长1小时），完成如下事项：
- 制定需求和任务优先级；
- 评估所有任务的准备工作是否完成，如UI设计图与架构设计图等；
- 迭代目标；
- 版本发布计划和范围。
产品负责人：根据价值交付原则制定产品类需求的优先级。
架构师/技术专家：负责制定技术类需求的优先级，并评估需求对系统造成的影响，提前分析可行性，安排技术演进线路图，规划和粗略评估迭代的技术架构任务。
2、迭代计划会
在迭代开始时，敏捷教练组织产品负责人、架构师、研发团队参与迭代计划会（会议时长2小时左右），完成如下事项：
- 规划迭代目标；
- 认领迭代需求和任务；
- 分解用户故事；
- 估算工作量。
产品负责人：给研发团队讲解需求。
架构师：讲解技术类需求，认领架构设计任务，协调研发团队架构改造与功能开发的交付节奏。
研发团队：分解用户故事、估算工作量并认领任务 。
3、每日站会
每天上午9:00-9:15，敏捷教练组织产品、架构师与研发团队参与每日站会（站会时长不超过15分钟），完成如下事项：
- 敏捷团队成员更新自己任务进度，相互了解依赖任务的风险和计划；
- 敏捷教练和产品负责人了解项目风险，动态调整任务优先级和范围；
- 解决任务开发中遇到的阻塞。
站会规则：
- 必须站立，不要坐着，因为站着更容易集中注意力，同时要把控时间，高效完成站会；
- 拥抱变化，每天动态调整任务优先级，如“线上问题”和“紧急需求”需要最高优先级处理；
- 每天早上固定时间、地点进行；
- 不能快速讨论出结果的问题，由敏捷教练整理问题并召开跟进会议。
每个成员在会议前做好准备，会议上快速阐述3点内容——昨天完成了什么？今天计划做什么？当前的工作有没有被阻塞？
4、迭代评审会
迭代结束或版本发布前，敏捷教练组织产品、架构师、研发团队与UI设计师参与迭代评审会（会议时长1-2小时），完成如下事项：
- 需求负责人演示产品功能；
- 产品负责人验收产品类需求；
- 架构师/技术专家验收技术类需求；
- UI设计师验收前端页面。
5、迭代回顾会
迭代最后1天，敏捷教练组织团队所有人参与迭代回顾会（会议时长1小时），完成如下事项：
- 团队成员匿名反馈“做得好的”和“做得不好的”事项/人；
- 团队一起针对“做得不好的”事项/人，商讨出改进措施，并制定落地计划；
- 团队一起针对“做得好的”事项/人，提出表扬并鼓励大家继续保持。
DveOps流程
充电桩敏捷开发过程，注重开发与运维之间的交流和合作，以⼩步快跑的形式，快速迭代、构建、测试并发布版本。在日常工作中，按照以下步骤，以提升效能：
1、架构设计
架构师与研发团队在迭代早期，针对本迭代需要引入架构设计的需求，讨论方案，对业务流程、代码架构与数据架构进行设计或重构。
2、Git工作流
充电桩项目开发遵守Git工程流：按照分支管理规范创建版本主分支(dev/)、主要功能分支(feature/)及研发各自的开发分支，云效上设置保护分支，制定代码提交规范与分支合并规范，尽可能关联云效任务。
根据功能的难易程度和影响范围，可选择2-3人同时开发同一个任务，以加快交付进度。
3、版本发布
敏捷教练和产品负责人制定版本发布计划，团队按照迭代计划开发。
如果遇到线上紧急问题，敏捷教练和产品负责人动态调整迭代发布内容及计划，团队快速修复问题后及时发布。
4、代码和架构评审
在研发的过程中和交付测试之前，架构师需要对功能模块的实现进行技术评审，以确保遵循架构设计的规范，同时评估架构设计的合理性，以及是否达到架构设计的目标。
5、知识分享
在开发过程中，研发团队的阶段性研究成果或踩过的坑，在团队内进行分享，并记录到研发wiki。
6、持续集成/持续部署（CI/CD）
充电桩项目在云效流水线上，建立了完整的编译、测试及发布流程，包含代码下载与编译、构建、上传镜像，以及静态代码扫描、单元测试、接口自动化测试、应用部署。
7、运维监控
快速响应：整个研发团队7*24小时保障系统平稳运行，所有人都需要对监控告警进行响应，快速拉起在线会议解决服务问题，以避免系统出现不可用情况。
资源按需申请：对关键服务和中间件的性能指标进行监控，根据业务增长情况预估资源使用量，并在恰当时间进行升配，以应对不断增长的业务流量。
质量保证
为配合敏捷项目的快速发版，并确保上线的版本质量，充电桩项目遵循“端到端的质量策略，快速的质量反馈”的基本原则。
1、功能测试
通过需求层层确认对齐，保证需求的分析质量和传递质量，结合高效测试来快速地反馈质量。
-
尽早介入了解需求，减少对需求理解偏差，让团队成员对需求的理解保持一致；
-
紧跟迭代任务进度，缺陷状态，快速反馈质量结果，推动研发提升效能；
-
高效测试：结构化测试（基于需求设计测试用例，关联衍生场景用例等） + 探索性测试（基于埋点数据/用户反馈进行故障推测，异常条件测试等）。
2、自动化测试
引入自动化测试是确保质量的重要手段，尤其在少量人工投入的情况下可达到高覆盖率。目前充电桩项目单元测试和接口自动化测试已集成云效流水线，提前发现代码逻辑缺陷，提高开发质量和软件交付率。
-
单元测试（Junit框架，新功能80%覆盖率）的实现，确保软件的各个模块能够按照预期运行，排除潜在的缺陷和错误；
-
接口自动化（Pytest，接口数95%覆盖率）的实现，节省回归测试人力，缩短测试周期；
-
UI自动化（Selenium WebDriver框架）在规划中，将会为产品上线后快速验证，提供可靠的依据。
3、性能测试
利用性能测试工具（JMeter）模拟真实场景进行压测，通过监控平台识别系统瓶颈，协助开发性能调优，目前主要进行接口和数据库MongoDB慢查询优化。
总结
充电桩项目在经历半年多的敏捷开发模式的运作下，共经历了22个迭代，无重大生产事故：
充电桩项目敏捷开发经验可概括为以下几点：
1、为满足随时发版，采用敏捷发布火车发版模式，解耦迭代与版本之间的关系；
2、为解决“紧急任务插入迭代”与“已排期任务” 之间的冲突，根据价值交付原则，动态调整迭代任务优先级；
3、为解决代码冲突，减少发布故障，通过设置代码仓库分支策略来应对灵活的发布要求；
4、为保证快速的质量反馈，利用敏捷可视化工具（如用例分类管理、用例需求关联、需求缺陷关联以及缺陷定制化流程处理），提高研发效能，避免不必要的时间浪费；
5、为解决团队异地办公问题，通过敏捷可视化工具监控项目进度，利用好钉钉高质量的会议沟通，让团队协作顺利进行。
标签：需求,团队,迭代,敏捷,交付,充电,分享 From： https://www.cnblogs.com/bkyfw/p/18129483