企业出海经常会面临网络不稳定、延时高的问题，直接影响用户的访问和出海业务的发展。这是因为当前网络主要是通过光纤传输，传播路径长，物理传输速度有限，用户跨境访问服务器不可免的存在高延时，影响访问。华为云网络服务可以提供一种新的选择——云连接CC。通过云连接，企业可以基于合规跨境实现业务应用在全球的分布式部署，支持海外终端用户就近高效访问企业应用前端，该服务使用简单灵活，性能优异。云连接产品优势：全网互联，简单灵活、性能优异、全球合规维度云连接VPC对等连接公网EIP组网能力支持多Region   VPC互通支持云下单点接入访问多Region VPCRegion内VPC点到点互通，不支持跨Region VPC互通或多VPC互通云下基于云专线单点接入访问所在Region VPC，无法访问其他Region VPC跨Region间VPC点到点互通，不支持Region内VPC互通或多VPC互通组网性能基于专用MPLS网络承载，高性能高可靠，安全性高基于DCN网络承载，高性能高可靠，安全性高基于Internet承载，性能及可靠性无法保证，安全性需要基于IPSec保证跨云能力支持跨华为云及伙伴云互通不支持跨云互通支持跨华为云及伙伴云互通合规跨境具备合规跨境资格不具备跨境能力不具备合规跨境资格 典型场景：跨国企业协同办公场景：海外办公点接入国内云上/数据中心应用或者海外有分布式系统部署的企业。传统方案：各子公司建立一个小型数据中心的节点分别管理；各子公司之间如涉及跨境还需要进行备案，遵从法律要求。痛点：因为使用时间过长而逐渐跟不上使用需求，需要更新设备、增配运维人员等。但这样不仅意味着人力成本大大增加，数据中心设备升级的难度也很大。如上图：ERP系统云上部署环境，要求海内外分支机构云上VPC部署的应用可高效访问主VPC部署的应用系统（本图以ERP系统为例）使用云连接CC的优势：1.   基于华为云全球区域，出海灵活扩展业务，通过云连接快速实现互联，组建支持企业海外多VPC业务部署的云上网络2.   简单灵活：只需三步，分钟级让海外多VPC上的业务快速互通，且支持混合云架构3.   全球合规：提供全球一站式合规的网络能力，支持用户专注自身业务创新 数据备份或同步场景：国内外跨地域开发部署及数据传输备份等业务（例如OBS，VBS，CSBS，软件仓库，数据库备份等），需要不同站点间高速通道和稳定的数据传输。痛点：1.   不同地区间网络资源获取慢，专线资源耗时长，费用高；2.   各国对企业数据跨境合规的要求日趋严格，跨境专线申请困难、审批周期长。3.   Internet长程连接时延大，丢包率高。方案：各地区业务可以通过配置云连接，实现对其他地区业务应用的数据同步和备份。使用云连接CC的优势：1.   只需三步，分钟级让海外多VPC上的业务快速互通2.   带宽弹性灵活3.   全球合规：提供全球一站式合规的网络能力，支持用户专注自身业务创新4.   华为全球网络基础设施能力，提供低时延、高质量体验 企业在混合云架构下跨Region网络互通结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的 “两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。场景：中大型企业基于公有云多Region部署两地三中心架构，应用本地双活并进行异地云上灾备痛点：1.   预算有限：自建数据中心实现两地三中心的成本太高；2.   缺乏经验：没有两地三中心灾备实施经验。优势：在华为云上可以通过云连接连通云生产、灾备两个Region，搭配ELB，RDS，OBS等云服务实现“两地三中心”架构，保证业务的高可靠性。 互联网（视频/游戏加速）场景场景：出海企业在国内部署业务，同时也需要给海外用户提供业务。痛点：海外客户访问在国内部署的应用，时延长，丢包率升高。方案：企业在海外使用云资源用于业务贴近End-User部署。优势：通过使用云连接，用户接入就近Region VPC，通过云连接跨Region跨境访问总部服务器，网络全球延时缩短到158ms，丢包率大大降低。优化前端Internet用户访问部署在后端Region的业务的端到端访问体验。

常常有童鞋做完任务领了奖励就挥一挥衣袖不带走一片云彩但是！！创建的资源没有删，它它它就一直在扣费啊，心痛！所以小助手在这出个删除【ELB+集群+VPC】的教程，避免大家有不必要的损失。删除资源秘笈一、首先删除我们创建的环境（这个免费）二、其次删除ELB负载均衡器（这个正在扣钱）先删除监听器：listener-test01和listener-HTTP然后返回负载均衡器页面删除ELB，记得一定要勾选【释放该负载均衡绑定的弹性公网IP，不然要再去删一遍弹性IP，切记】三、然后删除k8s集群（这个扣钱最多）注意：如果是购买的包年包月，则无需操作，包租期类型的资源到期之后会自动释放先在基础设施下找到K8S集群，单击要删除集群的“更多”下的删除集群然后勾选图上内容，输入“DELETE”确认删除即可四、再然后删除弹性IP（扣钱ing）先在左上角服务下找到虚拟私有云VPC，并进入控制台然后在弹性公网IP和带宽下找到弹性公网IP，如果操作需要解绑，那就先解绑再删除，如果不需要解绑，就直接点更多里面的删除即可。五、最后删除VPC（这个免费）先在基础设施下找到虚拟私有云（VPC），单击要VPC的名称找到子网并删除，才能删除VPC注意，出现如下提示，是因为集群还没完全删除，需要【休息休息一下】，等待集群删除完成就可以啦！集群删除成功后，单击操作中的删除，子网也可以删除了最后在虚拟私有云页面删除VPC即可好啦，本次的保姆级删除资源教程就到这里，还有啥问题可以直接社区发帖求助哦，小助手不会的，大神来帮忙！

资源创建之创建VPC、CCE集群和ELB创建虚拟私有云以及子网                                步骤 1      登录控制台，选择“虚拟私有云”。                                步骤 2      单击“创建虚拟私有云”。                                步骤 3      在“创建虚拟私有云”页面，根据界面提示配置虚拟私有云参数。                                表1-1 创建虚拟私有云参数配置                                                                其它使用默认配置，单击“立即创建”。                                ----结束                                至此您已经快速创建一个虚拟私有云。快速创建Kubernetes混合集群                                步骤 1      登录控制台，在左侧导航栏中单击“基础设施 > K8S集群（CCE）”，单击“创建Kubernetes集群”，单击 “创建混合集群”，进入购买混合集群页面。                                步骤 2      在购买混合集群页面的“服务选型”步骤中配置集群参数：                                表1-2 创建集群参数配置                                          其它使用默认配置，单击“下一步：创建节点”进入“创建节点”步骤。                                步骤 1      在“创建节点”步骤中，配置如下参数：                                l   计费模式：跟随集群的计费方式。                                l   可用区：选择“可用区1”。                                l   节点名称：cluster-test01-node01。                                l   节点规格选择“2核8GB”，如下图：                                       l   其它使用默认配置                                步骤 2      单击“下一步：安装插件”，使用默认配置。                                步骤 3      单击“下一步：配置确认”，勾选“使用说明”的“我已知晓上述限制”。                                步骤 4      确认规格和费用后，单击“去支付”。           勾选领取的代金券并完成订单即可。                                集群创建预计需要6-10分钟，您可以单击“返回集群管理”进行其他操作或单击“查看集群事件列表”后查看集群详情。                                ----结束                                至此，您已经快速创建一个Kubernetes集群。快速购买弹性IP并绑定集群                                步骤 1      登录控制台，在左侧导航栏中单击“弹性公网IP和带宽 > 弹性公网IP”，单击“购买弹性公网IP”，选择 “共享负载均衡”，进入购买弹性负载均衡页面。                                步骤 2      在购买弹性IP页面中配置如下参数：                                步骤 3      单击“立即购买”，确认参数并提交。                                步骤 4      在绑定弹性公网IP：在“弹性公网IP”界面待绑定弹性公网IP地址所在行，单击“绑定”。选择实例。单击“确定”。                                ----结束                                至此，您已经快速创建一个弹性公网IP并绑定实例。快速创建ELB负载均衡器                                步骤 1      登录控制台，在左侧导航栏中单击“弹性负载均衡 > 负载均衡器”，单击“购买弹性负载均衡”，选择 “共享负载均衡”，进入购买弹性负载均衡页面。                                步骤 2      在购买弹性负载均衡页面中配置参数：                                表1-1 购买弹性负载均衡参数配置                                                                其它使用默认配置，单击“立即购买”。                                 步骤 3      负载均衡创建完成后，需要配置监听器。在左侧导航栏中单击“弹性负载均衡 > 负载均衡器”                                步骤 4      在刚才创建的负载均衡的“监听器（前端协议/端口）”一列点击“点我开始配置”。                                步骤 5      在“监听器”页签单击添加监听器，配置如下：                                l   前端协议/端口： TCP/31543                                l   名称：server_group-test01。                                l   其它使用默认配置                                步骤 7      单击“完成”，ELB配置成功。                                ----结束                                至此，您已经快速创建一个ELB负载均衡器。                                

参照你们DVPP接口文档以及sample，对VPC接口输入输出的图片的尺寸限制有点不明白宽和高的对齐方式分别是什么？宽和高最大和最小分别是多少？(下图中“约束条件”标红部分针对的是输入还是输出？还是指的是输入和输出？适用的是所有VPC功能，还是特定功能的约束？)参照Sample工程下的DecodeVideo和DecodeImage，为什么DecodeVideo 里执行DvppCtl时设置输出ROI的宽高对齐是128 * 16（DVPP_STRIDE_WIDTH * DVPP_STRIDE_HEIGHT） ，而DecodeImage里DvppCtl接口设置输出ROI的宽高对齐是16*2 (DVPP_STRIDE_16 * DVPP_STRIDE_2)参照Sample工程下的DecodeVideo，VdecCtl 接口解码出来的视频是 宽128对齐，高16对齐吗？根据文档介绍VPC输入宽高对其情况如下图，这个应该是输入的对齐方式，输出对齐方式是什么样的？

