• [技术干货] 你也被DevOps的流水线坑过吗?
    背景在一次DevOps线上活动的提问环节中,有这样一个问题:“我们公司刚刚完成了DevOps转型,搭建了一条流水线,流水线确实让我们部署上线的效率提升了,但是也更快的让客户当上小白鼠,因为我们让问题更快的暴露出来了……”可以想象,一个开发人员开心的点了一下流水线的启动按钮,然后就开心的下班了,然后用户看着屏幕的404,然后就没有了然后(坏笑)……其实这真不是开玩笑,如果将项目中的流水线发布权限下放给了开发,那么404真的就是很现实和普遍的问题,因为很多开发认为自己的工作就是开发。像这样的坑你是否也掉进去过,我们一起基于此,来看看什么样的流水线是不坑人的吧。问题分析这些年来,DevOps已经逐渐的深入到软件企业中,尤其是一些互联网的项目中,需要更快的适应市场的变化迎合用户的需求,传统低效的方式来部署生产环境已无法存活, DevOps的流水线(部署流水线)也应运而生。然而在企业追求高效的同时,往往又引入了新的问题——高效的将bug展现给了用户。项目开发的前期,代码都是比较简单的,开发团队的人员也比较少。但慢慢随着时间的推移,代码越来越复杂,团队成员越来越越多,经手变更的也越来越频繁。一旦出现了问题,作为一个开发人员往往首先会想到的是——快速修复上线。DevOps在速度这点上确实帮了大忙,经历过传统部署发布的同学肯定深有体会。但是这样往往却又伴随了新的问题——“打地鼠现象”。何为打地鼠现象? 简单的说,就是一个问题你修复了,可能又会蹦出来几个新的问题。长期下去,不仅开发团队压力大,客户更是成了“小白鼠”。其实,这并不能把问题归结到部署流水线身上(无辜躺枪),借助流水线的快速发布,只是将问题更早的暴露出来,其归根结底上,问题还是出在质量上。那么,我们就不得不谈到——质量内建。戴明(William Edwards Deming)曾提出“问题发现得越早,修复的成本越低”,有数据指出85%的缺陷都是在代码编码阶段引入的,然而大部分的缺陷并不是在编码的时候发现的,而是在之后的测试阶段发现的,甚至是已经上线后。而且随着越往后发现缺陷,修复的成本也越高。来源《Applied Software Measurement:Global Analysis of Productivity and Quality》按照STICKYMINDS网站上上的一篇名为The Shift-Left Approach to Software Testing的文章中所给出的(如上图),假如在编码阶段发现的缺陷只需要1分钟就能解决,那么单元测试阶段需要4分钟,功能测试阶段需要10分钟,系统测试阶段需要40分钟,而到了上线之后再发现可能就需要640分钟来修复,这可以说是很难让人接受的,所以质量内建是至关重要的。在质量问题上,当然离不了我们老生常谈的开发阶段的编码规范、重构、检视等活动,这里不做叙述。随着DevOps的引入,我们需要将质量内建,加入到DevOps的各个环节中,而部署流水线就是贯穿这些环节的重要工具。某种程度上说,部署流水线的质量基本上决定了软件质量——是带伤上阵还是安稳的睡大觉,部署流水线是关键。那么如何算是一条不坑的部署流水线呢?解决方案测试左移(Shift-Left testing)如上面所提到了,在开发完成后,越到生命周期的后面修复的成本越高。那么基于这样的情况,测试应该尽早的开始。在传统的开发周期中,问题都在什么时候发现的呢?如下图所示:来源《Applied Software Measurement:Global Analysis of Productivity and Quality》可以看到传统模式下,问题很少会在开发阶段发现,而现在提出的测试左移,就是在要在开发阶段尽可能的发现更多的问题,而避免问题被发现在之后的阶段。这也就是我们搭建一条不坑的流水线最基本的理念之一。一般来说,在流水线的构建阶段我们会加入静态代码检查,比如使用Findbugs、Sonar等。可按需自行设置是否随代码提交而触发检查(推荐),或伴随持续集成的工程实践开展,可一天一次或多次,这就保障了不会掉进最基本静态代码层面的坑。此外在流水线的设计上一定要有API、UI等自动化测试。一般来说,可按部署到不同的环境,对应创建不同的流水线阶段,如集成环境有对应的流水线的集成阶段,测试环境有其测试阶段。当部署时,就可以在对应的阶段中加入所需要的测试活动。如当开发人员修复某一个bug后,想要保证其他功能的成长,可以通过在流水线的自测阶段通过加入API的测试等。总结来说,就是在流水线的构建阶段加入静态代码的检查,在部署阶段加入自动化的测试活动,以保证代码的质量和功能的可用。质量要求在质量建设中,不能仅停留在质量管控的基本要求——有,还要注重质量的高低。因为某种意义上来说,较松的管控等于没有,这也是最坑的地方——有等于没有,试想如果流水线中只有某个API测试的情况,那么验证的基本就是这个服务有没有成功启动而已。那么,这就需要加入一个质量阀值的要求。质量阀值的高低是一个衡量质量高低的重要标准。这个阀值可以是接口覆盖率达到多少,也可以是静态代码检查出来问题的数量等。一个严格的质量门禁可以说流水线完成后发布上线的定心丸,这也就可以用来解决了上文提到的“打地鼠”现象。一般来说,接口测试的覆盖率建议达到百分之百,而考虑单元测试和接口测试某些程度上的重复以及UI测试的ROI等因素可按需进行配置,因情况不同这里不做叙述。对于代码检查来说,也可设置某一个数值作为阀值,这个数值可以按照某种规则设定。如一般问题记1分,严重问题记5分,安全问题记8分等,当检查后所累积的数值超过10则不能发布或进入下个一个阶段,当然数值越低越好,具体设置(代码检查的维度不再此叙述)也需按实际情况而定。此外,还可以考虑如开源第三方jar包的扫描、安全漏洞扫描等活动。如果考虑划分的更有层级和模块化,相对于接口测试或静态代码检查的质量建设,扫描的可以单独作为一个阶段按需设置。总结来说,质量建设按照项目的实际情况来设置,而且对于团队来说,质量永远不仅仅是某一个人或团队的事情,而是所有人的事情。相对于质量的坑来说,意识上更是我们应该避免掉进的坑。如了解更多请访问华为DevCloud流水线的内容,详见附录。这里提到了意识,意识是关乎人的主观性层面的了,那么应用在流水线上,其实也是需要考虑的。诚然有些时候我们依赖于机器和自动化,如上面说提到的接口测试、安全扫描等。但是也不能完全依赖于自动化,比如我们也需要人工的代码检视活动。这在搭建流水线的时候也可以考虑到把人工环节加入到其中,比如在发布到生产环境的阶段增加一个发布看板,其中包含了是否有人工代码的检视以及检视出来的代码的质量的阀值或要求等。综上,一条流水线除了必须的、按需的自动化+人工以外,还需要在实践的过程中不断的总结结合自身特点加以定制,然后才能放心大胆的点击“启动”而不被坑。最后引用姚冬老师文章中的一句话“流水线确保代码和基础设施始终处于可部署状态,所有提交到主干的代码都可以安全的部署到生产环境。”这也是笔者非常认同的,也相信搭建实现这一目标,提供这能力的流水线才能更好的实现持续交付,配合好我们的DevOps转型。参考附录测试左移以终为始,再谈持续交付流水线DevCloud的HE2E DevOps的流水线构建博客
  • [技术干货] 【DevCloud·敏捷智库】如何利用故事点做估算
    作者:黄药师(黄隽) 背景在某开发团队辅导的第二天,一个团队负责人咨询道:“领导经常管我要开发计划,我如何能快速的评估出预计开发完成时间呢,我们目前用工时估算,我听说过故事点估算,不知道适合吗?”问题分析从这个团队负责人那里了解到,领导一般在接到项目大量新需求时会问这个问题。领导需要做到“心里有数”,有一个预计的项目新需求完成时间。加上领导一直做传统的瀑布开发项目,他非常关心项目中远期计划,也就是我们通常讲的里程碑或关键结点的问题。团队目前使用敏捷开发方式初期,团队成员本身也对如何更快、更好地做好估算感到困惑,目前纠结是否应该采用故事点估算。从以上问题分析中可以得出:第一,团队对故事点不了解,需要学习什么是故事点;第二,解决如何快速提供给领导开发计划的问题。 解决措施解决问题我们来分两步走。首先解决不熟悉故事点的问题,先给大家介绍一下故事点的定义及特性。然后大家了解一下两层估算即产品待办列表估算和Sprint待办列表估算的简单区别,解决开发计划的问题。如果有时间,建议可以先看看上篇《如何估算第二篇:利用核心概念理解估算》了解估算的核心概念。然后再来看这篇文章效果更好。这篇文章主要讲故事点。具体的估算方法有没有比较好的实践呢?在《如何估算第四篇:利用2种常见方法做估算》中会介绍几种比较好的估算方法,包括:“计划扑克估算”、“敏捷估算2.0(Agile Estimating 2.0)”等。本篇仍然在为估算做技能储备(磨刀不误砍柴功),即明确什么是故事点。前面文章已经讲过估算的一个核心概念即估算相对大小,这个相对大小我们用故事点为单位。工时和理想人天相信大家都理解,不做过多解释。在这里着重从故事点的定义、故事点的特性两个方面解释下什么是故事点,然后解决给领导提供计划的问题。故事点的定义故事点是表述一个用户故事,一项功能或一件工作的整体大小的一种度量单位。当采用故事点估算时,我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要,我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。团队不要采用100、200、300,而要使用1、2、3。估算结果是相对值,而不是绝对值。“当使用故事点来估算用户故事的大小时,并没有固定的公式来规定如何计算故事点的数值。故事点估算用于评估为了交付一个用户故事所包含的工作量(team effort),用户故事的复杂度(complexity),风险,以及所有其他需要考虑的元素。——《Agile Estimating and Planning》, Mike Cohn.故事点的特性说明是相对单位它是一个相对单位。比如,不同的组织团队,对于同样的用户故事的故事点大小一般是不同的;即使同一团队,针对不同用户故事的故事点大小,甚至是针对同一用户故事的故事点大小,都允许是不同的。但同时提醒,不同团队不同用户故事的故事点的设定,有利于组织能力的积累和横向参考。不等同于工作量估算故事点估算不是简单等同于工作量估算。如Mike Cohn所描述,它包含工作量、技术含量、各方面制约等多方面价值因素。有时其他的这些因素,在故事点估算中占有比重会胜过工作量方面的考虑。考虑“完成的定义”故事点估算必须要覆盖直到实现产品待办项待真正完成的所有事项。如果团队的“完成的定义”中包括了创建自动化测试来验证这个故事(并且这是一个好主意)这个事项,那么创建这些测试的工作量也应该包含在故事点估算结果中。以上介绍,有些朋友可能会问:有些团队用工时(单位小时)来估算,不可以吗?上一篇文章末尾提到,有些较成熟的团队,也可以借鉴历史数据和经验,直接应用工时或理想人天估算也并非不可。如果一定要推荐工时(或理想人天)和故事点分别在什么时候应用比较好,那么我一般推荐在做产品待办列表估算时用故事点,而Sprint待办列表估算时用工时(单位是小时)。原因很简单,结合最开始团队负责人的问题,其实老板大多对什么时间点可以交付多少需求(用户故事形式体现)感兴趣。最常见的问题是:“这50个需求什么时间可以做完?”很明显,老板并不是在问本Sprint能做完多少需求,而是在问项目得有一个预计的时间点或里程碑。换句话说就是,需要对某个时间点可以交付什么样价值做出一个长期一点的预测。如果每个故事平均15分钟估算,那么50个用户故事估算需要50*15分钟=750分钟=12.5小时。显然估算所需要花费的时间代价比较高,ROI太低。如果采用准确度差不多的故事点估算,则效率会大大提升。前面提到过为什么故事点估算容易,这里不再重复解释。此时建议团队平均3分钟完成一个用户故事的估算,那么估算需要50*3分钟=150分钟=2.5小时。这样根据团队正常速率,就可以预计完成时间,回答老板的问题了。对于Sprint列表的估算,其目标更多的是要确定团队本Sprint要完成的工作量,故事点显得有点抽象。团队具体执行时,时间概念上有点困难,而小时数就容易得多。通常Sprint列表项也会比产品待办列表项少得多,所以时间上不会花费太多。另外,就Sprint列表中的工作项而言,它会是更具体的需求,通常会进行任务细化和“完成定义”,进而很清楚如何去做,谁来做。这些因素综合看,以工时(小时)来估算成为优势。参考附录1.      Mark C. Layton. 敏捷项目管理[M].北京:人民邮电出版社。
  • [技术干货] 【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**** 本内容被作者隐藏 ****
  • [热门活动] HCSD集训营—软件开发流水线专场 学习心得分享
    活动链接:https://developer.huaweicloud.com/signup/b6b49a7d511e4f548cd10d0cc4d9b20c?medium=share_kfzlb&invitation=72c6caa2cea74bf9bd071e48641d9a71              学习心得  首先针对打卡二做的实验我选择是使用VSS完成安卓及鸿蒙应用安全检测,该二进制分析,移动应用安全先前参加过产品特训营培训,就此所学习的内容介绍下所了解为什么会有这个功能,相比友商的优劣势等 ,也是自己的学习心得所获:  背景:国家政策:2021年《移动互联网应用程序个人信息保护法》     移动合规测试中会遇到的问题:         1.政出多门,合规风险大         2.无专业合规人员进行法规解读         3.自动化检测能力弱,测试工作量大         4.本地工具需部署环境,运维成本高     移动应用安全场景         1.检测全面,深度贴合国家监管标准         2.高效精准,隐私合规模拟真实场景触发         3.报告全面,提供专业的修复完建议         4.与华为应用市场能力同源     注:因为IOS使用Object-C编写,封闭系统,当前国家无针对于IOS应用的隐私合规测试标准      然后对于打卡一的实验智能增值税发票识别,体验过后,感觉到的是顺应市场需求,发票拍照识别系统可以解放财务的双手,自动采集发票上的会计要素,自动对票据建立索引并归档,提高凭证信息查阅的一致性与准确性,与传统的会计人工录入数据方案相比,可以减少90%的工作量,提升了其工作效率。      最后是打卡实验三“使用华为云DevCloud实现20分钟一行代码上云”; 因为在之前参加其他活动,所以这次我就借助于加入的课程购买了“基于华为云DevCloud的托马斯商城”,以及通过实验手册进行了实验练习,并学习完成,以85分通过了该微认证。   整个学习材料了解到从敏捷起源--敏捷思维-敏捷宣言-敏捷原则-敏捷较传统模式更符合软件开发规律-敏捷与瀑布的外在区别;进而引入华为DevCloud的一站式开发平台,集华为研发实践、前沿研发理念、先进研发工具为一体,面向开发者提供研发工具服务,让软件开发简单高效免费领取华为云软件开发云平台基础套餐 DevOps是目前最流行的开发模式,重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevCloud基于华为研发云的成功实践经验,通过云服务的方式提供一站式云端DevOps平台。开发团队基于云服务的模式按需使用,在云端进行项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等。在云端进行项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等。三、活动规则 1、报名后,请首先开通领取免费产品资源,否则其他积分将不作数: 2、将最终打卡完成截图和心得体会统一进行一次回帖,多次回复将不做数,最终只按照最后一次回帖为准 3、心得体会包含但不局限于,只有有效回帖才能获得此部分积分     ①用户对产品的评测,优点、缺点     ②希望能用到的场景     ③产品优化建议4、积分规则:四、活动奖励
  • [技术讨论] 百炼成仙 导学篇
    ![百炼成仙导学篇](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202201/29/092027fgurshtzgft0w6mk.png)# 是什么  托互联网的福,你每天都在接收大量信息,不仅有搞笑视频,美女跳舞,也有丰富的教育资源。  不得不说,在你站在学习这个十字路口,看到如此多的方向时,这些反而使你更加迷茫,因为你不清楚,也没有人曾告诉你,哪条路可能使你步履艰难、越陷越深,那条路是阳关大道让你冲出重围,乘风破浪。不过有一点你是十分清楚的,人类的精力和时间都是有限的,选择一个适合自己的学习方法往往事半功倍......  正如五年前的我,站在这个十字路口,踌躇满志却很迷茫,不知道哪些技能职场更需要......如果可能,我真想穿越时空,对这个懵懂青年说,来!往这走!不骗你。可无论我怎么努力,这个青年肯定是听不见的。不过,你可以......  教学内容采用 **“是什么”** ,**“能做什么”** ,**“举例”** 三个模块进行教学,不仅记录了从CV小子到世界500强的经验,同时也把自己的编程经验和理解融入到系列教程中,让你在吸收知识的同时,还能感受到知识的美味。我觉得,当下世态,能看进去一板一眼文字教学的人并不多,所以我决定尽量**减小教学篇幅,把更多的文字留给对单次教学的思维拓展**。最后,希望我们永远持以一颗初学者的心去学习,力争成为一名超级个体。  教学计划(试行):**百炼成仙 · Python**# 能做什么  导学篇,用来介绍这个任重而道远的连载项目
  • [热门活动] 【小编精选】【邀测】DevCloud测试服务APIMock正在邀测中,欢迎参与!
    【参与方式】1. 请在此帖下进行盖楼,留下您的联系方式(微信或手机号),我们随后会联系您!2. 请扫描此二维码进入微信群,具体方式咨询群内工作人员,群里有不定期套餐优惠福利,还有VIP一对一教学指导提示:您填写并提交的上述信息视为您同意华为云通过电话方式联系您完善信息以便能够为您提供更贴心的云服务【APIMock测试服务介绍】Mock服务旨在提供功能强大的接口 Mock 及接口管理服务。可以通过模拟接口的响应,解决开发或测试过程中依赖的服务不稳定等问题。Mock服务的使用场景有以下几种:并行开发:在被依赖模块未开发完成时,使用Mock服务替代真实服务,可进行并行或前后端联调测试。依赖服务不稳定:当依赖服务不稳定时,会导致自动化测试用例失败,使用Mock服务替代真实的服务,可以保证自动化测试稳定执行,提升流水线的健壮性。构造异常场景:测试时会需要构造一些异常数据或延迟响应等异常场景,使用真实服务通常无法满足需求,使用Mock服务可以快速构造异常场景,提升测试覆盖率。点击下方超链接跳转为您介绍如何在软件开发平台中使用Mock服务,包括:     新建Mock服务分组     添加Mock服务     编辑Mock服务     访问Mock请求     导入OPENAPI接口定义文件
  • 【会员中心/2021新品】敏捷扑克,大有文章
    熟悉DevCloud会员中心的大佬们基本有一个共识:攒的码豆换插线板一定不亏。但今天,在下敏捷小智,想介绍另一款同样物美价廉,可供兑换的礼品:华为云敏捷扑克牌。在几周前,就有眼尖的朋友发现新品上线,便在论坛提出疑问:这扑克牌里面有啥?值不值得换?相信看完今天的文章,您心中会有答案。不懂术语,何以沟通?小明是一个95后,上进好学,加入团队已经有一个多月了,这段时间基本上适应了团队敏捷开发的节奏,可是有时大家说的一些词,他还是不明白,脑子晕晕的,自己网上学习了几天,也没能建立清晰的知识体系。于是他来求助同组的大佬,说了自己的困惑。大佬说会给他带一个神器,保证药到病除。 大佬:你需要的是一个理论框架,帮你把这些知识系统化、结构化梳理显示,再结合你平日的敏捷团队实践,你就会清楚了。和你提到的神器就是《华为云敏捷扑克牌》,来,给你看一下。这套敏捷知识扑克牌大有来头,它以华为云DevCloud的HE2E知识体系为主体,HE2E即华为端到端的DevOps实施框架,是结合了华为30年研发经验并集合了业界先进的实践所形成的一套可操作可落地的敏捷开发方法论。敏捷扑克牌的54张牌,张张都经过了精心的内容设计。大王是华为云DevCloud的DevOps能力屋,小王是华为云 DevCloud HE2E DevOps体系框架,四个花色分别对应HE2E框架中的软件开发四个阶段,即持续规划与设计、持续开发与集成、持续测试与反馈、持续部署与发布。每个花色的13个扑克牌,对应每个阶段的13个核心知识点。(小明听到这儿已经惊呆了)以图文形式进行展示。这样知识点和所在的阶段一目了然,再也不怕混淆了,忘记了就翻出来看看。因为牌面空间有限,所以每张卡牌上的知识点还有详细的知识点解读和应用,这副牌可以看做知识索引。关注大佬(敏捷小智)(也就是我)的博客,会持续更新发布。嘿嘿。博客传送门→说说学习方法:回去之后你先看敏捷扑克牌,熟悉整体框架内容,根据卡牌上的图文搞清楚每个知识点的基本含义和所在阶段,首先做到条理清晰,心中有数。整体清晰之后,在工作时遇到了哪个术语,你再去看对应的卡牌,需要的话可以继续去看博客文章,或者查看书籍和资料帮助你学习理解。最后,还有疑问的话,欢迎随时来博客留言,我们共同探讨学习。小明:太专业了,简直就是**服务,能问一下这套敏捷扑克牌是谁做的吗?敏捷小智:哈哈那我就不得不打一个广告了,制作团队是华为云DevCloud专家服务团队,他们是专业提供敏捷和DevOps的培训认证和咨询与实施服务的,帮助企业提升软件交付能力和使能企业数字化转型。放心吧,绝对专业,产出的内容经得起推敲。这套扑克牌一共设计了红色、白色、黑色三个款式:小明:真的酷,这么强大的神器,我觉得团队应该人手一副,从哪能获取到呢?敏捷小智:我今天带了一盒白色款的,可以送给你,如果还需要的话,你可以到华为云码豆会员中心进行兑换。目前正好在限量兑换的活动中。有两种可选,一个是单盒装,颜色随机发货;另一个是套装,内含三盒,三款颜色各一。小明:我得赶紧回去告诉我的小伙伴们。小智,记得更新后续文章啊~今后你这敏捷的大腿我是抱定了!华为云敏捷扑克牌,包含敏捷&DevOps的54个知识点,覆盖软件开发全流程。怎么样,从知识学习的角度而言,是不是比插线板更香呢?3副套装只需要7888码豆。自己留一副把玩,余下的送给其他玩开发的朋友,颇有些“礼轻情意重”的意味。下次,我会分享一些精选卡牌对应的内容扩展文章。大家可以持续关注~
  • [技术干货] 想尝试规模化敏捷的同学请留步~
    敏捷软件开发理念已渐渐被业界普遍接受,Scrum框架更是早已被敏捷团队所熟知。随着大家敏捷的理念和实践一步步的提升,越来越多的公司和团队为了面对更快更强的适应变化的市场需求、减少内耗和项目规模的扩大等,不得不面对一个新的问题,就是规模化敏捷的引入和实现。目前市场上规模化框架主要有SAFe,Less,Scrum of Scrums, Spoity等等。其中SAFe是使用最广泛的规模化敏捷框架,那么SAFe到底是个什么东东呢?SAFeSAFe是什么SAFe(Scaled Agile Framework,大规模敏捷框架),是一个在线的知识库,该知识库具有经过验证的集成原则、实践和能力,可大规模实施精益、敏捷和DevOps。 SAFe发展历史2011年,SAFe第一版由Scaled Agile公司创始人Dean Leffingwell在scaledagileframework.com网站发布,截止到2019年10月,SAFe已经更新至5.0版本。SAFe核心价值观协调一致领导者通过建立和表达投资组合策略和解决方案愿景来传达任务,在计划期间确定业务价值,并指导范围的调整以确保需求与能力相匹配。内建质量领导者通过创建内建质量成为标准的环境来改变系统并展示承诺。透明领导者促进所有相关工作的可视化,并创造一个环境:“...事实总是友好的,在任何领域中人们可以获得的每一个证据都使人们更加接近事实。”项目群执行领导者作为企业所有者参与计划增量(PI)的规划行业执行,在积极消除障碍和消极因素的同时,庆祝高质量的产品增量。SAFe的原则SAFe核心能力l  精益敏捷领导力l  团队和技术敏捷l  DevOps和Release on Demandl  商业解决方案和精益系统工程l  精益解决方案管理SAFe的配置SAFe支持各种开发环境,具有四种开箱即用的配置。分别是:必不可少的SAFe配置Essential SAFe配置是所有SAFe配置的基本构建块,是最简单的实现起点。它提供精益敏捷领导能力,团队和技术敏捷性能力,以及DevOps和按需发布能力。SAFe以一个名为敏捷发布培训(ART)的组织结构为基础,敏捷团队,关键利益相关者和其他资源致力于一项重要的,持续的解决方案任务。大型解决方案的SAFe配置大型解决方案SAFe配置引入了业务解决方案和精益系统工程能力,支持那些构建最大,最复杂的解决方案,这些解决方案需要多个敏捷发布列车和供应商,但不需要组合级别的考虑因素。这种解决方案的开发对航空航天和国防,汽车和政府等行业来说很常见,因为大型解决方案 - 而非投资组合治理 - 是主要关注点。解决方案培训组织结构可帮助企业应对最大的挑战 - 构建大规模,多学科的软件,硬件,网络物理和复杂的IT系统。开发这些解决方案需要额外的角色,工件,事件和协调。投资组合SAFe配置Portfolio SAFe配置提供精益项目组合管理能力,使组合执行与企业战略保持一致。它通过一个或多个价值流围绕价值流组织发展。投资组合SAFe通过投资组合战略和投资资金,敏捷投资组合运营和精益治理的原则和实践提供业务敏捷性。完整的SAFe配置完整的SAFe配置包括精益企业的所有五项核心能力。它是框架的最全面版本,支持构建和维护大型复杂解决方案组合的企业。关于SAFe的更多了解请移步到我们的华为云DevCloud专业服务,服务中包含SAFe的系统化培训课程,并提供了相关认证,更有资深专家的亲自指导。此外,DevCloud专业服务还提供了开发者的相关能力评估,点亮象征着荣誉的开发者勋章,赶快来吧~~~~
  • [技术干货] 【敏捷智库知识卡】敏捷和DevOps知识集锦
    文章太长看不下去怎么办?知识卡来帮你~知识卡是将一篇敏捷&DevOps文章的核心精华内容汇聚到一张卡片上,涵盖人和组织、工程方法、最佳实践等多方面内容。卡片由华为云DevCloud专家服务团队出品,持续更新,建议关注收藏。为了持续提供优质的内容和服务,卡片版本不断的优化升级。请点击这里说出您的想法,参与即有礼,期待您的反馈!第14期 DevOps人才千姿百态,I&O新角色与技能提升第13期 企业DevOps转型七步路线图第12期 项目需求剪不断,理还乱——读懂四个关键词来帮你第11期 项目团队人员变动频繁怎么办?——大牛走了,你怕不怕?第10期 Scrum Master的心酸谁能知?—— 任务不让指派还没人认领,我咋整?第9期 微服务架构难落地?——MSA实施指导框架来帮你第8期 拍脑袋估算法?OUT!——科学估算,平稳生产,嗷闪!第7期 5D自检模型——组织DevOps转型的驱动力第6期 敏捷大师拍了拍“刺头”——乖,别闹,做个乖宝宝第5期 敏捷回顾,奥利给!第4期 Hey bro,你的故事low不low?——用户故事就是三段式?NoNoNo!第3期 DevOps转型避坑指南——如何避免六大“焦油坑”第2期 用户故事拆分——学到好方法,拆分不再难第1期 每日站会18Key——轻松玩转每日站会敏捷智库知识卡历史帖链接:【敏捷智库知识卡】第1-7期合集【敏捷智库知识卡】 第8期 拍脑袋估算法?OUT!:科学估算,平稳生产,嗷闪!【敏捷智库知识卡】第9期 微服务架构难落地?MSA实施指导框架来帮你【敏捷智库知识卡】 第10期 任务不让指派还没人认领,我咋整?—— Scrum Master的心酸谁能知?【敏捷智库知识卡】 第11期 项目团队人员变动频繁怎么办——大牛走了,你怕不怕?【敏捷智库知识卡】第12期 需求剪不断理还乱(内附1-12期卡片合集下载)
  • [技术干货] 【冬哥有话说】敏捷&DevOps系列合集
    DevOps VS 敏捷:傻傻分不清楚DevOps入门系列DevOps入门篇1-概念、技术实践、研发工具链DevOps入门篇2—DevOps的3大核心基础架构DevOps入门篇3——朴素的DevOps价值观:业务、架构与技术DevOps入门篇4——朴素的DevOps价值观:人、流程与工具DevOps入门篇5——朴素的DevOps价值观:原则、方法与实践
  • [热门活动] 【有奖反馈】敏捷智库知识卡出新版啦!选出你喜欢的知识卡,好礼等你拿~
    第13期敏捷智库知识卡出新版啦~~蓝色清新海报款,白色简洁流程图喜欢哪一款?参与反馈就有机会获得华为手环,蓝牙音箱等。点击下方链接或者扫描图片上二维码即可参与,让我们马上开始吧~https://devcloud.huaweicloud.com/expert/open-assessment/qtn?id=e40ffc503cad4841935db18d6af933a9往期卡片回顾:【敏捷智库知识卡】第1-7期合集【敏捷智库知识卡】 第8期 拍脑袋估算法?OUT!:科学估算,平稳生产,嗷闪!【敏捷智库知识卡】第9期 微服务架构难落地?MSA实施指导框架来帮你【敏捷智库知识卡】 第10期 任务不让指派还没人认领,我咋整?—— Scrum Master的心酸谁能知?【敏捷智库知识卡】 第11期 项目团队人员变动频繁怎么办——大牛走了,你怕不怕?【敏捷智库知识卡】第12期 需求剪不断理还乱(内附1-12期卡片合集下载)高清无水印知识卡请点击附件下载
  • [热门活动] 【有奖反馈】敏捷智库知识卡出新版啦!选出你喜欢的知识卡,好礼等你拿~
    第13期敏捷智库知识卡出新版啦~~蓝色清新海报款,白色简洁流程图喜欢哪一款?参与反馈就有机会获得华为手环,蓝牙音箱等。点击下方链接或者扫描图片上二维码即可参与,让我们马上开始吧~https://devcloud.huaweicloud.com/expert/open-assessment/qtn?id=e40ffc503cad4841935db18d6af933a9往期卡片回顾:【敏捷智库知识卡】第1-7期合集【敏捷智库知识卡】 第8期 拍脑袋估算法?OUT!:科学估算,平稳生产,嗷闪!【敏捷智库知识卡】第9期 微服务架构难落地?MSA实施指导框架来帮你【敏捷智库知识卡】 第10期 任务不让指派还没人认领,我咋整?—— Scrum Master的心酸谁能知?【敏捷智库知识卡】 第11期 项目团队人员变动频繁怎么办——大牛走了,你怕不怕?【敏捷智库知识卡】第12期 需求剪不断理还乱(内附1-12期卡片合集下载)高清无水印知识卡请点击附件下载
  • [技术干货] 【敏捷智库2020年8月刊】 本期推荐:包不同的沙雕敏捷,敏捷需求管理系列分享
    【摘要】 敏捷智库月刊,每月更新一刊,欢迎大家品读。本期推荐包不同的沙雕敏捷、敏捷需求管理系列、规模化敏捷、敏捷教练Lucy和实战专家管知时、RSG2020,精彩内容值得分享。月刊反馈有礼,点这里惊喜等着你~【敏捷智库2020年6月刊】 本期推荐:敏捷和效能专家郑立,第14次敏捷报告重磅解读【敏捷智库2020年7月刊】 本期推荐:专家Yegor解密软件质量墙,DevSecOps的前世今生完整无水印版请下载附件。
  • [技术干货] 【大咖分享】敏捷教练的成长之路
    分享专家: Lucy Liu   Scrum Alliance 认证敏捷团队教练CTC  大家都说现在是VUCA的时代,变化及不确定。那么敏捷Agile,能够更好的应对变化及不确定性,聚焦客户价值,快速的迭代反馈,持续的改进,让人们保持较高的热情投入到工作中。这也是二十年来在IT领域中敏捷盛行的原因,这种趋势在逐步的扩大到传统企业的转型中,汽车制造、快消品、金融等,而且势不可挡。在这些企业敏捷转型中,有一个角色起到了非常大的作用,它就是敏捷教练。据说在国内一份今年的IT行业薪资调查中,敏捷教练高居榜首。今天我们不讨论敏捷教练能够给企业带来的价值,而是来看看敏捷教练的成长之路,或许可窥见它能提供的价值。 2020年,对于我的敏捷之路,是非常关键的一年。我拿到了Scrum Alliance的团队教练,当时是国内的第四位,具备认证Certified ScrumMaster (CSM) 和Certified Product Owner (CSPO) 的资格。这对于我来说,是非常大的肯定和里程碑,也支持我继续走在这条并不好走的道路上。 在转做敏捷教练之前,我在大外企做团队经理,感觉各方面挺不错。但也有对职业发展的忧虑,不清楚自己的下一步去往哪里。在花费了很多精力优化团队流程,提升质量的过程中,偶然接触到了敏捷,申请在团队中尝试。那是在2012年,也是我接触敏捷的开始。边尝试边学习,把一整个业务线做敏捷转型,前前后后做了5年。直到2017年,因为扎实的敏捷转型经验和对敏捷的热情,有机会转做公司亚太区的敏捷教练。一次机缘巧合,在全球敏捷大会中,认识了CST老师,开启了敏捷社区的参与。在那次国际大会中,认识了很多有名的敏捷教练,听了很多经验分享和讨论,收到很多的启发。从那时起,正式开始了专业的敏捷教练的历程和精进。敏捷教练8项必备技能1、团队级敏捷教练的经验        扎实的团队级敏捷教练的经验,接触不同类型、背景、成熟度的团队,给与不同的指导和带领。几十个团队的经验积累,可以大大提升专业技能,应对不同的情况。这部分我是自己真正动手参与的,积累的。我不能确定是否有捷径可以走,但这部分的积累在之后教练工作中一定用得到。 2、敏捷领导力        敏捷转型中,最难的是哪部分?我认为是领导。如果领导是支持的,是有强大意愿推动的,那么就有了很好的基础去做转型。那么敏捷教练需要什么技能?很好的沟通能力,向上管理的能力,影响力,教练能力,可以让老板支持又有一定的耐心,一起朝着目标前进。3、引导技能        初级的敏捷教练,我认为引导技能的需求高于专业教练技能。引导技能在很多场合都可以应用,明显的就是各种会议中,提升效率,激发意愿。如果再熟练掌握心法,在对话中也是可以应用的。我学习引导至少有十年的时间,一开始是自己查一些资料和书籍,边学边用,已经觉得很有效果。后来师从Pepe Nummi,是芬兰引导协会的第一任主席,中正又谦逊,让我的引导技能精进不少,也拿到了Pepe在国内引导课程的认证讲师资格。4、培训技能        这个在我转做教练之后,还真是花费了一番功夫。之前也是做过团队培训的,但连续2天的专业培训没有做过。第一次讲完,觉得自己嗓子都冒烟了,整个人也超级疲惫,内容中也有不满意的地方。另外一位伙伴帮忙把所有上课的过程都录制下来,再基于反馈的基础上回看和再次调整,终于可以把所有的敏捷相关的课程高质量的交付。还专门学了一些发声技巧,结合一些引导技术在课程中,效果也越来越好。5、专业教练        职位是敏捷教练,所以有个教练在其中。大家最常见的是运动教练,那么为什么一个足球队可以赢得胜利?队员是一方面,也要有好的教练。教练可以专业上给与指导,经验上分享,战术上制定,情绪上纾解与鼓励。。。最重要的,教练聚焦于成果和未来,这也是与心理咨询有很大不同的地方。在专业教练上,我没有一开始就选择国际教练联合会ICF的专业课程,而是选择跟Vernon Stinebaker 老师学习,老师是PCC。在老师的指导下,我系统的学习了Scrum Alliance的Path to Coaching的项目,并且老师也对我进行了一对一的长时间的指导。另**加了Coaches Rising这个国际组织提供的教练相关的学习,这里面的老师都是国际知名的,比如前面提到的《领导者的意识进化》的作者Jennifer等。经过大量的练习,基本达到了ACC的专业教练水平,顺利通过了Scrum Alliance关于这方面的考核。那么今年,我又选择去参加专业教练的系统学习,可以在这方面继续精进。6、自我觉察        在最近的两三年,因为专业教练的学习,我发觉自己更加的敏感。发生一些事情,或者脑中有一些想法时,可以去看自己思考的逻辑,自己的着眼点,为什么会产生这样的情绪或者想法?这种想法有可能是不对的吗?对方的出发点是什么?即使我不同意,能否真心感谢和接纳?怎样改变自己的言语创造更好的协作空间?这方面的觉察,不只在工作中得到应用,在个人的生活中也是非常明显的。以往可能一说到什么就生气,现在自己能察觉到模式,那么就可以有效管理和改善。这也打开了自我意识进化的可能,察觉自我的模式,打破旧模式,建立新模式。过程是漫长的,但转化是必然的。7、持续学习        每一位敏捷人,都充满了向上的力量,不管是思想还是行为上。一直都在保持着持续的学习,各种的课程,会议,分享等等。当然我也不例外。每年都在持续的提升自己,今年主要是在专业教练和领导力方面投入很大。8、敏捷社区的投入        我比较明显的是对建设敏捷社区的投入。不只是组织各种的全国敏捷大会,也会有各种小的分享。今年组织了每周一次的教练诊所,希望能提供切实的经验给到敏捷的实践者。我的绝大部分工作外的时间,除了学习,都是在建设社区的工作中。这当然也给了我无穷的回馈,获得社区伙伴的支持和认可。我经常说社区给我力量,所以我也很感恩社区!这可能也跟我的性格相关,外向型性格的人,需要从周围环境中获得反馈和能量。一起打造好社区,是我们每一位伙伴应该做的,因为社区是能让我们长久良性发展的土壤。 想要做好一个教练,上面够了吗?这只是开始,还有很多内容需要修炼。比如创新,绩效体系,大规模的敏捷实施,传统领域的转型,组织进化。。。最后 当把自己的能力逐步提升,扎扎实实的走好每一步,一定会给组织提供更多的价值,也能够让组织认可这种价值。教练这个职业,是一个需要累积的职业,但也是一个长青的职业。很多事情都可以人工智能取代,但跟人打交道的事情,应该是最后被攻克的堡垒吧。一起加油吧!愿我们都能拥有自主选择的权利--- 这也是我一直追求的,自己手握选择的权利!愿我们每一位伙伴都能活出自我,心里有火,眼里有光! 
  • [技术干货] 项目管理:如何显性管理并提升Story分解能力
    引言:在“DevOps能力之屋(CapabilitiesHouse of DevOps)”中,华为云DevCloud提出(工程方法+最佳实践+生态)×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列,针对DevOps领域场景,阐述该场景在华为云DevCloud上的实施方法与实践。在敏捷项目中,用户故事(User Story)是产品团队用来描述用户需求的主要方式。每个用户故事是小的、独立的行为,最好可以在一个迭代中增量式实现,并为最终用户提供价值。Bill Wake提出的INVEST模型,描述了良好的用户故事应该具备的特征,是用户故事应该遵循的原则:•     Independent:独立性•     Negotiable:可协商性•     Valuable:有价值•     Estimable:可估算性•     Small:短小•     Testable:可测试性将业务特性分解成为符合INVEST模型的用户故事,成为每一个敏捷团队的必备技能。LeffingWell在《Agile SoftwareRequirements 》一书中提出了分解故事的10种方法:•     Workflow steps•     Business rulevariations•     Major effort•     Simple/complex•     Variations in data•     Data entry methods•     Deferred systemqualities•     Operations •     Use-case scenarios•     Break-out spike不少人经常会说分解用户故事在增量式开发中既是艺术性又是科学性工作。敏捷产品团队可以参照10种方法进行故事分解,并使之尽量符合INVEST原则。然而敏捷产品团队如何在软件交付中记录故事分解方法,以更好地分享方法或者事后回顾改进或者统计分析呢?当然比较好的方式是采用敏捷项目管理工具,例如华为云DevCloud的项目管理(ProjectMan)。在华为云DevCloud的项目管理中Story并没有缺省字段来记录分解方法,因此需要通过“Story设置”特性来自定义此字段。用户可以在项目中通过“设置”-“项目设置”-“Story设置”-“字段与模板”进入工作项模板页面,如图所示:在工作项模板页面,点击“编辑模板”,并在字段配置处点击“+新建字段”,在下图中输入字段名称、字段类型以及字段选项等。将工作项模板编辑后进行保存。新建字段“故事分解方法”这样,在新建Story或者编辑Story的时候,团队成员可以记录故事分解方法。如下图所示在Story中记录故事分解方法随着敏捷项目的迭代进行,产品团队将不断积累此项目的故事分解方法,团队成员可以基于此数据进行分享与学习,将局部的、隐性的分解方法变为了全局的、显性的分解方法。这也正是DevOps三步法(Three Ways)在持续学习与实验中提倡的实践之一“将局部知识转化为全局知识”。一旦在项目迭代开发过程中,团队积累了故事分解方法的过程数据,那么团队可以在适当的实际进行相应的统计分析。对于故事分解方法的统计分析,目前华为云DevCloud的项目管理的自定义报表特性尚未提供基于自定义字段的维度分析,产品团队可以使用工作项导出特性,将Story导出到Excel进行统计分析,发现分解方法的一些规律,可以指导产品团队更好地有重点地提升分解能力。