7月9日，以“数据新要素 产业新动能”为主题的大数据产业峰会线上直播正式开启。会上，中国信息通信研究院为通过大数据产品能力评测的产品颁发证书，华为云FusionInsight MRS超大规模单集群以测试项全部满分的成绩顺利通过评估，并成功突破单集群2万节点的超大规模，树立行业新标杆。 中国信通院云大所大数据与区块链副主任姜春宇发布评测证书中国信通院大数据产品评测是国内最权威的大数据评测体系，评测范围涵盖大数据产品的基础能力与性能专项，历经六年的蓬勃发展，大数据产品认证已经成为政企客户选购选型过程中的重要参考，是业界衡量大数据产品质量和能力的重要标准。华为云FusionInsight MRS大数据为政企客户提供一站式企业级大数据平台，满足客户对全栈大数据平台高性能、低成本、灵活易用的诉求，助力企业快速构建海量数据信息处理平台。在本次评估测试中，华为云FusionInsight MRS一次性通过了27个必选用例，此外，在集群无宕机升级、双集群互备、运维监控模块失效及恢复、跨数据库关联操作、在线水平搜索能力等六个可选用例中也实现了一次性通过，100%的通过率使得FusionInsight MRS在本次评估测试中交出了一份完美的答卷。丰硕的成果离不开辛勤的劳作，在整个研发过程中，华为云FusionInsight MRS超大规模单集群的实践也遇到了诸多挑战，华为云大数据研发团队凭借雄厚的研发实力和丰富的探索实践经验，通过以下七个方面实现了业界首个单集群突破2万+规模，具体如下：运维管理架构改造：将原来的集约主从模式调整成了可弹性伸缩的分布式模式，提升了主备模式的监控、告警、配置、元数据存储模块的性能，成功解决了运维管理面临的难题。Superior超级调度器：自研调度引擎，支持35w/s个Container的调度速率，资源利用率达到98%以上，超出开源Capacity的能力近一倍。文件对象管理优化：利用合并单次读写流程中的交互次数、使用改良的数据通信压缩算法、DataMovementTool等技术方案，在确保文件对象管理性能的同时，自动均衡不同命名空间之间的数据，大大降低了集群维护成本。多租户的资源隔离能力：支持标签存储、多服务、多实例、DN分组等方式进行细粒度隔离，提升多租户的资源隔离能力。元数据优化：支持分布式缓存Redis方案，结合分布式锁、缓存黑白名单机制、缓存生命周期管理等技术手段突破了Hive服务的元数据读写性能瓶颈，使得元数据能够在大规模的单集群上规模商用。跨AZ的网络带宽消减：存储上提供感知AZ的文件存储策略，计算上提供感知AZ的任务调度机制，优先在同AZ下进行存储与计算，减少跨AZ的网络带宽消耗。可靠性增强：支持多种机制保障任务的可靠运行，如Hive不中断业务的能力可确保发生异常时任务不中断；Application Master的断点续传能力可记录任务状态，待AM恢复后继续执行。得益于以上七个方面的大数据技术增强与优化，华为云FusionInsight MRS顺利通过信通院分布式批处理平台基础能力测试，节点规模达 21000，成为业界首个单集群突破2万节点的商用大数据产品。华为云FusionInsight已是60+国家，3000+客户的共同选择，广泛布局于政府、金融、大企业、互联网等领域。FusionInsight联合800+合作伙伴，践行“平台+生态”战略，释放政企数据价值，让数据“慧”说话，使企业更智能。相关文章：重磅发布！华为云EI智能数据湖FusionInsight 8.0 MRS 6月30日发布新特性，更快更安全，小伙伴们快来GET√+CarbonData，华为云EI智能数据湖FusionInsight让数据处理飞起来！华为云EI智能数据湖FusionInsight 成功助力10000+大数据集群滚动升级！华为云EI智能数据湖FusionInsight携手Kyligence助力保险业数字化转型！华为云EI智能数据湖FusionInsight MRS大数据在银行业的应用探索与典型案例进而有为！华为云EI智能数据湖FusionInsight亮相华为云与计算城市峰会南京站！直击痛点！华为云EI智能数据湖FusionInsight助力政企客户释放数据价值！

