oto网站开发,顺企网官网企业名录,代做网页设计作业,wordpress可以自定义模型吗简介#xff1a;如何开一场高效的迭代排期会#xff0c;高效落地敏捷开发#xff0c;先从这3个关键活动着手#xff0c;通过本文你将了解到什么是敏捷开发、什么是双周迭代、如何高效地开展排期会#xff0c;以及如何在云效项目协作Projex 中落地排期会相关事宜。
摘要如何开一场高效的迭代排期会高效落地敏捷开发先从这3个关键活动着手通过本文你将了解到什么是敏捷开发、什么是双周迭代、如何高效地开展排期会以及如何在云效项目协作·Projex 中落地排期会相关事宜。
摘要如何开一场高效的迭代排期会高效落地敏捷开发先从这3个关键活动着手通过本文你将了解到什么是敏捷开发、什么是双周迭代、如何高效地开展排期会以及如何在云效项目协作·Projex 中落地排期会相关事宜。 作为团队的负责人你希望将研发模式从瀑布式转为敏捷并进行持续改进但却不知道从哪里开始
作为项目管理人员你希望负责建立迭代机制并进行规模化的推广和度量但却不知道如何快速建立机制
作为产品经理需求排期后你希望能方便地跟进需求进展及时发现问题但却不知道怎么跟进方便
接下来我们将通过 3 篇文章带领大家逐步了解敏捷开发的全过程及高效落地指南。
敏捷开发之 Scrum 方法介绍 在敏捷开发落地的过程中通常采用 Scrum 的方式所以我们以 Scrum 为例来介绍敏捷开发的流程和场景如上图在这个过程中
1. 首先产品经理会进行
○ 需求的收集、调研和分析形成按优先级排序的产品待办列表
○ 对高优先级的需求进行详细设计和澄清
○ 通过迭代排期会形成按优先级排序的迭代待办列表
○ 排期完成后需求从产品经理侧流向技术同学侧。
2. 在需求澄清的情况下研发团队来会
○ 以 14 周的迭代周期进行持续开发和交付迭代待办列表中的内容
○ 采用每日站会来跟进计划和发现问题并在迭代过程中持续或间歇性地交付可工作的软件。
与此同时产品经理会在这个阶段进行下一迭代的需求设计和澄清。
3. 迭代待办列表开发完成后产品经理和研发团队一起进行迭代演示交付可工作的软件。
4. 最后通过迭代复盘会活动驱动团队持续改进。
在落地 Scrum 方法时无论是阿里内部还是云效的企业客户通常采用双周迭代的运作机制下面我们以「双周迭代」为例进行介绍。
双周迭代的运作机制 双周迭代时序图
上图是双周迭代的运作流程
● 在 N-2 和 N-1 周业务和产品会持续做需求的分析和设计会把要排入迭代的需求按优先级高低准备好包括需求的分析、设计和澄清
● 随后开发和测试同学在排期后的两周内 N 周和 N1周按优先级对需求进行开发、测试、验收和发布上线。注排入迭代的需求在迭代排期前要已澄清清楚并明确验收标准。
● 迭代排期在双周迭代中起着前后衔接的作用每两周进行一次一般每次 12 小时。排期前业务和产品同学需要准备好待排期的需求排期后开发和测试同学需要按照计划对需求进行开发、验证和发布。
● 迭代节奏和发布频率是要解耦的迭代节奏可以是两周或一周而发布频率可以是每两周一次、一周一次、或一周多次等。有的企业或团队会按照每个迭代进行一次发布来落地也有可能按照一个迭代进行多次发布来落地。
至此我们理解了敏捷开发的整体流程及双周迭代的运作机制。可以看到在双周迭代的运作中一个迭代中有 3 个非常重要的活动迭代排期、迭代跟进和迭代复盘。本篇文章我们先从「如何开展一场高效的迭代排期会」聊起。
如何开展一场高效的迭代排期会
想要开展一场高效的迭代排期会需要相关同学做一些准备工作我们将排期活动中的需要准备的事项、目标等整理在一起如下表供大家参考。 我们会看到在排期输入、排期过程、排期输出环节的要求比较多如果没有要求的话排期会将会比较低效后续的迭代推进也会出现各种问题。如下是我们在辅导敏捷开发团队过程中总结的几个注意点
● 明确的迭代目标迭代需要有比较明确的目标没有目标容易出现需求范围蔓延的情况导致团队成员无法聚焦
● 需求唯一优先级很多产品经理在提迭代需求时会出现需求的优先级都是“紧急”的情况其实这反映了需求的真正优先级是不明确的。我们需要明确出唯一优先级排序这个过程不但能够让团队深入思考、对优先级提出积极挑战也能梳理出优先级高、真正对业务有价值的需求
● 需求已澄清且技术方案已确认需求已澄清是排入迭代的基本要求有些团队会把未经过分析、设计和澄清的需求排入迭代导致排期时无法给出准确的工作量预估也无法快速进入开发这会影响其他需求的进展和整个迭代的节奏
● 需求已拆分通常情况下需求要拆分到在一个迭代内可以完成交付方便快速验证业务假设缩短业务的响应周期
● 明确需求负责人需求进入开发时一般会需要多位技术同学合作完成如前端和后端或多个后端这时我们建议由其中一位同学担任需求负责人跟进需求到发布上线为止。这样可以更好地协调开发内部协作避免过程中的争论或互相推脱提升整体的协作效率。
● 明确关键时间点需求排期时往往会有 3 个时间点需要明确
○ 联调时间需要联调协作的开发同学会比较关注联调时间
○ 预计提测时间测试同学比较关注什么时候提测这是开发与测试协作需要明确的时间点
○ 预计发布时间产品经理比较关注的需求什么时候发布。
● 同步下一个迭代的需求有的研发团队会说不知道接下来要做什么也有的团队会出现需求断档这里建议产品经理可以提前把下一迭代要做的需求同步给大家让大家了解近期规划以便更好地安排研发节奏。
敏捷开发落地往往需要平台或工具支撑下面我们以云效项目协作·Projex 为例介绍如何使用工具来高效落地迭代排期活动。
借助云效项目协作·Projex 开展迭代排期
一、 排期输入
正如前面所说为了能够开展一次高效的迭代排期会需要准备一些内容。在云效项目协作·Projex 中我们也提供了准备排期会相关的产品能力。
1.创建迭代并明确的本次迭代需要达成的业务目标负责人产品经理或研发负责人
通常创建迭代由产品经理或研发负责人负责此时需要明确迭代的名称、负责人、迭代周期、迭代容量和迭代目标需要注意
● 迭代名称需要遵循一定的规范如“迭代迭代结束日期”
● 迭代容量团队人数相对固定时一个迭代内的工时容量也是相对固定的如双周迭代是10个工作日如果团队有 8 位同学一天的有效工时按照 7 个小时计算容量就是 560 个小时
● 迭代目标目标需要具体可衡量且与业务目标有直接或间接的关系。 创建迭代
2.将产品待办列表按优先级排序 负责人产品经理
云效项目协作·Projex 的需求管理中产品经理可以根据诉求使用过滤器配置“产品代办列表”公共视图视图默认按照优先级排序也可以设置成按照状态、负责人等其他自定义属性排序。 产品需求待办列表
3.待排期的需求已澄清并满足准入排期的要求负责人产品经理
4.保证需求已拆分到可在一个迭代内完成交付负责人产品经理
5.各需求的技术方案已评审通过包括但不限于各模块间依赖关系、接口定义负责人研发负责人
产品经理一般通过开展需求评审会来澄清需求在澄清过程中产品经理会对需求内容进行讲解并将需求拆解到较小颗粒度一个迭代内可以完成交付。同时研发团队会根据需求实现的复杂程度来判定是否需要做技术方案或预研工作。对于需要做技术方案的需求需要明确技术方案评审的时间点以便可以尽快投入开发。
在云效项目协作·Projex 中对于已澄清的需求需求更改状态到“已评审”状态。技术方案已确认的需求可以在需求上打上“技术方案已确认”的标签。
注团队在云效项目协作·Projex 中创建项目时可以定义需求的工作流建议为「待处理-已选择-设计中-已评审-已排期-开发中-待测试-测试中-待验收-待发布-已发布」在这个工作流下仅对状态为“已评审”的需求进行排期。 可排期的需求列表
6.提前梳理好下一迭代的需求列表负责人产品经理
为什么要在这个迭代中去讲下一个迭代的需求列表呢在辅导云效客户的研发团队过程中我们发现有的研发团队会出现不清楚下一迭代会做什么或需求断档的情况。如果你们的团队也有类似的问题建议在迭代排期的时邀请产品经理把下一迭代需要做的需求大致讲一下让研发团队提前了解并识别风险如果你们团队没有类似的问题可以跳过这个环节。
在云效项目协作·Projex 中下一迭代的需求可以用两种方式呈现一种是给需求打上“下一个迭代需求”的标签另一种是直接把迭代字段更新到下一个迭代。如下图是以标签方式实现对下一迭代需求管理的方式 二、 排期过程
1. 研发负责人做上一迭代回顾
在排期会刚开始时研发负责人可以在云效项目协作·Projex 的迭代模块中带领大家回顾上一迭代需求的完成情况需要重点关注未完成的需求情况如果有未完成的需求需要评估还需要投入多少工作量并将其移入即将开始的迭代中。 上一迭代回顾
2. 产品经理讲解和规划需求
首先产品经理可以在迭代概览中看到创建迭代时设置好的迭代目标并向研发团队介绍。 概览中的迭代目标
随后产品经理按优先级讲解迭代待办列表中的需求需要通过评审和技术方案确认。在云效项目协作·Projex的迭代规划中如下图产品经理可以通过所需条件过滤需求过滤条件可以保存并按照优先级高低讲解需求讲解过程中或之后可以直接将排入迭代的需求拖拽迭代卡片中。 迭代规划时讲解需求 需求拖拽规划
3. 研发团队进行工作量评估
在排期的过程中研发团队需要评估各需求的工作量根据团队整体人力容量情况确定本次排期的需求列表
● 明确需求工作量需求工作量是指各需求需要的人力工时数量可在排期会前或会上进行估算
● 确定迭代容量迭代容量是研发团队一个迭代所能投入到需求完成的工时总量
在排期的时候我们可以随时在目标迭代的右上角查看排入需求与团队工时容量的匹配情况。 迭代容量统计
4. 明确需求负责人和任务拆解
在排期会上很重要的一个事情时对已排期的需求明确需求负责人拆分到技术开发任务并给出各需求的关键时间点譬如计划提测日期和计划上线日期。
● 明确需求的负责人这里特指需求的开发负责人需要负责需求从进入开发到发布上线的全过程
● 需求拆分到开发任务需求的开发负责人需要负责将需求拆解到各个开发任务Web端、H5 或 客户端的需求往往需要前端和后端的联合开发或者一个需求要不同开发同学负责还会涉及到联调任务这是便需要对需求进行任务的拆解。不过对于特别小颗粒度的需求也可不进行任务拆解。 需求拆分为多个开发任务
明确关键时间点在迭代排期上测试同学会关心需求什么时候提测提测日期产品经理会关心需求什么时候上线交付时间如果有研发内部协作时研发团队也需要明确开发内部的联调时间等。这些时间点建议在排期会上基本明确下来。如下图可以在迭代“工作项”页面设定需求的关键时间点。 明确需求的关键时间点
更新好需求状态需求排期确定后需要的状态要更新到“已排期”。 需求状态更新到“已排期”
5. 明确已排期需求的发布窗口
这一点要看团队的实际情况有的团队是固定发布窗口有的是一个迭代一次发布也有的是一个迭代多次发布。
● 如果是一个迭代发布一次相对简单上一步的关键时间点可以选择不填。
● 如果是一个迭代发布多次的需要查看每个窗口发布的具体需求条目和数量往往发布窗口的时间和需求的计划完成时间是一致的。
● 如果是持续发布的那这一条可以忽略。
6. 下一次计划排期的需求讲解
产品经理按照优先级和状态讲解下一次排期的需求情况可以用标签也可以直接用迭代来标识 下一个迭代的需求
三、 排期输出
在迭代规划会后我们需要有明确的产出
● 本次迭代的目标和已排期的需求列表
● 已排期的需求用迭代标记规划入迭代
● 各需求的负责人和关键时间点
● 本次迭代内的发布窗口和对应的需求列表
● 下一次计划排期的需求列表
● 输出迭代排期会议纪要同步给相关人员包括团队成员、业务方、依赖和被依赖方等。
前面 5 个点我们在云效项目协作·Projex 迭代详情页面的“工作项”中均可查看包含需求名称和各关键属性如下图 此外迭代“概览”中还可以通过“迭代工作项概览”和“迭代工时概览”卡片查看迭代的排期完成后的工作项和工时统计数据、迭代成员的工作量情况
● 迭代工作项概览统计迭代中排序的需求、任务和缺陷的数量情况
● 迭代工时概览展示迭代容量统计迭代中需求的预计工时总和 ● 工作项排名按照团队成员负责的工作项包含需求、任务和缺陷数量进行排名凸显前5名方便对工作内容进行重新安排和调整
● 迭代工时排名按照团队成员负责的工作项预计工时数排名凸显前 5 名方便对工作内容进行重新安排和调整。 针对第 6 点-会议纪要部分排期会的负责人在会前就需要指定好会议记录的负责人在结束后把“排期输出”以会议纪要的形成同步给相关人员尤其是业务方、依赖方和被依赖方等。
总结回顾
当你打算落地敏捷开发方法时我们建议一开始就要让团队成员理解敏捷迭代的落地过程并共识双周迭代的运作机制这样可以让整个团队都心中有数并提前准备关键事宜。
而在整个敏捷开发方法运作过程中迭代排期会至关重要起到承上启下的作用相关负责人需要做到
● 迭代排期会前产品和研发团队需要把待排期的需求准备好
● 迭代排期会时产品和研发团队需要达成共识明确排入迭代的需求列表并做出相应的承诺
● 迭代排期会后需要对排期的计划进行推动和跟进直到需求完成开发、测试和发布上线为止。
至此我们已经了解了什么是敏捷开发、什么是双周迭代、如何高效地开展排期会以及如何在云效项目协作·Projex 中落地排期会相关事宜。后面2篇文章我们将详细介绍迭代跟进-每日站会、迭代复盘这两个活动期待大家的持续关注。
原文链接
本文为阿里云原创内容未经允许不得转载。