学习网络规划设计 助力企业轻松上云       如今，企业上云已成为热门话题，云可以驱动流程创新和业务创新，成为企业新的利润增长点，被看成是企业实现数字化转型的必经之路。华为云网络服务可以为企业用户的云服务器、云容器、云数据库等资源构建隔离的、用户自主配置和管理的虚拟网络环境，提升用户云上资源的安全性，简化用户的网络部署。如何更好地运用云上网络，保证其安全性、可控性？云上网络规划成为重中之重。学习华为云微认证《企业上云网络规划设计》，你将提升对华为云网络规划设计能力，为企业上云助一臂之力！华为云网络服务小讲堂在使用传统数据中心时，需要管理复杂的网络装置，包括服务器机架、路由器、防火墙设备等，但是在云上可以更快地自定义服务并调节其规模，以应对不同用户的需求。在学习云上网络规划之前，我们先来了解一下华为云上部分网络服务。       VPC：虚拟私有云 是用户在华为云上申请的隔离的、私密的虚拟网络环境。       EIP：弹性公网IP 提供独立的公网IP资源，包括公网IP地址与公网出口带宽服务。       VPN：虚拟专用网络 用于在远端用户和虚拟私有云之间建立一条安全加密的公网通信隧道，当您作为远端用户需要访问VPC的业务资源时，您可以通过VPN连通VPC。       NAT网关：能够为虚拟私有云内的弹性云服务器提供网络地址转换服务，使多个弹性云服务器可以共享使用弹性IP访问Internet。       DNS：云解析服务 提供高可用，高扩展的权威DNS服务和DNS管理服务，把人们常用的域名或应用资源转换成用于计算机连接的IP地址，从而将最终用户路由到相应的应用资源上。对等连接：两个VPC之间的网络连接。终端节点：VPC终端节点能够将VPC私密地连接到终端节点服务，使VPC中的云资源无需弹性公网IP就能够访问终端节点服务。       了解了这么多云上网络服务知识，接下来我们如何规划设计云上网络呢？做完下面的实验，你就可以掌握云上网络规划设计啦！实验六步走 推开企业网络设计的大门       下面这张图就模拟了企业实际环境，我们用一个实验就能搭建好这看似复杂的一张架构图。       1、搭建本地数据中心 也就是图上的广州区域。2、配置VPN连接 实现本地数据中心跟云上环境（上海区域）互联互通。3、创建NAT网关 使得Public Subnet下面的资源能够通过SNAT规则访问互联网。而位于Private Subnet的资源则限制访问互联网。4、部署云上环境WEB业务 为图上的上海区域配置DNS内网解析并添加关于RDS内网IP地址的A记录，使得WEB业务能够通过域名访问数据库。5、配置VPC对等连接 因业务环境变化，需要在云上环境（上海区域）再次新增一个VPC，并通过VPC对等连接配置两个VPC能够互相通信。6、配置VPC终端节点内网访问OBS 如果你希望自己的本地数据中心通过VPN或者云专线以内网方式访问OBS服务，可以通过创建终端节点连接终端节点服务实现。通过上述实践，你就能快速了解华为云网络服务，提升企业业务上云后服务的安全性、可控性。想不想轻松掌握，来开启《企业云上网络规划设计》学习之旅吧，小白也能变大咖哦。       如果您是对云网络感兴趣的人员，计划上云的企业运维人员、架构师和社会大众，那么就来学习《企业云上网络规划设计》，来提升对华为云网络规划设计能力吧，点击链接，详细了解一下吧！  

【背景】当前在华为云华南、华东、香港region均部署了业务，同时在华南region通过云专线与线下IDC打通，线下IDC有需要提供服务的IDC Server，想实现各region间正常互通以及各region与华南IDC Server数据的交互。【拓扑分析】【前提条件】确保安全组/网络ACL/安全设备等已放通对应端口、地址、网段【操作步骤】一、创建各region的实例（VPC）1）登录控制台，创建对应region的VPC2）全部创建完成后如下3）按照拓扑规划，为各VPC内添加对应的ECS（共计4台）以及线下IDC通过云专线接入的服务器一台（10.32.0.32）4）在加入云连接之前，对各region内VPC的ECS（且ECS未购买EIP）进行连通性测试，均不可达二、将这些region的VPC通过云连接打通1）进入控制台，创建云连接2）云连接创建好后，需要加载网络实例，将各实例打通（此处的实例指的是VPC）3）将实例加载到云连接参数说明：区域：您将要添加的实例所在的区域（region）VPC：您将要添加的实例名（当同一region有多个实例时，需要添加多次）VPC CIDRs：您将要添加的实例对应的子网信息（可全选也可选择部分子网，部分有安全要求的子网可以不添加，这样起到了安全保护的作用）4）继续加载，直到所有的实例添加完成，此时也可以看到添加好后生成的路由信息5）购买带宽包，分配域间带宽分配完成后，云连接创建完成。三、结果验证1）通过登录香港的ECS，进行同region不同vpc测试，不同region不同vpc测试，以及各regionECS到华南IDC Server测试，发现已全部可达，后续业务可正常交互。【结果验证截图中，直接ping了各服务的域名，提前做了解析，更方便识别】

最近几个月，我的变化其实还蛮大的，从一个被实习生“无视”的“前浪”，转变成了不仅能够解决技术问题还能解决业务问题（顺手还能帮实习生解决恋爱问题）的“前辈”。前面几期故事记录了我的高光时刻，有兴趣可以点击前文查看（https://bbs.huaweicloud.com/forum/forum-1104-1.html）。 公司的短视频项目上线之后一直不温不火，老板挺着急，运营部提出要在6月底组织一次千人直播带货活动，邀请1千个主播同时在短视频平台上开直播，拉用户和流量。 千人同时在线直播，短视频平台的目标访问量在百万级以上，需要技术部门保证高并发流量下服务器的稳定。这个好办，华为云弹性云服务器是可以随时扩容的，经过部门研究，我们给出的技术方案是临时创建100台云虚拟机来支撑这次活动。 这个任务又光荣地落到了我的身上，谁让我是公司公认的云服务器专家呢…可离直播活动落地只有一个星期的时间了，还要留出时间进行压测。“通过API可以批量处理弹性云服务器，但我现在一个个接口封装也来不及啊！而且根据我的经验，还得提前做好随时扩容的准备，能够支持比预估目标更高的流量，得赶紧想想除了API还有什么可以用……”我心里有点着急了。 习惯性地打开华为云官网，在首页发呆了1分钟，一道灵光闪过：操作简单，可以快速控制批量资源，这可不就是SDK的特性吗！说来就来，我很快就有了思路：先快速创建100台按需计费的弹性云服务器作为直播支撑，在直播完成后，再对这些弹性云服务器进行释放。 打开API Explorer（https://apiexplorer.developer.huaweicloud.com/apiexplorer/overview?utm_source=apiwz&utm_medium=read ）快速浏览，确认我需要用到的接口是CreatePostPaidServers 、 ListServerDetails 和DeleteServers。 万万没想到，这个设计还真起到了救急的作用！ 直播开始前1个小时，运营部门突然反馈，这次活动的推广效果大大超出预期，峰值流量可能是预期目标的10倍！这将给网站访问带来很大的压力，老大给我打电话问我有没有办法处理。 这当然难不住我了，因为提前准备了技术方案，在直播过程中随着访问量的变化，随时批量调整服务器的配置，完美保障了直播的进行，最后在10倍于目标值的访问量下，依然没有出现任何卡顿/延迟的情况。 活动结束后，我又开始了疯狂输出，将SDK的配置方法写在了文档里： 一、前置条件：获取必填参数 1.     华为云SDK的认证方式为AK/SK认证，可以在华为云控制台”我的凭证-访问密钥”页面上创建和查看AK/SK。更多信息请查看访问密钥(https://support.huaweicloud.com/usermanual-ca/zh-cn_topic_0046606340.html)。 2.     准备接口的必填参数PS：在华为云控制台-镜像服务IMS中可快速获取公共镜像相应的ID服务器配置详情：l   区域：华北-北京一 - cn-north-1l   可用区：可用区1 - cn-north-1al   规格：通用计算增强型 - c3.large.2l   镜像：Windows Server 2019数据中心版 64 位简体中文 - fb48d5c7-8718-489a-9273-d3e0e09c84d7l   服务器名：任意指定 - 如 "live-stream”l   系统盘类型：普通 IO 磁盘 – "SATA"l   虚拟私有云 ID（VPC ID）：可获取当前账号在北京一区域中默认的 VPC ID，若没有默认 VPC 则新建l   网卡信息：可获取当前账号在北京一区域中默认 PC / 新建 VPC 下的子网 IDl   允许重名：当批量创建弹性云服务器时,云服务器名称是否允许重名,当count大于1的时候该参数生效 - false 二、实战演练PS：指南：https://github.com/huaweicloud/huaweicloud-sdk-java-v3/blob/master/README_CN.md 1.     新建maven项目，导入SDK的maven依赖<!-- add dependencies in pom.xml --><dependency>    <groupId>com.huaweicloud.sdk</groupId>    <artifactId>huaweicloud-sdk-core</artifactId>    <version>[3.0.1-beta, 3.1.0-beta)</version></dependency><dependency>    <groupId>com.huaweicloud.sdk</groupId>    <artifactId>huaweicloud-sdk-ecs</artifactId>    <version>[3.0.1-beta, 3.1.0-beta)</version></dependency>2.     批量创建弹性云服务器Demoimport com.huaweicloud.sdk.core.auth.BasicCredentials;import com.huaweicloud.sdk.core.http.HttpConfig;import com.huaweicloud.sdk.ecs.v2.EcsClient;import com.huaweicloud.sdk.ecs.v2.model.*; import java.util.LinkedList;import java.util.List; public class TestCreateEcs {    public static void main(String[] args) {        String ak = "{your ak string}";        String sk = "{your sk string}";        String projectId = "{your project id}";        String endpoint = "https://ecs.cn-north-1.myhuaweicloud.com";         HttpConfig config = HttpConfig.getDefaultHttpConfig().withIgnoreSSLVerification(true);         BasicCredentials credentials = new BasicCredentials().withAk(ak).withSk(sk).withProjectId(projectId);         EcsClient ecsClient = EcsClient.newBuilder().withCredential(credentials).withEndpoint(endpoint).withHttpConfig(config).build();         // 确认创建虚拟机的必填参数        String az = "cn-north-1a";        String flavorRef = "s3.medium.2";        String imageRef = "fb48d5c7-8718-489a-9273-d3e0e09c84d7";        String name = "live-stream";        String vpcId = "{you vpc id}";        // 网卡信息        PostPaidServerNic nic = new PostPaidServerNic().withSubnetId("{your subnet id}");        List<PostPaidServerNic> list = new LinkedList<>();        list.add(nic);        // 系统盘信息        PostPaidServerRootVolume root = new PostPaidServerRootVolume().withVolumetype(PostPaidServerRootVolume.VolumetypeEnum.SATA);         PostPaidServer servers = new PostPaidServer().withAvailabilityZone(az)                .withFlavorRef(flavorRef)                .withImageRef(imageRef)                .withName(name)                .withNics(list)                .withRootVolume(root)                .withVpcid(vpcId)                .withCount(100)                .withIsAutoRename(false);         CreatePostPaidServersRequestBody body = new CreatePostPaidServersRequestBody().withServer(servers);        CreatePostPaidServersRequest request = new CreatePostPaidServersRequest().withBody(body);        CreatePostPaidServersResponse response = ecsClient.createPostPaidServers(request);         System.out.println(response.toString());    }}3.     批量删除弹性云服务器Demo// Step1: 查询当前以"live-stream"为开头的虚拟机列表ListServersDetailsRequest listServersDetailsRequest = new ListServersDetailsRequest().withName("live-stream");ListServersDetailsResponse listServersDetailsResponse =    ecsClient.listServersDetails(listServersDetailsRequest); // Step2: 构造删除请求中的ServerId列表List<ServerDetail> serversList = listServersDetailsResponse.getServers();List<ServerId> serverIdList = new ArrayList<>();for(ServerDetail server : serversList) {    ServerId id = new ServerId().withId(server.getId());    serverIdList.add(id);} // Step3: 传入serverId列表，删除虚拟机DeleteServersRequestBody deleteServersRequestBody = new DeleteServersRequestBody().withServers(serverIdList);DeleteServersRequest deleteServersRequest = new DeleteServersRequest().withBody(deleteServersRequestBody);DeleteServersResponse deleteServersResponse = ecsClient.deleteServers(deleteServersRequest);活动取得了非常好的成绩，实现了短视频平台流量和用户增长的目标，但是这次老板居然没有表扬我，我还有些纳闷：难道老板已经习惯了我的优秀？过了几天，HR小姐姐递过来一张表让我签字，表上写着：“调薪申请表，调薪幅度30%”，老板已经签好了名字。 目前API Explorer平台(https://apiexplorer.developer.huaweicloud.com/apiexplorer/overview?utm_source=apiwz&utm_medium=read)已开放EI企业智能、计算、应用服务、网络、软件开发平台、视频等70+云服务，共上线2000+个API、6000+个错误码。在前期试运行期间，华为云API Explorer平台上的API接口也已被多家企业成功接入。点击查看详情：《API Explorer新功能上线：支持一键分享调用参数，从此定位接口问题只要一键转发就行了，现在试用还有码豆拿哦》华为云API Explorer平台在未来几个月会实现更多功能，比如支持SDK示例代码、CLI等特性，同时也会开放更多的云服务API接口，连接更多开发者实现创新、拓宽创新边界。【拓展阅读】【API进阶之路】因为不会创建云服务器，我被实习生摆了一道【API进阶之路】前浪的绝地反击与自我证明【API进阶之路】甩锅大会上，我是如何绝地求生的【API进阶之路】一个技术预案，让老板当场喊出了“奥利给”【API进阶之路】万万没想到，一个技术方案帮实习生追到了运营妹子!【API进阶之路】一个技术盲点，差点让整个项目翻车【API进阶之路】老板给我涨薪30%！如何通过SDK接口搞定千万级流量直播【API进阶之路】半天搞定百万条手机号归属地查询，竟影响了公司战略方向！【API进阶之路】无法想象！大龄码农的硬盘里有这么多宝藏【API进阶之路】高考要考口语？一场10w+刷屏活动是如何用多模态评测API做出来的【API进阶之路】帮公司省下20万调研费！如何巧用情感分析API实现用户偏好调研【API进阶之路】逆袭！用关键词抽取API搞定用户需求洞察【华为云API学习赛】为入门初学者量身定制的学习平台，以赛带学，学以致用。参赛、邀请都有丰富奖品，还有机会拿P40 5G手机~API入门学习赛·AI人脸识别l   报名地址l   奖项设置API入门学习赛·探险寻宝之旅l   报名地址l   奖项设置