一、FusionInsight MRS概述        FusionInsight MRS是华为FusionInsigth HD企业级大数据平台本与原华为云MRS服务的融合版本，是华为云(Huawei Cloud)、HCS(Huawei Cloud Stack)统一的企业级大数据云服务。FusionInsight MRS完全兼容开源组件接口，结合华为云计算、存储优势及大数据行业经验，为客户提供高性能、高性价比、灵活易用的全栈大数据平台，一站式运行Hadoop、Spark、HBase、Kafka、Flink等大数据组件，帮助企业快速构建海量数据处理系统，发现全新价值点和企业商机。FusionInsight MRS服务拥有强大的Hadoop组件内核团队，历经行业数十万节点部署量的考验，为60+国家3000+客户提供企业大数据服务。 FusionInsight 8.0 MRS产品架构        FusionInsight 8.0 MRS针对开源组件进行了大面积升级，提供最新能力，并在社区基础上对功能、性能、可靠性等方面进行了增强。        FusionInsight 8.0 MRS详细组件列表见下图：二、FusionInsight 8.0 MRS的新特性根据最新的架构，对于主要功能在新版本的增强如下：2.1 Hadoop Core支持从2.7.2版本平滑升级至3.1.1版本；支持RBF的多NameNode部署，缓解主NameNode压力，提升响应速度；支持CPU、内存等多种资源模型调度；Superior调度器提高资源任务调度性能。2.2 流接入与流处理1、支持Flink on Hive，提供FlinkSQL与Hive交互的能力，给离线数仓带来Flink实时流能力，同时大大提高Flink易用性：集成Hive，允许用户使用 SQL DDL 将 Flink 特有的元数据持久化到 Hive Metastore、调用 Hive 中定义的 UDF 以及读、写 Hive 中的表；Batch SQL支持原生分区：写入静态分区、写入动态分区；投影下推；LIMIT 下推；读取数据时的ORC向量化；Table API/SQL扩展，SQL DDL 中支持定义 watermark，扩展SQL DDL的语法，支持创建目录函数、临时函数以及临时系统函数。2、Flink窗口存储空间优化，提升处理性能：针对SlidingEventTimeWindow和SlidingProcessingTimeWindow在保存原始数据时存在的数据冗余问题，对保存原始数据的窗口进行重构，优化存储，使其存储空间大大降低。3、支持Apache Kafka 2.4，并集成社区最新能力：增强的压缩算法，controller处理逻辑优化，broker启动优化等；支持可视化管理界面极大提高运维效率，一键进行分区迁移和扩容等操作；增强监控告警，实时管理Kafka服务、Topic消费生产状态；支持基于磁盘容量、分区数分区的自动分配策略，防止数据倾斜；支持用户连接数限制；支持对用户操作进行审计。2.3 数据仓库1、面向大数据集提供更快的SQL分析能力，包括对HetuEngine、Hive、Spark和CarbonData的提升：HetuEngine支持动态过滤、算子下推、动态分区裁剪、Bloom Filter/Star Tree Index/启发式索引、SMILE传输协议优化、并行查询、基于历史查询性能的SQL优化等特性，性能超越Impala 30%，交互式查询超越Hive 3倍；CarbonData统一索引语法，新增index server，解决Driver侧索引内存太大问题；索引进行预加载，数据入口后即自动预加载，解决首次查询慢问题；新增二级索引和Geo索引，提升查询性能；Hive支持Tez引擎，大大提升了任务运行效率，TPC-DS性能提升50%以上；Hive支持LLAP，提升交互式查询场景的性能；Spark SQL优化：动态分区裁剪、distinct下推、启发式join reorder、runtime filter、scalar subquery合并等特性；Spark新增内置高阶函数，可以直接操作复杂类型，并具备比UDF更好的性能。2、支持事务ACID，提供T+0贴源分析的能力：Hive支持ACID，基于事务表支持数据的INSERT/UPDATE/DELETE/MERGE语句，拓宽业务使用场景；Hive支持增强语法语句、物化视图、CBO等特性；CarbonData支持统一MV语法，新增支持时序数据，支持Parquet/ORC表格；CarbonData支持DB实时数据同步，只追加Delta文件，IO冲击小。对比“文件重写”，更新时间缩短50%-70%；多个Delta文件自动合并，避免小文件问题；CarbonData支持一张表内混合格式：CSV、TXT、JSON、Parquet、ORC、CarbonFile。3、交互式查询数据虚拟化引擎的功能与性能全面提升：全面兼容SQL 92、SQL 2003；提供跨域查询能力；动态资源管理，基于YARN进行动态资源管理，支持多租户隔离和并发处理，支持Capacity/Superior多种调度器。2.4 NoSQL与多模计算HBase升级到了2.2.3版本，Phoenix升级至5.0.0版本，并相互适配；Hbase完善了AMv2，通过降低启动时对ZK的依赖，缩短启动时长以及故障恢复时间；支持Netty RPC，提升请求的并发处理能力；提供RS Group能力，通过Group隔离更好的支持多租户能力。2.5 全文检索Elasticsearch通过提前跳过大量在早期被识别为不会在Top-K结果集中的文档来剪枝，提供更快的Top-K查询性能。提供了功能完备的 high-level REST client，新增易用的search_as_you_type类型，该字段会将同一个字段进行多种类型的分词，满足用户的多样性查询需求。2.6 数据安全1、新增组件Apache Ranger提供一个集中式框架进行审计，认证和授权功能：更好的细粒度访问控制；动态行过滤、动态列脱敏、基于属性的访问控制、支持大量组件对接，支持用户、租户、数据库、表、记录等不同组件不同维度细粒度访问控制；更丰富的策略控制，可以采用Allow/Deny constructs、自定义策略条件/上下文增强器，基于时间的策略，Atlas集成（用于基于标签的策略）等策略；组件审计日志统一管理；安全集群、非安全集群统一使用，并添加初始权限，增加易用性。2、ZooKeeper升级到了3.5.6版本，安全功能增强：支持安全端到端通信加密，保证数据传输可靠性；支持对用户操作进行审计；支持对服务ZNode进行配额设置，防止无限制使用ZooKeeper资源，导致过载。2.7 集群管理1、支持云化部署，提供集群快速发放，弹性伸缩能力，主动运维：一键式集群申请，半小时级发放；支持规则和时间计划两种弹性伸缩的策略；主动运维，故障响应最快时间5分钟。2、运维管理能力增强：提供滚动升级能力，不中断业务，保证业务连续性；提供客户端管理能力，方便跟踪客户端地址，避免升级遗漏；提供配置历史跟踪能力，记录配置修改记录、过期配置展示、非默认值展示能力；支持堆栈采集能力，提高进程异常等问题定位效率；提供维护模式，减少变更操作对运维人员的干扰。2.8 超大集群能力1、支持超大规模集群，单集群节点数可达2万+：改造运维管理架构，利用成熟的分布式组件技术，将原来的集约主从模式调整成可弹性伸缩的分布式模式，实现超大集群的管理运维能力；深度优化Superior调度器，Container的调度速率达到35万个/s，集群资源利用率达到98%以上，超过开源Capacity的能力100%，具备超大规模调度能力。2、支持单集群跨AZ，解决超大集群可靠性问题：提供全组件单集群跨AZ高可靠，单机房故障，核心数据和计算任务不受影响；优化Yarn任务调度能力，减少不同AZ间网络开销。3、全组件支持IPv6协议，解决超大集群持续演进过程中的网络升级扩容的要求：全组件支持IPv6能力，满足国内各行业对IPv6升级改造的进程要求；通过对通信端的验证和对数据加密保护，使数据在IPv6网络上传输更安全。4、支持异构混部，解决超大规模集群建设中设备利旧的问题：支持鲲鹏&X86混合部署；支持混搭操作系统（RedHat/SUSE/CentOS/Euler）。三、总结       FusionInsight 8.0 MRS在6月30日发布全新版本，提供2万超大规模集群能力；HetuEngine提供了高性能交互式查询；支持Flink On Hive，增强批流融合能力；Hive支持Tez引擎，大大提升了任务运行效率；CarbonData提供丰富的索引和物化视图，提升Spark/Hive性能；支持事务ACID，实现全量数据T+0入湖；新增Ranger组件，增强细粒度安全控制，以及提供全新的大数据组件版本，大幅提高政府、金融、运营商、大企业等各行业大数据应用场景能力。        十多年来FusionInsight 致力于为全球60+国家地区、3000+政企客户构建企业级智能数据湖，结合平台+生态战略，与800+商业合作伙伴 ，广泛应用于金融、运营商、政府、能源、医疗、制造、交通等多个行业，在政企数字化转型中，释放数据价值，助力政企客户业务高速增长！扫码参与FusionInsight问卷调查 责任编辑：雷文信相关文章：华为云EI智能数据湖FusionInsight 成功助力10000+大数据集群滚动升级！ 华为云EI智能数据湖FusionInsight携手Kyligence助力保险业数字化转型！华为云EI智能数据湖FusionInsight MRS大数据在银行业的应用探索与典型案例 进而有为！华为云EI智能数据湖FusionInsight亮相华为云与计算城市峰会南京站！ 直击痛点！华为云EI智能数据湖FusionInsight助力政企客户释放数据价值！+CarbonData，华为云智能数据湖让数据处理飞起来！

           上回说到，公司的新业务增长速度放缓，运营部门提出要发展短视频来促进更快的业务增长，而我也因为提前准备好了技术预案再一次得到老板的赞赏（了解详情请看上集：一个技术预案，让老板当场喊出了奥利给 ）。            既然万事俱备了，公司就着手开始做短视频业务。本着最小化成本验证、快速迭代的原则，公司并没有大规模地去推进，而是先开发一个简单的短视频网站，招聘了一个妹子来做运营，先跑着看看效果再决定要不要加大投入.                  说到这个运营妹子，那可真是青（fu）春（bai）朝（mao）气（mei）有（da）活（chang）力（tui），听说她自己在短视频平台的账号就有几十万粉丝，还是什么穿搭博主。我们组那个985名校实习生明显感觉来公司上班的劲头都足多了。 你还别说，新来的运营妹子三天两头跑过来找我们实习生小哥，今天拜托给连个外接显示器，明天请帮忙查个网站新用户数，经常就听见：“小哥哥，你看这个要怎么实现呀~”小哥哥那也是有求必应，毕竟萌妹子嘛，总是不好拒绝，不像我们产品大哥要提个需求，那简直是山崩地裂。            前两天运营妹子突然跑过来问：“小哥哥，我这个网站可以放到一个单独的IP地址上么？”原来她遇到一个问题：新网站受原来网站的影响，不好做优化，负责网站优化的同事告诉她需要换一个单独的新IP地址。这个需求可把小哥哥给难住了，向来有求必应的他不知道怎么办才好，只能说：“每个服务器只有一个IP地址，如果要换IP地址，可能需要部署到新的服务器上，这个需要和老板协商…”运营妹子一听实现不了，明显就有些不开心了地走了，留下小哥哥在原地不知所措。            唉，还是太年轻呀，让老夫来帮你一把吧。我把实习生喊过来说：“想要有单独的IP地址不需要申请新的服务器，在现在的华为云弹性云服务器上挂载一个新的网卡就行了，只需要3步就可以实现。而且双网卡配置还能提升服务器带宽，提升短视频的访问速度。”           真的么？实习生小哥两眼冒光，特别期待地问我：“那怎么实现呀，我快点弄好，给她一个惊喜！说不定今天晚上就能一起去看电影了呢。”           具体操作嘛，很简单，很快我就给他写了一个操作文档：《3步实现弹性云服务器挂载网卡》《3步实现弹性云服务器挂载网卡》步骤1：创建网卡，发送POST请求，记录subnet 、network、port等ID。1、创建网络1）发送一条POST请求。POST：https://{endpoint}/v2.0/networks，其中endpoint是云服务器所在的区域节点。Body：{   "network": {     "shared": false,     "name": "demo-net",     "admin_state_up": true,     "tenant_id": "74610f3a5ad941998e91f076297ecf27"   } }2）记录返回响应中“network”的ID。{   "network": {     "id": "c4a3019d-1ac0-4cfb-a838-2342eb992e6b",     "name": "demo-net",     "status": "ACTIVE",     "shared": false,     "subnets": [],     "availability_zone_hints": [],     "availability_zones": [      "az_test_01",      "az_test_02"     ],     "admin_state_up": true,     "tenant_id": "74610f3a5ad941998e91f076297ecf27",     "provider:network_type": "vxlan",     "router:external": false   } }2、创建子网1）发送请求。POST：https://{endpoint}/v2.0/subnetsBody：{     "subnet": {         "name": "testsubnet",         "enable_dhcp": true,         "network_id": "c4a3019d-1ac0-4cfb-a838-2342eb992e6b",         "tenant_id": "74610f3a5ad941998e91f076297ecf27",         "dns_nameservers": [             "8.8.8.8",             "8.8.8.7"         ],         "allocation_pools": [             {                 "start": "10.0.10.2",                 "end": "10.0.10.254"             }         ],         "host_routes": [],         "ip_version": 4,         "gateway_ip": "10.0.10.1",         "cidr": "10.0.10.0/24"     } } 2）      记录响应中“subnet”的ID。{   "subnet": {     "name": "testsubnet",     "cidr": "10.0.10.0/24",     "id": "877b5567-e8c6-4a0d-aabf-0f13da225fe5",     "enable_dhcp": true,     "network_id": "c4a3019d-1ac0-4cfb-a838-2342eb992e6b",     "tenant_id": "74610f3a5ad941998e91f076297ecf27",     "dns_nameservers": [       "8.8.8.8",       "8.8.8.7"     ],     "allocation_pools": [       {         "start": "10.0.10.2",         "end": "10.0.10.254"       }     ],     "host_routes": [],     "ip_version": 4,     "gateway_ip": "10.0.10.1"   } }3、创建端口1）发送请求。POST：https://{endpoint}/v2.0/portsBody：{     "port": {         "admin_state_up": true,            "fixed_ips": [             {                 "subnet_id": "877b5567-e8c6-4a0d-aabf-0f13da225fe5"             }         ],          "name": "test",          "network_id": "c4a3019d-1ac0-4cfb-a838-2342eb992e6b",         "tenant_id": "74610f3a5ad941998e91f076297ecf27"     } } 2）              记录响应中“port”的ID{   "port": {     "id": "7bf1c36f-e7f8-478a-be3d-674b486abbc4",     "name": "test",     "status": "DOWN",     "admin_state_up": true,     "fixed_ips": [       {         "subnet_id": "877b5567-e8c6-4a0d-aabf-0f13da225fe5",         "ip_address": "10.0.10.233"       }     ],     "mac_address": "fa:16:3e:db:91:f6",     "network_id": "c4a3019d-1ac0-4cfb-a838-2342eb992e6b",     "tenant_id": "74610f3a5ad941998e91f076297ecf27",     "device_id": "",     "device_owner": "",     "security_groups": [       "93031677-2895-4b83-855a-637e309aa9e6"     ],     "extra_dhcp_opts": [],     "allowed_address_pairs": [],     "binding:vnic_type": "normal",     "binding:vif_details": {},     "binding:profile": {}   } } 步骤2：挂载网卡 1）发送请求。URI格式：POST /v2.1/{tenant_id}/servers/{server_id}/os-interface示例POST：https://{endpoint}/v2.1/74610f3a5ad941998e91f076297ecf27/servers/9f4d9281-95e7-4915-a126-1ee597101e2e/os-interfaceBody：{     "interfaceAttachment": {         "port_id": "7bf1c36f-e7f8-478a-be3d-674b486abbc4"     } } 2）响应示例{   "interfaceAttachment": {     "port_state": "ACTIVE",     "fixed_ips": [       {         "subnet_id": "877b5567-e8c6-4a0d-aabf-0f13da225fe5",         "ip_address": "10.0.10.233"       }     ],     "port_id": "7bf1c36f-e7f8-478a-be3d-674b486abbc4",     "net_id": "c4a3019d-1ac0-4cfb-a838-2342eb992e6b",     "mac_addr": "fa:16:3e:db:91:f6"   } } 步骤3：确认挂载结果。1）      发送请求。URI格式：GET /v2.1/{tenant_id}/servers/{server_id}/os-interface示例GET：https://{endpoint}/v2.1/74610f3a5ad941998e91f076297ecf27/servers/9f4d9281-95e7-4915-a126-1ee597101e2e/os-interface2）响应示例{   "interfaceAttachments": [     {       "port_state": "ACTIVE",       "fixed_ips": [         {           "subnet_id": "46712fe4-25bd-4eae-874b-a528abfb76be",           "ip_address": "192.168.0.50"         }       ],       "port_id": "dd706739-b696-40be-a9f4-477ce478cb18",       "net_id": "17251a8f-a671-4d7c-85d9-af5415962994",       "mac_addr": "fa:16:3e:a5:e0:3c"     }, {       "port_state": "ACTIVE",       "fixed_ips": [         {           "subnet_id": "877b5567-e8c6-4a0d-aabf-0f13da225fe5",           "ip_address": "10.0.10.233"         }       ],       "port_id": "7bf1c36f-e7f8-478a-be3d-674b486abbc4",       "net_id": "c4a3019d-1ac0-4cfb-a838-2342eb992e6b",       "mac_addr": "fa:16:3e:db:91:f6"     }   ] }看到"port_state": "ACTIVE",就表示我们已经挂载好网卡了。 据说，由于疫情的原因，当天两人电影是没看成，但是正式处对象了……万万没想到，一个技术方案还让我当了一次月老。从此以后，实习生小哥看到我那叫一个毕恭毕敬~ 据了解，目前API Explorer平台已开放EI企业智能、计算、应用服务、网络、软件开发平台、视频等70+云服务，共上线2000+个API、6000+个错误码。在前期试运行期间，华为云API Explorer平台上的API接口也已被多家企业成功接入。点击查看详情：《华为云一站式API解决方案平台API Explorer上线》华为云API Explorer平台在未来几个月会实现更多功能，比如支持SDK示例代码、CLI等特性，同时也会开放更多的云服务API接口，连接更多开发者实现创新、拓宽创新边界。目前API Explorer在会员中心有登陆调测送码豆的活动，欢迎大家免费试用哦！【拓展阅读】【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   奖项设置

