![](https://img-blog.csdnimg.cn/20201014180756757.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
敏捷迭代管理
杨不羁
所谓格物致知,本博客致力于梳理研发管理之道,以致高质高效自驱可控。
展开
-
中型研发组织管理之--敏捷迭代管理
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理敏捷一直都是一种“思想”,讲究“沟通”、“协作”、“信任”,轻“合同”,轻“文档”;所有理想很丰满,但落地真的很骨感。可以说绝大多数团队都是形式化敏捷。一方面是“思想”这种东西比较虚无缥缈,很难在团队内达成统一认知;另一方面,“沟通”、“协作”、“信任”,轻“合同”,轻“文档”,这玩意儿对成员素质要求太高,人性这东西,不太可能在搬砖这件事情上莫名其妙散发光辉;因此,这么多年经验告诉我,需要一个基于敏捷“思想”的.原创 2020-12-06 12:12:54 · 727 阅读 · 1 评论 -
敏捷迭代管理 --定期发布
研发组织管理--项目管理--敏捷迭代管理--定期发布目的定期发布作为敏捷迭代的一个基石,两个关键字“定期”和“发布”;定期:保证周期稳定,原则上不允许修改周期,保证迭代间产出的各类数据有参考价值,以复盘和有效规划下个迭代发布:保证团队固定周期对需求方有交付,交付不是承诺某功能一定在某天上线,而是确保需求按卡片优先级顺序开发测试并在迭代上线日上线;落地规则1.两周一迭代,迭代周期最后一天发版,若发版日后一天为节假日,顺延至节假日后一天发版。故迭代周期正常10个工作日,顺延时11个工作日原创 2020-12-06 11:41:05 · 887 阅读 · 1 评论 -
敏捷迭代管理 --需求讲解会前准备
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--需求讲解会前准备同定期发布一样,需求讲解会前准备也是直接决定敏捷过程是否成功的绝对基石,因此需要重点关注其内容和实效性;目的1、大致确定本迭代需求范围; 2、检查需求完整性; 3、确认需求外部接口文档,对接人,联调时间; 4、确认需求优先级;时间&频次1、由PM发起,上个迭代周期内(需求讲解会前一天确认完毕); 2、上个迭代最后一天TTL、Master验收;议程1、打开卡片逐个检查需求完.原创 2020-12-06 12:09:51 · 649 阅读 · 0 评论 -
敏捷迭代管理 --需求讲解会
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--需求讲解会目的1、PM讲清楚需求; 2、RD,QA理解透需求,三方达成一致; 3、确保大卡片被拆分; 4、拆分后的卡片预分配到RDQA人员;时间&频次1、由Master发起,按团队维度召开; 2、上个迭代结束后,第一天早上一早开;议程1、PM按需求卡片,优先级从高到低依次讲解需求; 2、单个卡片讲解中RD,QA可参与进来讨论,对细节发问,主要集中在一些业务异常; 3、每个卡片讲解完进行是.原创 2020-12-06 12:30:13 · 506 阅读 · 0 评论 -
敏捷迭代管理 --迭代启动会前准备
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--迭代启动会前准备迭代启动会前准备也是直接决定敏捷计划是否合理,因此需要重点关注每个角色的需求精读质量;目的1、保证卡片按完整功能拆分并粒度足够小; 2、保证RD/QA完成需求精读 3、保证卡片工作量相对准确的预估;时间&频次1、需求讲解会结束后的4H内; 2、迭代启动会前;议程1、根据需求和发布安排确定开发卡片的最终优先级; 2、TTL进行卡片预分配和经验预估点,预估当期迭代的任务饱和度.原创 2020-12-06 12:56:24 · 631 阅读 · 0 评论 -
敏捷迭代管理 --迭代启动会
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--迭代启动会目的1、团队确认整个需求范围即明确的卡片列表; 2、每人明确自己工作任务; 3、明确迭代内上线次数、负责人和分批上线的功能;时间&频次需求讲解会后4H,如果有耽误(非需求变更原因),也一定尽量要在当天完成2会(讲解会、启动会)议程1、TTL按照卡片优先级依次明确卡片的开发人员,测试人员,并最终确认估点,计入迭代内直到团队产能耗尽; 2、过卡片过程中QA特别关注卡片的测试时间线是否符合.原创 2020-12-06 13:37:37 · 1007 阅读 · 0 评论 -
敏捷迭代管理 --每日站会
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--每日站会目的1、同步信息,抛出问题; 2、周知需求变更及调整;时间&频次1、每天一次固定时间, 开始时间由master安排; 2、时长由master控制(通常n+5分钟内);议程1. master整理准备看板. 2. 以产品,研发,测试顺序对属于自己的卡片状态进行更新 产品--是否有需求变更(非站会时更新的需求变更研发经理及RD不能接) 研发--今天做了什么,有没有遇到什么问题, ...原创 2020-12-06 14:56:58 · 973 阅读 · 0 评论 -
敏捷迭代管理 --迭代回顾会
↵本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--迭代回顾会目的1、回顾,自我更新不断优化团队; 2、提出做得好的加以赞许(很重要); 3、提出待改进点,加以跟进; 4、提出期望,借助外力优化;时间&频次1、迭代启动的第一天; 2、前4次迭代,必开,后期最少每两次迭代开一次;议程1、打开wiki,查看往期“better”项已指定“跟进人”的待改进项,逐条查看是否已解决,关闭已解决项; 2、每人依次发言,分别提出:good、bet...原创 2020-12-06 15:04:42 · 1892 阅读 · 0 评论 -
敏捷迭代管理 --Master传帮代
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--Master传帮代目的1、增加团队敏捷理解; 2、每个组员轮职Master,承担一些例行事务,也体验一下站在全局的思考;时间&频次1、Master每迭代轮换一次,并指定下个Master;议程各流程环节Master主持时,下任Master跟进学习,配合记录todo或会议纪要,做到流程及责任认知,下迭代能独立完成各流程事项和相关会议的主持;Master职责1、协助下任Master熟悉和掌握..原创 2020-12-06 15:14:18 · 411 阅读 · 0 评论 -
敏捷迭代管理 --卡片挂起细则
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--卡片挂起细则目的1、及时解决卡片挂起原因; 2、调整迭代计划,避免人力浪费;议程1、相关责任人尝试解决挂起; 2、如无法解决,角色负责人及时调整迭代计划并周知全员;罚则卡片责任人未及时同步卡片风险造成卡片不能上线且需求方不认可。罚基数*2。Master职责关注或改变卡片状态并站会同步全员TTL(team tech leader)职责根据挂起调整计划PM(产品经理)职责评估卡片调整后上线.原创 2020-12-06 15:20:35 · 370 阅读 · 0 评论 -
敏捷迭代管理 --需求变更规范
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--需求变更规范目的1、保证已规划迭代节奏不被打乱,规划卡片按优先级交付;2、拥抱变化,允许合理的高优线级需求插入;议程Master职责1、操作卡片; 2、站会周知;PM(产品经理)职责1、需求提出,建立行云卡片到backlog中; 2、参与需求评审; 3、参与变更评估;TTL(team tech leader)职责1、参与需求评审 2、参与变更评估RD(前后端)职责参与相..原创 2020-12-06 15:26:22 · 1216 阅读 · 0 评论 -
敏捷迭代管理 --分支管理&提交规范
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--分支管理&提交规范目的1、提高需求开发并发能力;2、优化提测,上线分支管理;3、完善代码回滚策略;时间&频次迭代启动会开始之前拉好分支;议程1、系统负责人拉出当前迭代对应的统一迭代分支,以迭代号命名,如:release/01(迭代末),release/01.1(迭代中); 2、系统负责人拉出当前迭代对应的统一开发分支develop/01,并在开发环境部署; 3、 开发人员从mast.原创 2020-12-06 15:34:31 · 1081 阅读 · 0 评论 -
敏捷迭代管理 --设计沟通
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--设计沟通目的1、规范设计,前后端想清楚设计方案并达成一致; 2、在模型字段定义、交互和前后端接口层面达成一致并输出文档; 3、测试了解程序的运行逻辑并理清测试点;时间&频次1、每个Story开发前 前后端RD沟通; 2、每个story提测前,RD和QA沟通;议程1、前后端对照产品原型、PRD讨论清楚相互方案、设计实现方案,并达成一致; 2、完成业务模型的定义、和接口定义并前后端达成一致,复杂.原创 2020-12-06 15:41:36 · 393 阅读 · 0 评论 -
敏捷迭代管理 --提测管理
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--提测管理目的1、保证提测质量; 2、研发提测内容清晰可记录,并且不影响主干测试分支; 3、测试更容易对上线内容和配置进行管理, 把控上线进度;时间&频次每个卡片联调完成之后;迭代启动会后测试推送上线计划表;每次提测后更新上线计划表;议程1. 研发完成代码后需要开发环境通过P0用例(主干P0和卡片P0); 2. 研发在提测行云卡片中填写变更影响范围,以及需要关注的功能点、接口文档地址;.原创 2020-12-06 15:59:43 · 969 阅读 · 0 评论 -
敏捷迭代管理 --上线流程和规范
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--上线流程和规范目的确保不会由于不规范的上线流程导致线上问题或延迟上线;时间&频次每次上线(默认一个迭代1到2次);议程1. 上线日16:00测试封板代码, 锁定待上线Release分支; 2. 测试通过上线计划发送测试最终结果; 3. 研发上线负责人基于上线文档卡片(迭代启动会时master建立)开始整理上线分支, 需要打包的项目,SQL ,各项配置变动和执行顺序,安排上线时间(每个git项目的.原创 2020-12-06 16:20:04 · 2297 阅读 · 0 评论 -
敏捷迭代管理 --工时估算(估点)
本文在研发组织管理中的位置:研发组织管理--项目管理--敏捷迭代管理--工时估算(估点)敏捷推荐按难易程度来估点,即设置一个标准难易程度的任务作为参照,记为:一个点,其他任务均参照此任务进行估点。不过此种方式比较玄乎,新团队一来就按照这种方式大家容易一下比较懵,还是推荐一种不太“敏捷”的方式做过渡,成熟后再尝试上述方式。下面介绍一下这种中庸之法:总工时:每迭代10天 = 80h (需求估点 + 日常事例 + 线上问题)需求估点 = 需求设计时间(这很重要) + 代码开发时..原创 2020-12-07 14:16:50 · 1826 阅读 · 0 评论