• [技术干货] 【DevCloud · 敏捷智库】如何玩转每日站会?(内附下载材料)
    作者 黄隽 Charlie背景企业的一些项目团队每天都开站会,像Scrum里面建议的一样说那三个问题,但是效果不理想,好像是形式化的内容,并没有起到什么实质的作用。比如,开完站会后,成员继续做着手头的工作,成员依然只关心自己的工作,其它人员的工作完全不了解,好像站会并没有带来什么效果。再比如,开站会本身也有很多问题:会议超时、成员迟到、成员注意力不集中等,具体常见问题如下图所示。 到底如何正确的开站会?站会的意义在哪里?可以不开站会吗?这些问题一直困惑着不少的团队。问题分析关于站会的问题大致分为两类情况:第一种,团队非常清楚应该开站会,认识到站会确实有一些价值,但是对于目前的站会状况不是很满意,如何玩转站会是团队关心的。对于这类的团队,问题的根源为不是非常清楚站会的核心价值,以及不知道怎么样实践,团队更需要一些具体的措施来帮助他们更好的开站立会议。第二种,团队在试着开站立会议,不知道站立会议有什么价值,好像开和没开没有什么区别。针对这种情况,是因为团队没有尝到站会的价值带来的甜头,团队没有概念,同样缺乏最佳实践。综上,不管是第一种还是第二种情况,都需要对站会的价值进一步理解,也就是为什么要开站会,它的意义是什么?然后,都需要明确正确的站会应该怎么样开?最后,都需要一些最佳实践和关键点来帮助团队开好站会。解决措施为了增加一些趣味性,我们先来看两个视频,思考和感受一下“正确”与正确的站会可以开成什么样。视频一:教您开“正确”站会。视频二:教您开正确站会。如何玩转站会?我们按照如下思路学习一下。 理解站会价值团队每天站着召开的短时间会议称之为每日站会。每日站会是团队对每天工作检视和调整,提前进行自组织。通过站会团队每个人可以了解全局,知道发生了什么事情,实现冲刺目标的进展如何,对当天的工作是否需要修改计划,有什么问题或者障碍需要处理。每日站会是一个检视、同步、适应性制定每日计划的活动,以帮助自组织团队更好地完成工作。有些团队认为每日站会是解决问题的,是传统意义上向项目经理汇报状态的会议,其实都是不准确的,或者说误解了它的核心意义和价值。每日站会对于让团队成员每天集中精力在正确的任务上是十分有效的。因为团队成员在同伴面前当众作出承诺,所以一般不会推脱责任。给团队成员一种精神激励,要对每日的工作目标信守承诺。每日站会还可以保证Scrum Master和团队成员可以快速处理障碍,培养团队文化,让每个人意识到我们是“整个团队在一同战斗”,一些没有使用敏捷的组织有时候也同样做采用每日站会。归纳一下站会的价值和意义,以及误解: 明确正确站会正确的站会应该怎么开呢?我们一起学习下。对于每天的工作,为了提前进行自组织,团队成员准时围绕着白板前站立(增加仪式感)。 团队成员在站会上需要轮流发言,回答如下三个问题:    我昨天做了什么?(从上次站会到现在,我做了什么?)    今天计划做什么?(在下次站会之前,我会做什么?)    我遇到了哪些问题和障碍?(哪些问题和障碍阻止了我的工作或使我的工作放缓?)这简单的三个问题可以促使团队成员每天都要检视自己的工作、制定自己的工作计划、获得清除障碍的帮助以及对团队做出承诺。如果团队按正确的方式开站会,进行得好的话,可以达到如下效果:共济压力健康的敏捷团队都会共济压力。所有的团队成员都要承诺要一起完成冲刺的工作。这就使得团队成员之前相互依赖并且对彼此负责。如果一个团队成员连续几天都做相同的事情,并且没有进展,显然缺乏前进的动力,而其它团队成员不能视而不见。因为他未完成的工作会变成其他成员的障碍。细粒度的协作在站立会中,团队成员的交流应该快速而且有重点。举例,当一个成员说完今天计划做什么后,另外一个成员可以会说:“哦,原来你今天计划做这个啊,这就意味着我要调整我的工作优先级,没关系,你按照你的计划做吧,我可以调整。很高兴你说了这些。”这种细粒度的协作使得团队成员知道他们之间如何及何时仰仗对方。一个敏捷团队应该追求高效、零等待,避免等待浪费。聚集少数任务在站会期间,团队中的每位成员都可以知道哪些工作正在进行,哪些工作已经完成。健康的团队应该关注事情的完成,也就是说任务不能一直处在进行中。在站会中,团队需要确认哪几个少数任务是当前的焦点,这样团队就可以尽快把焦点任务做完。换句话说,做完10件事,远比正在做100件事儿更有意义。每日承诺在站会上,团队成员需要对团队做出承诺。这样团队成员就知道敏捷交付什么成果并如何保持彼此负责。提出障碍其实在敏捷中任何时间都可以提出障碍,但是站会是一个黄金时刻,团队成员可以停下来认真思考“有什么事情阻碍了我或让我的工作放缓了”最佳实践和关键点前面理解和明确了站会的价值和站会怎么开,以及开得好会获得什么样的效果,但是没有讲怎么可以把站会开好,实践的关键点是什么并没有讲。别急,接下来一起来总结下站会开好的关键点。通过大量实践总结出一些能够帮助开好站会的关键点,也许这些关键点并不是全适用,所以还是要根据现实情况做出合适自己团队的选择和裁剪。这些关键点,我称之为“站会18 key”。站会18key按照人(People)、过程与方法(Procedures and methods)、工具与设备(Tools and equipment)划分,帮助大家记忆和学习。 Key 1: 主持人会议主持人(比如Scrum Master,也可以团队成员轮班,轮流感受下站会的节奏)确保会议的举行,并控制会议时间,团队成员进行简短有效的沟通。Key 2: 两个比萨大小的团队在《Scrum敏捷软件开发》一书中,作者麦克.科思提出了一个简单的方法用来辨别什么是合适的团队规模,那就是,如果两个比萨够整个团队成员吃的话,那么这个团队的规模比较适合。因为两个比萨大小的团队跟家庭的规模相似,站立会的目标可以轻松达成。当团队是家庭规模大小时,人们头脑中就很容易追踪到团队中发生的事情。人们可以很容易地记住每个人每天的承诺,以及每个人对于其他成员或团队成果的责任。Scrum中也建议团队规模不要太大,一般为7-9人左右。最后再强调一点,并不是要求团队一定要按以上15key进行开站会,15key只是在很多实践中总结出来的一些经验,曾经解决过很多问题。对于每个具体团队需要结合实际情况进行选择应用15key,没有绝对的对与错,只有适合和不适合。Key 3: 限制发言团队外成员也可以参与,但没有发言权。Scrum中曾经使用过术语“猪”和“鸡”来区别在每日站会中哪些人应该参与发言,哪些人就站在旁边看就行了,不过这两个术语现在已经不用了。这两个农场动物术语来自一个老笑话:“在早餐吃的火腿鸡蛋中,鸡是参与者,猪是全部投入了。”显然,Scrum使用这些术语是为了区分参与者(鸡)和为了实现冲刺目标面全力投入的人(猪)。在每日站会中,只有猪应该发言,如果有鸡参加例会的话,应该作为旁观者。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: 问题风险跟踪将站会成员遇到的问题和风险做概要的记录(不必详细,只要说明重点即可,不需要在记录上花费更多的时间),然后保留到wiki,或者方便大家跟踪的地方。此目的是确保这些问题和风险得到了闭环(例如,问题和风险可以会后按排专题讨论、跟踪,直到关闭)。Key 14: 回顾改善本身每日站会就是最小化的戴明环(PDCA),另外团队在回顾会议上时也可以对站会开的效果进行回顾,哪些地方做得好,哪些地方做得不好,有哪些改善点可以在下一轮迭代中改善等。(站会只是回顾会议中一个回顾点,如果没有问题不用做专题回顾)Key 15: 发言棒站会时可以利用一些小道具来保证会议不会超时。我会找一只笔或者一个娃娃(女生多的团队)作为发言棒仍给一位成员,让他拿着发言棒陈述完“三个问题”,然后将其交给下一位。没有拿发言棒的成员不允许发言。如果有人用时过长,我会把发言棒换成一个水桶(当然是盛满水的)让他托起,直到托不动为止。如果他想说就让他说,要么会议很快结束,要么我们的开发人员练成强大的臂力,按我经验,一般都会挑重点说,会议按时结束。Key 16: 冲刺待办列表站会中,成员在发言时可以利用冲刺待办列表来检视当前工作项的完成状态。冲刺待办列表记录了团队成员工作的进展,需要每天更新并跟踪。电子化的冲刺待办列表更能很好的解决异地团队开站会思路不聚集的问题。发言人在讲那“三个问题”时,同步可以展示冲刺待办列表给团队。DevCloud冲刺代办列表演示如下。 Key17: 任务看板在站会期间,通过任务板,团队中每一个人都可以知道哪些工作正在进行,哪些工作已经完成。团队关注事情的完成,一直处于进行中的任务为被发现,成为当前的焦点,这样团队就可以尽快把这些焦点问题解决掉。Key 18: 燃尽图燃尽图是将进展和剩余工作情况可视化的有力工具。一般竖轴表示剩余工作量(小时、故事点或工作项个数),横轴表示冲刺时间(一般单位为天)。 开站会时,发言人可以利用燃尽图来做进展讲解。燃尽图让所有团队成员一眼就可以看出冲刺的状态,进展情况非常清楚,看出工作是否在按计划进行,状态是否良好。这些信息可以帮助团队确定是否可以完成预定数量的工作项,并在冲刺早期做出明知的决定。使用燃图易达成如下效果:    高可视性,直观展示进度情况和剩余工作;    快速识别风险;    帮助团队建立信心,了解自己的能力;    了解团队成员工作步调;    了解团队冲刺计划;    和任务墙能非常高效地匹配使用。关于18key,这里想强调一下,并不是站立会议时要把所有18key都要执行一遍,这里的18key只是提供了一些参考实践和关键点,18key来源于大量的实践,也解决过团队站会的问题,所以大家在站会遇到了问题时,可以先想到这个18key,然后选择适合自己团队的key。没有绝对的对与错,只有适合和不适合。举一个例子,这里有四个key是关于工具的,这些工具我们都要使用吗?当然不一定。敏捷宣言里提到“个体和互动高于流程和工具”,工具是为团队服务的,不是团队的负担,更不能被工具所绑架。所以团队一起选择适合的,才是正确的做法。了解更多成员迟到的解决方案对于经常有人迟到的现象,团队成员在回顾会议上可以认真分析原因,重新征求团队成员意见,为什么每日站会的开始时间一定是早晨九点,其它时间是否可以,是否有什么困难,团队成员共同找出问题原因并做出决定。促进团队成员需要自觉按时到场的意识,尊重别人的意识。会议主持人要按照预先定的时间、地点开始会议,而不管是否还有人没到场。有人迟到不要重复信息,否则会传达“可以迟到”的信号。对于迟到的人员要有一些惩罚措施,比如红包、做俯卧撑、全体下午茶等。惩罚措施和数量由团队成员事先共同商定。如果是红包,如何支配由团队共同决定。不要PM或SM自己决定让团队执行。相比别人给你的规则,大家更愿意执行自己提出的规则,守自己的承诺。如果说发红包和下午茶这样的惩罚对于那些土豪无约束,那就把惩罚做到可视化。比如在白板中规划出一个特定区域,每迟到一次就把照片贴上去,次数累加。这个特定迟到的区域是迟到信息的扩大器,让更多的人看到。俗话说,人要脸树要皮,相信会有所收敛(此方法要考虑多一些,避免意外)。对于经常迟到的人需要谈话,试着理解他有哪些问题,是否有真正的困难,关心团队成员,大家一起帮助解决困难。如果迟到现象严重,可能不是团队能解决的问题了,可以试着从公司政策方面施压,严格执行公司的考勤制度,但其实不符合敏捷的自管理相思,不是真正解决问题的方法。总结一下解决迟到现象应该关注以下因素:    分析原因,关心成员,共同决定    同一时间,同一地点,准时开会    有人迟到,不重复同步信息    建议小惩罚机制    理解迟到原因,是否有困难参考附录1、Kenneth S. Rubin. Scrum精髓[M].北京:清华大学出版社。2、Lyssa Adkins. 如何构建敏捷项目管理团队[M].北京:电子工业出版社。3、Mark C. Layton. 敏捷项目管理[M].北京:人民邮电出版社。华为云DevCloud作为一站式云端DevOps平台,集成华为近30年研发实践和前沿理念,面向开发者提供研发工具服务,让软件开发简单高效。现支持5人以下额度范围内,可以免费使用,并且可以预约免费的产品演示和技术交流,详情查看华为云官网。点击下载 附件:如何玩转每日站会V0.5.pdf
  • [技术干货] 敏捷开发DevOps流-华为云MVP汪珺
       KANBAN被人擦掉了怎么办,Scrum之前几个版本的迭代丢失了怎么办,XP把人培养出来人跳槽了怎么办,针对这些问题看敏捷开发汪珺老师是如何去解决的?                    全部
  • [技术干货] 敏捷开发Scrum流-华为云MVP许舟平
    MVP敏捷开发许舟平代表Scrum流进行“反击”,Scrum跟极限编程不一样,更关注的是如何利用好节奏去做编程,即制定周期性的迭代冲刺计划具体就让我们来看看许舟平老师是如何进行答复的吧
  • [技术干货] 敏捷开发XP流-华为云MVP徐磊
    长久以来,敏捷开发领域有多种不同的流派并存,华为云MVP徐磊走的就是XP流,他指出XP是敏捷的前身,创造了很多提高开发效率的实践想了解更多吗?
  • [分享交流] 精准测试与开源工具Jacoco的覆盖率能力大PK
    导读:本文根据实际使用情况,简要分析了精准测试和类Jacoco等传统白盒工具在设计理念、功能和应用场景的异同点,并阐述了覆盖率技术如何在新型企业开发体系中,发挥应有的重要作用。 覆盖率技术可以说是测试理论中最基本的技术体系,但由于传统覆盖率并没有很好的适应新型软件开发模型,导致应用场景越来越窄。比如:Jacoco等同类工具,仍停留在传统白盒覆盖技术的技术演化层面,目前基本仅适用在瀑布模式的开发体系下。最新的测试黑马技术—“精准测试”覆盖率功能是企业级、面向敏捷迭代场景、全新的覆盖率技术。它明确提出了用例层级覆盖率的概念,并将用例层级覆盖率技术广泛应用于智能的测试分析算法。 精准测试的专利技术之一:测试用例与代码的双向追溯,可以简单理解为:所有分析和计算依赖于测试用例维度的覆盖信息。它创新性的将覆盖率统计维度从全局维度显示,降维到了测试用例这一细节,使覆盖率的放大作用远超出原有能力。它如同放大镜一样,使测试分析、测试算法以及测试数据真正做到一览无余,不错过任何重要细节。 Jacoco是传统的白盒覆盖率工具,不具备将覆盖率与用例关联的功能,很遗憾的不具备精准测试的所有高级特性。下面仅就“覆盖率”这一功能,将精准测试与Jacoco为代表的传统白盒覆盖工具进行一个简单比对:1 覆盖率分析能力PKJacoco:作为传统白盒功能的代表,它的应用模式是部署在后台,采集所有执行代码的覆盖率,所有用户请求和功能的覆盖数据为混合统计,范围仅围绕在看覆盖率上。但这种覆盖信息的弊端是:它从全系统维度来统计,导致颗粒度太大,无法详细定位和深度分析覆盖率的真正问题。 精准测试:可以像调焦距一样,在并发访问的后台服务中,将某个测试用例的执行路径分离出来,进行各种细致分析。它用例级的双向追溯的覆盖信息,带有执行时序,可以很快定位缺陷发生时刻代码的执行路径(类似于重现单步调试场景),与此同时,还可以对测试人员的用例执行情况,进行非常精确的代码级跟踪。2 对于敏捷测试的响应能力PKJacoco:不适应于敏捷迭代过程对于覆盖率的企业级需求。当代码发生变更后,Jacoco将重新采集覆盖率,各个发布版本采集的结果孤立存在。现代企业通常每天会发布多个版本,孤岛式无对比分析的覆盖率结果,价值不大。因为每组测试执行通常是在每个版本上跑一部分用例,而不是瀑布模型下在一个版本上进行所有用例的测试。 精准测试:在覆盖率计算和应用上有累积覆盖率、增量覆盖率、相关覆盖率、高风险覆盖分析、可变分母覆盖等诸多创新办法,随时响应敏捷迭代需求。1)累积覆盖率:精准测试可以将多个测试覆盖进行累计和投影,这样就无所谓中间发布多少个版本、每个版本上跑多少个用例,可以自由选择看一个阶段的总体覆盖率。 2)增量覆盖率:由于企业软件体量庞大,因此无论如何测试都很难满足100%覆盖率的要求。所以通常企业更关注的是增量覆盖率,即新发布版本相比上一个测试版本修改后的代码覆盖情况。精准测试由于每个版本发布的时候都有详细的代码静态分析数据支持,因此它可以智能标识版本差异,并将版本差异的代码覆盖进行高亮显示,帮助企业关注新增/调整代码部分的覆盖率。 3)相关覆盖率:精准测试创新性提出了相关覆盖率技术,即把一个功能模块相关的代码作为计算的分母计算覆盖率。这样非常有利于在敏捷迭代场景下,只测试部分功能的覆盖率分析。相关覆盖率可用于支持功能模块(用例分类)级别的覆盖率,从业务角度统计某一个功能模块相关代码范围的覆盖率,明确指出某一个功能范围的测试覆盖充分度,而不是传统的全局代码覆盖率。 4)高风险覆盖分析:精准测试支持基于静态数据和动态数据高风险的模块检出,引导用户把精力投入到最高风险的模块覆盖逻辑补充上。 5)可变分母覆盖:精准测试支持多种系列的企业级覆盖计算要求,例如通过界面设置,将某些确定不需要或者无法覆盖的代码(例如暂时保留的无效代码)从覆盖率计算结果中排出,整体重新进行覆盖率的计算。支持某一个代码路径下(某一程度模块)范围内的代码覆盖等高级特性。3 覆盖率可视化能力 PKJacoco:基于字节码插装,没有全面的程序静态分析过程,因此无法将覆盖率通过静态分析得到的可视化图形结合清晰展示覆盖率信息。另外,Jacoco必须提供源码才能看懂覆盖率。 精准测试:具有多种函数调用图,控制流程图上展示覆盖率信息,可以在没有源码的情况下,基于精准分析结果,结合动态覆盖率视图,清晰展示程序的覆盖和执行路径信息。4 覆盖率统计能力 PKJacoco:以行覆盖和分支覆盖为主。Jacoco是传统行覆盖,基本上每行都需要进行插装。在结合代码展示覆盖的视图方面,无法取得程序的深入静态信息,因此一般只能再代码视图上以颜色表达是否覆盖。 精准测试:支持覆盖率计算可视化、多覆盖率算法标准及深度的数据分析。1)支持覆盖率计算可视化,覆盖率是如何计算的都表达的非常清晰(贡献覆盖率的分子分母对应的程序元素、数量),方便用户去深入理解覆盖率的含义和信息。 2)精准测试支持更加深度的条件以及条件组合级别以及航天级MC/DC的覆盖率标准。精准测试提供的语句覆盖是基本块覆盖,一个顺序的代码段因为有静态分析结果的支撑,只需要一个插装点。 3)精准测试对程序的静态结构有深度的分析数据,因此它的代码展示视图很清晰,程序结构都可以绘制出来,代码覆盖率视图看起来非常清晰。例如中间没有跳转的基本块会在展示效果上绘制为一个整体,并有是否覆盖标识,而不是每行都要进行标识。5 高度产品化特性 PKJacoco:属于开源范畴,采用字节码插装(指令层级),插装后的代码不可见不可维护,出现问题后很难排查原因,很难定位和修复,商用使用风险较高。每次获取一次覆盖数据都需要访问一个网页地址显示的重新生成。 Jacoco的应用模式是部署在后台采集,无前端显示。出现异常时,测试人员无法知晓自己执行的测试用例是否有效。精准测试:由星云测试(www.teststars.cc) 主导研发,自主可控。在产品化特性有不可比拟的优越性:1)基于源码插装,插装代码可见且开放,非常利于企业应用排查问题和进行流程整合等。万一出现特殊语法问题引起插装问题,用户可以随时查看并自行处理,不会因为极个别情况影响产品应用。 2)覆盖率信息是实时汇总的,通过客户端可以由多个有查看权限的用户(包括开发、测试以及管理人员)实时查阅。 3)软件示波器可实时传输测试过程中的数据,对于传输过程中测试执行覆盖率采集是否有效,可进行可视化的故障排查。
  • [技术干货] 【DevCloud · 敏捷智库】软件项目需求变更频繁,如何做好有效的需求管理和规划?
    概述围绕项目需求变更频繁,如何做好有效的需求管理和规划,本文从背景、问题分析、解决措施、如何进行需求结构化管理?如何进行需求优先级管理?如何避免重要需求遗漏?几个方面进行了细致解答。全文字数:__2662 字__,预估阅读时间:___7 分钟__。全程干货。背景不管是项目型软件开发还是产品型软件开发,需求变更频繁都是影响研发效能的第一号因素,在2019年中国DevOps现状调查报告中也可以发现,超半数企业认为需求的频繁变更是阻碍软件按时交付的主要原因。解决或缓解需求变更频繁带来的影响,是势在必行的重要工作。联想阅读2019年中国DevOps行业现状报告:中国信息通信研究院、华为云DevCloud、南京大学联合发布    问题分析由于每家企业的情况不同,包括客户合作方式、人员能力水平、研发流程等各方面的差异,同样是需求变更频繁,所体现出来的具体症状却有所不同,导致问题发生的根因也可能不同,所应采取的措施也需要根据实际情况来选择。根据我们的观察以及与企业交流的经验发现,一般都体现为如下几种情况,接下来我们结合这些情况的部分实例来分析:第一种情况:需求杂乱、经常变更,难以管理;第二种情况:领导或客户时不时地要把某些需求提前,打乱了开发计划;第三种情况:做着做着发现有些需求遗漏了;【第一种情况】软件项目前期结构清楚,开发到后期,需求变化多而细,如何管理,如何规划。困扰我们的是前期需求不明确、不完善,导致后期需改动,需求需要发生变更。而使用DevCloud的项目管理的支持不够。我们发现出现这种情况,往往跟客户未能正确使用需求规划有一定关系,存在着需求层次划分不清晰、缺少规范机制等问题。例如,某客户规划一个用户登录功能,按照下图所示规划需求。用户会将其中管理员登录的Task放在第一个版本中发布,后期又增加了一个手机号登录的需求,设置成Task放在第二个版本中发布,这样一个Story里面存在多个不同版本(或迭代)发布的Task,不方便管理。由此我们可以将这个问题的根因定性为如何进行需求结构化管理的问题:没有区分跟随项目进展而持续产生的碎片化需求和系统/产品持续完善的功能特性;对DevCloud提供的Epic-Feature-Story的需求结构理解有误,未能正确使用;【第二种情况】软件项目进行过程中,领导需要提拉需求,在敏捷研发模式中该如何去操作?提拉需求的意思也就是要将某些需求的优先级提高,要求团队先实现它们,因而我们将此问题定性为需求优先级管理的问题。解决此问题,我们需要了解:为什么领导会要提拉需求?如果是合理的,那么我们就应该提升响应能力、优化工作安排流程,使得优先级调整对研发进展带来的影响最小化,且我们能够尽快地响应领导需要,先交付被提拉的需求;这种情况发生频率有多高?如果是经常发生,那就是一种常态,而且是一种不好的常态,那我们需要去思考是什么导致了这种常态发生,并考虑如何从流程、制度、协作模式或人员能力等方面去做调整,减少过程中提拉需求情况的发生;如果是偶尔发生,那就可以特事特办,为例外情况调整流程、制度反而会加重常态工作的负担,没有必要;需要提拉的需求有无共性特点?比如是否都跟某个客户有关,或者跟某个功能域(如退款)有关?如果能够找到共性,那我们就可以针对这些共性去思考针对性的解决方案。【第三种情况】由于外界原因经常会临时增加一些紧急需求,并且这是目前常态临时增加需求,首先是一个如何处理突发需求的问题;紧急需求,也就是说需要马上就做,而且是插队,那就不仅仅是紧急,肯定也是重要的需求,不然不需要插队先做,所以这还涉及到需求优先级管理的问题。但是当两种情况合在一起,我们需要将它定性为是重要需求遗漏的问题,反问一句就是 —— 为什么这些紧急重要的需求无法更早预见?同样的,我们需要了解:具体是哪些外界原因?这些原因是否有共性,有的话,那就针对性处理;增加的需求有无共性特点?有的话,可以针对性处理;临时增加有多临时?我们是否有提高或改善响应能力的空间,如果我们可以更快调整和响应,使得这些临时需求对我们产生不了什么影响,那么这个问题也就不再是问题了;既然是常态,为何我们的流程没有做出调整去应对?是调整过流程或工作方式,还是无法解决问题,还是说不知道该怎么调整流程或工作方式去适应?解决措施综上,前面几种参考情况经分析后得出了根因,基于这些根因,我们将所要解决的问题重新描述如下:如何进行需求结构化管理?如何进行需求优先级管理?如何避免重要需求遗漏?如何进行需求结构化管理?首先,并不是说任何情况下都需要进行需求的结构化管理。只有在需求较多、且需求之间存在关联,而且即便是已经实现的需求也需要进行一定的管理、维护的情况下,我们才需要去思考需求结构化管理的问题,此时,我们需要使用DevCloud提供的Scrum项目模板,因为里面有Epic-Feature-Story的需求结构,以及需求规划功能可以辅助我们进行需求的结构化管理。那么我们应该以什么为脉络来建立这个结构呢?这就意味着,我们的需求结构化管理,需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息,则可以通过需求的不同属性甚至标签等方式来实现。简单来说,可以通过如下三个步骤来完成:针对产品或系统建立DevCloud项目确立Epic-Feature-Story的需求结构对不同模块以及版本的管理,可以通过工作项的属性来进行管理联想阅读 【华为云 · 敏捷智库】如何进行需求结构化管理?如何进行需求优先级管理?需求优先级的管理,其实是为了帮助我们确定先做哪个需求后做哪个需求,从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理,或者更直接来说是优先级顺序管理,我们需要做到如下几件事情:确定优先级模型:需要考虑的因素以及因素的综合判断原则,比如Kano模型;排定需求优先级顺序:因素的具体量化和排序标准,例如成本收益法是按照收入还是按利润的多少来排序;调整需求优先级顺序;改进优先级模型:根据反馈调整模型或模型的落地实施细节,以提升效果;联想阅读【华为云 · 敏捷智库】如何进行需求优先级管理?    如何避免重要需求遗漏?根据重要需求遗漏的事前、事中、事后的不同时间点,我们可以采取不同的措施。参照八二原则,我们需要确保常态问题有对应的处理方式,软件项目成员按照既定方案进行处理即可,而特殊情况要有应急机制指导现场处理、事后再复盘总结。事中的处理:按照常规做法进行处理,或是特殊情况特殊处理,先解决眼下的问题;事后的处理:基于模型或思路进行复盘,并落实为新的常规做法或特殊情况处理方式;事前的处理:明确如何区分常规情况或特殊情况,并制定相应的处理方式或应急机制;联想阅读【华为云 · 敏捷智库】如何避免重要需求遗漏?参考附录相关文章敏捷联盟网站上的Epic术语解释:https://www.agilealliance.org/glossary/epic维基百科上的Kano模型词条:https://en.wikipedia.org/wiki/Kano_model相关书籍Mike Cohn:《用户故事实战》杰拉尔德·温伯格:《成为技术领导者》邱昭良:《复盘+:把经验转化为能力》
  • [技术干货] 【DevCloud · 敏捷智库】如何避免重要需求遗漏?
    避免重要需求遗漏的思路避免重要需求遗漏,首先我们需要反问一句 —— 为什么这些紧急重要的需求无法更早预见?同样的,我们需要了解:具体是哪些外界原因?这些原因是否有共性,有的话,那就针对性处理;增加的需求有无共性特点?有的话,可以针对性处理;临时增加有多临时?我们是否有提高或改善响应能力的空间,如果我们可以更快调整和响应,使得这些临时需求对我们产生不了什么影响,那么这个问题也就不再是问题了;既然是常态,为何我们的流程没有做出调整去应对?是调整过流程或工作方式,还是无法解决问题,还是说不知道该怎么调整流程或工作方式去适应?具体操作方法具体操作,可以按照事前、事中、事后各个阶段来采取不同的措施处理。一、事中的处理根据具体情况不同,在发现需求遗漏的当时,可以采取如下一些做法:重要需求遗漏,不紧急:既然不紧急,按照常规做法增加进去即可,但如果经常出现遗漏,就要考虑是否是需求分析和规划的实践做法有问题,才会导致问题持续出现,这种情况,应强化需求结构化管理,从全局出发进行思考和规划,避免因为思考的片面化和局部性导致的遗漏;重要需求遗漏,紧急:既然是又重要又紧急的需求,那么必然就得调整当前开发工作的顺序,把这个遗漏的重要紧急需求排进去,把工作安排下去;然后就要考虑从需求的优先级和需求的结构化管理两个方面入手复盘,并切实改进,避免类似情况再次发生;需求遗漏:如果是不太重要的需求遗漏,按照常规做法处理即可;可以根据其紧急程度和影响,决定是否调整工作顺序让这个需求插队;如果这种情况反复出现,那建议可以考虑进行复盘,从需求结构化管理的角度进行分析,并商讨改进措施; 二、事后的处理事后其实就是复盘,复盘的关键是要基于盘来推演和分析,这个盘就是事前制定的模型和规范。是我们有模型有规范,但执行出了问题?还是说这几个需求情况特殊,模型比较简单没有覆盖到这些特殊情况?还是说模型和规范都没问题,就是人员能力不足,导致判断偏差大?只有找到正确的根因,才能够真正有效的解决问题,所以我们不复盘则已,要复盘就务必要认真严格地进行复盘。怎么复盘?复盘也是有方法有套路的,业界也有相关书籍可供我们参考借鉴。例如温伯格在《成为技术领导者》中提出的MOI模型就可以用作复盘的一种思路。M:激励(Motivation),是不是人们没有动力去做这件事情?O:组织(Organization),是不是无组织无纪律、一片混乱,人们不知道自己或别人该做什么?I:想法或创意(Idea/Innovation),是不是缺少如何解决这些问题的点子或创意,不知道有什么办法解决这个问题?复盘时要注意,受限于能力或经验以及出问题次数多少的影响,我们可能无法得出一个准确的结论和必然有效的解决方案。此时一方面需要秉持持续改进的心态,我们可以先落实当前已经比较明确的改进措施,后续再观察效果,持续复盘、持续改进即可。另一方面我们也可以先采取一些临时措施。预留时间:比如,如果确实很难分析清楚为什么总是会遗漏需求,无法进行非常有针对性的处理时,也可以采取较为模糊应对的方式。可以拉取过去一段时间的工作记录,评估这段时间每个迭代的突发需求所消耗的工作量投入,可以取个平均值,然后在后续进行迭代工作安排的时候,固定的预留出一定量的时间,用于应对极有可能会出现的突发需求。需求拆细:当出现突发需求,导致我们需要调整工作顺序时,很有可能会因为需求颗粒度大以至于腾挪余地有限,而难以避免突发需求带来的影响,因而还应该尽可能地采取拆细需求的方式,将颗粒度比较大的需求拆分为较小颗粒度的需求,可以增加调整需求工作顺序时的灵活性;要确定到底要预留多少时间,可以利用DevCloud的Epic-Feature-Story结构,把突发需求汇集在一起,便于统计。例如创建一个特殊的Epic“突发需求”,下一级是为每个迭代创建的Feature,用来承载各个迭代里面具体的那些突发需求(体现为Story),并做好工时的记录,迭代结束后,就可以来计算出现了多少个突发需求、投入了多少工作量了。也可以采用“模块”字段来辅助记录和统计突发需求的数据。例如,新建一个模块,取名“突发需求”,所有突发需求都标注为这个模块,那么后续就可以基于模块进行筛选或查看报表等方式来统计突发需求所消耗的工作量了。三、事前的处理事前的处理放到最后来介绍,是因为之所以会出现问题一般都是因为事前没有做好,但已经出现了问题就需要在当时尽快处理,所以先介绍了事中的处理。但当我们处理完问题也完成了事后复盘,就需要考虑未来的事前,尽可能的避免问题发生。 简单来讲,事前的话,就是要做好需求的结构化管理和需求的优先级管理,以及做好相关规范的宣导、人员的动员和能力的培养,这样就能够有效的避免或减小突发需求带来的影响了。参考附录相关书籍杰拉尔德·温伯格:《成为技术领导者》邱昭良:《复盘+:把经验转化为能力》
  • [技术干货] 【DevCloud· 敏捷智库】物理看板和电子看板该如何选择?(内附下载材料)
    作者 黄隽 Charlie是选择物理看板还是电子看板敏捷项目最终的成功还是失败与使用物理看板还是电子看板没有绝对的因果关系。换个方式说,选择哪种看板不是对与错,而是适合与不适合。所以,要思考的是哪种方式更适合你的团队。接下来会先分别描述物理看板与电子看板的优势和劣势,然后再给出一些建议,从而帮助大家进行看板类型的选择。物理看板的优势和劣势优势1、成本低几乎不需要成本。办公室允许粘贴的玻璃墙、白墙或者白板均可。再准备点便签和笔。2、 入门快只要团队想好了怎么做,立刻可以做到工作的可视化,特别适合刚刚使用看板的入门级团队。3、 更改方便对于看板的规划,只要有新的想法就可以灵活的变动和快速的实现。比如,列的变化、泳道的变化。同样,特别适合刚刚使用看板的入门级团队。4、 仪式感强每日站会的仪式感很强,这个是电子看板无法取代的。劣势1、数据无备份历史数据不能备积累,无法对历史数据度量与分析。2、异地同步难如果团队成员分布在异地,信息的同步是很大的问题。3、  记录的信息量少受便签空间制约,书写的信息量有限,但是同时也约束了内容的简洁性。电子看板的优势与劣势电子看板以Devcloud的看板为例。优势1、  历史数据积累方便可以很方便的对数据进行度量与分析。通过报表功能可以快捷实现数据统计,如下图的DevCloud为例。2、 异地协作可视化可以方便的实现异地团队工作内容的可视化。3、  管理人员方便查看电子看板不受地域的限制,管理人员随时可以查看项目进度。4、 信息记录完整可以在卡片中增加更多的重要信息,比如验收标准等。还可以关联更多的内容。 劣势1、更改慢这里指对电子看板功能的制定化需求,新增加功能性需求需要开发团队配合完成,不能在第一时间随时按团队的想法自行更改。也就是说,团队的流程规划受电子看板功能制约。2、 仪式感弱团队成员在同一地点还好,如果分布在不同地点(包括在同一个办公室不同座位的情况)仪式感会弱化。 建议物理看板的选择,在团队刚刚开始使用敏捷时,如果团队成员都在同一地点办公,还是使用物理看板更适合。两个到三个迭代后,团队自然对敏捷流程有了认识,一些敏捷的习惯已经养成。要引导团队的改善活动,看板从开始到稳定要经历过几次进化,最后达到团队理想的流程管理和最佳的可视化状态。这个时候建议再引入电子看板,让敏捷习惯持续传承。电子看板的选择,如果团队成员分散到多个地域,毫无疑问电子看板是最适合的。有些团队会两种看板同时存在,这种情况多见于看板的管理规则不同(多数情况是更喜欢物理看板的仪式感及精简版的管理和内容),如果规则相同,建议用一种看板就好,否则两种看板之间的同步也是一种额外的工作量。作者序言随着近些年敏捷在行业及企业的推广,越来越多的企业意识到了敏捷所带来的好处,并愿意在敏捷上有所投入,从而越来越多的朋友加入了敏捷从业者行列,愿意学习敏捷知识。多年热衷于敏捷的我,参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动,阅读大量书籍、文献,活跃于敏捷大咖们的议题讨论,以及从事多年专职顾问的经验,有些小热情总结一系列文字内容分享给那些已经或者正准备踏上敏捷之路的朋友们,用于个人学习、研究和讨论,以及非商业或盈利性用途,为在敏捷之路的个人和群体贡献一份力量。系列文字主要内容来自于个人敏捷转型实践、书籍文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定敏捷理论基础的朋友们阅读,并按实际场景进行参考。如以上内容涉及版权或原创作者有不同见解之处,敬请及时告知,乐于接受并给予修正。附件:物理看板和电子看板该如何选择.pdf**** 本内容被作者隐藏 ****
  • [技术干货] 【DevCloud · 敏捷智库】如何进行需求优先级管理?
    需求优先级管理四步走需求优先级的管理,其实是为了帮助我们确定先做哪个需求后做哪个需求,从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理,或者更直接来说是优先级顺序管理,我们需要做到如下几件事情:确定优先级模型:优先级看起来像是一个简单直接的值,但实际上它是一个基于多种因素进行综合判断之后得出的一个值,这些因素和判断原则,就是我们所说的优先级模型;排定需求优先级顺序:将需求代入优先级模型进行计算,得出每个需求的优先级顺序;调整需求优先级顺序;改进优先级模型:如果经常发生需要调整需求优先级顺序的情况,那么最好是对这些情况进行一定的复盘分析,如有必要,修正或改进当前的优先级模型,让它可以适应实际情况,以避免调整优先级顺序的情况反复发生;另外就是需求可能已经交付或发布上线,但是该功能的实际用量或价值不吻合预期,则需要反思我们对这些需求的分析和判断,究竟是分析判断有误还是优先级模型有误,并进行相应的调整;一,确定优先级模型成本收益分析就是最简单的一种优先级模型,重要/紧急的四象限也是一种优先级模型,Kano模型也是一种优先级模型,它们都可以帮助我们去确定需求的优先级顺序。模型可以简单也可以复杂,根据企业实际需要来确定即可。务必切记优先级模型不应追求完美,以避免模型过于复杂,导致优先级管理的管理开销过高,喧宾夺主,反而影响了需求的开发和交付。如果较为简单的模型就可以满足需要,就应该首选使用较简单的模型。企业可以从简单开始,逐渐完善,不需要也不应该在一开始就追求过于复杂的模型。简单可以体现在考虑的要素更少,比如成本收益分析只考虑两个要素,就比考虑更多要素的模型简单;简单还可以体现在要素的取值范围更窄或精度要求更低,比如预计利润只要求评估高/中/低,就比要求以万元为单位评估预计利润更简单;优先级模型确定后,可以进行存档管理,注意该模型宜供所有人或相关人员查阅学习,比如录入到DevCloud的Wiki知识管理系统就是一个很好的做法,如下图:二,排定需求优先级顺序比如成本收益分析,可以是把预期市场收入作为收益值,把预期研发投入作为成本值,计算差值,或计算ROI均可。假设需求A预计收益为10万元,研发投入按人天折算预计3万元,那么预计利润就是7万元,预计ROI是 233%;需求B预计收益为5万元,研发投入折算预计4万元,那么预计利润1万元,预计ROI为 25%。那么需求A的优先级顺序就要比需求B更靠前。这种相差悬殊的情况往往不难判断,我们假设还有需求C预计利润也是7万元、预计ROI是50%,以及需求D是预计利润1万元、预计ROI是500%。那么A、B、C、D这四个需求的具体顺序怎么排定呢?如果真的出现这种情况,那就更复杂一些了,需要考虑引入权重,然后计算出一个综合值,这个值按照某种规则(例如从大到小)排列出来就是最终的优先级顺序,比如:预计收入(万元)预计成本(万元)预计利润(万元)利润权重利润加权值ROI(%)ROI权重ROI加权值综合值优先级顺序需求A10370.10.7233%12.333.032需求B5410.10.125%10.250.354需求C211470.10.750%10.51.23需求D2110.10.1500%15.05.11 根据上述表格中所得出的结果,我们就应该依序将需求D、需求A、需求C、需求B排入开发计划。优先级顺序,在DevCloud中,可以使用工作项的“优先级顺序”字段来实现,该字段取值范围1-100,如下图所示。三,调整需求优先级顺序调整顺序本身非常简单,只要在DevCloud中重新设定该需求的“优先级顺序”字段的值就可以。但重要的是,需要将优先级顺序调整这件事情记录下来,包括为什么要调整、具体如何调整的、调整背后的具体考虑等信息都记录下来,同样,建议记录在Wiki知识管理系统中。用于后续的复盘回顾中作为参考信息,比如每个Sprint/迭代结束时的回顾会议上拿出来进行探讨。四,改进优先级模型市场在变化,用户在变化,产品在变化,优先级模型自然也必须跟随着发生变化。我们可以定期或不定期的安排对需求优先级模型进行复盘分析,找出可以改进或优化的点,并跟进落实。可以是定期开展,例如每个月进行一次复盘,把这个月所涉及的需求都拿出来审视,或者是其中有调整过优先级顺序或者出现过问题的需求拿出来审视均可;也可以是不定期,以问题驱动的方式,比如某天进行了大量需求优先级的调整,那么当天或第二天就可以临时召集一次复盘会议,分析为什么会发生这种情况。复盘要有好的效果,就必须尽可能的复原问题发生当时的情况,所以前面提到的Wiki记录就变得非常重要。复盘会议应提供尽可能多的相关信息以便参会人员了解情况,充分探讨。复盘过程中,我们要定位出正确的根因,是模型本身设计有问题(例如要素和尺度),还是取值、加权有问题(比如某类需求的预计收入就是非常难估算),还是过程管理的问题(比如过早进行估算,因为缺乏必要信息,导致估算得出的优先级顺序不准确),并进行针对性地改进。参考附录相关文章维基百科上的Kano模型词条:https://en.wikipedia.org/wiki/Kano_model相关书籍杰拉尔德·温伯格:《成为技术领导者》邱昭良:《复盘+:把经验转化为能力》
  • [技术干货] 【DevCloud· 敏捷智库】敏捷实践之Sprint Backlog在看板中的移动
    黄隽 Charlie序  言随着近些年敏捷在行业及企业的推广,越来越多的企业意识到了敏捷所带来的好处,并愿意在敏捷上有所投入,从而越来越多的朋友加入了敏捷从业者行列,愿意学习敏捷知识。多年热衷于敏捷的我,参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动,阅读大量书箱、文献,活跃于敏捷大咖们的议题讨论,以及从事多年专职顾问的经验,有些小热情总结一系列文字内容分享给那些已经或者正准备踏上敏捷之路的朋友们,用于个人学习、研究和讨论,以及非商业或盈利性用途,为在敏捷之路的个人和群体贡献一份力量。系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读,并按实际场景进行参考。如以上内容涉及版权或原创作者有不同见解之处,敬请及时告知,乐于接受并给予修正。正常情况下的移动使用看板主要意图之一是控制在制品数量(WIP, work in process),需要拉动式的移动,这样可以有效控制在制品数量,防止工作项过多积压。另外需要提示一点,在整个移动过程的前提是需要制定一套移动规则,具体什么样的规则这里不做过多的描述,根据团队自身情况定义就好,规则根据团队意见可以调整几次,最后团队满意就是合适的。需求变更情况下的移动不接受变更当一个Sprint的Sprint Backlog和Sprint 目标确认后,为了保持团队在很短的时间内,全力以赴的向着Sprint目标冲刺,一般情况下不接受PO提出的需求变更。在很短的周期内,PO是有责任负责整理好Sprint Backlog的,进一步说,PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog,然后按优先级,挑选出最近一个Sprint的Product Backlog形成Sprint Backlog,因此经常性的需求变更建议团队不接受,另一方面也是一个好习惯的养成,促进PO对需求的把控能力。所以这种情况下,团队正常移动看板中的卡片就好。 拥抱变更完成拒绝需求变更是不现实的,有的时候高优先级的需求一定要满足变更的要求。比如,有市场时效性的,本Sprint不能完成,不能抢占市场先机,但变更需要遵循“NO CHANGE”原则。接到需求变更后,首先不是直接接受或者拒绝,而是先对需求进行分析,分析对当前迭代的影响。一般分析结果为以下几种情况:1)    无价值需求与PO沟通协商,对于无价值需求果断拒绝,当然是与PO协商后的结论,看板中的卡片不做任何移动。至于这些无价值的需求怎么来的,情况比较多,这里不做引申了。2)    变更少,影响小的需求高优先级的,对Sprint影响小的需求变更,可以柔和接纳,但要评估工作量,做等价交换。简单说,就是把未做的优先级低的需求从看板中替换出来,移动到Product Backlog中,这也是Product Backlog Refinement的过程,然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理:一种是移回到Product Backlog列,这种情况多于以完成特性需求为目标,更符合敏捷。另外一种是移到Done列,这种情况多见于物理看板中对统计度量数据比较看中的团队,团队需要对工作量进行有效统计。当然第二种情况在有些电子看板中也可以灵活统计来满足团队需求,那么就可以直接移动到Product Backlog列。3)    变更多,影响很大的需求高优先级的,对Sprint影响很大的需求变更,需要停止当前Sprint,重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值,这时果断停止当前Sprint,另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成,也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。
  • [技术干货] 【DevCloud· 敏捷智库】如何进行需求结构化管理?
    为什么要进行需求结构化管理?首先,并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求,也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联,那么不需要思考需求结构化管理这个问题。这种情况下,不管是用DevCloud的Scrum项目模板还是看板项目模板,都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联,而且即便是已经实现的需求也需要进行一定的管理、维护的情况下,我们才需要去思考需求结构化管理的问题,此时,我们需要使用DevCloud提供的Scrum项目模板,因为里面有Epic-Feature-Story的需求结构,以及需求规划功能可以辅助我们进行需求的结构化管理。以什么为依据进行需求结构化管理?需求结构化管理,应该以什么为脉络来建立这个结构呢?软件研发无非是分为项目型软件研发和产品型软件研发两种,项目通常来讲都是临时性的,或者说短期性的,而产品或者软件系统是长期性的,或者说我们会持续维护、更新其功能特性的。项目复项目,我们很可能通过持续地完善和刷新同一套软件产品或系统来达成项目目标,交付软件项目所要求的功能特性的。这就意味着,我们的需求结构化管理,需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息,则可以通过需求的不同属性甚至标签等方式来实现。使用DevCloud进行需求结构化管理的一种方式接下来,我们介绍推荐的一种方式。一、针对产品或系统建立DevCloud项目也即一个产品或系统,建立一个DevCloud项目,该产品或系统的所有需求,都在此DevCloud项目里面进行管理。二、确立Epic-Feature-Story的需求结构这个产品或系统的业务模块作为Epic,比如用户中心、购物车、配送管理等,比如一家货运云商,他们的油卡业务,就适合作为一个Epic,针对油卡的各种功能,就可以作为Feature展开;Epic要承载业务价值,也即Epic需要是对企业本身是有意义的;针对前面业务模块的具体展开、拆开,就可以作为Feature,也可以简单理解为一个业务流程、用户流程;以前面用户中心为例,用户信息可以是一个Feature、我的订单可以是一个Feature、地址管理可以是一个Feature;或者以油卡为例,购买油卡、我的油卡等就可以作为不同的Feature;Feature要承载用户价值,也即对于用户来说,是可以理解这个Feature,且认可其价值的,通常Feature也是用户可以直接感知、可以操作的;Feature往往还是有些大有些复杂,那就需要拆成颗粒度更小的Story,用来承载一个具体的用户操作,例如可以查看到所有订单、可以过滤订单、可以修改用户昵称、可以自定义头像等功能;再往下一级的Task,就主要是为了分工协作,也即是说,如果Story可以包干到人,那么不再拆分Task也是可以的;Task往往是关于工程师需要具体做的工作,也就跟业务价值、用户价值、用户单步操作都没有了什么关系,通常都是把Story按照具体的组件、模块进行拆分,例如前端、后台、数据库之类的,或者是按照工作流程分工来拆分,例如UCD、开发、测试、部署等;如下图所示,各层级为:Epic:用户中心Feature:地址管理Story:用户可以新建地址Task:【Web端】页面入口及地址编辑表单、【数据库】用户地址数据表设计和实现 三、不同模块以及版本的管理可以通过工作项的属性来进行管理,如下图:模块:Web端发布版本号:1.0.1.2 至于模块清单的维护,可以在工作项编辑状态,点击“模块”字段右侧的小齿轮图标,即可在弹出窗口进行操作,可以添加、修改、删除模块:在工作项管理的Backlog视图下,通过“设置显示字段”增加“模块”字段后,既可以很方便地看到工作项相关的模块,当然也可以进行过滤:参考附录相关文章敏捷联盟网站上的Epic术语解释:https://www.agilealliance.org/glossary/epic相关书籍Mike Cohn:《用户故事实战》
  • [技术干货] 【DevCloud · 敏捷智库】中国DevOps社区大连第二届Meetup
    作者:黄隽(Charlie)八月的最后一天中国DevOps社区在大连举办了第二届Meetup。关于本次Meetup将从社区活动介绍、活动内容和流程、分享的主题、心得等几个方面来小结一下。先分享活动后对专业人士的采访吧…社区活动简介中国DevOps社区大连Meetup是一年一度的大连本地DevOps社区聚会,旨在传播DevOps文化,落地DevOps实践,帮助大连本地的IT从业人员共同学习和进步,也是帮助有需求的企业培养更多的DevOps人才。到今年已经举办了两届,这次由DevOps社区主办,敏捷江湖桃花岛社区协办,邀请了大连本地著名公司的DevOps和敏捷专家为大家分享和现场答疑。中国DevOps社区中国DevOps社区由一群拥有相同价值观和理念的志愿者们共同发起,并于2018年7月正式成立。社区的目标是推动DevOps在中国的蓬勃发展。社区设有理事会和专职运营人员。社区使命:传播DevOps文化,落地DevOps实践社区愿景:成为中国DevOps运动的领航人与催化者社区核心价值观:开放、专业、使命感 敏捷江湖桃花岛社区敏捷江湖桃花岛社区是19年1月成立于美丽的浪漫之都大连。由最初单纯的敏捷分享交流演变而来,《华山论剑》是社区的金牌活动。由开始的华为云DevCloud敏捷专家组和运营组以及邀请的圈内几个好朋友一共十几个人组成,现在已经发展到二百多人。主要成员为敏捷教练、DevOps工程师、企业家、高级项目管理人员、出版社的朋友们。社区努力打造高价值的技术和人脉分享平台,共建敏捷生态圈。 内容和流程本次活动上、下午共计一百人左右,从上午10:00持续到下午6:20。主要进行了DevOps和敏捷相关实践、主题分享。上午DevOps动手操作,下午DevOps和敏捷主题分享和最后的Open Space互动。第一部分:上午进行了DevOps实战工作坊。来自IBM的明星DevOps团队,为大家带来为期2小时的DevOps实战工作坊!你有机会在专家的指导下,模拟项目实景,亲自上手体验DevOps的工具链操作,用最短的时间,最快的路径,获取DevOps的知识和实操经验! 该工作坊是国内首次由经验丰富的一线DevOps专家设计的,基于项目实景环境,帮助参与者直接获取实操经验的工作坊,机会难得。第二部分,下午上半场进行了DevOps&敏捷大咖心法分享。本次Meetup活动汇集了来自IBM,、埃森哲、东软、华为云DevCloud的资深实践专家,为大家分享DevOps&敏捷在实施过程中的宝贵经历。参与者可以获取一手经验,了解到DevOps&敏捷在团队层面的操作,以及在部门和公司等更高层级上的应用和影响。同时一窥大连本地的各主流公司对DevOps的应用情况,及各公司内部的DevOps生态环境。 第三部分,下午下半场进行了“开放空间”活动。由各位主讲嘉宾带队,每位参与者都有机会提出或选取自己最感兴趣的关于DevOps&敏捷的问题,获得大咖的深度解答,同时可以和参会的其他同行进行深入讨论,互相学习。主题分别为:如何进行CI\CD?---埃森哲架构师 刘玉森如何保证DevOps的安全性?---IBM DevOps应用安全架构师 于湍(Nick)敏捷团队如何做绩效管理?---IBM 敏捷教练管 婷婷(Lisa)如何快速落地敏捷?---东软敏捷教练 巩敏杰敏捷站会你开对了吗?---华为云 DevCloud敏捷专家 黄隽(Charlie)分享的主题在最后2个小时左右的Open Space环节,对大家感兴趣的几个话题中选出了“如何正确开站立会议”进行了引导、分享,同时介绍了我们DevCloud敏捷专家组日常站会。 会上大家关于站会的问题集中在:    总结的18Key如下,得到了很好的验证,具体关于18Key内容可以参考【DevCloud专家智库】中的“何如玩转每日站会”: Key 1: 主持人会议主持人(比如Scrum Master,也可以团队成员轮班,轮流感受下站会的节奏)确保会议的举行,并控制会议时间,团队成员进行简短有效的沟通。Key 2: 两个比萨大小的团队在《Scrum敏捷软件开发》一书中,作者麦克.科思提出了一个简单的方法用来辨别什么是合适的团队规模,那就是,如果两个比萨够整个团队成员吃的话,那么这个团队的规模比较适合。因为两个比萨大小的团队跟家庭的规模相似,站立会的目标可以轻松达成。当团队是家庭规模大小时,人们头脑中就很容易追踪到团队中发生的事情。人们可以很容易地记住每个人每天的承诺,以及每个人对于其他成员或团队成果的责任。Scrum中也建议团队规模不要太大,一般为7-9人左右。最后再强调一点,并不是要求团队一定要按以上15key进行开站会,15key只是在很多实践中总结出来的一些经验,曾经解决过很多问题。对于每个具体团队需要结合实际情况进行选择应用15key,没有绝对的对与错,只有适合和不适合。Key 3: 限制发言团队外成员也可以参与,但没有发言权。Scrum中曾经使用过术语“猪”和“鸡”来区别在每日站会中哪些人应该参与发言,哪些人就站在旁边看就行了,不过这两个术语现在已经不用了。这两个农场动物术语来自一个老笑话:“在早餐吃的火腿鸡蛋中,鸡是参与者,猪是全部投入了。”显然,Scrum使用这些术语是为了区分参与者(鸡)和为了实现冲刺目标面全力投入的人(猪)。在每日站会中,只有猪应该发言,如果有鸡参加例会的话,应该作为旁观者。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: 问题风险跟踪将站会成员遇到的问题和风险做概要的记录(不必详细,只要说明重点即可,不需要在记录上花费更多的时间),然后保留到wiki,或者方便大家跟踪的地方。此目的是确保这些问题和风险得到了闭环(例如,问题和风险可以会后按排专题讨论、跟踪,直到关闭)。Key 14: 回顾改善本身每日站会就是最小化的戴明环(PDCA),另外团队在回顾会议上时也可以对站会开的效果进行回顾,哪些地方做得好,哪些地方做得不好,有哪些改善点可以在下一轮迭代中改善等。(站会只是回顾会议中一个回顾点,如果没有问题不用做专题回顾)Key 15: 发言棒站会时可以利用一些小道具来保证会议不会超时。团队可以找一只笔或者一个娃娃(女生多的团队)作为发言棒仍给一位成员,让他拿着发言棒陈述完“三个问题”,然后将其交给下一位。没有拿发言棒的成员不允许发言。如果有人用时过长,建议把发言棒换成一个水桶(当然是盛满水的)让他托起,直到托不动为止。如果他想说就让他说,要么会议很快结束,要么我们的开发人员练成强大的臂力,按经验,一般都会挑重点说,会议按时结束。Key 16: 冲刺待办列表站会中,成员在发言时可以利用冲刺待办列表来检视当前工作项的完成状态。冲刺待办列表记录了团队成员工作的进展,需要每天更新并跟踪。电子化的冲刺待办列表更能很好的解决异地团队开站会思路不聚集的问题。发言人在讲那“三个问题”时,同步可以展示冲刺待办列表给团队。Key17: 任务看板在站会期间,通过任务板,团队中每一个人都可以知道哪些工作正在进行,哪些工作已经完成。团队关注事情的完成,一直处于进行中的任务为被发现,成为当前的焦点,这样团队就可以尽快把这些焦点问题解决掉。Key 18: 燃尽图燃尽图是将进展和剩余工作情况可视化的有力工具。一般竖轴表示剩余工作量(小时、故事点或工作项个数),横轴表示冲刺时间(一般单位为天)。  开站会时,发言人可以利用燃尽图来做进展讲解。燃尽图让所有团队成员一眼就可以看出冲刺的状态,进展情况非常清楚,看出工作是否在按计划进行,状态是否良好。这些信息可以帮助团队确定是否可以完成预定数量的工作项,并在冲刺早期做出明知的决定。使用燃图易达成如下效果:高可视性,直观展示进度情况和剩余工作;快速识别风险;帮助团队建立信心,了解自己的能力;了解团队成员工作步调;了解团队冲刺计划;和任务墙能非常高效地匹配使用。关于18key,这里想强调一下,并不是站立会议时要把所有18key都要执行一遍,这里的18key只是提供了一些参考实践和关键点,18key来源于大量的实践,也解决过团队站会的问题,所以大家在站会遇到了问题时,可以先想到这个18key,然后选择适合自己团队的key。没有绝对的对与错,只有适合和不适合。举一个例子,这里有四个key是关于工具的,这些工具我们都要使用吗?当然不一定。敏捷宣言里提到“个体和互动高于流程和工具”,工具是为团队服务的,不是团队的负担,更不能被工具所绑架。所以团队一起选择适合的,才是正确的做法。心得1.促进人才交流,更多的小伙伴们有着共同的爱好走到了一起。助力DevOps和敏捷人才的培养,更多的人才加入到DevOps和敏捷的队伍中,为需要的企业做人才储备。2.了解最新行业动态,一窥大连本地的各主流公司对DevOps的应用情况,及各公司内部的DevOps生态环境,良性促进行业发展。3.高校志愿者学生提前感受IT前沿管理和技术内容,明确日后学习和发展方向。
  • [技术干货] 【DevCloud· 敏捷智库】江湖茶馆——Scrum四大事件之一 “每日站会”
    黄隽 Charlie江湖茶馆是敏捷江湖桃花岛中一项话题讨论活动,通过华山论剑层层闯关后的江湖高人,才可获得登岛机会,与敏捷大咖面对面交流互动。 本期主题Scrum四大事件之一:每日站会 本期主讲嘉宾:黄隽 (敏捷江湖桃花岛——黄药师) 话题概要:本期话题根据江湖人士关注点,共围绕六个问题开展话题讨论,分别是:问题一:站会时间长?问题二,PO是否必须参加站会,如果参加,该怎么参加?问题三:我们没有发言棒啊,主要就是天天都开……放下一切工作去开站会,隔一天一开不行么?问题四:站会用物理看板还是电子看板?问题五:站会需要维护team的burndown图吗?问题六:还有个更难解决的问题:会上每个人只关注自己task的状态,没人关心story这个整体,如果有业务等外来变化,影响现在的story,没人关心? 以下内容为本期话题的精品沉淀: 问题一:站会时间长?会议上每个成员需要回答3个问题:1、昨天都完成了哪些工作?2、今天准备完成什么?3、工作中遇到了什么问题?回答的形式与目的不是向领导汇报工作,而是团队成员之间相互交流,以共同了解项目情况和共同解决问题。会议主持人(比如Scrum Master、轮值者、教练、团队协调者)确保会议的举行,并控制会议时间,团队成员进行简短有效的汇报。另外要注意时间盒,也叫timebox,是开发团队的一个时间盒限定为 15 分钟的事件。 时间建议不要太久,对于5-9人的团队来讲15分钟的会议时间足够。团队外成员也可以参与,但没有发言权。某位团队成员在发言期间,其他人员应认真倾听,如有疑问可简短确认,但不应做过多讨论。如果对某位成员的报告内容感兴趣或需要其他成员的帮助,任何人都可以在每日站立会议结束后即刻召集相关感兴趣的人员进行进一步的讨论。并且在发言时可以利用道具,比如话筒,谁拿到话筒谁发言,限制频繁打扰发言人的情况。 问题二:PO是否必须参加站会,如果参加,该怎么参加?Scrum Guide 中建议,站会由开发团队参与即可,如果其它人员参与,有听的权力,建议不要给干扰团队开会的权力。就是说禁言,以确保会议高效 问题三:我们没有发言棒啊,主要就是天天都开……放下一切工作去开站会,隔一天一开不行么?没有什么不行,也没有绝对正确的。如果团队所有成员觉得站会隔日开,那么SM要判断一下。我一般的做法是,尊重团队成员想法,给团队试错的机会,如果发现问题,引导团队自行改善。当团队成员有了对比,开与不开,或者天天开,和隔日开是有感觉的,打在自己身上才有疼的感觉,不给团队尝试机会,我不建议。当然SM要及时引导,服务,和排除障碍。 问题四:站会用物理看板还是电子看板?电子看板优势1) 历史数据积累方便可以很方便的对数据进行度量与分析。2) 异地协作可视化可以方便的实现异地团队工作内容的可视化。3) 管理人员方便查看电子看板不受地域的限制,管理人员随时可以查看项目进度。4) 信息记录完整可以在卡片中增加更多的重要信息,比如验收标准等。还可以关联更多的内容。 电子看板劣抛1) 更改慢这里指对电子看板功能的制定化需求,新增加功能性需求需要开发团队配合完成,不能在第一时间随时按团队的想法自行更改。也就是说,团队的流程规划受电子看板功能制约。2) 仪式感弱团队成员在同一地点还好,如果分布在不同地点(包括在同一个办公室不同座位的情况)仪式感会弱化。 物理看板优势1) 成本低几乎不需要成本。办公室允许粘贴的玻璃墙、白墙或者白板均可。再准备点便签和笔。2) 入门快只要团队想好了怎么做,立刻可以做到工作的可视化,特别适合刚刚使用看板的入门级团队。3) 更改方便对于看板的规划,只要有新的想法就可以灵活的变动和快速的实现。比如,列的变化、泳道的变化。同样,特别适合刚刚使用看板的入门级团队。4) 仪式感强每日站会的仪式感很强,这个是电子看板无法取代的。 物理看板劣势1) 数据无备份历史数据不能备积累,无法对历史数据度量与分析。2) 异地同步难如果团队成员分布在异地,信息的同步是很大的问题。3) 记录的信息量少受便签空间制约,书写的信息量有限,但是同时也约束了内容的简洁性。 我的建议: 敏捷流程有了认识,一些敏捷的习惯已经养成。要引导团队的改善活动,看板从开始到稳定要经历过几次进化,最后达到团队理想的流程管理和最佳的可视化状态。这个时候建议再引入电子看板,让敏捷习惯持续传承。如果团队成员分散到多个地域,毫无疑问电子看板是最适合的。有些团队会两种看板同时存在,这种情况多见于看板的管理规则不同(多数情况是更喜欢物理看板的仪式感及精简版的管理和内容),如果规则相同,建议用一种看板就好,否则两种看板之间的同步也是一种额外的工作量。 问题五:站会需要维护team的burndown图吗?建议更新,而且认真做好团队中每个成员的每日燃尽和团队整体的每日燃尽。 问题六:还有个更难解决的问题:会上每个人只关注自己task的状态,没人关心story这个整体,如果有业务等外来变化,影响现在的story,没人关心?我估计,你的团队人数比较多,Scrum中建议团队人数为5-9人。你的团队中的成员应该不是特性型团队Feature, Story, Task要区分好,团队是一个整体,要强调Sprint目标完成,团队才胜利,个人目标完成Sprint也是失败。另外,发言顺序团队经过几次站会,你会发现很巧妙,顺序好像自然固定了,建议业务耦合度高的放在一起发言。 以上为本期江湖茶馆的全部精品内容,如果您也想加入敏捷江湖桃花岛与大咖切磋问道,可添加桃花岛助手小昭微信:devcloud08.黄药师微信:65983808。
  • [问题求助] 【DevCloud· 敏捷智库】敏捷实践:一周的Sprint太短,可以调吗
    黄隽 Charlie背景一个人数为7人左右的团队采用Scrum框架工作。Sprint的长度,团队目前采用时间盒为1周。团队经常会出现在Sprint结束时不能完成当初设定的Sprint目标,很多工作项需要跨Sprint才可以完成。问题分析目前Sprint中存在的主要问题是Sprint目标完成不好,解决掉障碍,Sprint目标按承诺完成即可。 团队成员的工作内容中包含很多探索性工作项,对工作内容领域不熟悉,需要投入一些学习成本,导致工作项的实际完成用时要比正常多。每个用户故事的工作量也比较大,多数超过24小时。PO对工作项完成标准的要求非常高,评审严格,不合格的工作项在Sprint中经常返工。团队当前的Sprint时长为一周,并且四大事件按照Scrum框架执行,其中Sprint计划会议和Sprint回顾会议平均持续时长为2小时左右。 从分析中归纳影响Sprint目标完成的几个主要因素如下表:影响Sprint目标因素表(一)。影响Sprint目标因素表(一)序号影响因素具体分析1探索性工作项多无法改变现状,学习成本的投入是必须项。可以考虑团队成员间知识共享,随着能力提升学习成本会逐渐减少。2工作领域不熟悉,需要学习成本  3用户故事比较大由于工作项的特殊性,用户故事普遍比较大,可以考虑拆分为更小的故事,或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。4PO完成标准高进一步理解PO完成标准,在计划会议上需要明确验收标准(AC, Acceptance Criteria) 和 (DoD, Definition of Done).5Sprint周期短团队初始确定的周期长度为一周,经过几轮Sprint后,如果Sprint目标完成不理想,根据工作项特殊性考虑到周期有点短,适当调整周期。6Sprint计划会议和Sprint回顾会议持续时间略长每项会议其实是有建议的时长,正常一个月的Sprint周期,建议Sprint计划会议为8小时,那么按比例一周的Sprint,建议计划会议为2小时时长。同样,一个月的Sprint周期,建议Sprint回顾会议不超过3小,显然,对于一周Sprint时长的回顾会议用掉2小时是严重超时的。 解决措施针对以上问题的分析,建议这种情景下将Sprint的时间盒由一周改为两周。Sprint的时间过短,团队成员会忙于准备计划会议、评审会议及回顾会议,真正完成工作项的时间较少。对于突发事件的应对能力减弱,不利于形成团队稳定的节奏。Sprint的时间过长,失去了短时间盒的优势,失去了时间盒的意义。因此,如果团队在时间盒为一周的Sprint中经常不能完成Sprint目标,可以试着把时间盒调为两周。同时要注意优化用户故事的大小,提高四大事件的效率。Spring的时间盒由一周改为两周后影响因素会有所改善,具体如表:影响Sprint目标因素表(二) 影响Sprint目标因素表(二)序号影响因素Sprint由一周改为两周后的相应缓解1探索性工作项多有相对充分的缓冲时间应对学习、探求性工作以及突发情况。2工作领域不熟悉,需要学习成本  3用户故事比较大时间相对宽裕后,计划会议开得更充分,用户故事拆分为更小的故事,或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。4PO完成标准高时间相对宽裕后,理解PO完成标准更加充分,在计划会议上明确验收标准(AC, Acceptance Criteria) 和 (DoD, Definition of Done).5Sprint周期短调整周期后,团队成员氛围更加好,每个Spring目标完成度得以改善,成员更加自信。6Sprint计划会议和Sprint回顾会议持续时间略长时间相对宽裕后,每项会议质量有所提高,在合理的时间范围内可以高质量完成会议内容。计划会议 其它情况Sprint的时间盒长度建议如下,需要说明的是以下情况不是绝对的,需要根据团队现况选择适合的就好,没有绝对的对与错,适合的就是最好的。 ·        一周到两周新产品研发团队,产品具有时效性的特点,业务需求迎合市场随时调整,灵活多便,快速响应业务需求,经常性的自检。·        两周团队节奏相对稳定,故事点较大,不好拆分,需要更多的时间评审和返工修正。·        三周到四周节奏稳定,团队稳定,需求稳定,团队有固定的节奏,浪费较少。 了解更多:什么是时间盒?在Scrum框架中,工作在建议时间长度为一个月或者更短的迭代或循环中进行,这个迭代或者循环叫做冲刺。冲刺在一个时间盒(Time Box)内,也就是冲刺有固定的开始和结束时间。时间盒的优点具体内容如下:1) 时间盒是设定WIP数量限制的技术。WIP英文全称为work in process是已经开始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工作事项,因此时间盒是为每个冲刺设定WIP数量限制。2) 时间盒可以强制排列优先级。我们需要先执行高优先级的工作,时间盒可以强制我们按优先级排序执行小批量工作,这样我们的注意力可以更集中于快速完成高价值的工作。3) 时间盒可以展示进度。时间盒可以展示我们需要多少个时间盒才能完成大特性的进度,帮助准确知道为交付整个特性还需要做多少工作。4) 时间盒可以避免不必要的完美主义。有时候团队会花过多的时间把事情做得“完美”。每个冲刺中,时间盒限定了一个固定的结束日期,通过这种方式强制结束可能无休止的工作。5) 时间盒可以促进结束。冲刺有明确的最后期限,这个期限不允许修改,这可以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有时间盒的限制,Scrum团队成员就不会有完成工作的紧迫感存在。6) 时间盒可以增强预测性。团队不预测后续长时间段内可以完成的工作,但是预测下个冲刺内能够完成的工作是可以做到的。每个冲刺持续期短有很多好处。持续期短的冲刺更容易规划,反馈快,错误有限,投入产出比(ROI)高,有助于保持较高的参与热情,检查点多。具体好处如下:1) 持续期短的冲刺更容易规划。为短时间的工作范围做规划所需要的工作量比给长时间的工作范围做规划的工作量要小得很多,结果更准确,可执行性更强。2) 持续期短的冲刺可以产生快速的反馈。快速反馈可以去掉不适宜的产品路径和开发方法,避免产生更多的差产品质量成本(COPQ,Cost of Poor Quality)。最重要的是快速反馈可以使团队更快速地发现和利用稍纵即逝的商机。3) 持续期短的冲刺投入产出比(ROI)更高。持续期短可以更早、更频繁地交付,有更多的机会快速投入生产,产生收入。4) 持续期短的冲刺所犯的错误也是有限的。在短短1或2周的时间内,就算错了,全部搞砸了,也只是失去了短短的1或2周的时间,不会带来巨大的损失。坚持持续期短的冲刺能够进行频繁地试错,协调和反馈。5) 持续期短的冲刺有助于保持较高的参与热情。团队参与工作的热情,兴趣和兴奋程度会随着时间的拉长而越来越弱。如果一个项目时间过于长,人们看不到结果,那么显然人们会逐渐失去兴趣。持续期短的冲刺通过频繁快速的交付可用的工作产品,让参与者有满足感,操持较高的参与热情,便团队成员恢复兴趣并渴望继续完成冲刺的目标。6) 持续期短的冲刺能提供多个有意义的检查点。传统瀑布式开发有里程碑,例如分析、设计、编码、测试和运行。这些里程碑其实是一些不太靠谱的指标。Scrum在每个冲刺结束时会有一个有意义的检查点(冲刺评审会议),团队中的每个人可以根据展示的可以工作的特性做出判断和决策。有更多的检查点来检验和修正,我们就能更好地应对复杂的项目。 参考文献    Scrum指南(2017-Scrum-Guide-Chinese-Simplified),2017年11月版。
  • [技术干货] 敏捷开发KANBAN流-华为云MVP王立杰
    敏捷领域KANBAN方法如果具体去操作,在敏捷领域做计划也是一种浪费,应该不拘泥形式与流程,具体如何去看待KANBAN在敏捷领域的优势,请看王立杰老师如何回答?                    全部
总条数:274 到第
上滑加载中