看视频，还可参与回帖互动领好礼活动！快来参与吧：https://bbs.huaweicloud.com/forum/thread-59291-1-1.html从零代码开始，10分钟快速开发一个可以发送弹幕的网站，并将其部署在华为云服务器上；学完本期教程，将可以知道如何使用Nginx、如何将自己的网站部署到云服务器上，还可以免费学习WEB前端全栈教程，各位小伙伴们一起来学习吧~，传送门--->WEB前端全栈成长计划开发思路    首先是让弹幕的随机高度出现，这个计算方法是：最大高度=屏幕的高度-发送div的高度-弹幕本身的高度，范围就是 0-最大高度了，弹幕总是从右往左移动，所以出现最右侧的位置计算方法是：最右侧位置=屏幕的宽度-弹幕本身的宽度；接下来就是设置随机颜色，颜色按照‘#aabbcc’这种格式，利用Math.random()随机数生成；最后是弹幕的发送，首先是获取输入框中的值，然后新创建一个div，并设置随机颜色、位置等属性，调用init() 函数。    总结如下步骤：    1、获取弹幕对象：随机高度、初始化颜色    2、水平期间设置范围：浏览器宽度-弹幕对象的高度    3、移动功能函数:定时器 setInterval    4、实现用户发表弹幕用到的知识点    1、首先页面搭建，就是这些东西是如何摆放的——html+css布局    2、弹幕字体的位置和样色设置——css样式    3、可以输入文字然后点击可以发送弹幕——按钮的点击事件    4、字体可以旋转——css动画    5、弹幕字体可以从右往左滑动——js控制字体对象的style属性代码块style代码  <style type="text/css">     * {       margin: 0;       padding: 0;     }     .screen {       width: 100%;       height: 100%;       position: absolute;       top: 0;       left: 0;     }     .send {       width: 100%;       height: 76px;       background: #333;       position: absolute;       bottom: 0;       left: 0;       text-align: center;       line-height: 76px;     }     .send .s_txt {       width: 600px;       height: 36px;       border: 0;       border-radius: 3px 0 0 3px;       font-size: 16px;       line-height: 36px;     }     .send .s_sub {       width: 100px;       height: 37px;       background: #65c33d;       border: 0;       font-size: 14px;       color: #fff;       border-radius: 0 3px 3px 0;       cursor: pointer;     }     .send .s_sub:hover {       background: #3eaf0e;     }     .screen div {       position: absolute;       top: 76px;       left: 0;       font-size: 22px;       color: red;     }     .magictime {       animation-duration: 1s;       animation-name: magictime;     }     @keyframes magictime {       0% {         opacity: 0;         transform-origin: 100% 0;         transform: scale(0, 0) rotate(360deg) translateY(100%);       }       30% {         transform-origin: 100% 0;         transform: scale(0, 0) rotate(360deg) translateY(100%);       }       100% {         opacity: 1;         transform-origin: 0 0;         transform: scale(1, 1) rotate(0deg) translateY(0);       }     }   </style>弹幕滚动div代码<div class="screen">     <div>这是一条弹幕！</div>     <div>这是另一条弹幕！</div>     <div>老黄最帅~~~</div>     <div>没错，这又是一条弹幕！</div>     <div>这里都是弹幕</div>     <div>前方高能！！！</div> </div>发送弹幕div代码<div class="send">     <input type="text" class="s_txt" />     <input type="button" id="send_sub" value="发表评论" class="s_sub" /> </div>javascript逻辑代码<script>     var oShowList = document.querySelectorAll('.screen div')     var oShow = document.querySelector('.screen')     var oSend = document.querySelector('.send')     var oText = document.querySelector('.s_txt')     var oBtn = document.querySelector('#send_sub')     oBtn.onclick = function () {       var oDiv = document.createElement('div')       oDiv.innerHTML = oText.value;       oDiv.className = 'magictime';       oShow.appendChild(oDiv)       init(oDiv)       oText.value = ''     }     for (var i = 0; i < oShowList.length; i++) {       init(oShowList);     }     function init(obj) {       var screenHeight = document.documentElement.clientHeight;//获取浏览器高度       var screenWidth = document.documentElement.clientWidth;//获取浏览器宽度       var sendHeight = oSend.clientHeight;       var maxTop = screenHeight - sendHeight - obj.clientHeight;       var maxLeft = screenWidth - obj.clientWidth;       obj.style.top = Math.random() * maxTop + 'px'       obj.style.left = maxLeft + 'px'       obj.style.color = randomColor()       move(obj, maxLeft)     }     function randomColor() {       var color = '#';       for (var i = 0; i < 6; i++) {         color += Math.floor(Math.random() * 16).toString(16)       }       return color;     }     function move(obj, maxLeft) {       maxLeft -= 3;       if (maxLeft > -obj.clientWidth) {         obj.style.left = maxLeft + 'px'         requestAnimationFrame(function () {           move(obj, maxLeft)         });       } else {         oShow.removeChild(obj)       }     }   </script>安装部署首先领取一个月的免费服务器，如果通过我这里注册，还可以领取200元的代金券，可多购买两个月的服务器  领取地址 ，然后系统选择Ubuntu 18.04 server 64bit，设置密码，领取后按照以下步骤初始化：首先修改一下安全组，点击控制台-弹性云服务器，点击实例名字点击安全组-更改安全组添加以下端口配置在网页上远程登录也可以通过xshell登录，用户名为root，密码为之前设置的，如果忘了可以选择重置系统安装nginx# 更新一下系统 apt-get update # 安装： apt-get install nginx # 安装上传工具 apt install lrzsz配置nginx# 上传弹幕的文件 cd /var/www/htm/ rz  # 选取弹幕网页文件  index.html，可在附件下载 # 启动： nginx -c /etc/nginx/nginx.conf  # 访问 访问自己的公网IP即可，老黄的是 http://124.70.138.209/好啦，以上就是开发一个可以发送弹幕网站的完整过程了，如果有什么疑问，欢迎在下面留言告诉老黄~

