这两年所处团队是公司的能效部门，平时的主要工作就是工具开发，并且制定相关流程规范的。因此，这个团队自己的规矩也是特别多，虽然不用天天在复杂多变的业务中肉搏，但也需要跟各种指标、规矩撕逼。下面就来从一个开发的角度来说说日常开发中的迭代流程吧。
首先一个完整的迭代从IPM开始，以retro结束。在这期间不同的角色有着不同的任务：
- 开发人员：开卡、开发、结卡、修结卡问题、代码检视、提测、修缺陷、填写上线变更信息、执行上线、
-
测试人员：开卡、编写测试用例、结卡、封版、合并代码至release、部署ST环境、测试、回归、上线
-
BA：分析需求、编写用户故事、细化功能点、与TL一起评审下个迭代的功能点、开IPM、开卡、结卡
- TL: 也是开发人员，不过额外需要做功能中的技术预演，功能点评审，绩效考核等管理工作。
什么是IPM? 如何开IPM的？
在敏捷实践中，IPM就是迭代计划会议，主要目的是与团队成员功能确定本迭代工作内容，以及制定详细执行计划。
我们在IPM正式开始之前有一个步骤，就是梳理上一个迭代各成员完成的功能，确定当前的迭代速率。正常情况下我们的迭代速率是0.7，会看看哪些人没有达到，为什么没有达到，以便在本次IPM中做出适当调整。
这里解释一下什么是迭代速率：比如一个功能的功能点理想情况下是1人天，按我们0.7的速率，那么一天只能按0.7天算，实际消耗天数1.4天左右。具体的可以查询相关知识。
IPM就是主持人一般是BA，他会将所有的功能依次进行澄清，在此过程中其他人都可对该功能提出问题，BA（或者功能提出者、其他熟悉功能的人）需要就问题进行回答，如果不能回答，该功能将被搁置。
当一个功能完全澄清、且问题均被解答后，就是开发人员估点了。估点的时候需要结合自己的实际情况，以某种标准来衡量复杂度（我们是以一张带有表单网页或者后台一个CURD接口为标准，也没法具体量化，大概就是那么多）进行估点。然后最高的人员需要对自己点数进行澄清，为什么需要那么多时间，是否有其他同时未考虑到的情况，如果存在则需要重新估点；不存在基本上是以平均值作为最终点数。
但所有的功能都评估完后，IPM基本上就结束了。会后，BA或者TL会根据实际情况对功能点进行排序，并在看板的需求分析价值列的done泳道中建立对应卡片，开发人员按照顺序依次领取任务。
如何进行开结卡的？
上面说了，IPM后开发人员会按照顺序领取任务，领取后该如何开始和结束任务呢？那就涉及到开卡和结卡了。
开卡
在开卡之前，开发人员需要将功能卡片拖动值开发价值列的todo泳道中，对任务进行完全熟悉，并指定相应的开发计划。梳理出涉及哪些服务，修改范围，有些复杂的关键的功能还需要将类名、方法名等定出来。当前开发人员认为自己已经完全了解了任务需求后，就可以约相关人员开卡了。
开卡一般需要QA，BA，TL，以及其他相关人员一起进行，由开卡人员复述功能需求，以及说明将如何完成工作。这个过程中，参与开卡的人都可以进行提问，以保证功能需求理解没有问题，以及修改方案不会影响到其他功能。QA全程参与所有的开结卡，这个过程中他也会提出自己的理解和问题。
开卡最终大成的效果是QA、BA、开发三方对功能需求完全一致（说句题外话，越是开发经历丰富，越会知道沟通才团队中最高的成本）。
编码
接下来就是开发进行编码、自测过程，QA也会同步进行用例编写。功能完成后，开发人员发起结卡行为。
编码过程如果遇到问题，需要及时与BA进行确认，如果需要修改卡片内容，则需要同步至所有开卡参与人。
结卡
结卡参与者与开卡完全一直，开发人员按照卡片中的内容，逐一进行演示，以确保做的东西是需求要的。
如果结卡中存在重大问题，会进行返工重做，完成后重新进行结卡。
如果仅存在少量不严重的问题，则会被记录在卡片末尾，以结卡问题进行修复，修复后不需要再次结卡。
如果没有任何问题（或者结卡问题已经修复完毕），就进入测试流程了。
测试过程对于开发侧比较简单，就是修复QA提出的缺陷。对于测试侧来说需要做的就比较多，需要封板、冒烟、提缺陷、回归缺陷等。
等测试通过后，就要准备上线了（投产）。
如何上线的？
迭代最后一天，测试会进行封版，封版后所有与当前迭代相关的代码，只能通过fix分支提交到release
上。同时，会发出本次上线的checklist
checklist包含内容：
- 确定本次上线后端owner、前端owner、测试owner
-
对应功能卡，涉及服务，各环境修改内容，对应负责人
- 本次上线涉及服务，以及代码合并情况，以及对应负责人
- 本次上线涉及数据库脚本，以及对应负责人，以及各环境执行情况
- 回归测试结果，投产当日下午4点之前（我们一般是晚上8点执行上线操作）
-
部署前的流程
- 兼容性确认
- 服务范围确认
- 脚本确认
- 上线通知
- changelog
- 检查检视问题、issue、故事卡等一切状态是否就绪
- 检查版本号
- 各环境配置是否已经准备就绪
- 确定流水线执行至出库（部署前一步）
- 发布权限申请
- 迭代特有工作是否完成
- 数据库脚本执行
- 服务部署
- 部署后需要进行验证
- 上线功能确认
- 版本号是否正常
- 是否需要回退
- 帮助中心文档更新
- 是否存在遗留脚本
- 上线问题登记
以上为我们的完整上线流程
如何开retro的？
开篇的时候就提到了，retro是一个迭代完全结束的标志，一般上线完毕第二天就行进行retro。retro都要做些什么？这个之前我有写过一篇文章《敏捷实践：retro》。这个地方就不多做赘述。
如何管理数据库脚本的？
之所以将数据库脚本单独提出来说是因为团队的数据库脚本管理上确实有可借鉴的地方。
团队的数据库脚本有一个单独的项目进行管理，所有的字段、配置、表等修改都需要编写sql脚本，然后提交到仓库，由流水线自动执行。
禁止一切开发人员自行修改数据库表结构的行为，包括DEV环境也是不被允许直接修改。这避免了多个环境数据库表结构不一致导致结卡时和测试时功能表现不一致的情况。
在封板之前，所有的脚本都是直接提交到master分支，如果脚本有错误，流水线会回滚本次提交中的所有脚本。
如果并非语法问题，而是逻辑错误，则需要重新提交矫正脚本，以及新方案脚本。
封板后直接将master合并至release， 并且冲突时保留master中的内容。后期如果修改脚本内容，需要单独拉分支合并至release，同时需要合并至master。这个跟普通项目相似。
上线后完成后，会对脚本进行归档，其实就是将已经执行的脚本挪到一个归档文件中，以便后期追溯负责人。
数据库脚本管理的核心思想就是，对数据库表结构和配置有修改的，均不能开发自行执行。
如何开早会？
早会是敏捷实践中的一个重要环节，用于回顾昨天完成工作，更新各功能的进度，计划今天的工作内容。以便全体成员了解与自己下一步能做什么，该做什么。
还有一个作用就是收集目前开发过程遇到的问题，TL需要针对问题提出解决方案，看是否搁置开发，还是寻求相关方的支持。
最后就是检查目前团队的健康度，比如说是否有遗留失败的流水线，超期的功能，长期停留的卡片等。
团队有一个“扣命”的实践，就是制定了一个团队契约，契约中有扣命条款、加命条款，初始三条命，扣完就需要交一定的经费作为retro的活动经费，缴费后恢复初始状态。
如何进行代码检视？
代码检视是团队的日常工作，所有功能上线之前，都必须经过检视，并且将检视问题完全修复。
我们一般会在封板后集中进行代码检视，平时也会有一定的检视安排，主要针对一些关联度比较高功能，以免后续改动较大。
检视过程就是开发需要按照一定的顺序将讲解自己的代码，其他人就代码中的规范、风险、命名、布局等提出建议和问题，并会记录到检视平台中，开发需要在三天内修复所有检视问题。
每次检视会议不会太长，一般在1.5小时左右，如果一次检视不完，则下次继续。
以上就是团队中的一些敏捷开发实践，这也是这两年来在非技术领域的最大收获了。