作者：黄药师（黄隽）背景在某开发团队辅导的回顾会议上，团队成员对于优化估计具体方法上达成了一致意见。询问是否有什么具体的估计方法来做估算。问题分析回顾意见上大家对本次Sprint的效果做回顾，其中80%的成员对于本次Sprint的估算效果不满意，最终团队希望在下一个Sprint中，估算活动能有所改善。经了解，团队目前的估算方法很简单，基本上是架构师和团队中有丰富开发经验的成员一言堂。估算的速度也很快。对于有些有疑问的需求，开发成员也是保持沉默，草草认领了任务。团队迫切希望学习新的估算方法来优化目前的估算活动，因此分享几个具体的估算方法给团队实践，让他们自己选择适合、喜欢的估算方法是解决问题的关键。解决措施上篇《如何估算第三篇：利用故事点做估算》了解了什么是故事点后，我们来学习下具体的故事点估算的实践，感受一下估算。这里介绍最常用的两种估算方法：一个是计划扑克估算，另一个是敏捷估算2.0。下表内容展示了这两种估算方法在什么情形下选择。估算方法选择理由计划扑克估算ü  使不同技术水平和工作速度的人在估算结果上保持一致。ü  激发对工作项细节的思考，让所有假设都显露出来，充分了解工作项。ü  需要估算的用户故事量不是非常大（例如，500个就非常大，采用此方法会非常耗时）。敏捷估算2.0ü  通常耗费的时间会缩短。ü  需要估算的用户故事非常多。计划扑克估算在敏捷开发中，最典型的使用故事点做估算的方法是计划扑克（Planning Poker）。计划扑克由James Grenning在2002年首次提出。计划扑克集合了专家意见（Expert Opinion），类比（Analogy）以及分解（Disaggregation）这三种常用的估算方法，使团队通过一个愉快的过程快速而准确的得出估算结果。计划扑克的参与者是团队的所有成员。典型的敏捷团队规模推荐为7±2人，如规模比较大可以考虑拆分成为多个小团队各自独立进行估算。Product Owner也需要参加，但不参与估算。计划扑克开始时，每个参与估算的组员都会得到一副计划扑克，每一张牌上写有一个Fibonacci数字 （典型的计划扑克由12张牌组成：?，0, ½，1, 2, 3, 5, 8, 13, 20, 40, 100,∞，其中?代表信息不够无法估算，∞代表该用户故事太大）。开始对一个用户故事进行估算时，首先由Product Owner介绍这个用户故事的描述。过程中Product Owner回答组员任何关于该用户故事的问题。展开讨论时主持人(通常由Scrum Master担任)应注意控制时间与细节程度，只要团队觉得对用户故事信息已经了解到可以估算了，就应当中止讨论开始估算。所有问题都被澄清后，每一个组员从 扑克中挑选他／她觉得可以表达这个用户故事大小的一张牌，但是不亮牌，也不让别的组员知道自己的分数。所有人都准备好后，主持人发口令让所有人同时亮牌，并保证每个人的估算值都可以被其他人清楚的看到。经常会出现不同组员亮出的分值差距很大的现象。当出现有很多不同分值的时候，出分最高的人和出分最低的人需要向整个团队解释出分的依据。（主持人需要注意控制会议氛围，避免出现意见不一导致的攻击性言论。）所有的讨论应集中于出分者的想法是否值得团队其他成员进行更深入的思考。随后全组可以针对这些想法进行几分钟的自由讨论。讨论之后，团队进行下一轮的全组估算。一般来说，很多用户故事在进行第二轮估算的时候就能得到一个全组统一的分值，但是如果不能达到全组意见一致，那么就重复的进行下一轮直到得到统一结论。敏捷估算2.0（Agile Estimating 2.0）计划扑克是Scrum团队应用最广泛的敏捷估算方法，但是有时候计划扑克玩起来耗费比较多的时间，尤其是在十人左右的团队中。Ken Schwaber在他的书《Agile Project Management with Scrum》中指出，在进行迭代规划时，迭代计划环节应该控制为一个4小时的固定时间，但是从战术的角度看，如果一个会议持续4小时，大部分的参会者会有精疲力竭的感觉，并且很难保持持久的注意力。为了解决这个问题，Brad Swanson 和 Björn Jensen在上海Scrum Gathering （2010/4/19）上介绍了Agile Estimating 2.0技术。这个新的估算技术同样基于的专家意见，类比和分解，同样适用Fibonacci数列，但是它可以显著地缩短会议时间。它的估算过程大致分为主要四步，如下图所示：第一步：由Product Owner向团队介绍每一个用户故事，确保所有需求相关的问题都在做估算前得到解决。第二步：整个团队一起参与这个游戏。只有一个简单的游戏规则：一次仅由一个人将一个用户故事卡放在白板的合适位置上：规模小的故事在左，大的在右，一样大的竖向排成一列。整个团队轮流移动故事卡，直到整个团队都认同白板上的故事卡的排序为止。  第三步：团队将故事点（Story Point）分配给每个用户故事（列）。最简单的做法是使用投票来决定每个用户故事分配到哪一个Fibonacci数字。最后一步：使用不同颜色来区分影响估算大小的不同方面，并且重新考虑是否需要修改估算值。例如，我们使用红色来表示那些无法被自动化测试脚本覆盖的用户故事，因此那些用户故事需要一个更大的数字来容纳手工回归测试的代价。在国内一些企业多次实践Agile Estimating 2.0之后，反馈的结果还是令人兴奋。据称，团队对于估算的准确性更有信心了，并且只耗费原先的1/2时间。通过以上介绍，相信了解了如何使用用户故事来分析了解需求。在学习了估算的核心概念及故事点后，对于估算方法的实践也有了更深的体会。不论是计划扑克估算还是敏捷估算2.0都只是估算的一种实践，不是固定的唯一方法。只要理解估算的意义和核心概念，选择适合的方法就是没有问题的。另外补充一下，这里讲的估算偏重于用故事点估算，如果团队成员一致达成共识，用工时或理想人天效果更好，便可以尝试，给予团队试错的机会，说不定也有意想不到的收获。完成了估算后，我们需要对估算的内容进行管理。华为云DevCloud在用户故事或者Task中均有一个记录估算结果的属性，比如预计工时。所有工作项估算结果记录以后就可以以列表的方式进行查看。可以按处理人排序，查看每个成员认领的任务是否饱和。开发团队完成的工作内容可以时时更新实际数据，这样每轮迭代也可以就估算准确度进行统计和分析。看看估算结果和实际结果的差别，以便可以后续做估算调整和改善。参考附录Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。估算系列文章【DevCloud · 敏捷智库】估算第一篇：利用用户故事了解需求【DevCloud · 敏捷智库】估算第二篇：利用核心概念解决估算常见问题【DevCloud · 敏捷智库】估算第三篇：利用故事点做估算