活动链接: https://developer.huaweicloud.com/activity/HWexpert.html云享专家官网：https://developer.huaweicloud.com/expert 【华为云·云享专家征集令—第二期】活动时间：2020.6.1-2020.6.30云享专家招募活动正在进行中，参与活动将赢取多种好礼！信息的发展可谓是迎来了一个新的阶段，云计算与大数据相结合，智能化与万物互联齐携手，共同驱动着新工业革命，驱动着传统产业升级，每个企业行业都处于新的起点，我们正见证着一个新格局的出现。 我们不禁要问：未来，究竟谁能把握全球产业发展的新形态？  未来已来，或许我们更需要一群值得信赖的行业专家和业界精英，作为技术的先行者，将自己的经验分享给更多的人，帮助更多的人；或者找到同道中人，和最优秀的开发者们一起合作，让企业和行业走得更远！  而在这个过程中，华为云专家项目显然是走在了前列。 一、华为云·云享专家是什么？云享专家，是一群乐于技术分享的专业人士和行业精英，帮助云用户快速成长的开发者人群二、如何参与活动分享云享专家申请链接（官网、活动页面等）至身边好友，邀请好友入驻华为云专家，入驻成功即可获得奖励！三、推荐奖励步骤推荐成功≥1人   获得收纳包+数据线+华为云代金券100推荐成功≥3人  获得定制书包+旅行本（套装）+华为云代金券400推荐成功≥5人  获得机械键盘（普通）+无线鼠标+华为云代金券600推荐成功≥8人  机械键盘（雷柏）+定制书包+无线鼠标+数据线+华为云代金券1000备注：被推荐者申请时请在“个人介绍”中备注推荐人姓名+联系方式！想了解更多活动详情，请添加华为云专家小助手“Hwyzj223”各位还在等什么，赶紧来参加吧！人总是要有梦想的，万一实现了呢！点击请查看详情：https://developer.huaweicloud.com/activity/HWexpert.html

