• 【测试微课堂】DevOps敏捷测试之道
    【测试微课堂】共6期,此篇为第1期。本文介绍企业在敏捷和DevOps的逐步转型过程中,测试如何应对挑战,有的放矢进行测试,建立适合产品自身发展阶段、产品特点的敏捷测试能力。敏捷和DevOps敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈,新商业模式的创新和变现时间窗口越来越短,催生更多的企业采取精益创业的方式,捕捉市场需求后,尽量缩短TTM产品面世时间,快速推出MVP产品并快速响应客户需求迭代产品。以华为为例,在2008年左右的时候,华为的项目还是采用传统的交付方式,例如在年初开始一个项目,在项目立项之初就会把客户的需求全部收集好,包括一些用户的反馈,并把需求做了全年的排序。年中的时候发布产品给用户,两个月之后再出一个补丁,最终年底出一个正式的版本。当时版本交付的节奏还是比较慢的,但是对质量要求比较强。因为产品发布给客户以后,下一个补丁需要两个月,如果用户在这个期间发现产品问题,他们只能再等两个月,而在这期间如果用户不接受我们的产品,会导致项目前功尽弃,所以就对产品的质量有严格的要求。产品逐渐向敏捷方向发展,这时有一部分研发工具平台已经陆续转到云上去了,一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次,转型之后变成一个月,甚至两周发一次,但这时的转变并不彻底,与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型,这个时候一些商业模式发生了根本性的变化,也就是说当需求上云了以后,用户更加快速的介入进来。基于云平台,把一些功能快速的开发出来,然后频繁的和用户去商量,听取客户意见,牵引产品做快速迭代,这种交付方法使得交付周期一下变快了,之前是半年交付一次,现在是一周、两周,更有甚者,可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化,基本做到了小步快跑,快速试错。测试债务    从瀑布到敏捷再到DevOps,在开发和测试生产率和需求交付效率提升的过程中,不同的组织或多或少面临一些积压问题没有解决,影响测试能力和测试价值的持续提升。•    从对测试的重视程度上看,有的公司存在重开发、轻测试的情况,测试人员职业发展受限;手工测试人员不熟悉编程,开发人员对测试重视不足;测试工作量高,但人员配比低。•    从部门组织和流程和文化上看,测试人员对需求理解不足,测试和开发之间的部门墙导致信息不透明、沟通协作滞后和不足,质量向速度过分妥协,以及忽视敏捷文化和价值观的培养塑造。•    从测试和产品技术和方法上看,产品耦合度高、可测试性差,测试过于依赖黑盒功能测试,测试策略、方法不恰当,测试环境部署时间长,频繁升级等。测试的焦点:业务价值的质量    测试首先就是一个质量活动,做测试就是要保证质量,其次是一个工程性的活动,即在有限的时间、人力、资源投入内获得尽可能大的产出价值。质量有多个维度,需要有一个焦点,就是业务价值的质量,也就是产品“对客户呈现的价值”的质量。测试围绕业务价值去做,确定质量在功能、安全性、性能、易用性、兼容性等多个维度上的权重和优先级,而不是说一个测试上来之后,就把测试相关的关系点、关联点全部做测试。    让我们来看几个例子:例如现在正在做一个线上支付的功能,对这个功能最关心的方面肯定是安全,所以相关的测试用例关键点就应该围绕安全大做文章,一定把安全保证好。再比如,现在要做一个线上商城,面向用户是老百姓,不仅要让年轻人会用,也要让老人都会用,那么就要关注易用性。除此之外,电商举办大规模抢购促销活动,那就还需要关注性能。所以测试要求瞄准了产品本身的业务价值,确定产品的目标,相应的制定质量关键点,制订相关的测试策略,然后实践落地。落地之后还要基于一些不良的效果不断的进行反馈、循环,校验整体的测试过程是否达到预期结果,这就是我们的测试焦点。 自动化测试金字塔    自动化测试金字塔最早是由MikeCohn在2009年的著作《Succeeding withAgile: Software Development using Scrum 》(《Scrum敏捷软件开发》)中提出。最早提出来的时候是一个三层的金字塔,从上到下分别是UI界面/Service服务/Unit单元测试,随着敏捷测试的不断推进,测试金字塔出现一些变种。实际使用中不用太拘泥于每层的名字,在服务化软件架构中Service层也可以理解为 API测试。    这种下宽上窄的三角形结构,代表在各层自动化的建议投入分配比例,越接近底层的单元测试建议的投入最多,接口测试居中,界面层建议的投入最少。    MartinFlower关于测试金字塔有这样一段评论。“GUI测试用例还很脆弱,如对系统的一些修正可能导致很多用例的失败,这时候你需要重新录制。你可以放弃录制的方法来解决这个问题,通过写GUI测试代码,但是这样效率非常低。就算你已经很精通了GUI测试代码的编写,端到端的GUI测试用例也很容易出现不可预期结果的问题-一些用例成功一些用例失败,因此,基于GUI的自动化测试是脆弱、耗时(包括用例维护和执行)的。所以测试金字塔要表达的是:底层应当有更多的单元测试和接口测试和逻辑测试,GUI测试用例能覆盖到主业务流程即可。”    测试金字塔中每层中涉及的测试技术均有自己的优势和局限性,由于上层GUI测试的脆弱(不稳定性)、耗时(执行效率)问题,以及问题表现位置(UI)和问题根因位置(代码)距离太远的问题,测试金字塔由关注测试数量转向关注测试质量,推荐增加底层的测试投入。•      层次越靠上,运行效率越低,延缓持续集成的构建-反馈循环•      层次越靠上,开发复杂度越高,如果团队能力受限,交付进度受影响•      端到端测试更容易遇到测试结果的不确定性•      层次越靠下,单元隔离性越强,定位分析问题越容易    原则上单元测试需要开发人员承担,很多团队中开发人手不足,优先保障功能的实现,在单元测试的投入不够,并且很多开发人员的单元测试经验不足,导致很多团队中不做单元测试或者被动执行流于形式,有人提出了金字塔结构的反模式:蛋筒冰激凌模式和纸杯蛋糕模式。常规安全与弹性安全    在我们常规的设想中,通常是哪个地方不安全,就一定要把所有不安全的因素找出来,清除掉。这是常规的做法,但却偏向于理想,在实际工作中是不可能把整个系统中不安全的因子全部识别到的,这其中涉及能力、架构等各方面的原因。    因而在此基础上演变出了弹性安全,就是通过场景模拟的方式将不安全因素尽量展现出来,从而基于这种不安全场景,给出快速的修复方案弥补这个不安全因素,从用户角度来讲是感知不到的。从产品来讲,它的商业目的和质量目的都可以达到,这就是所谓的弹性安全,即便发生了错误,能够及时快速的修复漏洞或者自我修复,达到正常工作的目的。测试左移和测试右移    左移就是前移,尽量把活动向前移。例如BDD行为开发,基于场景直接设计出符合这个场景的用例,来匹配这个设计;契约测试,服务和服务本身之间有耦合,我们可以通过契约测试解耦,以防导致问题。    测试右移是指要把测试活动的覆盖范围尽量向后蔓延。通常的测试只进行到了版本发布之前,测好之后发布一个软件包,而测试右移要把软件包发布到生产环境,以及到线上运营环节,都要去做测试。    在这两个方面也有一些相应的实践实践,例如线上拨测,主动线上监控用户的一些行为,并从行为轨迹里面快速捕捉相应的问题,主动推送给相关的责任人,让他去关注并且解决。所以线上的过程可以通过一些测试手段,不断的反馈给真正的开发人员,让他知道当前产品的整体表现,开发人员就会快速的针对产品作出应对方案。产品发展不同时期的测试策略    是否这个团队组建之初,就要把整个自动化测试的能力构建起来呢?其实这有一个过程,下面从软件的成熟周期的角度,看一下如何构建测试自动化的能力。在软件初期探索阶段,产品是一个不确定的状态,从前端的风格和整体的布局到后端的API都时刻在变化当中,而且变化比较频繁,因为自动化用例的生命周期比较短,所以在这个时候创建一些自动化测试用例是不太划算的。而这个时间段的产品,往往特性是可控制的,只有几个测试,所以可以以手动为主,不考虑自动化,让产品能够快速识别错误点,让用户能用起来。    到了产品扩张阶段,用户认可产品,这时候会出现两个现象。第一是用户量增长,第二是需求数量增长。这时候必须要考虑自动化。因为在这个阶段每一次迭代的全量验证成本会越来越大,而交付的速度也会越来越快。我们不可能每一轮上线的时候都全部用手工做测试,这时候旧的模块就需要自动化用例去保证。到产品提取阶段,产品已经到了需求的饱和期,产品的利益增长也到了饱和期,这时候要严格控制产品需求,自动化用例的职责变成守护,不允许变动引入额外的风险点、大的特性变动,导致对成熟的用户造成攻击。  团队规模对测试建设的影响    当团队规模在5个人以下,团队处于探索阶段,这时质量活动可以仅仅局限于测试的自组织阶段,只是做一些基础类测试管理活动,把缺陷管理起来,做一些回归测试。在这个阶段主要是建立一个测试管理的流程和机制,并没有接触到自动化测试。    随着项目的进一步扩大,逐渐增长到5-10人的团队规模,这时测试工作量突然增加,可能会有专门的测试人员进来,这个测试人员就会去和开发人员进行串联,把需求转化成自动化测试的用例,搭建持续集成,逐步演进一些测试手段。这个阶段已经开始做一些自动化的尝试。    团队进一步增大,一个人可能搞不定工作量的时候,会招聘更多的测试人员,成立专门的测试团队,这个团队就从自动化测试转向测试自动化,把更多的管理工作做进来。在这个管理过程中,我们会做一些产品的对接,包括开发专门的工具,实现自动化的整体能力,不仅仅是自动化执行了。     经过上面几个演进周期之后,测试团队具备了很多的测试自动化经验,这个时候可以进行面向云化的转型,现在很多团队都在进行DevOps转型,最关心的方面就是组建DevOps的全功能团队。那么之前转型的这些人在做什么?原有10-15人的测试专项团队做什么?在这个阶段团队要把测试专项能力向服务化能力转型。这时候测试专员就会在团队创建初期进行赋能,包括测试工程搭建,早期的测试用例怎么写,标准化模板的编制,针对非功能性测试的专项能力的赋能,所有团队进行测试流程的评审,包括测试策略、测试计划、测试用例的评审,再看一下整个团队里面流程上还有哪些改进的。从各个方面整个专项测试团队向服务化进行转型,帮助所有团队完成自动化转型。 自动化测试和测试自动化    这里要澄清一个概念,就是测试自动化(TestAutomation)。测试自动化的目的是减少手工测试和手工操作。测试自动化不仅仅包括自动化测试执行(AutomatedTesting),还包括其他所有可以减人力投入的活动,例如自动化创建测试环境、自动化部署被测系统、自动化监控、自动化数据分析等。很多自动化测试只是测试的执行部分,例如把一些测试执行的人工测试手段做成自动化测试,但是测试自动化不仅仅是只是执行,还包括了从环境的获取到生成测试数据、执行自动化测试,最终生成结果。如果有问题,会自动推送给相关的人,对应的组织解决。自动生成测试报告,测试人员直接拿到测试结果。    华为云DevCloud云测    华为云DevCloud云测是面向软件开发者提供一站覆盖测试计划、测试设计、测试执行、测试度量分析的端到端全生命周期测试平台。测试仪表盘和丰富的开箱即用和自定义报表实时统计测试进展和产品质量,保障团队高效透明协作。测试需求、测试用例/套件、缺陷、测试结果数据相互关联,记录修改历史,避免漏测、误测,易追溯审计,规范测试流程。接口测试基于接口URL或Swagger文档快速编排接口,支持测试关键字、响应提取、环境参数、动态参数、逻辑编排等高级特性,简化接口级测试难度,集成流水线,支持微服务测试、分层自动化测试。华为云性能测试服务全新界面风格,JMeter原生和自研双引擎,提供百万级并发的私有集群,支持混合云压测、流媒体协议、游戏高峰等场景。针对自动化测试类型种类丰富,用户遗留测试系统多的现状,云测将开放TestHub测试平台,支持用户自定义扩展集成。了解DevCloud云测 https://www.huaweicloud.com/product/cloudtest.html
  • [技术干货] 【DevCloud · 敏捷智库】软件开发团队如何管理琐碎、突发性任务(内附下载材料)
    作者 黄隽 Charlie背景开发团队如何管理琐碎、突发性工作?企业的一些软件开发团队经常出现类似培训支撑等突发性工作,开发团队不清楚如何管理好类似客户培训这样的突发性支撑工作。解决突发性工作的问题被很多开发团队所重视,它直接影响开发团队工作的进度和速率,间接着影响迭代目标是否能完成,甚至整个项目的成败。所以降低或解决突发性工作对开发团队的干扰非常重要。问题分析一种情况,支撑工作与开发工作混合,没有明显的优先级,来了新的支撑任务需要随时接受和完成。从管理上来说,这些突发的琐碎任务和开发任务同时管理增加了很大的难度。另一种情况,开发团队正常进行开发工作的时候,客户经常会提出一些干扰开发团队冲突任务。而且突发性的工作是由客户重点提出并需要优先处理的,所以开发团队经常会额外付出工作量去处理,造成迭代目标不能达成的风险。开发团队主要想解决如何处理琐碎、突发性的支撑工作,如何提高工作效率的问题。我们先将情况大致分类如下表:        类 型           特   点                                                          分       析          一支撑工作与开发工作混合,出现突发性工作是常态。支撑的工作和正常的开发工作混合在一起,开发人员会经常临时切换工作内容,难免会对管理增加难度,频繁切换工作内容也会造成时间的浪费,因为开发人员需要梳理新工作,新工作完成后还要继续回想之前的工作做到了哪里。因此,问题的根源在于开发团队模式上,在此模式下需要考虑时刻应对问题、风险。         二开发工作为主,伴随着出现突发性应急工作,也就是正常的需求变更。有了新的应急工作,开发团队成员不知道怎么应对,什么时候去接受这个工作,谁来决定是否要做,谁去做,没有一个公开、透明的规则。没有一个可以承载这些新工作的地方。问题的根源在于如何管理好Backlog。再进一步理解,当有新的工作项加进来时,如何更新Backlog,也就是我们常说的有了需求变更(临时增加任务也算需求变更)怎么办?解决措施敏捷方式是趋势,越来越多的开发团队开始接触和使用,DevCloud产品也是基于敏捷思维设计的,以下内容均以敏捷方式叙述,包括但不限于Scrum框架。类型一,可以从人员分工角度思考,建议开发团队人员最好有工作侧重点的划分。一部分人员精力用于开发,另一部分人员侧重于应对突发工作。应对突发工作的人员时刻准备着问题风险的对应(比如开发工作尽量领取简单、松耦合的)。应对开发工作的人员专心完成开发内容。不管工作分工是哪种类型的开发团队,再有新的工作进来时,都需要遵循开发团队制定的规则,也就是管理好工作项的规则。类型二,是我们很多开发团队中经常遇见过的,也是本解决方案着重描述术的情况。从根本解决工作项优先级的问题,系统地学习怎么样应对需求变更才是根本。解决方案思路我们知道了管理好工作项是解决问题的核心,那么在形成工作项之前,我们需要解决谁对工作项负责或者说工作项来源的问题,然后要针对工作项做好工作计划,这样开发团队才能很好的执行。首先,明确产品经理,做到需求来源唯一。其次,梳理产品待办列表,高优先级的工作项先做。然后,重新定计划,确保开发团队容量适合,合理更新迭代目标。再然后,回顾总结,选出改善点,下个迭代做得更好。最后,几个迭代下来,度量分析,不断改善。另外,同步需要进行的是人才的培养,向跨职能型团队努力。解决方案思路示意图如下:  明确需求责任人明确需求责任人,做到需求来源唯一。在DevCloud中一般指产品经理充当这个角色。需求责任人至少同时要面对两个方向。方向一,需求责任人必须很好地理解项目中的利益干系人、客户和用户的需要(包括前面提到的突发工作项)及其优先级,以便能充当他们的代言人。从这个角度理解,一般是产品经理充当需求责任人。方向二,需求责任人必须与开发团队交流要构建的特性及其构建顺序。需求责任人还必须保证特性的接收标准已有明确说明,让开发团队可以确定在什么情况下需求责任人可以认为特性完成了。在这个角度理解,一般是业务分析人员和测试人员的角色。同时,需求责任人还要在版本、迭代和Backlog层面都能够持续做出良好的经济决策,管理经济效益。为了统一叫法、便于理解,后面需求责任人都由产品经理充当(类似Scrum框架中的产品负责人)。总结一下,产品经理的主要职责如下图所示:图中标亮部分的产品经理职责就与迭代中对应这些突发性工作相关了。产品经理需要与利益干系人充分沟通,确定这些突发的工作优先级别,同时从业务价值和管理经济效益等维度考虑,明确是否一定要在本迭代中完成。一旦确定这些突发工作属于高优先级,必须在本迭代中完成,那就需要重新梳理工作项了。梳理Backlog梳理Backlog,高优先级的Backlog放到迭代待办列表即迭代中(更多关于迭代待办列表的内容请参考下面的“了解更多”)中先做。首先,我们一起先来了解一下什么是Backlog。Backlog是一个按优先顺序排列的、预期产品功能的列表。其次,再来理解一下什么是工作项。工作项是Backlog中的待办事项。对用户和客户来说,大多数的工作项都是有实际价值的特性和功能,当然也包括一些需要缺陷修复、技术改进、知识获取等工作以及产品负责人认为有价值的任何工作(当然有价值的突发性工作也属于工作项)。然后,什么是梳理?梳理是指三大重要活动。第一,确立并细化工作项;第二,对工作项进行估算;第三,为工作项排列优先顺序。下图说明了通过梳理活动改变Backlog的结构:梳理后,对应DevCloud中的体现,如DevCloud梳理活动结果图所示。经过产品经理梳理后,如图红色框线部分,突发培训任务的工作项得到了合理的优先级,而且是经过工作量估算,同时将原来的查询产品名称任务进行了拆分细化。产品经理是梳理活动的最终决策者,也就是说突发性的工作由产品经理主导梳理。优秀的产品经理能够充分协调利益干系人安排足够的时间,根据开发团队的特点和项目类型来开展梳理活动。同时开发团队还要估算新加入突发工作的工作量,帮助产品经理根据技术依赖关系和资源约束来排列工作项的优先顺序,如果新加入突发性培训任务的工作项优先级高,那么就会纳入本迭代代办列表中。 重新定计划重新定计划,确保开发团队容量适合,合理更新迭代目标。在重新定计划之前,我们一起来了解下什么是敏捷下的计划,敏捷提倡的计划和传统瀑布开发模式下的计划有什么区别。我们知道敏捷宣言中提倡“响应变化高于遵循计划。”,它与传统瀑布开发模式或者说计划驱动的顺序开发模式的计划不同点就是一个是偏向响应变化,一个是偏向遵循计划。顺序开发过程中,是计划驱动,计划是工作如何开展、何时进行的权威信息源。因此,计划是需要遵循的。相比之下,在敏捷中,根据实时信息关注适应重新制定计划胜于遵循计划。我们认为盲目的相信计划往往会让我们忽视“计划可能有错”这个事实。敏捷开发过程中,我们的目标不是满足某个计划或者某个事先认为事情如何进展的预言。相反,我们的目标是快速地重新制定计划并根据开发过程中不断出现的、具有重要经济价值的信息进行调整。因此,通过梳理以后的工作项,可以对应的调整计划。原计划准备做的工作项可能被移入到下一个迭代中实现,这里体现的是“等价交换原则”,意思是用优先级高的突发性工作项,替掉同等工作量的其它工作项,这也是为了保开发团队按照一个稳定的节奏交付。因为固定的开发团队一个迭代中容量是不变的,新加入突发工作项而不移除其它工作项势必会给开发团队交付带来压力,破坏开发团队的交付节奏。等价交换示意图如下:具体在DevCloud中的体现,如【等价交换图一】和【等价交换图二】所示。                                                                                           【等价交换图一】                                                                                        【等价交换图二】最后,从迭代中选取差不多工作量的低优先级工作项移回到Backlog中,即在DevCloud中完成了工作项的等价交换。 迭代回顾,识别改善点迭代回顾是一个会议,目标是持续改进流程,根据开发团队的需要改进和制定流程,以提高士气,提高效率,提高工作产出速率。几个迭代下来,需要对这类突发工作进行度量分析,识别改善点,持续改善。虽然我们提倡响应变化高于遵循计划,但同时执行迭代的时候也需要开发团队在不受干扰的情况下全力以赴的迭代。因此,就应该思考为什么每个迭代中都有外界的干扰(突发工作)存在,开发团队共同学会分析和找到解决办法才是真正的解决问题之道。这里给出一个DevCloud产品很好的小实践,可以提供客观数据帮助回顾。新纳入迭代待办列表的突发性工作项可以在DevCould的“模块”下进行管理。也就是说,在新建User Story之前建立一个“突发任务”模块,然后将User Story中的“模块”属性选中它。这是为了在后续几个迭代中对这类突发性工作进行度量分析(可以按模块排序,方便度量分析)以便持续改善做准备。如下【新建突发模块图】和【新建User Story图】所示:                                                                                        【新建突发模块图】                                                                                               【 新建User Story图】选择【报表】—【新建报表】—【自定义报表—【增加筛选条件(模块)】—【按迭代维度】—【保存】。然后对统计出来的数据进行分析。可以以图和表两种方式展示,具体如【按图展示】和【按表展示】所示:                                                       【按图展示】                                                  【按表展示】 同步进行人才培养同步需要进行的是人才的培养,向跨职能型开发团队努力。不仅仅是应对处理突发性工作,而是让开发团队更高效。每个任务应该由谁来做,或者说突发性工作应该由谁来做?答案很明显,应该是能够最快且正确完成这个工作的人来做。如果这个人不在了怎么办?或者他正在做其他工作,抽不出时间,但这个任务需要马上完成。开发团队成员都有责任考虑各种不确定因素,做出最好的选择。如果开发团队成员都是T型技能的时候,每个任务都有好几个人可以做,那么开发团队就能够在迭代执行期间几个人全力完成制约工作项流程的任务,更灵活地平衡资源,使开发团队更高效。了解更多什么是迭代待办列表?迭代待办列表在DevCloud中称“迭代”,它是一组为当前迭代选出的产品待办列表项,同时加上交付产品增量和实现迭代目标的计划。迭代待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能能到“完成”的增量中所需要工作的预测。当新工作出现时,开发团队需要将其加入到迭代待办列表中去。随着工作的执行或完成,剩余的工作量被估算并更新。当计划中的某个部分失去开发意义,就可以将其移除。在迭代期间,只有开发团队可以改变迭代待办列表。迭代待办列表是高度可见的,是对开发团队计划在当前迭代内工作完成情况的实时反映,该列表由开发团队全权负责。迭代待办列表在迭代计划会议中形成,其中开发团队不会被动分配任务而是由开发团队成员主动认领他们擅长和喜爱的任务。任务被分解为以小时为单位,建议任务不要超过16个小时。如果一个任务超过16个小时,那么它就应该被进一步分解。每项任务信息包括其负责人、工作量、承诺的完成时间及其在迭代中任意一天的剩余工作量,且仅开发团队有权改变其内容。参考附录1、Kenneth S. Rubin. Scrum精髓[M].北京:清华大学出版社。2、Scrum 指南2007版。 3、Mark C. Layton. 敏捷项目管理[M].北京:人民邮电出版社。----------------------------------------------作者随笔作为敏捷推广者和马拉松爱好者,聊聊敏捷与马拉松。一个胖子想变成瘦子,方法很多,比如无氧器械、疯狂单车、要命波比跳,当然还有马拉松。近年来马拉松被炒得火热,引得大家蜂拥而至。马拉松看似简单,实际上一个优秀的跑者是需要长年的基础训练和日积月累的跑量。有些人参加拉松是为了赶时髦,全凭三分热度,急于求成。往往前者已达终点,后者却在半路怀疑人生,早早弃赛。敏捷转型就像马拉松一样:理论实践vs基础训练,稳定速率vs平稳配速,定期回顾vs适时补给,持续改善vs健康奔跑,团队稳定vs跑得长久,个人有所长,团队全功能vs个人跑得快,群体跑得远。如果没有夜以继日的“内功”修炼,想要一朝练成“碧海潮生曲”,无疑是天方夜谭,必以失败告终。—敏捷江湖桃花岛 黄药师附件:开发团队如何管理琐碎、突发性任务.pdf**** 本内容被作者隐藏 ****
  • [技术干货] 【DevCloud·敏捷智库】如何利用用户故事了解需求(内附下载材料)
    作者:黄隽(Charlie)背景很多团队在应用敏捷开发时,对估算经常感到困惑。这里所说的估算是指产品列表条目(PBI, Product Backlog Item)的估算 。比如,估算以什么标准进行?开发、测试的工作量都要估算进去吗?又比如,估算出了预计工时,但是实际工作中这个预计工时经常不准,为什么还要估算这个预计工时呢?还有,做估算管理时,实际工时也会经常被使用,但很多团队成员不按实际情况做实际工时的更新,它的意义何在?问题分析为什么做估算呢?在规划和管理产品开发过程中,我们需要回答一些重要的问题,例如:“将要完成多少个特性?”“我们什么时候做完?”在使用敏捷时,为了能回答这些问题,我们需要估算产品的工作量大小并测算工作速率。有了这些信息,用特性集的估值除以团队速率,我们就能推算出产品开发的持续周期了。从小目标来讲,做好了估算也可以很好的理解需求,帮助团队成员认领任务。换句话说,团队成员通过估算过程(持续沟通、确认)达成对需求的理解一致,明确完成定义是最重要的。团队之所以做不好估算,首先是因为没有足够细化需求,更不了解敏捷估算的几个重要核心概念 ,即:“团队估算”、“估算不是承诺”、“要准确,而不是精确”和“使用相对值,而不是绝对值”。其次是不了解估算的正确方法 。这篇文章主要解决因为不能很好地理解需求而估算做不好的问题,在这里可以了解下如何利用用户故事了解需求。解决措施估算有这么些重要的意义,以下关于估算的内容是针对认可估算有意义,但是做不好的情况下给予的估算解决方案。如何更清楚的了解和细化需求是第一步,细化需求和估算是一对儿不能拆分的“鸳鸯”。然后再学习准确的估算,解决估算的各种困惑。要想准确的估算,先要了解和细化需求,同时了解需求很好的一种描述方法,即User Story。然后了解故事点以及什么是估算及估算的核心概念。基于以上了解后再研究估算方法的实践,最后选择适合的估算方法完成估算活动。可以参考如下示意图便于理解。本篇主要介绍如何了解和细化需求,后面几篇会分别介绍估算核心概念、故事点、估算实践方法和完成估算等内容,即:《如何估算第一篇:利用用户故事了解需求》、《如何估算第二篇:估算的核心》、《如何估算第三篇:估算故事点》和《如何估算第四篇:常见估算方法》。如何了解和细化需求,要先从用户故事开始聊起。什么是用户故事?用户故事是可用于陈述业务价值的一种简便格式,适合各种PBI,特别是特性。用户故事的制作方式旨在帮助业务人员和技术人员双方都能更好的理解需求。一个编写良好的用户故事是敏捷开发的基础。编写用户故事的过程就是了解需求,一点点细化需求的过程。需求了解清楚了,一定程度上讲估算的工作就已经完成了一大半,在不了解需求的情况下,估算也是没有意义的。需求的了解是渐近明细的,很多情况下用户的角度看是一种情况,开发人员角度看是另一种情况,这种误解在需求了解阶段经常出现,如下图。理解需求误区图我们一起看看,为什么说用户故事写好了就了解需求了呢?一个良好的用户故事应该是相对独立的、详情应该是便于开发者和用户沟通的、应该对用户是有价值的、应该对于开发者来说尽可能的清晰以便进行估算的、应该短小的、通过预定义测试用例的使用确保它是可以测试的。以上的特点具备了,相信写出来的用户故事是在了解了用户最初的需求基础之上。其实,这些特点有一个名称“INVEST原则”,是极限编程(英语简写XP,是敏捷开发方法之一)中对用户故事拆分的指导原则。INVEST原则用于评估用户故事,也就是说,好的用户故事应该具备INVEST特性:即独立的(Independent)、可协商的(Negotiable)、有价值的(Valuable)、可估算的(Estimatable)、大小适合的(Small)和可测试的(Testable)。用户故事究竟是什么呢,如何才能写好用户故事?极限编程(XP)的创始人之一Ron Jeffries给出一个简单有效的方法来帮助我们理解用户故事。他将它描述为3C:卡片、会话和确认。了解了3C也就大概清楚了怎么样才能写好一个用户故事,以及为工作量估算做好基础准备工作。 卡片卡片非常简单,最初可以写在便利贴上,有一个通用的格式,如下面用户故事模板图,即写明用户种类(即用户角色)、这类用户想要达成什么(目标)以及用户为什么想达成目标(收益)。用户故事标题的命名也是有讲究的,在辅导团队过程中发现有些团队的用户故事名称不统一,容易对团队造成困扰。例如,有的名称太长,甚至是长长的一段话;有的太短,不能清晰的识别用户核心内容是什么;有的没有价值,就是普通的任务(Task)。建议采用统一的动宾短语写出较好的用户故事标题:用户角度描述从用户角度看到的功能。例如,查看详细信息、新增查询、删除货品等。系统角度描述从待开发的系统的角度要实现的功能。例如,推送合同信息、发送用户订阅信息等。当然,你也许会有个疑问。这些标题都没有主语,好像也不太能快速识别用户故事的核心内容。Of course,如果你想更清楚表达,也是可以加上主语的。比如,新注册用户查看详细信息、库存管理员查询商品号、HR系统群发助手发送订阅信息等。不过,更想说的是,更详细的信息建议在卡片内容中说明,因为里面写明了用户种类(即用户角色)、这类用户想要达成什么(目标)以及用户为什么想达成目标(收益)。用户故事标题还是以简单、明了为主。用户故事卡片模板图 对话在对话中讨论需求细节。开发团队、产品负责人(PO, Product Owner)利益干系人在对话中发现并探讨需求的细节。用户故事仅仅是进行此对话的承诺。用户故事的一大好处就是它能把关注点从写作转移到会话。对话开启了一个更丰富的信息交换与协作形式,从而确保正确描述需求并使每个人都能理解需求。对话不仅仅是靠口头交流,还可以而且经常借助于文档,也可得出可以记下来的一张用户界面草图或业务规则的一份详细阐述。 确认用户故事还要包含确认信息,也就是我们常说的接收标准(AC, Acceptance Criteria)。有了接收标准,开发团队才更清楚要构建和测试什么,产品负责人也可以确认用户故事的实现是否符合预期。这些定义的接收标准也可以看作是高一级的接收测试。当然,开发故事的时候不会只有这几个测试,这些与故事挂钩的接收测试之所以存在,是因为从产品负责人的角度看,它们是捕获及沟通信息、确定故事是否已经正确实现的重要方式之一。我们了解了用户故事和它的3C原则,现在来看看怎么写一个好的用户故事,来更好地分析和理解需求。我们知道了用户故事的模板内容,看着非常简单,然而越简单的东西,反而越容易让人放松警惕,然后照着模板内容写出来的并不是一个很好的能够理解需求的故事。举例,一个餐饮点评网站的用户故事可能会这样写:作为一个用户,我希望看到某个地址附近的餐馆的公正的评论,这样可以决定去哪里吃饭。其实,这就是一个典型的质量不高的用户故事。写出高质量的用户故事的关键在于是否能够准确地描述用户希望获取的价值。这个观点只对了一部分,就像上面的故事一样。大家可能会问,既然用户希望获取的价值都描述清楚了,为什么客户还不接受呢?主要原因是你高估了自己的理解能力和表达能力,同时也高估了客户的理解能力和表达能力。如上面提到过的理解需求误区图,客户的角度看需求是“6”,需求调研人员角度理解的是“9”,这也是常见的需求理解问题。再来看另外一个例子:作为一个在国贸工作,午休时间短,又追求健康饮食的公司白领,我希望看到某个地址附近的餐馆的客观的评论,这样可以决定去哪里吃饭。可见,第二个故事中,感觉好多了。仔细看看差在哪里呢?熟悉需求调研的伙伴儿们都知道,需求调研是从了解客户是谁开始的,需要弄清楚产品需要获得什么样的客户的认可和接受,利用“对话”原则,充分沟通。这个故事描述了用户的特征,站在用户角度思考,更能够提升最终交付物为客户接受的可能性。同时,还要定义清楚什么是“接收标准”,与客户确认清楚具体的条件。这个故事的接收标准可以参考接收标准参考内容图:接收标准参考内容图现在可以了解怎么写好用户故事,以及如何更好地理解客户需求了。对需求有了更好的理解,接下来需要再了解一下估算的核心,《估算第二篇:估算的核心》以便更好地完成估算。参考附录1. Kenneth S. Rubin. Scrum精髓[M].北京:清华大学出版社。2. Mark C. Layton. 敏捷项目管理[M].北京:人民邮电出版社。----------------------------------------------作者随笔作为敏捷推广者和马拉松爱好者,聊聊敏捷与马拉松。一个胖子想变成瘦子,方法很多,比如无氧器械、疯狂单车、要命波比跳,当然还有马拉松。近年来马拉松被炒得火热,引得大家蜂拥而至。马拉松看似简单,实际上一个优秀的跑者是需要长年的基础训练和日积月累的跑量。有些人参加拉松是为了赶时髦,全凭三分热度,急于求成。往往前者已达终点,后者却在半路怀疑人生,早早弃赛。敏捷转型就像马拉松一样:理论实践vs基础训练,稳定速率vs平稳配速,定期回顾vs适时补给,持续改善vs健康奔跑,团队稳定vs跑得长久,个人有所长,团队全功能vs个人跑得快,群体跑得远。如果没有夜以继日的“内功”修炼,想要一朝练成“碧海潮生曲”,无疑是天方夜谭,必以失败告终。—敏捷江湖桃花岛 黄药师附件:如何估算第一篇:利用用户故事了解需求V1.0.pdf**** 本内容被作者隐藏 ****
  • [技术干货] 【DevCloud · 敏捷智库】项目团队人员变动频繁,如何对新人进行有效培养和管理?
    背景在华为云专家团队拜访某企业时,遇到了这样的一个问题,随着业务的扩张,新员工不断加入,其开发组长要对每一位新人交代相关的知识点、工作方式以及团队信息等,工作量在短期内激增……在一个项目中,随着时间推移、业务的扩张,项目中的核心成员,如项目经理、开发组长等往往都会面临如下几种情况和挑战:新员工加入,需要诸多方面的培养(培训),以便能快速进入工作状态。 老员工的离职,导致项目中缺少能了解和掌握关键技术和业务的人员。员工在工作了一段时间后,对自己的规划有了新的想法,从而想要转换工作方向。那么,项目负责人应该如何应对这些事件呢?问题分析一个项目在从小到大的过程中,项目团队也势必扩张,面临新员工的加入。新员工对刚接触的项目不够熟悉,所以针对新员工的培养(培训)是非常有必要投入人员配置的。项目发展过渡到平稳期的时候,可能会因为公司体质、薪资待遇、员工身心疲惫等原因,出现老员工的离职等情况,如果离职的老员工是核心骨干,就可能导致某些如业务无人知晓、关键技术断层等风险,当然在此期间,也包括老员工随着项目的延续,慢慢产生了对原来工作厌倦,或者因认知的提升以想要寻求一些新的工作内容,进而做了转型的打算。所以上述问题,如果没有得到较好的解决,将会影响到项目的进度和造成不必要的开销,甚至对于团队内部成长、自组织能力的发展建设也是不利的。所以问题的关键,仍旧是新人的培养。解决措施一般来说,在针对新员工加入所带来的内耗、关键核心人员的离职风险、个人发展转型等情况的应对,可以从团队信息、工作方式以及知识管理三方面来通过建立信息管理库进行解决。DevCloud是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台(更多了解请见附件或官网),也是笔者目前在使用的。以DevCloud为例,在DevCloud中提供了Wiki服务。Wiki本身是一种以知识库文档为中心,共同创作为手段,依靠众人不断地更新修改为实现的多人协作的工具。我们可以通过Wiki来管理和搭建项目或团队内的信息管理库,以达到有知识点可留存,有基本信息可查的目的,参考如下:团队信息用来记录项目团队的职能划分,职责担当等。当新人入职时,可以通过在Wiki中的团队信息,了解团队的组织分工等。这样一方面可以让新员工对团队人员分工有所了解方便日后的交流,另一方面也能让具备较高能力的新员工根据团队组织分工现状提出改善意见等。工作方式团队需要制定团队内的工作方式,如对开发流程、代码的管理、需求的变更等,团队统一按照要求进行工作。当有新员工加入,可以通过Wiki中的工作方式,了解相关流程等进而快速开展工作,同时也减轻了老员工在工作方式上对新员工的培训所带来的消耗。知识管理知识管理对于项目和团队是最重要的,大部分的产品都需要技术相关的输出整理,无论是基于现有项目进行维护,还是重构,开发新的应用,做知识整理都是不可或缺的。这种必要性在于,当新员工加入后,可以通过知识管理的学习了解项目所用技术框架,进而快速上手工作;当老员工离职,团队因有了Wiki对技术、框架、业务等知识的相关管理,可以较好的应对离职所带来没有backup、没有其他人懂某项技术、没有其他人知道某段业务逻辑等带来的影响;当员工内部转岗或转变业务技术方向时,可以帮助其相关知识,有助于更好的帮助提升跨专业技能。更多关于Wiki的相关内容请参见,参考附录。参考附录Wiki网站:维基百科DevCloud使用指南:DevCloud Wiki使用指南关联文章项目团队人员变动频繁,如何对新人进行有效培养和管理?
  • [技术干货] 【测试微课堂】DevOps敏捷测试之道
    【测试微课堂】共6期,此篇为第1期。本文介绍企业在敏捷和DevOps的逐步转型过程中,测试如何应对挑战,有的放矢进行测试,建立适合产品自身发展阶段、产品特点的敏捷测试能力。敏捷和DevOps敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈,新商业模式的创新和变现时间窗口越来越短,催生更多的企业采取精益创业的方式,捕捉市场需求后,尽量缩短TTM产品面世时间,快速推出MVP产品并快速响应客户需求迭代产品。以华为为例,在2008年左右的时候,华为的项目还是采用传统的交付方式,例如在年初开始一个项目,在项目立项之初就会把客户的需求全部收集好,包括一些用户的反馈,并把需求做了全年的排序。年中的时候发布产品给用户,两个月之后再出一个补丁,最终年底出一个正式的版本。当时版本交付的节奏还是比较慢的,但是对质量要求比较强。因为产品发布给客户以后,下一个补丁需要两个月,如果用户在这个期间发现产品问题,他们只能再等两个月,而在这期间如果用户不接受我们的产品,会导致项目前功尽弃,所以就对产品的质量有严格的要求。产品逐渐向敏捷方向发展,这时有一部分研发工具平台已经陆续转到云上去了,一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次,转型之后变成一个月,甚至两周发一次,但这时的转变并不彻底,与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型,这个时候一些商业模式发生了根本性的变化,也就是说当需求上云了以后,用户更加快速的介入进来。基于云平台,把一些功能快速的开发出来,然后频繁的和用户去商量,听取客户意见,牵引产品做快速迭代,这种交付方法使得交付周期一下变快了,之前是半年交付一次,现在是一周、两周,更有甚者,可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化,基本做到了小步快跑,快速试错。测试债务    从瀑布到敏捷再到DevOps,在开发和测试生产率和需求交付效率提升的过程中,不同的组织或多或少面临一些积压问题没有解决,影响测试能力和测试价值的持续提升。•    从对测试的重视程度上看,有的公司存在重开发、轻测试的情况,测试人员职业发展受限;手工测试人员不熟悉编程,开发人员对测试重视不足;测试工作量高,但人员配比低。•    从部门组织和流程和文化上看,测试人员对需求理解不足,测试和开发之间的部门墙导致信息不透明、沟通协作滞后和不足,质量向速度过分妥协,以及忽视敏捷文化和价值观的培养塑造。•    从测试和产品技术和方法上看,产品耦合度高、可测试性差,测试过于依赖黑盒功能测试,测试策略、方法不恰当,测试环境部署时间长,频繁升级等。测试的焦点:业务价值的质量    测试首先就是一个质量活动,做测试就是要保证质量,其次是一个工程性的活动,即在有限的时间、人力、资源投入内获得尽可能大的产出价值。质量有多个维度,需要有一个焦点,就是业务价值的质量,也就是产品“对客户呈现的价值”的质量。测试围绕业务价值去做,确定质量在功能、安全性、性能、易用性、兼容性等多个维度上的权重和优先级,而不是说一个测试上来之后,就把测试相关的关系点、关联点全部做测试。    让我们来看几个例子:例如现在正在做一个线上支付的功能,对这个功能最关心的方面肯定是安全,所以相关的测试用例关键点就应该围绕安全大做文章,一定把安全保证好。再比如,现在要做一个线上商城,面向用户是老百姓,不仅要让年轻人会用,也要让老人都会用,那么就要关注易用性。除此之外,电商举办大规模抢购促销活动,那就还需要关注性能。所以测试要求瞄准了产品本身的业务价值,确定产品的目标,相应的制定质量关键点,制订相关的测试策略,然后实践落地。落地之后还要基于一些不良的效果不断的进行反馈、循环,校验整体的测试过程是否达到预期结果,这就是我们的测试焦点。 自动化测试金字塔    自动化测试金字塔最早是由MikeCohn在2009年的著作《Succeeding withAgile: Software Development using Scrum 》(《Scrum敏捷软件开发》)中提出。最早提出来的时候是一个三层的金字塔,从上到下分别是UI界面/Service服务/Unit单元测试,随着敏捷测试的不断推进,测试金字塔出现一些变种。实际使用中不用太拘泥于每层的名字,在服务化软件架构中Service层也可以理解为 API测试。    这种下宽上窄的三角形结构,代表在各层自动化的建议投入分配比例,越接近底层的单元测试建议的投入最多,接口测试居中,界面层建议的投入最少。    MartinFlower关于测试金字塔有这样一段评论。“GUI测试用例还很脆弱,如对系统的一些修正可能导致很多用例的失败,这时候你需要重新录制。你可以放弃录制的方法来解决这个问题,通过写GUI测试代码,但是这样效率非常低。就算你已经很精通了GUI测试代码的编写,端到端的GUI测试用例也很容易出现不可预期结果的问题-一些用例成功一些用例失败,因此,基于GUI的自动化测试是脆弱、耗时(包括用例维护和执行)的。所以测试金字塔要表达的是:底层应当有更多的单元测试和接口测试和逻辑测试,GUI测试用例能覆盖到主业务流程即可。”    测试金字塔中每层中涉及的测试技术均有自己的优势和局限性,由于上层GUI测试的脆弱(不稳定性)、耗时(执行效率)问题,以及问题表现位置(UI)和问题根因位置(代码)距离太远的问题,测试金字塔由关注测试数量转向关注测试质量,推荐增加底层的测试投入。•      层次越靠上,运行效率越低,延缓持续集成的构建-反馈循环•      层次越靠上,开发复杂度越高,如果团队能力受限,交付进度受影响•      端到端测试更容易遇到测试结果的不确定性•      层次越靠下,单元隔离性越强,定位分析问题越容易    原则上单元测试需要开发人员承担,很多团队中开发人手不足,优先保障功能的实现,在单元测试的投入不够,并且很多开发人员的单元测试经验不足,导致很多团队中不做单元测试或者被动执行流于形式,有人提出了金字塔结构的反模式:蛋筒冰激凌模式和纸杯蛋糕模式。常规安全与弹性安全    在我们常规的设想中,通常是哪个地方不安全,就一定要把所有不安全的因素找出来,清除掉。这是常规的做法,但却偏向于理想,在实际工作中是不可能把整个系统中不安全的因子全部识别到的,这其中涉及能力、架构等各方面的原因。    因而在此基础上演变出了弹性安全,就是通过场景模拟的方式将不安全因素尽量展现出来,从而基于这种不安全场景,给出快速的修复方案弥补这个不安全因素,从用户角度来讲是感知不到的。从产品来讲,它的商业目的和质量目的都可以达到,这就是所谓的弹性安全,即便发生了错误,能够及时快速的修复漏洞或者自我修复,达到正常工作的目的。测试左移和测试右移    左移就是前移,尽量把活动向前移。例如BDD行为开发,基于场景直接设计出符合这个场景的用例,来匹配这个设计;契约测试,服务和服务本身之间有耦合,我们可以通过契约测试解耦,以防导致问题。    测试右移是指要把测试活动的覆盖范围尽量向后蔓延。通常的测试只进行到了版本发布之前,测好之后发布一个软件包,而测试右移要把软件包发布到生产环境,以及到线上运营环节,都要去做测试。    在这两个方面也有一些相应的实践实践,例如线上拨测,主动线上监控用户的一些行为,并从行为轨迹里面快速捕捉相应的问题,主动推送给相关的责任人,让他去关注并且解决。所以线上的过程可以通过一些测试手段,不断的反馈给真正的开发人员,让他知道当前产品的整体表现,开发人员就会快速的针对产品作出应对方案。产品发展不同时期的测试策略    是否这个团队组建之初,就要把整个自动化测试的能力构建起来呢?其实这有一个过程,下面从软件的成熟周期的角度,看一下如何构建测试自动化的能力。在软件初期探索阶段,产品是一个不确定的状态,从前端的风格和整体的布局到后端的API都时刻在变化当中,而且变化比较频繁,因为自动化用例的生命周期比较短,所以在这个时候创建一些自动化测试用例是不太划算的。而这个时间段的产品,往往特性是可控制的,只有几个测试,所以可以以手动为主,不考虑自动化,让产品能够快速识别错误点,让用户能用起来。    到了产品扩张阶段,用户认可产品,这时候会出现两个现象。第一是用户量增长,第二是需求数量增长。这时候必须要考虑自动化。因为在这个阶段每一次迭代的全量验证成本会越来越大,而交付的速度也会越来越快。我们不可能每一轮上线的时候都全部用手工做测试,这时候旧的模块就需要自动化用例去保证。到产品提取阶段,产品已经到了需求的饱和期,产品的利益增长也到了饱和期,这时候要严格控制产品需求,自动化用例的职责变成守护,不允许变动引入额外的风险点、大的特性变动,导致对成熟的用户造成攻击。  团队规模对测试建设的影响    当团队规模在5个人以下,团队处于探索阶段,这时质量活动可以仅仅局限于测试的自组织阶段,只是做一些基础类测试管理活动,把缺陷管理起来,做一些回归测试。在这个阶段主要是建立一个测试管理的流程和机制,并没有接触到自动化测试。    随着项目的进一步扩大,逐渐增长到5-10人的团队规模,这时测试工作量突然增加,可能会有专门的测试人员进来,这个测试人员就会去和开发人员进行串联,把需求转化成自动化测试的用例,搭建持续集成,逐步演进一些测试手段。这个阶段已经开始做一些自动化的尝试。    团队进一步增大,一个人可能搞不定工作量的时候,会招聘更多的测试人员,成立专门的测试团队,这个团队就从自动化测试转向测试自动化,把更多的管理工作做进来。在这个管理过程中,我们会做一些产品的对接,包括开发专门的工具,实现自动化的整体能力,不仅仅是自动化执行了。     经过上面几个演进周期之后,测试团队具备了很多的测试自动化经验,这个时候可以进行面向云化的转型,现在很多团队都在进行DevOps转型,最关心的方面就是组建DevOps的全功能团队。那么之前转型的这些人在做什么?原有10-15人的测试专项团队做什么?在这个阶段团队要把测试专项能力向服务化能力转型。这时候测试专员就会在团队创建初期进行赋能,包括测试工程搭建,早期的测试用例怎么写,标准化模板的编制,针对非功能性测试的专项能力的赋能,所有团队进行测试流程的评审,包括测试策略、测试计划、测试用例的评审,再看一下整个团队里面流程上还有哪些改进的。从各个方面整个专项测试团队向服务化进行转型,帮助所有团队完成自动化转型。 自动化测试和测试自动化    这里要澄清一个概念,就是测试自动化(TestAutomation)。测试自动化的目的是减少手工测试和手工操作。测试自动化不仅仅包括自动化测试执行(AutomatedTesting),还包括其他所有可以减人力投入的活动,例如自动化创建测试环境、自动化部署被测系统、自动化监控、自动化数据分析等。很多自动化测试只是测试的执行部分,例如把一些测试执行的人工测试手段做成自动化测试,但是测试自动化不仅仅是只是执行,还包括了从环境的获取到生成测试数据、执行自动化测试,最终生成结果。如果有问题,会自动推送给相关的人,对应的组织解决。自动生成测试报告,测试人员直接拿到测试结果。    华为云DevCloud云测    华为云DevCloud云测是面向软件开发者提供一站覆盖测试计划、测试设计、测试执行、测试度量分析的端到端全生命周期测试平台。测试仪表盘和丰富的开箱即用和自定义报表实时统计测试进展和产品质量,保障团队高效透明协作。测试需求、测试用例/套件、缺陷、测试结果数据相互关联,记录修改历史,避免漏测、误测,易追溯审计,规范测试流程。接口测试基于接口URL或Swagger文档快速编排接口,支持测试关键字、响应提取、环境参数、动态参数、逻辑编排等高级特性,简化接口级测试难度,集成流水线,支持微服务测试、分层自动化测试。华为云性能测试服务全新界面风格,JMeter原生和自研双引擎,提供百万级并发的私有集群,支持混合云压测、流媒体协议、游戏高峰等场景。针对自动化测试类型种类丰富,用户遗留测试系统多的现状,云测将开放TestHub测试平台,支持用户自定义扩展集成。了解DevCloud云测 https://www.huaweicloud.com/product/cloudtest.html来源: 【测试微课堂】DevOps敏捷测试之道
  • [课程内容] “敏捷江湖桃花岛”侠客行项目基于华为云DevCloud服务课程介绍
    “敏捷江湖桃花岛”侠客行项目基于华为云DevCloud服务课程介绍课程概述:敏捷江湖桃花岛是侠客行项目,通过深入浅出的讲解,从棉花糖挑战认识现代软件工程的敏捷开发,帮助企业快速进行敏捷转型。本课程结合高校实际教学场景,从棉花糖挑战赛这个游戏,引出对现代软件工程的认识,从而引出敏捷及scrum开发的相关概念。 紧接着通过一个典型项目,分4个阶段分别就项目立项、产品规划、技术准备和Sprint开发进行了详细的介绍。结合实践项目,搭配软件开发云,帮助学生了解整个软件开发的开发过程。 从需求管理,项目管理,到代码开发、测试、代码托管、代码质量检查、编译构建、发布、部署、流水线等方面,了解敏捷开发的整体流程,为学生毕业后进入企业工作,提前做技术储备工作。材料数作业数实训项目迭代数需求任务数代码量7420430040k 作者介绍华为云教育,本课程由华为云教育内容开发团队开发完成,团队主要负责教育解决方案内容开发和建设。包括但不限于课件、视频、习题、代码、案例项目、实训课等。  课程定位:本课程知识点涵盖敏捷Scrum、前端、后端、Cloud四大开发方向,项目跨度涵盖整个大学所学知识的连接,适合于高年级的学生来学习实践。在学完本次课程之后,会对本课程中之前所学相关的Java、Javascript、Scala等语法知识更能融会贯通,由于本次实践为学生自行立项组队,其中多角色划分会让学生对企业中岗位职责有初步的认识,为将来求职面试及发展规划打好坚实基础。岗位及从业方向:岗位:项目经理、产品经理、Scrum Master、UI、前端开发工程师,后端开发工程师,架构开发工程师、测试工程师等岗位。从业方向:项目管理、UI设计、产品研发、软件开发、测试、运维等。 前/后导课程:本课程是一门实践课程,既要掌握概念,又要团队配合,还要上机编程运行。其前导课会覆盖之前所学全部知识内容,是所学知识的一次串联与总结,其中有《C语言实践教学精品课》、《Web实践教学精品课》、《数据结构(C语言)实践教学精品课》《JAVA-实践教学精品课》《系统分析与设计》等本课程的主要任务是:1.通过学习本课程,学生可以掌握基本的项目级软件开发的全过程。2.了解敏捷Scrum开发方法,在其中体会到团队协作的工作方式。3.具备初步的高级语言程序设计能力及项目开发的能力。4. 项目完成后,基本达到入职企业所需具备的软件开发职业素质。5.培养学生严肃,认真一丝不苟的工作作风。培养学生积极思考,通过团队中不同角色的深入,锻炼思维能力,培养创新能力。 本课程知识教学目标:        1. 了解程敏捷及Scrum的基本知识。2. 了解如何组建团队立项并展示。3. 了解产品规划及原型设计并展示。4. 掌握前端开发流程。5. 掌握后端开发流程。6. 掌握云上工具的使用。7. 掌握Scrum五大事件并按照流程展示。。8. 了解可视化管理。 教学大纲:从棉花糖挑战认识现代软件工程1)     通过游戏初探敏捷2)     敏捷的历史背景3)     敏捷思维4)     Scrum概述通过本章节的学习,学生可以:1)     了解敏捷的背景2)     掌握敏捷宣言及原则3)     理解什么Scrum框架 项目实战第一阶段:项目立项1)     如何立项2)     如何组建团队3)     团队立项展示通过本章节的学习,学生可以:1)     在Devcloud上创建项目并添加成员分工2)     团队讨论进行立项书的书写3)     团队进行立项书的展示,增强实践代入感 项目实战第二阶段:产品规划 1)     收集需求,进行需求管理2)     书写用户故事,生成产品待办列表3)     了解用户故事地图4)     了解MVP,进行产品版本规划5)     了解原型设计,并展示通过本章节的学习,学生可以:1)     在Devcloud上进行需求管理生成产品待办列表2)     掌握书写评估用户故事的方法3)     在了解MVP的基础上,团队进行自己产品的版本规划4)     团队自主进行低保真原型设计并进行串讲 项目实战第三阶段:技术准备1)     前端准备2)     后端准备3)     高保真原型设计串讲4)     技术准备示例代码展示通过本章节的学习,学生可以:1)     掌握Devcloud的操作使用2)     了解前端的开发流程,前端环境的搭建,及前端技术选型3)     了解后端的开发流程,后端环境的搭建,及后端技术选型4)     掌握前后端示例代码的编写5)     了解高保真原型设计并串讲 项目实战第四阶段:Sprint开发1)     理解Sprint迭代概念2)     进行迭代计划会议,并生成迭代待办列表3)     进行每日站会并记录4)     团队自主完成迭代的开发5)     进行迭代评审会议并展示6)     进行迭代回顾会议并记录7)     了解功能测试及BUG管理8)     了解可视化管理通过本部分的学习,使学生:1)     在Devcloud上进行迭代的开发,编译构建,部署发布2)     熟练掌握计划会议中优先级,增量的概念3)     团队内部每日站会中体会到各自工作4)     对本次迭代的输出产物进行展示评审5)     在回顾会议中体会到团队的问题暴露并改正 课时建议:序号课 程 内 容学  时  数合计理论教学实践教学实训教学教学实习1从棉花糖挑战认识现代软件工程3212项目实战第一阶段:项目立项41033项目实战第二阶段:产品规划52034项目实战第三阶段:技术准备40045项目实战第四阶段:Sprint开发102086项目实战学生自主阶段1000100总计367029 教学过程与方法目标:建议在进行该课程的教学过程中,充分利用Devcloud平台对敏捷团队以及项目的管理功能,在课堂上尽量让学生自己来研究,团队一起商量来展示,把课堂留给学生而不是老师单方面的灌输知识,实现“翻转课堂“在每个阶段之后,都设有不同的团队展示环节,可以将整个课堂交给学生,每个团队控制在在10~15分钟内,老师可以在这个过程中观看每组的情况,针对团队进展情况并进行当场评价,针对学生理解错误的知识点可以再次解答。 通过在Devcloud中,老师可以监控每个团队的项目进展状况,及时了解学生对该章节知识点的掌握情况,以便阶段性的基于落后的团队予以督促指导。在进行到第四阶段后,可以结合学生完成情况,增加相同的迭代阶段,引导学生自主来进行迭代相关的工作,以便帮助学生顺利完成整个项目实践任务。 考核要求:序号条目分值考核要求1Story录入10是否有Story在这个迭代;Story填写开始时间和结束时间(注意不要所有Story结束时间填写为迭代结束时间);Story预计工时是否录入;Story描述是否完整;Story对应的原型设计;Story分配、分解;关联Story的测试用例;Story关联代码fix id;Story开发过程中,刷新完成度;Story的状态要有变化。新建->进行中->已解决->测试中->已关闭。2原型设计5新增需求都要补充原型设计。归档到文档管理服务。3DBA5补充数据库表结构。每轮迭代数据库变更需要记录,变更过程归档到wiki。最终表结构说明归档到文档管理服务。4每日站会5wiki里记录每日站会情况,每次迭代至少五次5燃尽图2燃尽图一定是符合规律的下行曲线。6Story/Task完成情况3本轮迭代要对所有的Story、Task进行关闭。如果有超期的,备注里说明超期原因,和PO协商放到下轮迭代。如果所有Story都未完成,需要申请迭代延期。7需求覆盖率5需求覆盖率100%。8测试用例完整5确保测试用例覆盖功能、性能、安全、可靠性等领域。9缺陷管理5要有问题单、并且对问题单进行闭环。缺陷越多,证明测试执行的越好。10用例完成率5用例经过新建、设计中、测试中、已完成 四个状态,迭代最终要确保所有用例状态是已完成。11代码质量检查(加分项5分)使用代码检查服务,对devlop分支进行代码检查。自学。12代码分支创建是否合理5人人有自己的分支,每个人代码写完、自验证通过,提交到develop分支,develop分支作为统计每个人贡献度的分支。Develop分支验收通过后,可以由一个人(PL或SE)统一提交到master分支。13打标签5每轮迭代验收通过,正式发布前,需要对Master分支打版本标签。14代码贡献度5要求人人都必须有代码贡献(devlop代码统计提交代码量),并检查是否提交合理,严禁无效代码提交。15代码关联需求、问题5代码提交时,必须关联一个需求、或缺陷(fix id的方式commit)。针对无关联的提交,commit里面必须说明原因。16构建出包2创建一个构建任务,完成出包。17发布归档1在构建任务里配置归档路径,归档到发布仓库服务。18部署2创建一个部署任务,能贵将包部署到目标服务器。19流水线执行5将代码检查(如果有)、出包、部署过程自动化,通过流水线服务串联。20迭代验收10客户+全员进行本轮迭代效果演示,获得客户反馈,整理归档到文档管理服务。21迭代回顾10识别迭代过程中出现的问题,不达标项目进行全员回顾,整理归档到文档管理服务。 参考文献:《Scrum官方指南》 由Ken Schwaber和Jeff Sutherland开发并维护 
  • [技术干货] 【DevCloud · 敏捷智库】如何有效管理用户声音?
    背景目前,很多互联网企业越发地注重用户声音。用户声音,也可以说是用户对产品甚至说对企业的期望和认可,对于企业的发展来说起到重要的作用。用户声音往往具有量多、琐碎、突发性强等特点,所以很多企业会涉及到组建专门的客服团队,作为用户和产品研发团队的中间纽带,以适应市场提升产品竞争力。该FAQ主要是解决客服工作管理的问题,客服工作如何开展(例如如何解决客户问题让客户满意之类的问题)不在我们FAQ解答范围内。问题分析众所周知,随着物联网时代的到来,数据正成指数倍增长。据IBM研究,90%的数据来源于最近2年,大数据时代已经到来。在互联网初期阶段,某米公司,正是通过管理和接纳了几百上千的粉丝的声音取得了成功。而现在,人手一部手机,一部手机就可以用来代表一个客户的声音,而且渠道也不再是单一化的,用户声音已然成为一种大数据。用户声音在大数据时代不仅仅是量多,而且是个体化的,正所谓“一万个读者就有一万个哈姆**”,用户声音的复杂程度早已不再是千奇百怪、五花八门能形容的了,此外还有突发性强等特点。能否对用户声音的数据进行有效管理将会成为在大数据时代生存和参与竞争的一项基本能力,这也是对企业提出了很大的挑战。解决方案企业的管理者或项目经理,在规划管理日常用户声音大多采用的流程是,先收集用户的问题,然后整理提交需求,再由研发团队进行新需求的开发或者Bug的修复,最后反馈给用户,形成闭环。根据这个流程,可以从客服团队的工作管理、用户声音的分类管理、产品研发团队的协作三方面来解决客服工作管理的问题。客服团队的工作管理企业的管理者或项目经理可以按照团队规模的大小,以及客服工作量的大小,决定是否安排专职人员做接待用户声音的工作。如果团队规模较大,客服工作量也大的话,需组建专门的客服团队来负责管理客户的声音。反之,可以让一个开发团队的成员兼职做客服工作,一般建议由团队最懂业务的人员。团队组建后,由于用户声音量多、琐碎、突发性强等特点,一般企业或团队会使用项目管理工具进行管理。华为云的DevCloud是基于敏捷思想设计的DevOps工具链(更多了解请见附件或官网),在做关于用户声音的项目管理时,以DevCloud为例。当客服团队有用户声音需要处理时,可以在DevCloud中创建一个看板项目(请见参考附录的《Scrum和看板如何选择》),并为其创建对应的工作项(需求或Bug)。如下图:针对每一个用户声音所创建的工作项,建议从名称能看出来客户来源和主要问题。此外,为了能更加方便的查询,建议也为工作项设置相应的模块和标签,然后通过模块和标签等作为过滤条件快速筛选(见下图:过滤查询),然后跟踪工作项状态,直至用户声音得到解决,工作项关闭为止(更多看板项目的操作请见参考附录中  DevCloud项目管理操作指南)。此外,模块和标签的设置还可以在所有工作项的视图中实现分组的效果(见下图:所有工作项中视图)。更多客服团队基于工作项的配置操作还应按实际情况灵活使用。图:过滤查询图:所有工作项视图用户声音的分类管理一般来说,用户声音根据其特点分为两大类,一类是对于产品的视觉、使用、习惯等方面的建议、投诉、表扬的非实时性的,另一类属于实时性的,即需要马上得到回答和解决。这样分类后可以便于管理,以减少人力提升效能。企业的管理者或项目经理可按情况分别处理,建议如下:非实时性对于非实时性,只需要单向收集客户的反馈就行。对于这种情况,可以通过增加一个渠道,让用户以文字的形式选择相关的分类进行反馈,这样对处理用户声音的工作实效性就没有太高要求。像在DevCloud中通过意见反馈即可进入到意见反馈的页面,然后提出反馈意见,如下图所示:实时性对于实时性的处理用户问题,需要提供实时的客服渠道,首先可以将常见问题及答案提供出来,这样能解决一些共性、常见的用户问题。对于个性化的问题,可以先通过智能机器人问答的形式来处理,即通过用户输入的关键字,智能机器人提供相关的回答,最后是通过提供人工客服的方式,回答用户问题。产品研发团队的协作当客服团队收集到用户声音后,需要将需求或Bug等提交到研发团队,然后上线解决、再通知用户形成闭环。但是由于客服团队和研发团队在一个公司内常常是两个不同的组织,所从属的领导也不是同一个,所以为了避免协作过程中的责任划分不清、踢皮球的情况,建议企业的管理者要因此特性制定好协作的工作方式,让双方都能遵循。在DevCloud中可以通过Wiki来记录规则和说明,如下所示:当用户提出反馈意见或建议后,随着时间的推移,可能会需要主动或被动的给用户以反馈,那么就需要客服团队和研发团队能共享关于该用户声音需求的进展情况,形成双向关联。这样的好处不仅是能做到客服方能跟踪需求掌握进展,还能让研发团队了解到真实场景,更加符合用户的真实需求。在DevCloud中,可以通过工作项中的关联功能实现双向关联。如下图所示:当客服团队在所在项目中(VOC管理)创建完工作项(【传习教育】页面加载较慢)后可以通过关联工作项的功能和开发团队的项目(VOC需求)中工作项(传习教育需求)做关联,见下图:华为DevCloud提供了强大的项目管理和跨团队协作能力,更多功能操作请见参考附录中DevCloud项目管理操作指南。参考附录DevCloud项目管理操作指南Scrum和看板如何选择关联文章在互联网时代,如何有效管理用户声音?
  • 企业如何开展敏捷——价值协作篇
                  作为一名软件开发云的产品经理,我长期在华为公司内践行敏捷、精益、DevOps、OKR等先进理念,对于大型软件研发组织如何运作,有些经验跟大家分享,同时也欢迎大家能谈谈自己的想法。敏捷对研发的重要性       大家都知道,软件研发越来越依赖团队,团队协作和团队内部的知识共享是重要基础。随着持续创新的压力越来越大,对团队如何成长为更加高效的敏捷性团队来说至关重要。并且,团队必须学习、擅长使用工具来定义软件交付流程,打破战略、管理、开发和运营之间的孤岛。       传统团队转变为敏捷团队,最重要的变革之一就是团队目标的统一,这里的目标,是商业目标,是价值聚焦,而不是一般性质的工作目标,这与OKR的理念一脉相承。        对于团队来说,协作是企业前进的主要动力。必须合理得配置人、财、事,才能调动团队的积极性和创造性。除了企业内部上上下下应该重视协作,为员工培养必备的合作技能外,还需要注重协作的效率,团队规模与企业协作效率往往成反比,选择一款合适的协作工具非常重要。另外,团队内成员角色定位一定要清晰,只有这样,团队成员才能把注意力和精力放在目标的达成上,而不是相互扯皮或保护自己的“地盘”。软件研发中实现目标的路径往往并不明确,团队成员完成任务需要投入很多的时间和精力,这就更需要清晰的目标定位和良好的协作机制。下面来聊一聊华为云DevCloud如何解决企业的价值协作。 DevCloud新看板      DevCloud新上线的新版看板在于解决研发团队进行扁平化的针对目标价值交付的团队协作,同时它还提供了灵活的定制化能力,满足各行业各领域企业的团队协作流程。      首先,围绕角色分工制定了适用于角色的工作看板,如下图所示,企业高管关注战略,项目或产品owner关注需求,研发团队关注开发。       其次,价值通过战略层的商业目标来体现,企业高管类角色从市场或者用户那里识别出高价值目标,可以与团队协作逐层分解到下级角色和团队,这个过程就达成了目标对齐统一。各角色对齐目标后,可以各自聚集在自己的主要工作上,每个角色的工作有了进展系统就会知会给所有相关干系人,从而实现了团队的高效协作。如下图:需求层可以向下分解任务,并且可以直观看到进展。       最后,新版看板提供了供企业轻松定制协作流程的能力,不同企业的角色分工不同,不同企业内角色的协作流程也会不同,看板提供工作项层级的定制能力使企业可以根据分工情况定制,也提供流程的定制能力使企业根据协作流程定制,有效支撑各企业在敏捷转型中的价值目标统一和分工协作,使企业内敏捷转型通过思想变革与工具应用高度结合。如下图:可以高效得进行团队协作流程定制。如何使用新看板?1、进入DevCloud首页。2、拥有创建项目的权限时,点击创建项目即可创建新看板。(见下图)关于新看板的更多详细介绍,可以访问:介绍视频
  • [技术干货] 【DevCloud · 敏捷智库】Scrum和看板如何选择
    背景目前,Scrum和看板已成为了帮助团队贯彻敏捷的重要方法,我们也能经常看到敏捷爱好者在关于二者在各类社区、场合的讨论。无论是交流分享还是企业的咨询实施,关于Scrum和看板的讨论就一直没有停歇过。那么,对于一个正准备实践敏捷的团队,到底应该如何选择呢?问题分析一般来说,客户会纠结Scrum和看板的选择问题,主要是因为不清楚Scrum和看板方法的区别,不知道哪种更适合目前的项目或团队,也不清楚Scrum和看板方法能应对哪些场景。首先,从Scrum和看板方法的比较来了解两者的不同,见下表:描述Scrum看板方法目的探讨未知,处理新的、复杂项目自我检讨、消除浪费、得到好的效能团队角色产品负责人,Scrum Master,开发团队没有指定的角色度量指标团队速率生产周期、WIP(在制品)多变性承诺在Sprint周期不发生改变变化随时可能发生交付周期固定的Sprint时间盒完成一项工作的时间表: Scrum和看板方法的特征比较如上表所示,Scrum和看板方法在不同方面特征有所不同,企业在选择使用Scrum和看板方法的时候,可以根据上表中二者的特征并结合不同的实际情况,做出选择,具体参考如下情况和详细解释:情况Scrum看板方法团队所做的项目VUCA、需要一定的可预测性√团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级√项目需要有固定的迭代交付时间(2到4周)√项目的初期探索迎合市场的阶段√团队规模较小(不足5人)或较大(9人以上)√表: Scrum和看板方法的选择情况1:团队所做的项目VUCA、需要一定的可预测性在VUCA(详见参考附录中的解释)的时代,很多团队做的是易变的、不确定的、复杂的、模糊的项目,如互联网项目。针对于这样的特性,团队如果需要在某特定的时间发布或推广产品,以达到一定的市场预期的话。团队一般会将需求进行拆分和细化,如 Epic、 Feature、 User Story 、Task后,制定发布计划。随着拆分为较小的需求后,团队可以通过检查每个Sprint的进度并进行调整,从而预测交付时间,进而确保整个项目成功交付,Scrum是首选的方式。情况2:团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级Scrum的价值观之一是,承诺在Sprint内对计划不做修改,如果团队经常会应对紧急情况或者修改任务的优先级,那么看板方法因其灵活的工作流程可以更好的适应。情况3:项目需要有固定的交付时间(2到4周)在Scrum中每个Sprint的时间长度是固定(2到4周),并且每个Sprint结束后会交付潜在可交付产品增量,如果项目需要有固定的交付时间(2到4周),那么Scrum是比较好的选择。情况4:项目的初期探索迎合市场阶段以市场为导向的产品,产品越年轻,使用Scrum方式就越可能受益。因为在开发全新产品,尝试实现PMF(产品市场契合)或努力保持产品增长时,通常面临许多未知因素以及大量不确定性和变化。要通过迭代不断的输出增量以获取市场的反馈,进而更快更好的迎合市场的需求,所以Scrum是比较好的选择。(详见参考附录中的Scrum适合你的项目吗?)情况5:团队规模较小(不足5人)或较大(9人以上)Scrum团队理想的规模是2个披萨团队,给出的建议是5到9人,如果团队不足5人,在人员方面可能无法发挥Scrum的最大功效或存在一定上的浪费,那么建议使用看板方法。(Scrum of Scrums 不在此FAQ讨论范围内。)解决措施目前很多企业和团队,都是通过工具在实践Scrum或看板方法,华为云的DevCloud也是基于敏捷思想设计的DevOps工具链(更多了解请见附件或官网),以DevCloud为例,在DevCloud中提供了更加鲜明化的Scrum项目和看板项目的选择,具体可以参考根因分析中针对不同情况选择不同的项目(详见,表: Scrum和看板方法的选择)从目的来说,Scrum主要是为了探讨未知,处理复杂(VUCA)项目从而提升效率,而处理和效率的字眼往往是和时间关联起来的,如要在一个什么样的时间得到什么样的结果,这也是要求了时间把控上或者说做计划的能力,当团队所做的项目为了这样的目的,那肯定是选用Scrum,哪怕团队的规模没有达到Scrum所推荐的5到9人,或者是团队要为估算所浪费的时间开销而苦恼,又或者说在一个Sprint中需求经常变更等情况。因为不管是人数的问题也好、还是估算的问题也好、又或是需求变更的问题都是可以通过团队在回顾中不断的分析、复盘、总结慢慢优化的,如估算问题,那就提高估算能力减少开销;如时间开销问题,可以通过熟练度的提升、形式的改变来较少开销。总之,只要核心是不变的或者说关注点是围绕Scrum目的就应选择Scrum项目,典型项目有:新的应用程序开发、品牌发展、营销活动、具有季度/定时发布时间表的大型企业等。相反,如果团队的关注点就是以优先响应需求的能力,需求是必须要随时跟进和变更的,项目的可预测性、产品市场的契合度等的优先级并没有成为超过响应能力的话,那么看板项目就是一种更好的选择,因为这正是看板方法的优势,让价值能够快速的流动起来,以更快的满足客户的需求,典型项目有:生产支持、补丁发布、UX设计、营销宣传材料、新闻稿等。所以,对Scrum项目和看板项目的选择上,一定参考的是客户认为最重要的关注的点是什么。以目的驱动做响应的选择。另外,在DevCloud的Scrum项目也提供了看板的视图,可以很好的在Scrum的项目中使用看板方法,进而让Scrum可以和看板有效的结合起来,发挥更强大的效能。在DevCloud中, Scrum项目是以Scrum框架为核心的,提供用于处理探讨未知,处理新的、复杂项目的项目类型。Scrum项目提供了类似思维导图的方式,用来整理需求做项目规划,并提供了Epic 、Feature 、Story、Task的四级需求划分,如下图。在Scrum项目中的迭代视图中,未规划工作项相当于 Scrum中的 Product Backlog,当前的迭代相当于Sprint Backlog,可以很好的结合Scrum中Product Backlog和Sprint Backlog两个工件,如下图。Scrum项目提供了通过切换卡片模式转为看板视图,以用来Scrum和看板有效的结合起来,如下图。更多操作和相关内容请见参考附录中DevCloud项目管理用户指南。在DevCloud中,看板项目是以看板方法为核心,为团队提供流程可视化、限制WIP, 加速价值流动,以更快的满足客户的需求,看板项目中提供了非常友好的可视化看板板,默认提供了,新建、进行中、测试中、已关闭等状态列,用来标示任务的状态,可以通过拖拽的方式来实现任务的价值流动。团队在使用看板项目时,还可以修改默认提供的列(修改列名等)和自定义列以实现项目或团队定制化需求。此外,看板项目还提供了很多过滤和显示的快捷和便利操作等。更多操作和相关内容请见参考附录中DevCloud项目管理用户指南。参考附录Scrum适合你的项目吗?DevCloud项目管理用户指南Scrum 指南2007版VUCA 维基百科
  • [活动打卡] 结业实践结果征集【云享读书会-敏捷无敌之DevOps时代】
    感谢关注华为云 · 云享读书会系列活动~本期活动已结束~查看本期读书会领读视频   请戳:云享读书会《敏捷无敌之DevOps时代》查看本期读书笔记   请戳:读书笔记征集【云享读书会-敏捷无敌之DevOps时代】获取近期读书会活动安排,请私信小助手咨询哈~开发者,你好哟~欢迎参加华为云 · 云享读书会系列活动!本期云享读书会领读书籍为 - 敏捷无敌续作《敏捷无敌之DevOps时代》邀请作者团 - 无敌三人组(王立杰、许舟平、姚冬)与敏捷专家徐磊,四位大咖齐聚,论DevOps之道。如果你已完成结业实践作业,请在此帖回复结果截图~01. 征集时间2019.11.11 - 2019.11.1802. 截图示例回帖时请务必留下你的微信昵称和华为云账号截图示例:结业实践任务1-使用DevCloud进行敏捷项目规划:结业实践任务2-使用静态代码检查确保编码规范的有效落地:结业实践任务3-使用Git代码托管支撑敏捷团队持续交付:03. 注意事项1. 截图提交后,小助手会在3个工作日内按续完成审核,并增加活动积分200分;2. 本次活动共包含3个结业实践任务,通过完成结业实践,可获得的积分上限为600分;3. 请务必按照上述要求提交内容,以免影响积分增加;4. 若积分值相同则以完成学习任务的时间先后排序,其中任务完成时间的判定优先级为:结业实践>读书笔记>自测题;5. 其他积分获取方式请查看活动社群公告;6. 其他未说明事项请参照 云享读书会《敏捷无敌之DevOps时代》04. 关于云享读书会每期云享读书会活动,会选取一本技术相关的畅销书籍,由原作者提炼书籍精华,在读书会的专属微信社群中,每日输出精华知识的领读视频,帮助大家快速积累专业知识。活动期间会设置每日自测题、结业实践任务、提交读书笔记三种积分获取任务,并根据活动结束后的积分排行发放活动奖励。05. 活动奖励
  • [活动打卡] 读书笔记征集【云享读书会-敏捷无敌之DevOps时代】
    感谢关注华为云 · 云享读书会系列活动~本期活动已结束~查看本期读书会领读视频   请戳:云享读书会《敏捷无敌之DevOps时代》获取近期读书会活动安排,请私信小助手咨询哈~开发者,你好哟~欢迎参加华为云 · 云享读书会系列活动!本期云享读书会领读书籍为 - 敏捷无敌续作《敏捷无敌之DevOps时代》邀请作者团 - 无敌三人组(王立杰、许舟平、姚冬)与敏捷专家徐磊,四位大咖齐聚,论DevOps之道。经过作者的视频领读,如果你有些敏捷相关知识收获,欢迎在此帖留下你的读书笔记~01. 征集时间2019.11.11 - 2019.11.1802. 读书笔记要求1. 每篇读书笔记字数要求≥300字;2. 内容要求与每日领读视频、《敏捷无敌之DevOps时代》书籍或是华为云DevCloud产品优化意见相关;3. 内容原创不可抄袭;4. 回帖时请务必留下你的微信昵称和华为云账号。03. 注意事项1. 读书笔记提交后,小助手会在3个工作日内按续完成审核,并增加活动积分100分/篇;2. 本次活动通过提交读书笔记,可获得的积分上限为500分;3. 请务必按照上述要求提交内容,以免影响积分增加;4. 若积分值相同则以完成学习任务的时间先后排序,其中任务完成时间的判定优先级为:结业实践>读书笔记>自测题>其他;5. 其他积分获取方式请查看活动社群公告;6. 其他未说明事项请参照 云享读书会《敏捷无敌之DevOps时代》04. 关于云享读书会每期云享读书会活动,会选取一本技术相关的畅销书籍,由原作者提炼书籍精华,在读书会的专属微信社群中,每日输出精华知识的领读视频,帮助大家快速积累专业知识。活动期间会设置每日自测题、结业实践任务、提交读书笔记三种积分获取任务,并根据活动结束后的积分排行发放活动奖励。05. 活动奖励
  • [线上活动] 【9.22】2019深圳敏捷之旅十周年大会-华为云专家看点
    近年来,随着移动互联网时代的到来,精益、敏捷、产品管理、DevOps等前沿管理思想与先进技术受到广泛关注,组织的敏捷转型和变革越来越热门。简单的体系已经无法帮助企业抵抗外部快速的变化和满足企业创新的需求,DevOps、看板方法、Scrum等关键词,不再“洋气”,而是开始进入中国的本土企业当中,成为许多中国企业在这个时代变革转型的诺亚方舟。在深圳这座国内移动互联网发展速度最快的城市,敏捷转型早已在许多具有前瞻意识和风险意识的企业当中推广开来了:从团队敏捷到规模化敏捷,从个人到企业组织架构……但是在这个向敏捷转型过程中,大家的困惑也越来越多:如何在企业内部有效地切入并且推动敏捷?如何让团队成员从小白转型成高手?如何突破敏捷转型的瓶颈?等等……这些问题,在今年的2019深圳敏捷之旅十周年大会,你能得到解答。敏捷之旅的目的是提供一个高效有趣的敏捷开发学习途径,在全球范围内推广敏捷的思想和实践,帮助企业更好的实施敏捷。每年的冬天,敏捷之旅会在全世界各地举办,其中中国有20多个城市,深圳是全球敏捷之旅活动中的重要一站。深圳敏捷之旅在2019年迎来了大会的第10个年头,在过去的10年中敏捷在深圳逐渐的落地生根发芽,如今敏捷遍地开花,深圳敏捷之旅见证了敏捷在深圳的发展。2019深圳敏捷之旅十周年将于2019年9月22日举行,这次依然是干货满满,不仅有来自业界大咖分享的趋势动态,也有来自通信、互联网、金融行业的一线企业(华为、腾讯、百度、阿里、招行等)带来的实践分享。本期大会,华为云专家(云享专家&MVP)看点
  • [线上活动] 【9.22】深圳敏捷之旅十周年大会
    近年来,随着移动互联网时代的到来,精益、敏捷、产品管理、DevOps等前沿管理思想与先进技术受到广泛关注,组织的敏捷转型和变革越来越热门。简单的体系已经无法帮助企业抵抗外部快速的变化和满足企业创新的需求,DevOps、看板方法、Scrum等关键词,不再“洋气”,而是开始进入中国的本土企业当中,成为许多中国企业在这个时代变革转型的诺亚方舟。在深圳这座国内移动互联网发展速度最快的城市,敏捷转型早已在许多具有前瞻意识和风险意识的企业当中推广开来了:从团队敏捷到规模化敏捷,从个人到企业组织架构……但是在这个向敏捷转型过程中,大家的困惑也越来越多:如何在企业内部有效地切入并且推动敏捷?如何让团队成员从小白转型成高手?如何突破敏捷转型的瓶颈?等等……这些问题,在今年的2019深圳敏捷之旅十周年大会,你能得到解答。精彩看点:
  • [分享交流] 精准测试与开源工具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 · 敏捷智库】如何玩转每日站会?(内附下载材料)
    作者 黄隽 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
总条数:272 到第
上滑加载中