在《人月神话》的开篇提到焦油坑，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。他们挣扎的越是猛烈，焦油纠缠的越紧，没有任何猛兽足够壮烈或具有足够的技巧，能够挣扎束缚，他们最后都沉到了坑底。大型软件系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统，不过，其中只有非常少数的项目满足了目标、时间进度和预算要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在焦油坑中。‍（人月神话中的焦油坑）软件开发时间（月）的增加，人员数量（人）的增加，软件开发成果与工作量投入（人*月）一定就会同比增加吗？显然不是，因为人员之间的沟通，分工协作，业务的灵活多变，软件工程师技能差异，新技术如5G、人工智能、大数据、AI、物联网等技术复杂度的增加，太多不确定性因素将导致软件开发成果与工作量（人*月）的投入不成线性增长。这些不确定因素越少，软件开发成果与工作量（人*月）的投入就会接近线性增长，不确定因素如何减少呢？在国外，1999年，前甲骨文最副总裁Marc Benioff创立Salesforce，提出“软件终结”口号，面向开发者研发了force.com应用开发平台，基于此快速开发CRM软件系统，开启了低代码应用开发的航程。Mendix低代码领域开发平台成立于2001年，2018年8月被西门子用6亿欧元收购。OutSystems低代码开发平台成立于2002年，2018年6月被KKR和高盛公司联手以3.6亿美元收购。另外，科技巨头们也都纷纷推出自己的低代码开发平台产品，微软在2015年发布的PowerApps、Google 2018年开始测试的App Maker等都是低代码产品。在国内，低代码开发平台在近几年也如雨后春笋般快速的发展起来，宜创科技、奥哲、轻流、简道云、APICloud如今都汇入了低代码赛道，巨头科技企业华为，阿里也都纷纷推出了自己的低代码开发平台：华为的AppCube，阿里的宜搭。高盛私人投资公司董事总经理 Christian Resch 表示：“我们认为低代码开发领域具有非常显著的市场潜力，大多数全球企业正在将其业务数字化，他们正在尽可能利用软件简化运营、建立新的分销渠道、改善客户体验，以及创造新的产品和服务。”根据Forrester的报告，去年该领域的规模估计为 38 亿美元，预计到 2021 年将增长到 152 亿美元。这些低代码平台的崛起，为什么会被投资者看好，被开发者青睐呢?（点击链接参与讨论>>）“低代码”顾名思义就是开发者写很少代码，通过低代码平台提供的界面、逻辑、对象等可视化编排工具来完成大量开发工作，降低文章开篇提到的软件开发中的不确定性因子，从而大幅度的提升开发效率，让企业能够降低开发成本和价格，降低技术和人员门槛，快速创新应用，实现快速试错，敏捷迭代。低代码平台主要面向如下两类人员提供快速开发应用的能力：1、业务人员，通过提供大量的界面模板、业务模板、流程模板和对象模型，业务人员根据实际业务需要通过积木式组装的方式，就可以快速拼装应用系统，从而实现了应用快速创新。2、软件开发工程师，通过页面编排工具和流程编排的能力，开发者可在平台上组件化、微服务化已有的大量服务，再编写少量代码就可以实现自己想要的应用管理系统。以华为低代码开发平台AppCube为例，其为开发者提供了大量的页面组件、流程编排工具BPM、模型编排工具、基线应用模板、AI服务、视频服务、GIS服务、城市信息模型BIM服务、IOT服务等上千种开放接口，开发者利用这些编排工具，调用已有的大量服务，通过编写少量代码就可以实现自己想要的应用管理系统。除了上述的能力外，低代码平台大多数是以SaaS（Software As A Service）方式向开发人员提供服务，开发人员只申请一个开发者账号，就能使用低代码平台提供的线上开发环境，沙箱测试环境，商用部署环境。开发人员开发完毕后在线编译和打包，通过低代码平台提供的自动流水线，可以将软件包从开发环境部署到测试环境和商业环境。开发人员Anywhere，Anytime就可以开发自己的应用，测试自己的应用，发布自己的应用，所见即所得。但是也要看到，做低代码不是直接去造房子，而是做一套能反复造各类房子的引擎和系统，对平台技术的要求很高，国外的低代码玩家都经历了多年的发展，才走出先平后陡的增长曲线。而在国内，我们还有一段路要走，随着技术的不断发展提升以及各行业数字化转型对软件诉求的增强，低代码开发平台凭借其降低开发工作门槛，缓解成本、人才诉求等优势，减少软件开发的不确定性，使开发工作量的投入与软件有效开发结果向线性靠拢，大幅提升软件开发效率，必定也会走上蓬勃发展之路。那么到底当前各低代码开发平台发展的现状，各厂家的优势在哪里，我们下次再盘。作者：董鑫武

华为云关系型数据库RDS具有低成本、高性能、高安全性、高可靠性的优势。下面我来给大家详细解释一番……低成本即开即用您可以通过华为云官网实时生成目标实例，华为云关系型数据库服务配合弹性云服务器一起使用，通过内网连接华为云关系型数据库可以有效地降低应用响应时间、节省公网流量费用。弹性扩容可以根据您的业务情况弹性伸缩所需的资源，按需开支，量身定做。配合云监控（Cloud Eye）监测数据库压力和数据存储量的变化，您可以灵活调整实例规格。完全兼容您无需再次学习，华为云关系型数据库各引擎的操作方法与原生数据库引擎的完全相同。华为云关系型数据库还兼容现有的程序和工具。使用数据复制服务（Data Replication Service，简称DRS），可用极低成本将数据迁移到华为云关系型数据库，享受华为云数据库为您带来的超值服务。运维便捷RDS的日常维护和管理，包括但不限于软硬件故障处理、数据库补丁更新等工作，保障华为云关系型数据库运转正常。提供专业数据库管理平台，重启、重置密码、参数修改、查看错误日志和慢查询日志、恢复数据等一键式功能。提供CPU利用率、IOPS、连接数、磁盘空间等实例信息实时监控及报警，让您随时随地了解实例动态。高性能性能优化华为云多年的数据库研发、搭建和维护经验，结合数据库云化改造技术，大幅优化传统数据库，为您打造更高可用、更高可靠、更高安全、更高性能、即开即用、便捷运维、弹性伸缩的华为云数据库服务。优质的硬件基础华为云关系型数据库使用的是华为经过多年的研究、创新和开发，通过多重考验的服务器硬件，为用户带来稳定的、高性能数据库服务。SQL优化方案华为云关系型数据库提供慢SQL检测，用户可以根据华为云关系型数据库服务提出的优化建议进行代码优化。高端硬件投入关系型数据库使用的所有服务器硬件都经过多方评测，保证在性能和稳定性上都遥遥领先。高速访问关系型数据库可以配合同一地域的弹性云服务器一起使用，通过内网通信，缩短应用响应时间，同时节省公网流量费用。高安全性网络隔离通过虚拟私有云（Virtual Private Cloud，简称VPC）和网络安全组实现网络隔离。虚拟私有云允许租户通过配置虚拟私有云入站IP范围，来控制连接数据库的IP地址段。华为云关系型数据库实例运行在租户独立的虚拟私有云内，可提升华为云关系型数据库实例的安全性。您可以综合运用子网和安全组的配置，来完成华为云关系型数据库实例的隔离。访问控制通过主/子帐号和安全组实现访问控制。创建华为云关系型数据库实例时，华为云关系型数据库服务会为租户同步创建一个数据库主帐户，根据需要创建数据库实例和数据库子帐户，将数据库对象赋予数据库子帐户，从而达到权限分离的目的。可以通过虚拟私有云对华为云关系型数据库实例所在的安全组入站、出站规则进行限制，从而控制可以连接数据库的网络范围。传输加密通过TLS加密、SSL加密实现传输加密。使用从服务控制台上下载的CA根证书，并在连接数据库时提供该证书，对数据库服务端进行认证并达到加密传输的目的。存储加密通过静态加密、表空间加密对数据进行加密。华为云关系型数据库服务支持对存储到数据库中的数据加密后存储，加密密钥由数据加密服务的KMS进行管理。数据删除删除华为云关系型数据库实例时，存储在数据库实例中的数据都会被删除，任何人都无法查看及恢复数据。安全删除不仅包括数据库实例所挂载的磁盘，也包括备份数据的存储空间（通常为廉价的对象存储系统）。防DDoS攻击当用户使用外网连接和访问华为云关系型数据库实例时，可能会遭受DDoS攻击。当华为云关系型数据库安全体系认为用户实例正在遭受DDoS攻击时，会首先启动流量清洗的功能，如果流量清洗无法抵御攻击或者攻击达到黑洞阈值时，将会进行黑洞处理，保证华为云关系型数据库整体服务的可用性。安全防护华为云关系型数据库处于多层防火墙的保护之下，可以有力地抗击各种恶意攻击，保证数据安全，防御DDoS攻击、防SQL注入等。建议用户通过内网访问华为云关系型数据库实例，可使华为云关系型数据库实例免受DDoS攻击风险。高可靠性双机热备华为云关系型数据库服务采用热备架构，故障秒级自动切换。数据备份每天自动备份数据，上传到对象存储服务（Object Storage Service，简称OBS）。备份文件保留732天，支持一键式恢复。用户可以设置自动备份的周期，还可以根据自身业务特点随时发起备份，选择备份周期、修改备份策略。数据恢复支持按备份集和指定时间点的恢复。在大多数场景下，用户可以将732天内任意一个时间点的数据恢复到华为云关系型数据库新实例或已有实例上，数据验证无误后即可将数据迁回华为云关系型数据库主实例，完成数据回溯。