作者：黄药师（黄隽）背景在某开发团队辅导的回顾会议上，团队成员对于优化估计具体方法上达成了一致意见。询问是否有什么具体的估计方法来做估算。问题分析回顾意见上大家对本次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 · 敏捷智库】估算第三篇：利用故事点做估算

背景有些团队践行敏捷一段时间后，感觉回顾会议（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

作者：黄隽（Charlie）背景敏捷江湖桃花岛社区下线会议时，敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果，也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下：问题一：团队只关心数字。计划会议大家只关心估算的数字，经常花费大量时间做估算，怎么办？问题二：团队过度承诺。有时候，团队被迫承诺过多的工作，迭代目标完不成，怎么办？团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。问题分析以上两个问题也是敏捷初始团队经常遇见的问题，现简单分析发生原因如下：问题一：团队只关心数字。团队从瀑布开发方式转为敏捷开发后，学习了敏捷Scrum框架，然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话：“这个估算数字合理吗，我们要不要再好好想想清楚？”因此团队常常陷入无休止的讨论中。团队狭隘的理解为，计划会议中最重要的事情就是估算，而估算最重要的事情就是得到每个用户故事完成所需要花费的精确时间，即数字。也就是说，团队过于追求数字的准确性，忽略了估算的真正核心价值。问题二：团队过度承诺。团队经常在产品上市日期已经确定的情况下过度承诺。因为时间紧迫，领导施压（与资金和绩效挂钩）。比如，领导经常说：“大家加把劲儿，我相信大家的能力，努力一下，这些需求你们是可以做完的，大家的表现会影响绩效评估，年底咱们多发点资金。”所以团队常常了了估算、一言堂（架构师说的算）、猜测工作量，最后造成过度估算，经常完成不了迭代目标。小结“团队只关心数字”和“团队过度承诺”两个问题是敏捷初始团队经常遇见的问题。从以上问题分析中可知，团队成员并没有了解估算的真正核心意义，导致团队狭隘地理解成估算就是要最后的数字，而且在有外部压力的情况下团队也顾不上认真估算，盲目地过度承诺工作内容。其实估算并不只是为了得到估算数字和不靠谱的承诺。我们先一起学习和了解什么是估算的核心内容，这样可以更好地理解估算，然后再针对以上2个问题进行解答。解决措施利用核心概念树立正确认识在这里，我们只考虑不了解核心概念而导致估算活动不理想的情况。还有其它情况可以导致估算活动不理想。比如，不会利用故事点估算、不会估算具体方法等。这两种情况我们在后续的2篇文章中给予解答。通过上一篇《估算第一篇：利用用户故事了解需求》相信了解了如何利用用户故事理解需求。如果对用户故事不太了解的朋友，建议可以花一点时间阅读上篇文章，也会有助于做好估算。现在我们一起了解一下估算的4个核心概念，以便理解估算，树立正确认识，然后才能更好地解答以上2个问题。估算的4个核心概念所对应解决的问题如下表所示：问题估算核心概念问题一：团队只关心数字。利用“区分准确与精确”：估算应该准确，但不必过分精确。利用“估算相对大小”：人们更擅长对大小进行估算，而不是绝对大小。问题二：团队过度承诺。利用“团队一起估算”：在估算活动中，团队成员一起估算，结果更合理。利用“估算不是盲目承诺”：估算不是承诺，重要的是我们不能这样认为。区分准确与精确估算应该准确，但不必过分精确。比如，我们估算某产品是10888人时（是怎么做到这么精确的？）。其实这是很荒唐的，过于精确的估算纯属浪费。我们需要应该投入刚好够用的工作量，得到一个刚好的、大致正确的估值，如做估算时工作量和准确度的对比图所示：做估算时工作量和准确度的对比图在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。团队成员在做一项工作的同时，难免会遇到各种各样的问题，所以为了做到准确估算，在做估算时，任务的拆分一定要适当细，只有细化后，团队成员才清楚每项工作预计会花多少时间。当然细化也是有个度的，如前面提到的做估算时工作量和准确度的对比。当团队成员反馈超过预计工时时，需要了解是不是遇到了什么困难，需不需要帮助解决。超过16小时的任务建议需要再细化。在做估算时，我们经常会填写预计工时和实际工时。预计工时是我们估算的结果，实际工时是对估算结果的检验。我们允许预计工时的不准确，但是一定要填写准确的实际工时，这样才有助于我们在估算不准的问题上有充分的证据做分析，然后改进，进行良性循环。随着团队成熟度的提高和对业务的越来越了解，估算准确度经过几个Sprint会有所提高。估算相对大小建议使用相对大小而不是绝对大小来估算PBI。比较所有条目，然后确定某个条目和其它条目的相对大小。如下图所示，讨论一个杯子相对于另一个有多大比较容易，但对于杯子中可以盛多少绝对数量的液体，我们可能没有概念。相对大小对比图人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。当然，有些较成熟的团队，也可以借鉴历史数据和经验，直接应用工时或理想人天估算也并非不可。更多关于相对大小的内容介绍，可以阅读下一篇《如何估算第三篇：估算故事点》，其中会介绍一个具体实践，即故事点估算。团队一起估算而不是个别人估算在估算活动中，团队成员一起估算，而不是仅仅由项目经理、架构师、主要程序员估算。简单说，是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来估算。产品负责人和Scrum Master这两个角色都在场，但并不实际参与估算。产品负责人负责阐述PBI，并回答团队要求澄清的有关需求的问题。Scrum Master负责帮助指导和引导估算活动。最终的目的是开发团队能够一起确定每个PBI的大小，当然包括开发和测试的所有工作量。团队成员一起估算也是为了确保工作没有遗漏，不管怎么拆分任务，甚至是不拆分任务以story为最小颗粒度，那就按照story可以上线为标准来估算。如果团队非常关注每个人手头上的task，比如测试和开发人员手头上的task，那就没有统一标准，根据具体task内容估算。 记录工作项工时，可以参考华为云DevCloud，工作项工时显示如下图所示。需要客观估算而不是盲目承诺估算不是承诺，重要的是我们不能这样认为。举一个例子，如果在估算的时候告诉团队成员他们的估算正确性直接影响着他们的奖金和绩效，那么每个人都会给出一个比开始大得多的估值。估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。所以，团队成员在没有外因干扰情况下，大胆、放心的估算工作量，也就是估算预计工时。预计工时不仅仅是用于安排任务和估算本Sprint PBI在哪个时间点完成的,它还可以用于持续改进。预计工时就是估算需要多少时间可以完成，在Sprint进行中，会让团队成员根据实际情况去更新实际工时。例如，昨天更新4小时，今天又更新4小时，那就把实际工时更新为8小时。当Sprint结束后复盘时，我们会整体看这些预计工时和实际工时的数据，主要是为了提升团队/个人估算水平。如果估算和实际有明显差距，是需要深入分析的。本身也是期望通过估算促进做简单设计。应用正确认知处理问题，做好估算以上是估算的核心内容。现在我们回头看看之前的两个问题。问题一：团队只关心数字。面对这个问题，作者主张团队成员不要只是关心数字，还要关心投入产出比（ROI），避免浪费。另外还可以考虑采用更快、更易于理解的方式来进行估算。从估算的核心概念“准确与精确”中了解到，在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。另外从估算的另一个核心概念“估算相对大小”中了解到，人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。因此，我们在做估算时：首先，要把握一个估算的适度准确原则，不要过度浪费。其次，为了降低难度，团队更好的达成一致意见，可以采用相对大小方式进行估算。问题二：团队过度承诺。面对这个问题，作者主张估算由真正完成工作的成员在安全的环境下大胆、放心地估算，避免过度承诺。从估算的核心概念“团队估算”中了解到，估算活动是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来完成。也就是说，真正完成工作的人才会对工作需求内容更用心，也更了解团队的速率，他们的承诺更客观。估算另一个核心概念“估算不是承诺”中提到，估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。团队成员在没有外因干扰情况下（不建议奖金、绩效明显挂钩），大胆、放心的估算工作量。如果能做到以上相信至少在估算的结果上更为客观和靠谱。有些朋友可能会问，如果得到的估算结果是靠谱的，完成需求就是那么多工作量，产品上市日期也已经确认，那么怎么办？如果真的是因为产品上市日期已定，有上线压力，团队一定要承诺过多的工作内容，那么就确保团队把故事拆分得更细，即使他们交付不出设想中的高档理想的全功能版，至少也能每个典型的功能领域多少交付一些内容。说到这里，还是不建议这样做，尽量采用高价值的事情优先做原则，与客户协商，产品经理对需求排好优先级，优先实现高优先级的PBI。了解更多以上是针对不了解估算核心概念而导致估算活动不理想的解决措施。朋友们看到这里，相信对估算的核心有了基本了解。也许对什么是故事点估算以及具体估算方法感兴趣，欢迎阅读接下来的关于估算的另外两篇文章，即《如何估算第三篇：利用故事点做估算》和《如何估算第四篇：利用2种常见方法做估算》。参考附录Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。Rachel Davies. Liz Sedley.敏捷教练[M].北京：清华大学出版社。附件：如何估算第二篇：利用核心概念解决估算常见问题V1.2.pdf[hide]链接: https://pan.baidu.com/s/1qQHK_WxG_9YQOKIm8MO8aQ提取码: g6vn[/hide]

