云服务器内容精选
-
需求变更情况下的移动 不接受变更 当一个Sprint的Sprint Backlog和Sprint目标确认后,为了保持团队在很短的时间内,全力以赴的向着Sprint目标冲刺,一般情况下不接受PO提出的需求变更。在很短的周期内,PO是有责任负责整理好Sprint Backlog的,进一步说,PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog,然后按优先级,挑选出最近一个Sprint的Product Backlog形成Sprint Backlog,因此经常性的需求变更建议团队不接受,另一方面也是一个好习惯的养成,促进PO对需求的把控能力。所以这种情况下,团队正常移动看板中的卡片就好。 拥抱变更 完全拒绝需求变更是不现实的,有的时候高优先级的需求一定要满足变更的要求。比如,有市场时效性的,本Sprint不能完成,不能抢占市场先机,但变更需要遵循“NO CHANGE”原则。接到需求变更后,首先不是直接接受或者拒绝,而是先对需求进行分析,分析对当前迭代的影响。一般分析结果为以下几种情况: 无价值需求 与PO沟通协商,对于无价值需求果断拒绝,看板中的卡片不做任何移动。至于这些无价值的需求怎么来的,情况比较多,这里不做讲解了。 变更少,影响小的需求 高优先级的,对Sprint影响小的需求变更,可以柔和接纳,但要评估工作量,做等价交换。简单说,就是把未做的优先级低的需求从看板中替换出来,移动到Product Backlog中,这也是Product Backlog Refinement的过程,然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理:一种是移回到Product Backlog列,这种情况多于以完成特性需求为目标,更符合敏捷。另外一种是移到Done列,这种情况多见于物理看板中对统计度量数据比较看中的团队,团队需要对工作量进行有效统计。第二种情况在有些电子看板中也可以灵活统计来满足团队需求,那么就可以直接移动到Product Backlog列。 变更多,影响很大的需求 高优先级的,对Sprint影响很大的需求变更,需要停止当前Sprint,重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值,这时果断停止当前Sprint,另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成,也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。
-
问题分析 如何使用 IAM 来控制权限? 通常一个IAM主账号下,可以创建多个软件开发项目。默认情况下,只有IAM主账号默认可以设置是否能允许子账号创建项目,只有IAM主账号能查看所有项目和成员等。在某些企业场景下,IAM主账号可以通过IAM的细粒度权限管理,设置部分子账号可以代替IAM主账号的设置权限。 项目成员的角色有哪些? 通过项目管理创建的所有项目都支持基于本项目的权限设置,且每一个项目的权限设置相互独立。 在项目管理中,默认项目角色包含以下几大类: 项目管理员:项目的创建者。 项目经理:项目开发管理员。 测试经理:项目测试管理员。 产品经理:项目的需求分析管理者。 系统工程师:项目的架构分析管理者。 Committer:参与项目开发的人员。 开发人员:参与项目开发的人员。 测试人员:参与项目测试的人员。 参与者:参与项目指定工作处理的人员。 浏览者:关注或浏览项目内容的成员。 运维经理:参与项目维护工作的成员。 如何将成员添加到项目并分配角色?
-
解决措施 需求管理服务使用 统一身份认证 服务(Identity and Access Management,简称IAM)管理整个租户下多项目的统一权限。在单个项目内,基于具体项目设置进行项目内的权限管理。需求管理的权限管理分为两种,分别是云服务级和项目级。 云服务级:服务级的权限通过统一身份认证服务设置。IAM是华为云提供权限管理的基础服务,无需付费即可使用,您只需要为您账号中的资源进行付费。 关于IAM的详细介绍,请参见IAM产品介绍。 云服务级权限详情请参见需求管理云服务级权限介绍。 项目级:项目级的权限通过需求管理服务设置。项目级权限详情请参见项目级权限。 更多关于成员的相关内容请参见管理CodeArts项目级权限。
-
解决措施 如何玩转站会?我们按照如下思路学习下。 图2 站会学习思路 理解站会价值 团队每天站着召开的短时间会议称之为每日站会。每日站会是团队对每天工作检视和调整,提前进行自组织。 通过站会团队每个人可以了解全局,知道发生了什么事情,实现冲刺目标的进展如何,对当天的工作是否需要修改计划,有什么问题或者障碍需要处理。每日站会是一个检视、同步、适应性制定每日计划的活动,以帮助自组织团队更好地完成工作。 有些团队认为每日站会是解决问题的,是传统意义上向项目经理汇报状态的会议,其实都是不准确的,或者说误解了它的核心意义和价值。 每日站会对于让团队成员每天集中精力在正确的任务上是十分有效的。因为团队成员在同伴面前当众作出承诺,所以一般不会推脱责任。给团队成员一种精神激励,要对每日的工作目标信守承诺。每日站会还可以保证Scrum Master和团队成员可以快速处理障碍,培养团队文化,让每个人意识到我们是“整个团队在一同战斗”,一些没有使用敏捷的组织有时候也同样采用每日站会。 归纳站会的价值和意义,以及误解: 图3 站会的价值、意义和误解 明确正确站会 正确的站会应该怎么开呢?我们一起学习下。 对于每天的工作,为了提前进行自组织,团队成员准时围绕着白板前站立(增加仪式感)。 图4 站会示意图 团队成员在站会上需要轮流发言,回答如下三个问题: 我昨天做了什么?(从上次站会到现在,我做了什么?) 今天计划做什么?(在下次站会之前,我会做什么?) 我遇到了哪些问题和障碍?(哪些问题和障碍阻止了我的工作或使我的工作放缓?) 这简单的三个问题可以促使团队成员每天都要检视自己的工作、制定自己的工作计划、获得清除障碍的帮助以及对团队做出承诺。如果团队按正确的方式开站会,进行得好的话,可以达到如下效果: 图5 站会目标 共济压力 健康的敏捷团队都会有共济压力。所有的团队成员都承诺要一起完成冲刺的工作。这就使得团队成员之间相互依赖并且对彼此负责。如果一个团队成员连续几天都做相同的事情,并且没有进展,显然缺乏前进的动力,而其它团队成员不能视而不见。因为他未完成的工作会变成其他成员的障碍。 细粒度的协作 在站立会中,团队成员的交流应该快速而且有重点。举例,当一个成员说完今天计划做什么后,另外一个成员可以会说:“哦,原来你今天计划做这个啊,这就意味着我要调整我的工作优先级,没关系,你按照你的计划做吧,我可以调整。很高兴你说了这些。”这种细粒度的协作使得团队成员知道他们之间如何及何时仰仗对方。一个敏捷团队应该追求高效、零等待,避免等待浪费。 聚集少数任务 在站会期间,团队中的每位成员都可以知道哪些工作正在进行,哪些工作已经完成。健康的团队应该关注事情的完成,也就是说任务不能一直处在进行中。在站会中,团队需要确认哪几个少数任务是当前的焦点,这样团队就可以尽快把焦点任务做完。换句话说,做完10件事,远比正在做100件事儿更有意义。 每日承诺 在站会上,团队成员需要对团队做出承诺。这样团队成员就知道敏捷交付什么成果并如何保证彼此负责。 提出障碍 其实在敏捷中任何时间都可以提出障碍,但是站会是一个黄金时刻,团队成员可以停下来认真思考“有什么事情阻碍了我或让我的工作放缓了”。 最佳实践和关键点 通过大量实践总结出一些能够帮助开好站会的关键点,也许这些关键点并不是全适用,所以还是要根据现实情况做出合适自己团队的选择和裁剪。这些关键点,我们称之为“站会18 key”。 站会18key按照人(People)、过程与方法(Procedures and methods)、工具与设备(Tools and equipment)划分,帮助大家记忆和学习。 图6 站会18key Key 1: 主持人 会议主持人(比如Scrum Master,也可以团队成员轮班,轮流感受下站会的节奏)确保会议的举行,并控制会议时间,团队成员进行简短有效的沟通。 Key 2: 两个比萨大小的团队 在《Scrum敏捷软件开发》一书中,作者麦克·科思提出了一个简单的方法用来辨别什么是合适的团队规模,那就是,如果两个比萨够整个团队成员吃的话,那么这个团队的规模比较适合。 因为两个比萨大小的团队跟家庭的规模相似,站立会的目标可以轻松达成。当团队是家庭规模大小时,人们头脑中就很容易追踪到团队中发生的事情。人们可以很容易地记住每个人每天的承诺,以及每个人对于其他成员或团队成果的责任。Scrum中也建议团队规模不要太大,一般为7-9人左右。 最后再强调一点,并不是要求团队一定要按以上18key进行开站会,18key只是在很多实践中总结出来的一些经验,曾经解决过很多问题。对于每个具体团队需要结合实际情况进行选择应用18key。 Key 3: 限制发言 团队外成员也可以参与,但没有发言权。在每日站会中,只有为了实现冲刺目标面全力投入的人应该发言,对于参与者,应该作为旁观者。 Key 4: 预留缓冲时间 建议开发团队在上班时间后的半小时或者1小时后开每日站会。这样可以给例行工作(如查看邮件)提供一些缓冲时间。晚点开会还可以给开发团队一点时间来检查前一天的工作(比如,前一天晚上开始运行的自动化测试工具所生成的缺陷报告)。 Key 5: 同时同地 每日站立会议应尽可能在同一时间、同一地点召开,建议在团队的可视化的任务板前面召开。同一时间和地点也可以有效帮助团队成员形成固有的节奏,不用浪费时间再找地点和确认当天的开会时间。 Key 6: 准时开始 所有的团队成员需自觉按时到场,会议主持人要按照预定的时间按时开始会议,而不管是否有人还没到。对于迟到的人员要有一些惩罚措施,比如缴纳罚金或做俯卧撑等。惩罚措施和数量由团队成员事先共同商定,如果是罚金,如何支配也由团队共同决定。如果团队成员就是不自觉按时到场怎么办?关于更多这方面的解决方案请参考下面的了解更多中的“了解更多:成员迟到的解决方案”。 Key 7: 站立开会 团队成员一定要站着开会,这也是会议的名字叫站立会议的原因。站着开会确实比坐着开会简明扼要,让人更想快一点结束会议,开始一天的工作。坐下容易使人放松,精神不集中,不易控制时间。 Key 8: 强调站会目的 经常强调站会目的,特别适合刚刚启用站会的团队。可以由Scrum Master来强调,如果没有Scrum Master也可以由其它Leader(轮职的主持人也可以)来强调。然后询问团队成员对站会的意见及得到的成果,几次以后,团队成员可能选择目标声明作为每天的度量,在每次站会之后,团队成员对自己的表现做出相应的评价,是一种强有力的自我管理工具。 Key 9: 聚焦三个问题 站会期间,团队成员就说那典型的三个问题(昨天…今天…障碍是…),其它事情不说。只讨论已完工和即将开始的工作,或者在这些工作中碰到的问题和障碍。目的不是向领导汇报工作,而是团队成员之间相互交流,以便共同了解项目情况和共同解决问题。 Key 10: 眼神支持 这是一个好玩的游戏:当一个人站在前面发言时,要求其他团队成员都直视发言人,并进行眼神交流。别让发言人抓到你在看别处。这个游戏帮助发言人的发言简洁,同时可以加强成员对发言人所讲内容的理解。这样可以帮助团队加速完善每日计划。 Key 11:严格时间盒 站会是开发团队的一个时间盒限定为 15 分钟的事件。 时间建议不要太久,对于5-9人的团队来讲15分钟的会议时间足够。 Key 12: 会后讨论 某位团队成员在发言期间,其他人员应认真倾听,如有疑问可简短确认,但不应做过多讨论。如果对某位成员的报告内容感兴趣或需要其他成员的帮助,任何人都可以在每日站立会议结束后即刻召集相关感兴趣的人员进行进一步的讨论。 Key 13: 问题风险跟踪 将站会成员遇到的问题和风险做概要的记录(不必详细,只要说明重点即可,不需要在记录上花费更多的时间),然后保留到知识库,或者方便大家跟踪的地方。此目的是确保这些问题和风险得到了闭环(例如,问题和风险可以会后按排专题讨论、跟踪,直到关闭)。 Key 14: 回顾改善 本身每日站会就是最小化的戴明环(PDCA),另外团队在回顾会议上时也可以对站会开的效果进行回顾,哪些地方做得好,哪些地方做得不好,有哪些改善点可以在下一轮迭代中改善等(站会只是回顾会议中一个回顾点,如果没有问题不用做专题回顾)。 Key 15: 发言棒 站会时可以利用一些小道具来保证会议不会超时。我会找一只笔或者一个娃娃(女生多的团队)作为发言棒仍给一位成员,让他拿着发言棒陈述完“三个问题”,然后将其交给下一位。我会找一只笔或者一个小物件作为发言棒仍给一位成员,让他拿着发言棒陈述完“三个问题”,然后将其交给下一位。没有拿发言棒的成员不允许发言。如果有人用时过长,就及时打断,并要求将发言棒传给下一个人。 Key 16: 冲刺待办列表 站会中,成员在发言时可以利用冲刺待办列表来检视当前工作项的完成状态。冲刺待办列表记录了团队成员工作的进展,需要每天更新并跟踪。电子化的冲刺待办列表更能很好的解决异地团队开站会思路不聚集的问题。发言人在讲那“三个问题”时,同步可以展示冲刺待办列表给团队。 CodeArts冲刺代办列表演示如下: 图7 CodeArts冲刺代办列表 Key17: 任务看板 在站会期间,通过任务板,团队中每一个人都可以知道哪些工作正在进行,哪些工作已经完成。团队关注事情的完成,一直处于进行中的任务为被发现,成为当前的焦点,这样团队就可以尽快把这些焦点问题解决掉。 Key 18: 燃尽图 燃尽图是将进展和剩余工作情况可视化的有力工具。一般竖轴表示剩余工作量(小时、故事点或工作项个数),横轴表示冲刺时间(一般单位为天)。 图8 燃尽图 开站会时,发言人可以利用燃尽图来做进展讲解。燃尽图让所有团队成员一眼就可以看出冲刺的状态,进展情况非常清楚,看出工作是否在按计划进行,状态是否良好。这些信息可以帮助团队确定是否可以完成预定数量的工作项,并在冲刺早期做出明智的决定。使用燃图易达成如下效果: 高可视性,直观展示进度情况和剩余工作。 快速识别风险。 帮助团队建立信息,了解自己的能力。 了解团队成员工作步调。 了解团队冲刺计划。 和任务墙能非常高效地匹配使用。 关于18key,并不是站立会议时要把所有18key都要执行一遍,这里的18key只是提供了一些参考实践和关键点,18key来源于大量的实践,也解决过团队站会的问题,所以大家在站会遇到了问题时,可以先想到这个18key,然后选择适合自己团队的key。举一个例子,这里有四个key是关于工具的,这些工具我们都要使用吗?不一定都要使用。敏捷宣言里提到“个体和互动高于流程和工具”,工具是为团队服务的,不是团队的负担,更不能被工具所绑架。所以团队一起选择适合的,才是正确的做法。
-
背景 企业的一些项目团队每天都开站会,但是效果不理想,好像是形式化的内容,并没有起到什么实质的作用。比如,开完站会后,成员继续做着手头的工作,成员依然只关心自己的工作,其他人员的工作完全不了解,好像站会并没有带来什么效果。再比如,开站会本身也有很多问题:会议超时、成员迟到、成员注意力不集中等,具体常见问题如图1所示。 图1 站会常见问题 如何正确的开站会?站会的意义在哪里?可以不开站会吗?这些问题一直困惑着不少的团队。
-
问题分析 关于站会的问题大致分为两种场景: 场景一:团队非常清楚应该开站会,认识到站会确实有一些价值,但是对于目前的站会状况不是很满意,如何玩转站会是团队关心的。对于这类的团队,问题的根源在于不是非常清楚站会的核心价值,以及不知道怎么样实践,团队更需要一些具体的措施来帮助他们更好的开站立会议。 场景二:团队在试着开站立会议,不知道站立会议有什么价值,好像开和没开没有什么区别。针对这种情况,是因为团队没有尝到站会的价值带来的好处,团队没有概念,同样缺乏最佳实践。 综上,不管是第一种还是第二种情况,都需要对站会的价值进一步理解,也就是为什么要开站会,它的意义是什么?然后,都需要明确正确的站会应该怎么样开?最后,都需要一些最佳实践和关键点来帮助团队开好站会。
-
了解更多:成员迟到的解决方案 对于经常有人迟到的现象,团队成员在回顾会议上可以认真分析原因,重新征求团队成员意见,为什么每日站会的开始时间一定是早晨九点,其它时间是否可以,是否有什么困难,团队成员共同找出问题原因并做出决定。 促进团队成员需要自觉按时到场的意识,尊重别人的意识。会议主持人要按照预先定的时间、地点开始会议,而不管是否还有人没到场。有人迟到不要重新讲解他们错过的开会内容,否则会传达可以迟到的信号。 对于迟到的人员要有一些惩罚措施,比如红包、做俯卧撑、全体下午茶等。惩罚措施和数量由团队成员事先共同商定。如果是红包,如何支配由团队共同决定。相比别人给你的规则,大家更愿意执行自己提出的规则,守自己的承诺。 如果说惩罚措施毫无约束力,那就把惩罚做到可视化。比如在白板中规划出一个特定区域,每迟到一次就把照片贴上去,次数累加。这个特定迟到的区域是迟到信息的扩大器,让更多的人看到。 对于经常迟到的人需要谈话,试着理解他有哪些问题,是否有真正的困难,关心团队成员,大家一起帮助解决困难。 如果迟到现象严重,可能不是团队能解决的问题了,可以试着从公司政策方面施压,严格执行公司的考勤制度,但其实不符合敏捷的自管理思想,不是真正解决问题的方法。 总结下解决迟到现象应该关注以下因素: 分析原因,关心成员,共同决定。 同一时间,同一地点,准时开会。 有人迟到,不重复同步信息。 建议小惩罚机制。 理解迟到原因,是否有困难。
-
总结 以上三种没有人认领任务的情况,是比较常见的。但在真正的实际项目中,每个公司或团队的情况都不尽相同,无法穷举所有,应具体情况具体分析。比如,一个刚刚转型的敏捷团队,在开发任务的领取上可能会更偏向于半指派半领取的方式。这就好比中国经济一样 “以市场经济为导向,适当进行宏观调控”。但不管这个“调控”的力度如何,我们都应该鼓励团队成员能积极主动地领取任务,并随着任务的进展情况灵活调整,及时做好风险把控,必要的时候需要其他渠道的协调帮助或相关领导的介入,以保证迭代的目标不受影响。
-
问题分析 首先,相对于传统开发模式的指派开发任务,我们需要知道为什么在敏捷开发中是领取任务。在敏捷中,不管是敏捷宣言还是Scrum指南,都没有指派(assign)一词,而是使用了一个术语自组织,如下: 最佳的架构、需求和设计出自于自组织的团队(敏捷宣言12项原则)。 自组织团队自己选择以何种方式来完成工作,而不是由团队之外的人来指导(Scrum指南)。 开发团队是自组织的。没有人(即使是Scrum Master)有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量(Scrum指南)。 那么“自组织”是什么呢? 从字面的意思来理解,自组织就是:安排分散的人或事物使其具有一定系统性或组成一个整体,而安排的人就是安排者自己。在敏捷开发中,自组织团队就是具备自我管理、自我驱动、自我学习等能力的敏捷开发团队本身,这样的团队一般具备如下特点: 团队成员自己“拉”工作,不是被动等待领导分配工作。 团队作为一个整体管理工作。 团队仍然需要辅导和指导,但不需要指挥和控制。 团队成员彼此沟通紧密,互通有无。 团队主动发现和提出问题并共同解决。 团队不断提高自己的技能,鼓励探索和创新。 更多关于自组织的相关内容不在本文的范围内,如感兴趣请参阅参考文档。 从敏捷宣言和Scrum指南关于任务的工作方式上来看,在我们践行敏捷的时候,主要发挥的是开发团队自身的主观能动性,开发团队由原来的控制性转变成了自组织性,而开发任务也就由原来的指派变为了领取。这样的好处是,领取任务就是发挥了人的主动性,而自主性是人们从事创造性和解决问题的动力之一,良好的自我组织能给团队和个人带来高绩效、出色的工作成果以及喜欢的工作环境。另外,每个人都是最了解自己的,也擅长为自己分配任务,相对于传统的指派开发任务所带来的易主观臆断、分配不当等更具有合理性。 然后,回到“计划会议认领任务的时候,有几个任务没人认领怎么办?”这个问题上。 在此之前需要先澄清的一个观点:在计划会议中,不一定非要全部领取完开发任务。在Scrum指南中指出“领取工作在Sprint计划会议和Sprint期间按需进行。”可以理解为,在每日Scrum站会上基于目标领取任务。另外,Mike Cohn也表示过,不建议在计划会议中领取开发任务,这样可能会导致目标由团队变为了个人,进而违背了敏捷的本意,降低了灵活性。 一般来说,开发任务没人认领的原因主要有: 开发任务的难度大:当开发任务比较难以解决,超出了团队大部分成员的能力时,团队成员可能会存在担心加班加点而不愿意认领。 开发任务超范围:当开发任务的内容超出团队成员所掌握的范围时,如开发不会测试,就可能会出现“我是想认领的,但能力有限”的情况。 担心受到他人指责:工作内容存在一定的挑战性,担心由于自己没有做好,导致团队目标没有达成而受到指责。 那么应该如何解决呢?
-
解决方案 在一个敏捷Scrum团队中,Scrum Master扮演着重要的角色,该角色一部分的作用就是要帮助团队成为自组织型团队,以便让团队能以积极的心态去面对冲刺的开发任务。此外,当出现任务没有人愿意认领的情况时,首先Scrum Master应该帮助团队弄清楚没有人认领的原因是什么再对症下药,下面基于分析中的三种情况分别给出解决措施。 开发任务难度大 对于开发任务难度大的情况,Scrum Master应该组织团队进行有效的任务分解,使用探针Spike技术,探索出解决措施以降低任务的难度,再由团队去认领;或者鼓励技术能力较一般的成员和技术大牛通过结对编程的方式来一同认领任务。 在华为云CodeArts中,可以对该类难度大的用户故事通过子工作项的方式进行拆分,同时在基本信息中通过设置处理人和抄送人的方式以记录结对编程的人员配对情况: 图1 Story内容介绍 除此以外,在每日Scrum站会的时候要留意和了解该开发任务的情况,进行风险评估,如有问题及时帮助协调解决。在回顾会议中,应对该类情况进行分析并能输出基于团队的一套标准工作方式方法,然后将解决方案记录在团队知识库中,华为云CodeArts提供了知识库的功能,可以为团队很好的整理和记录工作方式,如图2所示。 图2 任务认领说明 开发任务超范围 敏捷提倡的团队是跨职能团队,但是团队的跨职能并不意味着一个人能做所有的事情,我们希望的跨职能团队往往是由掌握多项技能的T型人才(每个成员在一个专业领域具有深度,而在其他领域具有广度)所组成的。首先需要Scrum Master能够和团队整理和维护成员技术矩阵,把个人技能掌握情况对团队公开(知道团队欠缺什么、知道可以和谁学等),然后定期组织技术分享等活动以帮助团队成员学习(主要以学习一项新的技术后的分享方式),这样可以在一定程度上提升成员在冲刺中愿意领取其他任务的热情。另外,还可以由专长成员和意愿成员组队,采用结对编程的方式领取任务,以实现个人技术的扩充。团队成员的T型能力建设,不仅仅能让团队领取任务的时候有更多的选择,也提供了成员的backup能力,减少无人认领的情况发生。此外,同样也需要Scrum Master留意日常评估风险和引导团队回顾该事项并维护团队知识库。 担心受到他人指责 工作内容存在一定的挑战性,担心由于自己没有做好,导致团队目标没有达成而受到指责。Scrum Master应该对团队贯彻以团队为整体的思想,并指导和强调Scrum的价值观,尊重团队的每一个成员的背景、经验,也包括开发任务的选择,还要鼓励成员能有勇气去选择和尝试。在实际的工作中,我们可以通过在墙上、白板等贴上标语(如“尊重他人”、“只有团队没有个人”等)的方式,让团队从思想意识方面发生转变,慢慢敢于去领取有挑战性的任务。此外,Scrum Master要充分保护好成员对有挑战工作认领的热情。如防止在回顾会议上出现指责和批斗的情况,回顾和总结永远应该聚焦的是做事的方式方法而不是对人的苛刻和指责。
-
了解更多:迭代待办列表 迭代待办列表在CodeArts中称“迭代”,它是一组为当前迭代选出的产品待办列表项,同时加上交付产品增量和实现迭代目标的计划。 当新工作出现时,开发团队需要将其加入到迭代待办列表中去。随着工作的执行或完成,剩余的工作量被估算并更新。当计划中的某个部分失去开发意义,就可以将其移除。在迭代期间,只有开发团队可以改变迭代待办列表。迭代待办列表是高度可见的,是对开发团队计划在当前迭代内工作完成情况的实时反映,该列表由开发团队全权负责。 迭代待办列表在迭代计划会议中形成,其中开发团队不会被动分配任务而是由开发团队成员主动认领自己擅长和喜爱的任务。任务被分解为以小时为单位,建议任务不要超过16个小时。如果一个任务超过16个小时,那么它就应该被进一步分解。每项任务信息包括其负责人、工作量、承诺的完成时间及其在迭代中任意一天的剩余工作量,且仅开发团队有权改变其内容。
-
问题分析 目前Sprint中存在的主要问题是Sprint目标完成不好,解决障碍,Sprint目标按承诺完成即可。 团队成员的工作内容中包含很多探索性工作项,对工作内容领域不熟悉,需要投入一些学习成本,导致工作项的实际完成用时要比正常多。每个用户故事的工作量也比较大,多数超过24小时。PO对工作项完成标准的要求非常高,评审严格,不合格的工作项在Sprint中经常返工。团队当前的Sprint时长为一周,并且四大事件按照Scrum框架执行,其中Sprint计划会议和Sprint回顾会议平均持续时长为2小时左右。 从分析中归纳影响Sprint目标完成的几个主要因素如表1所示。
-
解决措施 针对以上问题的分析,建议这种情景下将Sprint的时间盒由一周改为两周。Sprint的时间过短,团队成员会忙于准备计划会议、评审会议及回顾会议,真正完成工作项的时间较少。对于突发事件的应对能力减弱,不利于形成团队稳定的节奏。Sprint的时间过长,失去了短时间盒的优势,失去了时间盒的意义。因此,如果团队在时间盒为一周的Sprint中经常不能完成Sprint目标,可以试着把时间盒调为两周。同时要注意优化用户故事的大小,提高四大事件的效率。 Sprint的时间盒由一周改为两周后影响因素会有所改善,具体如表2所示。 表2 影响Sprint目标因素表(二) 序号 影响因素 Sprint由一周改为两周后的相应缓解 1 探索性工作项多 有相对充分的缓冲时间应对学习、探求性工作以及突发情况。 2 工作领域不熟悉,需要学习成本 3 用户故事比较大 时间相对宽裕后,计划会议开得更充分,用户故事拆分为更小的故事,或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。 4 PO完成标准高 时间相对宽裕后,理解PO完成标准更加充分,在计划会议上明确验收标准,包括AC(Acceptance Criteria) 和 DoD (Definition of Done)。 5 Sprint周期短 调整周期后,团队成员氛围更加好,每个Spring目标完成度得以改善,成员更加自信。 6 Sprint计划会议和Sprint回顾会议持续时间略长 时间相对宽裕后,每项会议质量有所提高,在合理的时间范围内可以高质量完成会议内容。 其情况Sprint的时间盒长度建议如下,您可根据团队现况选择适合的时间盒。
-
了解更多:时间盒 在Scrum框架中,工作在建议时间长度为一个月或者更短的迭代或循环中进行,这个迭代或者循环叫做冲刺。冲刺在一个时间盒(Time Box)内,也就是冲刺有固定的开始和结束时间。 时间盒的优点具体内容如下: 时间盒是设定WIP(work in process)数量限制的技术。WIP是已经开始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工作事项,因此时间盒是为每个冲刺设定WIP数量限制。 时间盒可以强制排列优先级。我们需要先执行高优先级的工作,时间盒可以强制我们按优先级排序执行小批量工作,这样我们的注意力可以更集中于快速完成高价值的工作。 时间盒可以展示进度。时间盒可以展示团队需要多少个时间盒才能完成大特性的进度,帮助团队准确知道为交付整个特性还需要做多少工作。 时间盒可以限定结束日期。每个冲刺中,时间盒限定了一个固定的结束日期,通过这种方式强制结束可能无休止的工作。 时间盒可以促进结束。冲刺有明确的最后期限,这个期限不允许修改,这可以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有时间盒的限制,Scrum团队成员就不会有完成工作的紧迫感存在。 时间盒可以增强预测性。团队可以不预测后续长时间段内可以完成的工作,但是预测下个冲刺内能够完成的工作是可以做到的。
-
什么是Epic、Feature、Story和Task? Epic、Feature、Story和Task用来划分需求颗粒度的标签,可以看作需求占位符,分别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义,在进行需求划分的时候可以进行参考。 Epic:史诗,是项目的愿景目标。通过Epic的落地达成,使公司可以获得相应的市场地位和回报,具有战略价值。通常需要数月完成。 Feature:可以带来价值的产品功能和特性。相比Epic,Feature更具体,更形象,客户可以感知,具有业务价值。通常需要数周,多个Sprint才能够完成。 Story:通常所说的用户故事,是User Story的简称。Story是从用户角度对产品功能的详细描述,承接Feature,并放入产品Backlog中,持续规划,滚动调整,始终让高优先级Story交付给客户,具有用户价值。Story要符合INVEST原则(Idependent、Negotiable、Valuable、Estimable、Small、Testable),通常需要数天,并在一个Sprint中完成。 Task:是团队成员要完成的具体任务。在Sprint计划会议上,将Story分配给成员,然后由成员分解为Task,并预估工时,通常在一天内完成。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格