作为刚刚接触云计算的小伙伴，一定迫不及待的想买一台弹性云主机体验一把，一路下来很顺利，选配置、下单、官网远程登录成功。习惯用ssh工具的小伙伴一定不太喜欢那个web版的黑窗口，如何用ssh工具远程访问云主机呢？看到有不少初学者卡这里了，不是上不了网，就是无法远程访问。在这个互联网的时代网络安全尤为重要，华为云提供了全栈的安全保障措施，小伙伴们遇到的不是坑，是在购买ECS时为了确保安全，系统默认给的Sys-default安全组没有开放端口，或没有绑定EIP的原因。本文介绍了如何购买一个鲲鹏云主机，绑定EIP，介绍安全组的规则设置，一步一步指导初学者加入鲲鹏大家庭。第一步 购买ECS鲲鹏云主机1.1 注册华为云账户（https://www.huaweicloud.com/）略，购买鲲鹏ECS云主机，登录后点击控制台à计算à弹性云服务器ECSà购买弹性云服务器；根据您的需求可选择包月或按需计费，选择Region区域、可用区AZ可以随机分配；CPU架构，一定要选择鲲鹏计算（ARM架构），选择一款适合的配置。PS：这里只是为了跑一个demo选择1vCPU1GB足够了，正式开发环境建议用2vCPU4GB以上的配置。1.2 根据实际需求选择镜像类型，这里使用CentOS7.6 64bit with ARM，云硬盘先搞40GB，不够后边可以再扩充。对IO性能有要求，可以选择SSD或超高IO类型的云硬盘。1.3 云主机ECS和物理服务器一样运行在某个网络环境里，默认创新一个VPC虚拟专网（网段192.168.0.0），添加一块网卡，先自动分配IP地址。安全组是华为云提供的一种安全策略，可以保护VPC内的主机，设置访问策略；Sys-default（默认入方向禁止）、Sys-WebServer（开放web服务器常用的端口）、Sys-FullAccess（出和入全部不控制）。1.4 若你希望云主机能上网（访问互联网资源），需要购买一个EIP和网络带宽（和物理服务器一样）。如果这台云主机不需要对外提供服务，只在局域网内工作，暂时不购买需要时再绑定。1.5 给您的鲲鹏云主机起一个名字，如我们要在鲲鹏云主机上安装mysql5，就叫他esc-kp-mysql；设置root的账号和密码（一会儿登录时就用这个密码）；云硬盘可以后边再设计。1.6 确定购买鲲鹏云主机，这是购买下单的最后一步了，列出所选的配置信息，因为没有绑定EIP，因此提示无法访问公网。这里可以一次购买多台相同配置的主机；参考价格一直跟随所选的配置在变化，点击立即购买完成下单。1.7 登录鲲鹏弹性云ECS主机，下单后几秒钟就能看到一台运行中状态的ECS主机了（这就是云的好处之一，可以按需随时购买，免去了物理主机买回来后，要上电安装系统等各种操作）；点击远程登录就可以访问这台主机了。云主机不需要再手动安装操作系统，购买时通过选择镜像，华为云在创建ECS实例时会使用选择的镜像；用配置时设置的密码登录，可以看到属性的[xxxxxxx]# 命名提示符了。第二步 购买EIP远程登录云主机2.1 如果希望用ssh工具远程访问ECS需要绑定一个EIP（让你的云主机可以访问互联网），在控制台左侧选择弹性公网IPà购买弹性公网IP。2.2 根据需要选择计费方式，区域建议和ESC云主机在一个区域，线路有2种选择全动态BGP和静态BGP，对可用性要求不高时可选静态；公网带宽有3中选择，按带宽、流量和共享带宽，根据具体需求选择即可；设置带宽的大小，最后是带宽名称默认即可。2.3 下单确定购买后就可以绑定到ECS云主机上了（作用类似拉一条可以上网的宽带，并且连接到要上网的机器上，只是不需要购买和折腾那些光猫、路由器等硬件了）。2.4 用ssh工具远程连接ECS云主机，发现连不上也ping不同，在云主机Web控制台又可以ping通www.baidu.com，说明EIP肯定是工作正常的；华为云为了安全起见，默认安全组Sys-default入方向规则默认不允许，需要配置一下安全组，开放特定的端口以便ssh可以远程登录。在控制台左侧选择虚拟私有云VPCà访问控制à安全组；可以修改Sys-default或自己创建一个。2.5 创建一个安全组my-ssh并设置规则；入规则：允许ssh远程登录使用22端口；在入方向规则页签点击添加规则或使用快速添加规则选择一个（这里给出了几个常用远程访问开放端口规则）。出规则：全部允许；在出方向规则页签选择“一键放通”添加全部协议的出规则。2.6 修改我们ECS鲲鹏云主机的安全组规则，操作à更多à网络设置à更改安全组，把my-ssh安全组添加进去。可以有多个安全组，他们之间是合并关系。2.7 用ssh工具登录，快乐享用鲲鹏云弹性云主机吧。PS：按需付费时ECS关机会不收费，但云硬盘是会计费的（因为占用着存储资源）。

背景有些团队践行敏捷一段时间后，感觉回顾会议（Retrospective Meeting）时间太长，动辄2-3个小时，而且会议上走形式，会后无效果，那么如何才能让回顾会议有效果呢？问题分析在敏捷十二原则中提到：团队定期地反思如何能提高成效，并依此调整自身的举止表现。所以回顾的目的是为帮助团队定期改善工作，发现障碍和处理问题，从而实现持续改进。回顾想要实现的效果就是持续改进。回顾会议走形式，就无法保证改进计划的质量，没有计划后面的环节就都无从谈起。回顾会后没有执行、检查和调整，都会影响到改进的落地，就出现前面提到的会后无效果的情况。综上所述，要想回顾有效果需要具备两方面的条件：可行的改进项，也就是首先要保证改进计划（Plan）的质量；改进的落地执行，包括执行（Do）、检查（Check）和调整（Act）这几个环节。这样才是一个完整的过程，想要有效果就要做好回顾改进的PDCA。解决措施结合回顾的过程，我们首先需要通过做好会前和会中部分来保证产生可靠的计划；其次回顾会后要做好计划的执行、检查和调整来保证落地执行的效果。第一步：做好回顾的会前和会中工作，保证Plan的质量要保证Plan的质量，就要开好回顾会；开好回顾会，可以从会前和会中两个环节来考虑。会前可以从数据准备、会议设计和会议公约三个方面来考虑会议设计：确定回顾的重点。我们的会议不是大而全，而是小而精，要聚焦，在规定的时间盒内（建议1-1.5小时）产生可行的方案。会议的流程环节设计是为了保证会议按时完成和让会议有好的氛围，让大家都能积极参与。比如会议开始时的签到活动可以让大家聚焦到会议上，ESVP（Exploer,Shopper,Vacationer,Prisoner）的选择可以了解大家的心态；中间数据收集的时候通过事件时间线、表情图可以让团队对迭代情况建立共同背景，通过头脑风暴可以帮助大家发散思维，通过投票排序实现全员参与，共同承诺等等。关于会议的活动方式有很多，团队可以多积累一些。 数据准备：首先要准备迭代内改进情况的度量数据，这是为了回顾的Check和Act做准备的。其次要准备迭代内的度量数据，根据前面确认的回顾重点来准备数据，数据要客观真实。会议公约：公约制定最关键的要团队共创，而不是领导或者管理者一言堂。让每个人都参与制定，其实是为了形成团队的承诺，这样增加公约的效力。公约的内容是为了保证会议的顺利进行，比如守时，不玩手机，不开小会等，关键还是要团队共创。会中可以从引导者要求，营造氛围，改进项确定和结束回顾四个方面来参考引导者要求：这是很关键的一个角色，引导者的能力会决定会议时间和会议效果。可以是有经验的ScrumMaster或者团队成员。在引导的时候注意要中立，不要给出观点，参与讨论，这样会让自己忘了身份，忽视流程和时间的掌控。 营造氛围：会议的氛围影响团队成员的感受，决定他们的参与度和积极性。要营造一个安全的环境，确保团队成员可以放心的说出自己的心里话，不会瞻前顾后、欲言又止。通常参会人建议是团队和Scrum Master，关于管理者和PO或者其他外部人员想要参加，需要看团队的接受度，他们之间是否相互信任。还要营造一个放松的环境，可以准备团队喜爱的零食，还有做好会议设计和选择合适的引导者都会保证好的氛围。改进项确定：在确定改进项的时候，要团队共同决定，保证全员皆知，形成共识；其次要聚焦，选择可执行的1-2项，不要冒进贪多；最后是改进的目标要SMART(Specific,Measurable,Achievable,Relevant,Time-bound)。结束回顾：回顾的收尾也很重要。团队可以通过感谢卡的形式相互感谢，或者心流笔记表达感受，让团队成员之间彼此相互了解和感知，这是一个非常好的团队建设时机。还有就是要再次明确会议达成的改进项，并确认负责人，为后续的执行活动做好准备。第二步：做好回顾会后改进计划的Do、Check和Act，保证改进落地执行的效果有了高质量的Plan，回顾会后的Do、Check和Act也非常重要，每个环节缺一不可。Do的过程根据改进内容不同执行方式会有不同，同时在执行过程中增加一些实践，可以提高执行过程的效果。执行方式按照规则&纪律类、执行类和障碍类三种改进项类型进行阐述规则&纪律类：需要Scrum Maser和团队共同反复重申，慢慢形成团队统一的工作习惯和方式。比如工作项状态的及时更新，开会不迟到等。执行类：需要团队花费时间去执行，所以要放入Backlog。比如团队编码规范的改进，需要制定出统一标准，然后全员展开，并且跟踪检查执行情况。障碍类：是指对团队冲刺形成阻碍的事情，不需要团队成员花时间去改进，可以放入Scrum Master的管理清单中。如PO在计划会议前准备好Product Backlog，团队白板申请等，这些Scrum Master要和外部团队去沟通协作，并跟进行动的进展。执行过程中为了保证效果，可以参考以下几种做法可视化改进项：将改进的内容在团队的公共区域展示出来，让团队都清楚当前处在哪些阶段，需要做什么，如何做，注意什么。设立贡献墙：改进的工作都是迭代任务外的工作，大家关注度可能不同。对改进中积极参与者或者是取得进步大的人要进行公开鼓励，从而去带动大家的积极性，提升改进动力。预留改进时间：执行类的改进进入Backlog，就需要预估时间，因此要预留出改进的时间。不能既要求团队全力冲刺完成迭代任务，还要求团队额外做好改进，这是不现实的。某项工作完成的好坏取决于成员的能力和意愿两个方面，首先是需要有意愿，才能保证取得好的效果，不能在已经饱和的迭代任务外强加给团队改进工作，那样即使推行了也不会取得好的效果。结对实施改进：可以参考XP(eXtremeProgramming)中的结对编程的做法，结对实施改进。通过设立实施人和监督人，目的是保证改进的准时和高质量的完成。实施这个做法的前提还是要团队同意，一言堂强加不可。Check是落地执行的总结检查可以在执行改进所在的迭代回顾会进行，也可以单独设立改进回顾会。建议在执行改进所在的迭代回顾会，这样可以减少团队会议的频次。会上先对改进回顾，团队可以感受到回顾给团队带来的改变，团队的改进动力和参与度都会得到提升，会让大家对接下来的回顾会有更多的期待，会更有意愿去继续回顾和改进。Act是对总结检查的结果进行处理成功的经验加以肯定，并予以标准化；失败的教训也要总结，引起重视；没有解决的问题，在回顾会上团队决定是否提交给下一个PDCA循环中去解决。所以回顾带来的改进是阶梯式上升。整个PDCA循环不是在同一水平上循环，每循环一次，就解决一部分问题，取得一部分成果，团队就前进一步，水平就提高一步。到了下一次循环，又有了新的目标和内容，更上一层楼。如下图所示。改进是无止境、无终点的，在这个过程中团队会越来越好。最关键是开始的一点点进步。只有让团队看到效果，才会激发参与度和改进动力，让团队坚持去回顾，坚持去改进。敏捷回顾会议对团队非常重要，否则团队就可能在相同的问题上重蹈覆辙。愿我们都能坚持回顾，从一小步开始，不断进步。敏捷路上，你我同行！参考附录1.  敏捷原则2.  Esther Derby. Diana Larsen.敏捷回顾：团队从优秀到卓越之道[M].3.  Kenneth S. Rubin. Scrum精髓[M].4.  MBA智库：戴明循环5.文章博客地址：https://bbs.huaweicloud.com/blogs/163478附件：【DevCloud • 敏捷智库】如何让敏捷回顾会议有效果，这样做就对了.pdf[hide]链接: https://pan.baidu.com/s/1-sFwsbIZdLi4851mje17SQ提取码: 5pxp[/hide]