我们常见到Epic、Feature、Story和Task这些和敏捷相关的概念，它们之间的关系是什么？我们如何灵活使用这些概念，从而让敏捷的需求管理更为高效？本文为你解答，建议收藏。什么是Epic、Feature、Story和TaskEpic、Feature、Story和Task用来划分需求颗粒度的标签，可以看作需求占位符，分别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义，在进行需求划分的时候可以进行参考。Epic：史诗，是项目的愿景目标。通过Epic的落地达成，使公司可以获得相应的市场地位和回报，具有战略价值。通常需要数月完成。Feature：可以带来价值的产品功能和特性。相比Epic，Feature更具体，更形象，客户可以感知，具有业务价值。通常需要数周，多个Sprint才能够完成。Story：通常所说的用户故事，是User Story的简称。是从用户角度对产品功能的详细描述，承接Feature，并放入产品Backlog中，持续规划，滚动调整，始终让高优先级Story交付给客户，具有用户价值。Story要符合INVEST原则（Idependent, Negotiable,Valuable,Estimable,Small,Testable），通常需要数天，并在一个Sprint中完成。Task：是团队成员要完成的具体任务。在Sprint计划会议上，将Story分配给成员，然后由成员分解为Task，并预估工时，通常在一天内完成。  将上面的描述简单整理，如下表所示。它们之间关系是什么Epic-Feature-Story-Task是一种将需求进行结构化管理的方法，在使用时是从上到下逐层分解，形成自下而上的依赖。如下图所示。在实际的开发过程中，需求会发生变化，我们要不断的调整，在调整中避免偏离目标方向，每次新建需求的时候都要记得向上对齐到Epic，保证所添加的Story和Task和它们上层是有关联的，这样就可以在一定程度上保证团队在朝着目标前进。更多关于需求结构化管理的内容，请阅读【参考附录】【DevCloud· 敏捷智库】如何进行需求结构化管理？。我们如何灵活使用这些概念，让需求管理更为高效为了帮助大家加深对 Epic、Feature、Story和Task的理解，我们对一个案例进行需求拆分，过程中会结合项目管理平台进行展示，以华为云DevCoud为例。案例：某大型商超受互联网的冲击，营业额大幅下滑。为了减少门店消费者流失，保有市场地位和份额，决定用6个月的时间建立自己的网上商城。第一步： Epic确定和创建根据前面的介绍，在进行需求确认的时候先看颗粒度，然后再考虑其承载意义。※思考：一个产品是一个Epic吗？产品的每个业务模块是Epic还是Feature？产品通常具有战略意义，从这个角度看，产品适合作为一个Epic。但是不是所有的产品都适合，还要看产品是什么，它的颗粒度有多大。在本文的实例中，网上商城周期是6个月，目的是保有市场份额，从颗粒度和战略意义上，网上商城适合作为一个Epic。每个业务模块具体是Epic还是Feature要分情况。比如：构建智慧城市是一个愿景目标，下面包括智慧交通，智慧政务，智慧社区等，这些每个业务模块都很大，用Epic进行需求占位合适一些。我们在DevCoud创建一个Scrum项目，命名为某大型商超网上商城，进入到【需求规划】的界面，在【Epic】下面新建，如下图所示。新建之后，点击进入到详细编辑界面。将描述信息填写完整，可以使用DevCloud提供的模板，如下：作为 <用户角色> ，对于这个Epic来说，用户角色是整个公司。我想要 <结果>，想要的结果就是建造网上商城。以便于 <目的> ，目的是想要减少消费者流失，保有市场地位和份额。同时在基本信息中设定这个Epic的起止时间，优先级，重要程度，预计工时等信息。这些信息对于团队理解产品、理解项目起到至关重要的作用，所以要填写详细。编辑界面如下图所示。第二步：将Epic分解为Feature客户要求在6个月内交付5个功能模块：促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期，每个模块大概需要2-3个Sprint完成，从颗粒度和承载的意义，这5个模块适合作为Feature。创建如下。创建之后，如需要填写详细信息，可以在详细页面进行编辑。界面信息项和前面Epic的相同，此处不再赘述。第三步：Feature分解为Story敏捷开发是渐进明细的，不要求所有需求在相同时间做到同样详细，只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。客户优先级中，会员管理Feature优先级高，会员管理这个Feature就要在需求梳理会议上详细分解为Story放入到产品Backlog中。经过分解后，需要包含和管理员相关的以下功能: 积分管理、会员级别管理、用户分析、用户管理。这些具体的功能就可以作为Story。需要注意的是，我们分解出的Story要尽量在一个迭代内完成交付，如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的，无法交付的Story对于当前Sprint来说就是浪费。分解后的Story如下图所示。第四步：将Story划分为Task在Sprint计划会议上，团队和PO要共同从产品Backlog中按照优先级顺序选择本次Sprint需要完成的Story，进入到冲刺Backlog中。团队成员认领后，将Story分解为Task，并进行估算。※思考：Story和Task如何区分？Story聚焦价值，需要在Sprint中完成，要用数天的时间，要符合INVEST原则。Story的描述是一个名词，如积分管理这个Story的完整描述是：作为管理员，我能够进行会员的积分管理，以此来划分消费等级提供不同增值服务。Task聚焦实现价值，通过过程性的任务来实现Story的功能。通常是1-8个小时。Task的描述是一个动作。如积分管理这个Story，功能的实现需要通过业务逻辑开发，积分规则设计和积分数据库设计这几个过程来完成。这些就是Task。如下所示。这样，从Epic开始，到Task结束，我们完成了网上商城的需求拆分。总结：使用Epic、Feature、Story、Task管理需求时，需要注意以下几个方面。1.敏捷开发中需求是逐步细化的，遵循自上而下的方式去分解需求。2.Epic和Feature都是颗粒度比较大的需求，是用户对于产品的期望和功能特性的描述。3.分解为Story的时候，目前正在进行的Sprint需要分的更小更细，将来的Sprint需求（可能是3个及以上）就不需要那样细分。当进行到某个Sprint时，再进行分解，细分成一组更小、更细的条目。4.只有当前Sprint的Story进行Task分解。5.所有这些粗略和详细的Story都放在产品Backlog中，整个列表要遵循DEEP( Detailed appropriately, Emergent , Estimated , Prioritized )原则，定期梳理和排序优化，保证高优先级的需求优先实现和交付。6.在整个过程中需要和客户一直保持沟通合作，这样才能保证我们实现的功能是客户真正想要的。写在最后本文通过一个用户场景来帮助大家理解Epic、Feature、Story、Task的含义以及如何使用。因为没有相同的项目，所以在开发过程中还要结合产品和业务本身的特点，进行具体问题具体分析。为了更好的分析问题，我们需要扎实的掌握Epic、Feature、Story、Task的含义并理解他们之间的关系。相信随着大家深度使用，一定能运用的得心应手。敏捷路上，你我同行！参考附录1、Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。2、Mike Cohn.用户故事与敏捷方法[M].北京：清华大学出版社。3、【DevCloud· 敏捷智库】如何进行需求结构化管理？4、文章博客地址：https://bbs.huaweicloud.com/blogs/142259附件：【DevCloud•敏捷智库】读懂敏捷需求管理的4个关键词.pdf [hide]链接: https://pan.baidu.com/s/1O6viir4TtSoC2jWmRDfe_w提取码: diq8[/hide]