提起用户故事拆分，我们听得最多的就是INVEST原则（关于INVEST原则可以参考文章“用户故事等于需求说明”——你一定没有写好用户故事），但是拿到一个较大的用户故事时，该如何拆分才能使得它满足Small的原则呢？这个是很多人面临的问题，今天和大家一起讨论一下。 首先，拆分可以参考以下流程：评估待拆分用户故事-按方法拆分-评估拆分结果。（文末有彩蛋，不要错过）评估待拆分用户故事拆分前，我们需要知道手中的用户故事是否需要拆分，就是目前是否已经符合了Small的原则。我们推荐一个用户故事在1-2天内能完成，最多不超过3天，则符合Small原则。有些地方给出的说法是1/5-1/10团队速率，这个算法和你每个迭代天数以及团队成员数有关系，所以我个人还是喜欢简单的说，1-2个工作日能完成算Small。在这种情况下如果你的用户故事已经符合了INVEST其他原则的话，那就没必要拆成多个用户故事了，因为再拆就增加了管理成本（这里不包括拆成多个task，task可以再多拆分的）。好，当你已经根据上面评估了用户故事，发现依旧需要拆分的话，那么可以按下面方法进行拆分。按方法拆分目前业界比较好的方法是Richard Lawrence的方法，原文请参考https://agileforall.com/patterns-for-splitting-user-stories/，下图英文原版为Lawrence创作，中文版是姜信宝为Lawrence翻译的，此处引用并对二人致以感谢。图片来自Lawrence官方原文里有作者的切分方式，这里我只根据我的理解选择更熟悉的例子，同时合并了其中一些方法。 方法一：按流程拆分作为有爱心的有财力的中国人，我可以从国外进口口罩捐给武汉。这个用户故事涉及的过程就很多了，需要找到国外可靠的口罩供应商，然后付款，运回国内，再送到武汉捐给指定医院等等。我们可以先分析整个用户故事成一个一个连续的流程，如果每个小流程作为一个用户故事，能对用户有价值，那我们就先这么拆开。结果比如下面l  作为有爱心的有财力的中国人，我可以寻找个国外的朋友帮忙寻找可靠的口罩来源。l  作为有爱心的有财力的中国人，我可以在这个来源付款购买指定数量的口罩。l  作为有爱心的有财力的中国人，我可以将口罩从外国运回国内。l  作为有爱心的有财力的中国人，我可以将口罩从国内某地送到武汉捐给医院。方法二：按操作种类划分作为有爱心的中国人，我可以在口罩购买平台上操作以完成购买。如果是一个业务更简单的系统的话，对应的就是增删改查动作。这里的操作会复杂些，把每个操作拆分成一个用户故事即可。l  作为有爱心的中国人，我可以在口罩购买平台上购买。l  作为有爱心的中国人，我可以在口罩购买平台上退货。l  作为有爱心的中国人，我可以在口罩购买平台上查询。l  作为有爱心的中国人，我可以在口罩购买平台上卖货。方法三：拆出主要的工作作为有爱心的中国人，我可以购买N95/KN95/医用外科三种口罩进行捐赠。整个购买捐赠流程就很复杂了，还要买不同种类的口罩，明显这三种口罩可以拆成三个故事，同时考虑一点，就是无差别的完成购买一个口罩进行捐赠的故事后，剩下的两种需要的工作量就会很少了，同时这里如果没有区分三种口罩的优先级的话，我们可以先拆出一个作为主要工作，再看剩下的两个是合到一起还是继续拆分。比如拆成如下l  作为有爱心的中国人，我可以购买其中一种（N95/KN95/医用外科）口罩进行捐赠。（3个故事点）l  作为有爱心的中国人，我可以购买另外一种（N95/KN95/医用外科）口罩进行捐赠。（1个故事点）l  作为有爱心的中国人，我可以购买最后一种（N95/KN95/医用外科）口罩进行捐赠。（1个故事点）如果后两个都比较小，合道一起也没问题的话，也可以拆成如下l  作为有爱心的中国人，我可以购买其中一种（N95/KN95/医用外科）口罩进行捐赠。（3个故事点）l  作为有爱心的中国人，我可以购买另外两种（N95/KN95/医用外科）口罩进行捐赠。（2个故事点）方法四：业务规则分类作为有爱心的中国人，我可以购买三十万个口罩捐赠给武汉。这里购买的口罩可以选择多种类型，价格不一样，效果不一样，这就是我们要区分的不同的业务规则，拆分后可能如下l  作为有爱心的中国人，我可以购买三十万个最贵的口罩捐赠给武汉。l  作为有爱心的中国人，我可以购买三十万个口罩捐赠给武汉，不区分口罩种类。l  作为有爱心的中国人，我可以购买三十万个口罩捐赠给武汉，只要N95和KN95级别的。方法五：简单到复杂作为有爱心的中国人，我可以购买口罩捐赠给武汉。简单一句话，涉及的业务可以是购买何种口罩，如何捐赠，给什么机构等，明显不能作为一个故事进行交付，需要拆分。但是业务太复杂，一开始无法全都想清楚，可以先做最基本的，然后再根据方法四的业务规则分类进行扩展。l  （简单）作为有爱心的中国人，我可以购买口罩捐赠给武汉。l  （复杂）在XXX日期购买。l  （复杂）通过不同的运输通道送到武汉。l  （复杂）捐赠给XXX不同的医院。方法六：推迟性能实现作为有爱心的中国人，我可以明天购买口罩捐赠给武汉。明天这个性能太高了，实现起来可能比较困难，我们先实现购买和捐赠，不考虑哪天能完成，再考虑明天这个性能要求。l  作为有爱心的中国人，我可以购买口罩捐赠给武汉。l  作为有爱心的中国人，我可以明天购买口罩并完成捐赠给武汉。方法七：探针作为有爱心的中国人，我可以明天购买口罩捐赠给武汉。这个可能对我来说太复杂了，完全不知道该买什么类型的口罩，买30万个大概多少钱，渠道买比较靠谱，怎么捐赠，给哪个机构，如果现在就强行做计划的话，可能最后发现，我手上的钱是不够的，或者周期太长，到最后才发现的话，会损失很多。所以一般都是先去探探路。l  调查市场上口罩类型、价格、渠道。l  调查捐赠方式，靠谱的接受机构。l  实施捐赠（需要等前面的工作完毕后重新评估） 评估拆分结果拆分完毕后，再用INVEST原则进行评估，如果符合，那就没问题了。但是有的时候会不符合其中某些原则，比如独立性，但是实际业务就只能这样。比如上面提到的方法三的拆分，这个是必然有关系的，不可能先做第二个用户故事后做第一个。这时只能选择不符合独立性原则。 彩蛋看了上面这么多拆分方法，是否迷糊了？是否每次拆分都要对照上面的方法一个一个的试？其实不需要的，根据经验，拆分用户故事最重要的是，先捋清楚整个业务(划重点，这个最重要，之前很多例子你感觉切分的不如作者好，都是因为对举例的业务不熟悉)，然后按照最重要的原则-纵着切即可。如下图所示。图片来自网络纵着切的意思是，每个切分出来的需求是个单独对用户有价值的，就像上图中切出来的一块蛋糕，是独立的个体，包括这一块蛋糕的所有层次以及上面的小人。对比的横着切的意思是所有的需求放一起将前台、后台、数据库操作这样切分出来，结果就是先用几个迭代将所有的需求前台工作做完了，再开发后台的，这样无法尽早交付有价值的需求，比如先将蛋糕上上所有的小人都切下来了。如果业务比较复杂，那么就以MVP的思想，先交付一个简单的端到端的业务，再慢慢扩展复杂程度。如果过于复杂，就尝试探针方法。如果捋清楚了需求，尝试纵着切，发现很难下手，这时候再来看上面提到的Lawrence的七个方法，寻求帮助。

背景某公司在二手房交易平台项目中采用了敏捷开发模式，项目的一个需求为通过输入关键字可以为用户检索对应的房源信息。产品经理将这个需求编写成用户故事如下：“我想通过输入一些词，查询相关的房源信息”开发团队拿到用户故事后，有很多疑问：输入的信息包含哪些？搜索完成后，给用户展示什么信息？在展示效果上，只做一个查询房源信息的搜索框，能否满足用户需求？这条用户故事要实现得价值是什么？很多团队都遇到过这样的情况。用户故事可以帮助开发人员更好的理解需求，让开发人员形成以用户为中心的思维模式，从而开发出更符合用户期望的产品。那么应该如何有效的编写一个用户故事呢？问题分析什么是用户故事分析问题之前，我们先了解下用户故事。用户故事维基百科给出的定义是：“In software development and product management, a user story is an informal, natural language description of one or more features of a software system.”即在软件开发和产品管理过程中，对系统的一个或多个功能进行非正式，自然的语言描述。用户故事是为了表述用户渴望的功能和价值。与需求规格说明书对比同样是用来记录需求，用户故事和传统的需求规格说明书有什么差别呢？需求规格说明书是软件开发过程的范围标准，通常会很正式客观的说明系统需求范围，功能实现要点等，说明书的好处是可以让产品完全符合约定规范，达到交付标准；但是说明书要求做到的和客户内心期望的可能并不一样，比如：说明书中写“产品logo是黑豹”，产品经理是一个漫威粉丝，他希望产品logo是漫威的黑豹；只看说明书，很难看出产品经理的真实需求，于是研发人员就画了一个动物黑豹作为logo；从结果来看，按照说明书做出的产品与用户期望之间存在着很大偏差。用户故事通常比较短小，其核心是围绕用户期望的价值；它不像说明书那样事无巨细的记录下产品想要实现的功能，而是提醒研发人员正在开发或者待开发的功能要实现什么价值（理论上，用户故事应该由用户或用户代理如产品经理录入）。用户故事的三要素为角色、功能、价值，编写用户的通用模板如下：“作为一个<角色>, 我想要通过 <功能>, 以便于实现 <价值>。”使用用户故事来写描述刚才的需求可能就会写成，“作为产品经理，我想制作一个黑豹的logo，以便于利用漫威品牌去吸引用户。”研发人员通过用户故事的“价值”，可以知道这个logo应该是漫威的人物；如果不知道，也可以去问产品经理，这豹子和漫威有啥关系，经过产品经理解释，需求也可以被正确理解（体现了用户故事“可以商讨的”的原则），简而言之，需求规格说明书强调：“功能”，而用户故事比起“功能”更注重“价值”。根本原因了解了上述信息，再看背景中用户故事存在的问题。这条故事虽然有用户故事的样子，但是本质上更像一条需求说明——没有体现用户期望的价值，它只写了“作为 一个<角色>, 我想要通过 <功能>”，没有后半部分的“以便于实现 <价值>”， 所以这条用户故事不合格的根本原因是没有体现价值，这是一条无效的用户故事。这种无效的用户故事一方面会导致研发人员很难理解需求要实现的目的，做出的产品令用户不满意；另一方面，这个用户故事写的太粗略，研发人员不知道从哪下手。无效的用户故事只是一种形式，对需求澄清起到的作用微乎其微。接下来看下合格的用户故事应该怎么写。解决措施要写好用户故事，首先应该了解用户故事的必备条件，或者说用户故事的原则。用户故事的原则一个用户故事通常具备6个原则：独立的（Independent），可以商讨的（Negotiable），有价值的（Valuable），可以估计的（Estimatable），合适的小（Small），可测试的（Testable），6个原则取英文首字母会组成一个单词“INVEST”，所以用户故事的6个原则也被称为“INVEST原则”。独立的（Independent）：避免故事之间的依赖；这样做的好处是便于故事优先级排序以及估算。A故事：“作为购房者，我想要通过学区搜索房源，以便买到学区房，方便孩子上学”，B故事“作为购房者，我想要通过学校名称搜索房源，以便于生活在有文化气息的地方”，一定程度上来说，B故事对A故事有依赖，学校的范围包含学区内的公立学校外，还有学区外的私立学校和大学等。如果A故事需要1天，B故事需要3天，总体估算两个故事完成应该是4天，可是A故事完成后，B故事相当于完成了一部分，最后B故事可能只需要2天就完成了；而且本来优先级相同的两个故事，A故事优先级无形之中提高了。用户故事之间的依赖会让估算不准确，即不符合“独立的”原则；想解决这个问题，我们可以对故事重新划分，比如：重新划分成三个故事：“作为购房者，我想要通过私立学校名称搜索房源，以便于孩子将来得到不一样的教育”，“作为购房者，我想要通过大学名称搜索房源，以便于生活的地方有文化气息”，“作为购房者，我想要通过学区搜索房源，以便买到学区房，方便孩子上学”，这样故事之间就没有耦合性，每个故事都是独立的，便于优先级排序和估算故事点。可以商讨的（Negotiable）：用户故事只提供适量信息，让开发人员和用户（产品经理）针对一些细节进行讨论；“作为购房者，我想要通过学校名称搜索房源，以便于生活的地方有文化气息 ”，常规理解，这条需求包含：小学，中学，那大学是否包含呢，这样就形成了讨论性。这种情况我们可以在故事中加一段注释：“注释：包含小学，中学，是否包含大学待确认”。与客户的讨论过程在可能会挖掘新的需求，比如艺术学校等。用户故事注释不建议写的面面俱到，因为会减少故事的可商讨性。有价值的（Valuable）：敏捷开发以价值为导向，所以故事应该体现对用户的价值。“有价值的”原则在问题分析里面已经做了部分解释；还有一种情况“作为研发人员，我希望给后台数据库创建XX表，以便于我实现XX模块的功能”，这条用户故事看似ok，但实际上该用户故事只对研发人员有价值，换句话说用户不关心后台表结构，只关心系统是否可用，所以这条故事不符合“有价值的”原则。技术实现方面的需求可以适当转化成对用户有价值的故事，或者把它作为“作为购房者，我希望通过XX功能，以便于实现XX价值”这条故事下面的一个Task。可以估计的（Estimatable）：每个故事都应该可以估算出故事点，以便于对个人工作量以及团队速率进行估算；一个用户故事估算的工作量不能超过一个迭代，如果故事太大难以估算，可以将大的故事进行分解，分解成多个小的可估算的故事。“作为购房者，我需要按交通线路搜索房源，以便于找到方便搭乘公共交通的房源”，公共交通种类繁多：公交，地铁，轻轨等，假设实现每种交通工具搜索需要4天，要一下子实现这个故事至少需要12天，一个迭代开发不完，这不符合“可以估计的”的原则。针对这种情况，我们可以将这个大的故事拆分成三个小的用户故事，每种交通工具分别对应一个故事，这样一个故事就是4天，就符合了“可估计的”原则。合适的小（Small）：故事分解的小，便于估算也便于交付，但是如果故事分解的太小，以至于难以估算故事点，就需要对多个实现共同功能的小故事进行整合。“作为购房者，我希望搜索框背景是红色，以便于我可以更好的找到搜索框”这种用户故事工作量很难估算，可能少至十分钟，多则半小时就完成了；如果迭代中有很多这种小的故事，那对于整体速率估算是非常不利的。小故事可以和其他故事进行整合，形成可估算大小的故事；或者将小故事作为一个Task挂到其他类似用户故事下。可测试的（Testable）：用户故事必须要有一个明确的完成标准，以判断开发的功能是否满足用户期望。“作为购房者，我希望搜索到大房子，以便于我和父母孩子居住”，“大房子”是一个模糊的概念，面积90㎡还是140㎡算大房子？是不是三室两厅就符合条件？这种用户故事很难进行验收，也不符合“可测试的”原则。正确描述是：“作为购房者，我希望搜索到90㎡以上，三室两厅的房子，以便于我和父母孩子居住”这样标准就清晰很多，评审会议时也好判断功能是否符合用户期望。用户角色好的用户故事除了满足它的基本原则，还应该考虑一个问题：对于不同的“角色”，实现同样“价值”所需要的“功能”是否也不同？我们来对比两个用户故事：“作为购房者，我想要通过总房款的范围搜索房源，以便于找到我能买的起的房子”和“作为月薪5000，手头有30万存款的职场新人，我想要通过总房款的范围搜索房源，来确定我能负担得起的房子”，开发相同的“通过总房款范围搜索房源”功能，前者需求描述比较模糊：在搜索栏中输入比如100万，然后展示100万左右的房源信息？100万左右的“左”和“右”分别是多少？按这个需求做出来的产品，很大概率是模棱两可的产品，也很难被用户认可；而且在这个用户故事中，“角色”并没有起到该有的作用；第二个故事相对就好很多：30万做首付， 5000月薪可以作为月供的参考，通过这些参数可以大概的推测出总房款的范围，这个范围也可以作为这类人预算的参考；再深一点考虑：房屋总价做成可选区间，代替从搜索栏输入，也许用户体验会更好。由此可见，如果对用户角色进行细致划分能起到意想不到的效果。敏捷以用户为中心，不了解用户就无法掌握用户真正期待的价值。而研发时每个人对用户的理解是不同的，用户角色可以帮助团队形成统一的用户形象，研发人员可以聚焦目标用户，重点挖掘该角色需要的价值；同时使用用户角色会更有代入感，便于研发人员站在用户角度去实现产品该有的价值。用户角色可以通过头脑风暴或其他形式进行识别：按实际需求对用户群体进行细致分类；分类完成后，对有共性的用户适量整合形成具有代表性的用户。比如，对于购房者我们头脑风暴后，可能形成如下群体：年轻人，中年人，老年人，每个群体自身条件和期望都会有差异。年轻人群体中大多数个体财富积累较少，上班时间早，从他们角度会写出特定的用户故事，比如：“在市中心上班的小王，想要通过地跌线路搜索房源，以便于解决上班堵车导致迟到的问题”，要怎么做，为什么这样做，一目了然。同样对于已经成家的中年人，可能更关注孩子的教育（学区）；对于老年人群体，可能更关注附近是否有菜市场便于买菜，是否有公园便于日常锻炼，从这些群体的角度出发，搜索功能会形成不一样的用户故事。还应该想到一些极端情况，比如：“作为一个事业有成的企业家，我想要在空气清新的郊区买一个独栋别墅，以满足私人会谈和休假”，所以房源类型是别墅还是普通住宅也要考虑。接下来看一个例子。实例操作用户故事通常以手写的方式写在纸质卡片上，但是纸质卡片很难提供准确的数据用来进行相关分析，所以现在很多企业都选择使用电子卡片。华为云DevCloud是基于敏捷思想设计的DevOps研发平台，接下来在华为云DevCloud中写几个规范的用户故事，故事呈现的需求是背景提到的搜索功能。首先对年轻的上班族群体进行需求划分，比如有些年轻人工作单位在市中心，市中心房子太贵，离市中心稍微远一点开车或坐公交时间不可控（容易堵车），所以他们希望按照地铁线路搜索房源，以解决上班迟到的问题。用户角色就是：早晨八点要到单位（单位位置在市中心）的小王，小王想要做的事是：在这个网站里通过地铁线路搜索地铁站附近的房源信息，他这样做的目的是为了减少上班迟到的风险，写成用户故事：Tips：华为云DevCloud支持填写故事的各种属性，比如所属迭代，优先级，估算工时，故事点等。通过规范的用户故事，研发人员发现原来用户想要的搜索并不是无目的的搜索，而是想找到和自己特定需求相匹配的房源，如果在搜索框基础上，加上若干CheckBox会更有利于用户搜索，最后产品搜索页面如下。总结站在不同用户的角度，遵循用户故事的“INVEST”原则，可以更深层次的挖掘用户的需求，写出更有效的用户故事。参考附录Mike Cohn:用户故事与敏捷方法.北京：清华大学出版社文章博客地址：【DevCloud · 敏捷智库】“用户故事等于需求说明”——你一定没有写好用户故事