在华为云上部署SAP业务，能够充分利用华为云大规格、高性能、高安全和高可靠的能力以及全生命周期的管理服务，帮助企业简化管理、节省成本、高效运营，快速实现数字化转型。本文详细介绍了华为云SAP解决方案的干货，从了解产品、安装部署、客户案例等几个方面来介绍，具体包含云图说系列、SAP技术汇系列、帮助文档及其操作短视频等，详情如下表所示：类别内容链接       了     解     产     品SAP解决方案介绍视频 SAP解决方案介绍视频SAP成长地图 SAP成长地图SAP技术画册 SAP技术画册SAP特性树 SAP特性树云图说系列【云图说】第57期 华为云SAP解决方案，让业务运营更高效【云图说】第65期 SAP与华为云的“联姻之路”【云图说】第72期 稳稳的！华为云SAP解决方案【云图说】第77期 “坚若磐石”的华为云：SAP高可用/灾备【云图说】第112期 四大业务场景带您玩转华为云SAP【云图说】第124期 高效管理华为云SAP的“秘密武器”【云图说】第149期 SAP技术画册“一点通”【云图说】第171期 华为云帮助中心意见反馈“一点通”【云图说】第172期 初识华为云SAP认证规格【云图说】第183期 SAP Business One， 中小企业上云的“小钢炮”【云图说】第187期 初识华为云SAP系统磁盘【云图说】第190期 SUSE镜像介绍热点FAQ【热点FAQ】第一期   华为云SAP知多少-概念篇【热点FAQ】第二期   华为云SAP知多少-购买篇（上）【热点FAQ】第三期   华为云SAP知多少-购买篇（下）【热点FAQ】第四期   华为云SAP知多少-应用篇SAP技术汇【SAP技术汇】第一期   说说SAP那些事儿【SAP技术汇】第二期   什么？！SAP上云只需三步？【SAP技术汇】第三期   大话SAP迁移【SAP技术汇】第四期   SAP容灾一点通【SAP技术汇】第五期   SAP扩容实战【SAP技术汇】第六期   SAP HANA高可用之实战演练【SAP技术汇】第七期   SAP S/4HANA高可用之实战演练【SAP技术汇】第八期   2019年，华为云SAP资料大事记【SAP技术汇】第九期   SAP上云的最佳拍档 【SAP技术汇】第十期    初识华为云SAP系统磁盘【SAP技术汇】第十一期    云上SAP网络概述【SAP技术汇】第十二期    华为云SAP上云概况SAP认证规格  SAP认证规格SAP应用管理演示【SAP应用管理演示】SAP应用一键部署【SAP应用管理演示】SAP应用备份和恢复【SAP应用管理演示】SAP应用容灾【SAP应用管理演示】SAP应用监控     新     闻     资     讯华为生态大会完美闭幕 华为云SAP解决方案大放异彩 华为生态大会完美闭幕 华为云SAP解决方案大放异彩华为云SAP全新V5云服务器震撼发布！ 华为云SAP全新V5云服务器震撼发布！#岂止于大#   华为云SAP认证1.5T/3T/4T云服务器震撼发布！ #岂止于大#   华为云SAP认证1.5T/3T/4T云服务器震撼发布！华为云SAP全新C6云服务器震撼发布！ 华为云SAP全新C6云服务器震撼发布！性能有保障，复工有力量！  性能有保障，复工有力量！      咨     询     报     价咨询报价咨询报价       安     装     部     署帮助文档 SAP部署指南 SAP部署指南（专属云） Data   Provider for SAP用户指南 SAP安全白皮书 SAP备份与恢复指南 SAP高可用及灾备指南 SAP NetWeaver用户指南 SAP HANA描述 SAP HANA用户指南（单节点） SAP HANA用户指南（集群） SAP HANA用户指南（裸金属服务器单节点） SAP HANA用户指南（裸金属服务器集群） SAP HANA（精简版） SAP S/4HANA快速部署指南 SAP S/4HANA高可用部署指南 SAP   Business One快速部署指南 SAP Business One用户指南 SAP应用弹性伸缩用户指南 SAP备份上传OBS最佳实践 SAP系统扩容最佳实践 SAP ASE最佳实践 SAP迁移上华为云最佳实践 SAP企业项目管理最佳实践 常见问题 产品术语操作短视频【操作短视频】购买HANA云服务器（单节点）【操作短视频】安装SAP HANA（单节点）【操作短视频】查看SAP HANA数据库状态【操作短视频】备份SAP HANA数据【操作短视频】恢复SAP HANA数据库【操作短视频】单节点场景下的SAP HANA高可用【操作短视频】企业项目管理原理短视频【原理短视频】云上使用CBR整机备份功能迁移SAP系统【原理短视频】线下SAP系统迁移到华为云【原理短视频】华为云SAP HANA单节点高可用【原理短视频】华为云SAP S/4HANA高可用          客     户     案     例【客户案例一】哈药集团【客户案例一】哈药集团【客户案例二】浙江环 球滤清器【客户案例二】浙江环 球滤清器【客户案例三】周黑鸭【客户案例三】周黑鸭【客户案例四】良品铺子【客户案例四】良品铺子【客户案例五】高济医疗【客户案例五】高济医疗【客户案例六】广东拓斯达【客户案例六】广东拓斯达【客户案例七】双胞胎集团【客户案例七】双胞胎集团【客户案例八】武汉仟吉【客户案例八】武汉仟吉【客户案例九】广汽蔚来【客户案例九】广汽蔚来更多业务信息请点击：https://www.huaweicloud.com/solution/sap/