背景在传统开发模式下，开发任务是由项目经理指派给个人的，而在敏捷开发模式中，开发任务是团队领取的。很多企业在转型中遇到过这样的问题：“计划会议认领开发任务的时候，有几个任务没人认领怎么办？”问题分析首先，相对于传统开发模式的指派开发任务，我们需要知道为什么在敏捷开发中是领取任务。在敏捷中，不管是敏捷宣言还是Scrum指南，都没有指派（assign）一词，而是使用了一个术语“自组织”，如下：最佳的架构、需求和设计出自于自组织的团队（敏捷宣言12项原则）自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导（Scrum指南）他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量（Scrum指南）那么“自组织”是什么呢？从字面的意思来理解，“自组织”就是：安排分散的人或事物使具有一定系统性或整体，而安排的人就是他们自己。在敏捷开发中，自组织团队就是具备自我管理、自我驱动、自我学习等能力的敏捷开发团队本身，这样的团队一般具备如下特点：团队成员自己“拉”工作，不是被动等待他们的领导分配工作；团队作为一个整体管理他们的工作；团队仍然需要辅导和指导，但不需要指挥和控制；团队成员彼此沟通紧密互通有无；团队主动发现和提出问题并共同解决；团队不断提高自己的技能，鼓励探索和创新。更多关于“自组织”的相关内容不在此FAQ的范围内，如感兴趣请参阅更多文献。从敏捷宣言和Scrum指南关于任务的工作方式上来看，在我们践行敏捷的时候，主要发挥的是开发团队自身的主观能动性，开发团队由原来的控制性转变成了自组织性，而开发任务也就由原来的指派变为了领取。这样的好处是，领取任务就是发挥了人的主动性，而自主性是人们从事创造性和解决问题的动力之一，良好的自我组织能给团队和个人带来高绩效、出色的工作成果以及喜欢的工作环境。另外，每个人都是最了解自己的，也擅长为自己分配任务，相对于传统的指派开发任务所带来的易主观臆断、分配不当等更具有合理性。然后再回 “计划会议认领任务的时候，有几个任务没人认领怎么办？”这个问题上。不过在此之前，需要先澄清的一个观点就是，在计划会议中，不一定非要全部领取完开发任务。在Scrum指南中指出“领取工作在Sprint计划会议和Sprint期间按需进行。”这个期间，可以理解为在每日Scrum站会上基于目标领取任务。另外，Mike Cohn 也表示过，不建议在计划会议中领取开发任务，这样可能会导致目标由团队变为了个人，进而违背了敏捷的本意，降低了灵活性。更多请详见参考附录“Should Team Member Sign Up for Tasks During Sprint Planning？”。一般来说，开发任务没人认领的原因主要有：开发任务的难度大：当开发任务比较难以解决，超出了团队大部分成员的能力时，团队成员可能会存在担心加班加点，甚至“996”的情况而不愿意认领。开发任务超范围：当开发任务的内容超出团队成员所掌握的范围时，如 Android 不会 IOS，开发不会测试等，就可能会出现“我是想认领的，但实例它不允许啊”的情况。担心受到他人指责：工作内容存在一定的挑战性，担心由于自己没有做好，导致团队目标没有达成而受到指责。那么应该如何解决呢？解决方案在一个敏捷Scrum团队中，Scrum Master扮演着重要的角色，该角色一部分的作用就是要帮助团队成为自组织型团队，以便让团队能以积极的心态去面对冲刺的开发任务。此外，当出现任务没有人愿意认领的情况时，首先 Scrum Master应该帮助团队弄清楚没有人认领的原因是什么再对症下药，下面基于分析中的三种情况分别给出解决措施。开发任务难度大对于开发任务难度大的情况，Scrum Master应该组织团队进行有效的任务分解，使用探针Spike技术，探索出解决措施以降低任务的难度，再由团队去认领(更多关于Spike的解释请见附录)。或者鼓励技术能力较一般的成员和技术大牛通过结对编程的方式来一同认领任务(更多关于结对编程的解释请见附录)。在华为云DevCloud中，可以对该类难度大的用户故事通过子工作项的方式进行拆分，同时在基本信息中通过设置处理人和抄送人的方式以记录结对编程的人员配对情况，如下图。除此以外，在每日Scrum站会的时候,要留意和了解该开发任务的情况，进行风险评估，如有问题及时帮助协调解决。在回顾会议中,应对该类情况问题进行分析并能输出基于团队的一套标准工作方式方法，然后将解决方案记录在团队知识库中，华为云DevCloud提供了Wiki的功能，可以为团队很好的整理和记录工作方式，如下图。开发任务超范围敏捷提倡的团队是跨职能团队，但是团队的跨职能并不意味着个人能做所有的事情，我们希望的跨职能团队往往是由掌握多项技能的T型人才（每个成员在一个专业领域具有深度，而在其他领域具有广度）所组成的。那么首先，需要Scrum Master能够和团队整理和维护成员技术矩阵，把个人技能掌握情况对团队公开（知道团队欠缺什么、知道可以和谁学等），然后定期组织技术分享等活动以帮助团队成员学习（主要以学习一项新的技术后的分享方式），这样可以在一定程度上提升成员在冲刺中愿意领取其他任务的热情（学完了当然是想去用一下咯）。另外，还可以由专长成员和意愿成员组队，采用结对编程的方式领取任务，以实现个人技术的扩充。团队成员的T型能力建设，不仅仅能让团队领取任务的时候有更多的选择，也提供了成员的backup能力，减少无人认领的情况发生。此外，同样也需要Scrum Master留意日常评估风险和引导团队回顾该事项并维护团队知识库。担心受到他人指责工作内容存在一定的挑战性，担心由于自己没有做好，导致团队目标没有达成而受到指责。Scrum Master应该对团队贯彻以团队为整体的思想，并指导和强调Scrum的价值观,尊重团队的每一个成员的背景、经验，当然也包括开发任务的选择，还要鼓励成员能有勇气去选择和尝试。在实际的工作中，我们可以通过在墙上、白板等贴上标语（如“尊重他人”、“只有团队没有个人”等）的方式，让团队从思想意识方面发生转变，慢慢敢于去领取有挑战性的任务。此外，Scrum Master要充分保护好成员对有挑战工作认领的热情。如，防止在回顾会议上出现指责和批斗的情况，回顾和总结永远应该聚焦的是做事的方式方法而不是对人的苛刻和指责。总结以上三种没有人认领任务的情况，是比较常见的。但在真正的实际项目中，每个公司或团队的情况都不尽相同，无法穷举所有，应具体情况具体分析。比如，当一个公司首要考虑的是存活问题时，又比如一个刚刚转型的敏捷团队，在开发任务的领取上可能会更偏向于半指派半领取的方式，就像FAQ《从敏捷管理的角度来说，是团队主动认领任务好还是通过管理任务分发好》中所提到的，当团队敏捷成熟度较低时，可先由团队认领再让领导管控。这就好比中国经济一样 “以市场经济为导向，适当进行宏观调控”。但不管这个“调控”的力度如何，我们都应该鼓励团队成员能积极主动地领取任务,并随着任务的进展情况灵活调整，及时做好风险把控，必要的时候需要其他渠道的协调帮助或相关领导的介入，以保证迭代的目标不受影响。参考附录spike华为云DevCloudShould Team Member Sign Up for Tasks During Sprint Planning?文章博客地址：https://bbs.huaweicloud.com/blogs/152629