以下文章来源于胖教练说敏捷 ，作者Kaveri 徐毅严守三段式表述首先，我们要明确用户故事的三段式表述格式，因为这个五问法是需要使用者认可和严格遵守用户故事的三段式表述格式的。作为【某类用户】我想要【某个功能或解决方案】以便【满足某个诉求或产生某种价值】这里要强调，很多使用者都没有重视这个格式，比如“作为”的后面，是“某类用户”，英文是 a type of user，是非常具体的某个用户类型或者某个细分群体。不同群体的诉求和偏好不同，其实这应该很容易理解才对。第一问：这个功能或解决方案真的能满足诉求或产生价值吗？第一问，是为了检验逻辑链条的。有了 VIP 身份，就能够带来尊贵感受吗？有了登录限制，就能够避免滥用吗？要达成目标，除了实现功能，是否还有也需要满足的其他因素？第二问：要满足诉求或产生价值，只能用这个功能或解决方案才能实现吗？第二问，跟第一问是刚刚好反过来的，如果说用户故事里面的诉求或价值就是罗马，那么这个问题就是“通往罗马的路，真的只有一条吗？” 是否还有别的办法可以做到？以及，是否真的必须投入研发人力和资源实现功能才能做到？我亲历过一个案例，团队成员说他们想新开发一套系统，实现某种灵活的配置功能，让产品人员可以自行操作，以便将目前从前期勾兑需求到交付功能共约3-4个月的周期缩短1个月。这个案例其实适用于五问法的全部五个问题，但在此，我们就会问：要将3-4个月周期缩短1个月，必须要新开发这套系统才能做到吗？答案显然是“不”。第三问：这类用户真的关注/会用/能用/愿意用这个功能或解决方案吗？第三问，是为了确认我们所写下来的“某类用户”是否真的是这个功能或解决方案的用户？是否真的是我们要去服务的对象？是不是找错了用户群体？比如：作为业务人员，我想要晚上批处理新办卡申请，以便加快奖励积分到账速度。业务人员或许真的想要加快奖励积分到账速度，因为这样可以提升客户满意度，但是他们真的会去使用批处理新办卡申请这个功能吗？我想不会，明显不是他们会去某个系统里面点击某个菜单或按钮去操作的事情嘛。第四问：这类用户真的有这个诉求或期望实现这个价值吗？第四问，其实也是在辨析我们是否找对了“用户类型”，不过严格来讲，其实我觉得叫“干系人类型”可能更准确。咱们投入人力和资源去开发功能，就是为了交付功能或解决方案让“用户类型”满意，如果我们找错了对象，对准一个错误对象的不知道是否存在的述求，去提供功能，99.9%是做无用功。当然，大多数用户故事实践者的真正问题不是找错了对象或对象的诉求，而是根本没有关注过这一点。毕竟，有多少人写用户故事的时候会真的一板一眼地把“我想要【满足某个诉求或实现某种价值】”写出来么？第五问：怎么知道功能或解决方案已经实现、诉求已经满足或价值已经实现？这个问题应该不难理解，就是验收标准，只是它包括两个部分。一部分是功能有无实现，另一部分是诉求有无满足、价值有无实现，毕竟功能实现并不直接等于诉求一定被满足、价值一定被实现，对吧？如果你不认同，请回到第一和第二问。这就是我的用户故事五问法。非常简单，而愿意去抠逻辑的精神，则是五问法能否有效的关键。举一反三，普适版用户故事正如我在敏捷之旅演讲中提到的，用户故事也是我认为不仅适用于工作，同样也适用于生活的一个实践。但凡你要做一件事情，都可以拿出来，按用户故事的三段式写出来，再用五问法去套一套，应该就能帮助你达成所愿。比如以前有位Scrum Master曾经问我，说想要拉着团队开个反省会（还是叫啥别的名字有点不记得了），我让他把自己的想法用用户故事写了下来：作为 Scrum Master，我想要团队开个反省会，以便提振团队士气。我说，你自己读一下你的句子，你觉得能达到效果吗？反省会这个名字一听就觉得是批判人的、激起人负面情绪的，怎么去提振士气呢。名字和内容固然是有问题的，不过我的重点不在这里。关键是，你提到“想要团队开个反省会”，到底是你想要开会还是团队想要开会？这是为了谁的利益，你的还是团队的？这个五问法，我也曾经用于思考自己的职业选择。我会想，我是谁？作为这个谁，我想要加入某家公司、接受某个职位，以便能够怎么样呢？这个改变真的能够得偿所愿吗？还是另有他法？欢迎留言交流探讨。

敏捷开发和迭代开发啥区别啊

一、 论坛主题《国内国际双循环之项目管理发展趋势解析会》                                                                                               二、 主办单位中国国际数字和软件服务交易会三、 承办单位大连市项目管理协会大连高新区立智管理培训学校   四、 论坛时间大会时间：2020年12月19日13：30-17：10 五、 论坛方式线上直播形式六、 议程安排2020（第十二届）中国项目管理论坛13：00-13:30视频宣传13:30-14:10拥抱变化  适应发展新版PMP认证考试大纲解读和   《项目管理知识体系指南》PMBOK 7th 前瞻   刘亮  14:10-14:50什么是敏捷？孟繁强15:00-15:402021软考趋势解析&通过宝典吴芳茜15:40-16:20找到那匹更快的马洞察商业本质的商业分析方法孙涧溪16:30-17:10走进AWS公有云陈旭17:10会议结束 八、演讲嘉宾分享议题概况：演讲嘉宾：刘亮老师 Link PMP，PMI-ACP，NPDP，SAS Certified Professional;加州大学洛杉矶分校项目管理专业；工作相关：现工作于腾讯投资的汽车行业某初创公司；曾有易车和IBM的工作经历；一直活跃在奥迪中国数字化敏捷转型的一线；活动相关： 首届腾讯全球数字生态大会 分享嘉宾2018年中国商业分析峰会 演讲嘉宾演讲主题：拥抱变化  适应发展新版PMP认证考试大纲解读和《项目管理知识体系指南》PMBOK 7th 前瞻演讲概要：全面透彻了解项目管理的变革及认证动态           为什么改考纲？1.1商业环境变化1.2价值核心凸显1.3管理思潮涌现1.4当前的流程标准化的考纲就out 了2. 怎么改考纲？2.1 PMI人才三角具有更高的视野2.2 基于人才三角进行落地分解2.3任务的原则分解逻辑2.4背后是从知识域到绩效域的转变2.5前瞻 PMbok 7th 逻辑框架3、如何评价这次改变？3.1灵活化的过程更包容3.2“人”的侧重更助提升演讲嘉宾：孟繁强 Fred Meng资深效能教练专业教练、团队引导师准PCC/ CSP/ SPC/ CLP/ UCAC/ KMP/ 管理3.0引导师近20年项目/产品研发、管理、培训、咨询、教练经历。其中，10余年组织战略规划、改善、管理、培训、咨询经验，5年团队教练、专业教练经验。曾经为多家大型航空、汽车、医疗、金融、IT企业提供组织转型、战略规划和过程改善的咨询、培训和教练服务。目前，作为培训师、咨询顾问、外部教练服务于多家金融、汽车和IT企业。精益敏捷思想倡导者和践行者，全国敏捷社区组织者，中国教练联盟会员，多个业界知名会议/论坛分享嘉宾。演讲主题：什么是敏捷？演讲概要：l 是否？敏捷已经成为一种专有名词，在你的身边经常出现；l 是否？感觉已经做了很久敏捷，但很难向别人解释清楚敏捷的定义；l 是否？当老板问你：“我们现在算敏捷了吗？”你Feel not good；l 是否？敏捷、DevOps傻傻分不清楚；l 是否？敏捷成熟度，DevOps评级可以成为救命稻草；l 是否？我该学点什么，才能平安度过35岁危机？让我们运用Why、How、Who、What的模式，一起来帮助你解开敏捷的“未解”之谜吧！演讲嘉宾：吴老师 原命题组组员高级工程师，北京理工大学软件工程硕士，国家财政部政府采购项目评审专家，国家标准编制人，注册咨询工程师、注册监理工程师、PMP、信息系统项目管理师、招标师、软件造价评估工程师。自2007年至今，作为项目负责人独立或组织管理团队（根据项目规模）完成自项目立项直至项目交付和运维全过程的项目管理工作，包括信息化规划、项目可研、初步设计、招投标、需求讨论及确认，项目实施、项目验收等各环节的监督跟踪工作；通过方案审核、系统测试等手段监控项目质量（包括组织相关评审会议，检查各类输出资料、各类流程等）和保证项目进度，监控各环节资金使用的合规性和项目安全，承担过包括中办、国务院、中组部、中纪委、国家发改委等多个部委的国家级大型信息化建设项目的管理工作。演讲主题： 2021软考趋势解析&通过宝典演讲概要：1、软考之前世今生2、软考之来龙去脉3、软考之电照风行4、软考之妙算神谋5、了解软考和考试——为什么要拿到这个证书？6、如何合理备考，一次通关？演讲嘉宾：孙涧溪老师 美国项目管理协会（PMI）认证的 项目管理专业人士（PMP®）及商业分析专业人士（PBA®）美国产品开发与管理协会（PDMA）认证的产品经理国际资格认证（NPDP）中国外国专家局及PDMA认证的中国大陆首批产品经理NPDP讲师。高级项目管理师工作经历：曾任大连港集团码头操作系统项目经理、产品经理；国家排名前10的大型矿建企业 资讯部部长现就职于大型医药领域数据集团，任职PMO经理，负责国内顶级互联网企业的资审风控项目培训风格与特点:其授课突出不同知识体系间的内在联系，理论与实战并重，帮助学生内化知识，达成学习目标。其具备多年的软件研发、产品需求分析、创新团队建设、信用风控经验及项目管理经验，对项目管理、商业分析及产品管理具有丰富的实战经历。演讲主题：找到那匹更快的马 —— 洞察商业本质的商业分析方法演讲概要：企业在VUCA（易变性、不确定性、复杂性、模糊性的英文首字母缩写）时代参与日益激烈的市场竞争，需要更加重视项目前期的商业环境分析和商业论证，确保上马的项目是合理的、可行的，避免重回到高资源消耗、项目成果闲置的老路。组织项目或运营的前期分析研究重点在于“商业分析”，其目的在于保证企业经营活动的市场背后有其真实的社会需求，这是组织项目或运营活动的依据和能取得成功的前提。大纲：商业分析三要点，第一要点：分清需要 Needs 和 需求 Requirements商业分析三要点，第二要点：商业分析的核心——商业论证（Business Case）商业分析三要点，第三要点：支撑分析（ Analysis ）工作顺利的工具和模型们演讲嘉宾：陈旭老师程序员，DevOps 工程师极限编程大连社区技术主教练开黑后端技术负责人GitChat 推荐作者敏捷变革中心撰稿人视频课程《Linux 基础及应用》观看人数超过 40000 人PMP, CSM, RHCE, AWS Certified Solution Architect 认证参与并主导多个大型信息系统落地，拥有丰富的软件设计，数据中心规划，及软件开发和运维经验。曾受邀对 BGTA，重庆银行，城市热点等诸多国内外优秀企业进行技术培训及咨询服务。对敏捷软件开发，极限编程，混合云部署，无服务器架构，开源技术应用等见解深入，实践经验丰富。演讲标题：走进AWS公有云演讲概要：1. 公有云极简史2. AWS 核心服务3. AWS 集成服务4. AWS 架构支柱5. AWS 安全管理6. 公有云前景展望报名方式报名方法：点击下方链接，填写报名信息，销售顾问请选择“刘梦怡”，即可直接进入直播间。观看地址：https://mudu.tv/live/watch?id=o92e6xnm 联 系 人：    刘梦怡             联系电话：13889493590Email：liumengyi@cnpmi.com

[中国，2020年12月12日] 华为BETTER WORLD SUMMIT 2020（“共赢未来”全球线上峰会）自动驾驶网络FBB专场于12月20日到11日成功举办。本次线上峰会以“加速FBB网络自治，使能敏捷商业”为主题，来自全球的ICT产业领袖及行业精英在会上分享自动驾驶网络的前沿信息及实践成果，共同探讨在万物互联时代，如何以FBB自动驾驶网络使能敏捷商业。2020年新冠疫情席卷全球，驱动5G商用进程加速，更让全世界的网络的使用场景、流量的流向都发生了巨大的变化。新的变化与机遇，既对运营商的网络提出了更高的要求，也为运营商的商业增收打开了一个新机会窗，包括2B、2C、2H等全场景的敏捷性带来更快的TTR（time to revenue）、确定性体验销售，但这也使网络运维复杂性急剧提升，需要更少手工介入的网络保障，更智能的故障排除能力等。百万企业上云，iMaster NCE加速应用上云和5G承载先行当前，百万企业拥抱变化加速上云，SaaS流量激增，企业入云、多云协同成为云网融合的新重点。应对这个难题，华为NCE数据通信领域总裁国大正表示：“在云网场景，iMaster NCE通过网络服务化来实现网随云动，助力运营商提供云网一体化服务，满足企业入云的要求；在5G承载场景，提升规-建-维-优全流程自动化能力，满足5G规模建网、云网降本增效的要求”。网络需求暴增，“确定性体验”成时代新红利F5G时代，通过确定性体验，确保数字化家庭、千百行业信息化革新所需的高品质联接，不仅是时代的趋势，更是运营商的盈利机遇和盈利模式的新篇章。华为NCE传送接入领域总裁宋越刚表示“iMaster NCE实现资源预就绪、网络永在线和业务可承诺，使能确定性体验的全光自动驾驶网络，撬动F5G时代600亿美元的新产业空间。确定性体验就是溢价！”iMaster NCE基于AI技术实现管控析一体化方案，为智能联接保驾护航实现云网融合及确定性体验保障等更多可能性场景，需要技术上有架构性的创新。iMaster NCE 注入AI技术，为光纤网络、IP网络及家庭WiFi等FBB（固定超宽带）网络运行及维护提供支持。华为NCE产品部总裁陆海鸥表示“iMaster NCE通过海量数据和AI算法，驱动网络实时感知、分析和诊断，使能FBB网络的闭环自治。”在未来FBB网络运维愈加复杂的明天，华为将持续助力运营商加速FBB自治，为商业提供更多可能性，加速网络自动化、智能化进程。更多精彩内容，敬请关注BWS2020自动驾驶网络FBB专场直播回放：http://events.carrier.huawei.com/BWS-ADN/broadcast.html。

一个人不能没有生活，而生活的内容，也不能使它没有意义。做一件事。说一句话，无论事情的大小，说话的多少，你都得自己先有了计划，先问问自己做这件事，说这句话，有没有意义?你能这样做，就是奋斗基础的开始奠定。——戴尔·卡耐基2020年马上就要过去了，很多公司和团队以及个人都陆续着手这整年工作的归纳和总结，与此同时也开始对新的一年的展望。从小编上大学开始（那好像是一个很久远的时候……），大家会在QQ空间或者QQ签名上写一些很正能量的话以可能自己一年的努力和鼓励自己在新的一年能百尺竿头更进一步。当然很多有心人不仅是心怀美好期盼，而且还做了新一年的计划，比如，使用近些年来比较流行的bullet journal——子 弹笔记。子 弹笔记能它能让你在短时间内找到最重要的事情，高效的做好时间管理，告别盲目的做事情。在记录的时候，记得都是关键词或短句子，并且配合着一定意义的符号有条理的排列内容，给人一种简约和清爽的感觉。                                                       -------图片来源于网络子 弹笔记之所以被全球范围所推广和认可正是以为这样简约、高效的做计划的方式，其实这也正是遵循了现实的生活状态，即我们需要高效的同时，正每时每刻不再面临着变化，而详尽复杂的计划往往只是费力不讨好。这在软件行业中也是一样的。原来的瀑布式开发的方式已经无法适应当今快速的变化，详尽周密的计划必定无法指引软件走出VUCA时代所带来的“黑暗”，而敏捷开发的方式应时代所需势在必行，因为在敏捷宣言中就提出了“响应变化 高于 遵循计划”的口号。可能有些读者会有疑问说“难道敏捷就不做计划了吗？”，其实不是这样的。敏捷一样需要做计划。那么有些读者可能又会问“不是说响应变化高于遵循计划吗？怎么还做计划呢？”其实敏捷宣言不是说不做计划，而是说相比做计划更有价值的是响应变化，一切以变化为依据。那么有读者可能又会问“既然当今世界无时不刻不再变化，你如果响应了变化还怎么做计划呢？”很高兴有读者会有这样的疑问和思考，而这个问题也正是这篇文章所要和大家分享的，如何在敏捷开发中做计划，即敏捷规划。什么是敏捷规划敏捷规划是一种逐渐完善过程的规划方法，是对价值的探求过程。规划为一个概括性的项目开发问题“我们要构建什么？”找到最佳的答案，这一答案综合了功能、资源和进度三个方面。规划应该足够可靠，可以用来作对该产品和项目进行决策的基础。敏捷规划更关注规划过程而不只是建立一个计划。它鼓励修改、产生易于修改的计划，并且延续到整个项目过程。敏捷规划有效的原因经常进行重新规划在不同层次上制定计划基于功能而不是基于任务制定计划小故事保持工作流畅每次迭代都要消除处理中的工作在小组层次跟踪承认不确定性并为之做计划敏捷规划和传统规划的区别敏捷规划追求真实需求，重复初始计划敏捷团队开始时对项目的愿景有一个初步的讨论，之后用原型进行迭代。干系人可以在原型的基础上对项目进行反馈和调整。而在瀑布计划中，范围和解决方案还没有确定就需要干系人对项目进行详细的说明和反馈。敏捷通过原型来更好的理解相关领域，并以原型为基础进行进一步的计划和细化，这也体现了渐进明细的概念。敏捷规划贯穿于整个项目中，不仅仅是前期的工作传统规划中强调前期计划的重要性，主要集中在项目范围规划、时间规划、成本规划、质量规划、人力资源规划、沟通规划、风险规划、采购规划、干系人规划以及变更管理、配置管理和过程改进等相关计划上。这些过程都在项目开始之前就需要执行。敏捷恰恰相反，敏捷认为知识型项目的风险等级和不确定性使得前期计划出现了许多问题，所以敏捷方法提倡在整个项目生命周期中都进行规划，会有不同层次和详细程度的计划。但是， 敏捷认为前期计划是很有必要的，只是不宜过度，需要找到一个平衡点，既要做好足够的前期计划以减少大量重复和返工的风险，也能避免过度计划导致ROI下降以及多变的项目计划。敏捷规划是移动打靶，需要及时调整中期计划当目标是静止的时候，可以做很多计划，从而向着那个静止目标努力前进，当目标是移动的时候，就更加需要作出大量中期调整以保证目标达成，类似移动打靶。为了达成目标，敏捷方法使用了复杂的探测和适应系统去获取反馈并作出调整。敏捷规划的原则假设事先无法制定完美的计划事先规划有帮助，但不宜过度最后责任时刻再敲定计划关注调整与重新规划胜于与遵循计划正确管理WIP提倡更小、更频繁的发布快速学习规划并在必要时候调整方向敏捷规划的方法规划各层级计划，明确产品开发的方向在敏捷方法中，早期的计划是必要的，但有可能是不太完美的。不确定性导致了重复计划的必要性。为了体现适应性计划的特点，分别为：敏捷愿景、产品计划、版本计划、迭代计划、每日站会计划。计划的层次体现了渐进明细的特点，渐进明细的最终目的是为了交付与原始设计对象一致的产品。五层计划体现了在敏捷项目中一些细节不断涌现，需要根据反馈重新排序优先级，从而调整整个项目。这一点体现了敏捷宣言中的最后一条“响应变化胜过遵循计划”。五层计划如下图所示。定义愿景规划洋葱图的顶端是愿景层。产品愿景要清楚描述从哪些方面为用户或者客户之类的利益干系人提供价值。这一层是定义产品要解决的首要问题和产品的目标人群。考虑这些问题有助于了解产品为用户带来的真正价值，和如何让产品与其他试图解决相同问题的产品区别开来。确定产品概要列表和路线图开始时必须产生一些最基本的需求来填充产品列表，在确立列表之后，建立一个产品路线图。路线图要有时间轴、版本号和对应的特性功能信息。路线图可以表示产品随着时间的推移如何以增量方式构建和交付，以及驱动每一个版本的重要因素。制定版本计划根据产品路线图的时间路标从产品列表中选取适当的特性进入对应的版本计划中。版本规划是主要针对增量交付取得范围、日期和资源之间的平衡。每个企业和公司都需要有一个合适的节奏，有规律的向客户交付产品特性。迭代结束的可交付增量是潜在可发布的，是否发布要依据组织的发布节奏。通常的发布节奏有三种。在完成每个冲刺后发布：让发布和迭代的节奏保持一致。在完成多个冲刺后发布：将多个迭代的结果合并为一个版本进行发布。在完成每个特性后发布：不考虑迭代是否结束，做完一个特性就发布一个，这就是通常所说的持续发布。很多企业和公司完成一个特性后就马上向部分或者所有客户发布特性，非常频繁，有时可能甚至一天发布很多次。制定迭代计划迭代计划聚焦于实现本迭代所应开发的用户故事的详细任务以及任务的下发。一个迭代是一个较短的研发周期，通常持续2-4周。团队从产品列表中选择排序较高的用户故事纳入当前迭代中进行开发。制定迭代计划是为团队选择本迭代要完成的需求或任务。每日计划在每日站会中，团队成员聚在一起，每个人依次讲述自己在上次每日例会后做了什么，今天准备做什么，是否遇到了任何阻碍。团队通过每日站会的形式评估自己的状态，以一种非常直观的形式告诉大家当天计划做什么，这也可以让团队尽早识别风险。虽然早晨的这项仪式开始于对前一天的成果的讨论，但成功的团队会意识到每日站会是讨论计划的会议，而不是讨论状态的。因此，每日站会应该专注于制定一个每日进度的计划。最后以图的形式总结在这些级别产生的工件及其相互之间的联系。持续调整规划，保证产品的价值在敏捷的整个层级规划中，是一个持续规划的过程，团队会不断根据过程中的所学所获来逐步完善计划；这种方法使团队在短期内就能明确责任，同时帮助他们了解自己的责任是如何推动长期目标的实现的。规划洋葱图的每一个层次都不止执行一次，而是在产品的整个生命周期中多次执行。不过，每层执行的频率取决于该层的位置。一般而言，最常规划的是较低的级别，随着向更高级别的迈进，你将逐步减慢你计划的步伐。比如说，你要经常、乃至每天做日常规划，但你可能只需要每隔几个月甚至一年才重新审视你的产品愿景。在敏捷产品整个开发过程每个阶段都是持续进行的，结合开发过程图我们理解一下敏捷中的持续计划，过程图如下所示。通过流程图可以看出，先制定一个前期计划，通常是当前迭代以及未来2-3个迭代的任务是明确的；然后尽早实现并发布给客户获取反馈；根据反馈及时进行计划，对前期制定的版本计划和产品路线图进行调整，不停的在前期计划和及时计划中寻找平衡，保证团队的目标始终是给用户带来价值，从而保证产品的价值。敏捷规划的工具时间盒时间盒是固定的一段时间，相对比较短，计划的工作要在这段时间内完成。敏捷比较关注时间盒的概念，比如：一个迭代的时间盒是2-4周，一个迭代的计划会议是2个小时，一个回顾会的时间盒是1个小时，一个站会的时间盒是15分钟。时间盒的结束点可以视为一个检查点，采用时间盒的方式给整个敏捷项目的实施提供了频繁的检查点，通过结果评估、获取反馈、控制成本、管理风险来监控外界变换的不稳定的环境，从而测量进度并且重新计划进行中的工作。渐进明细渐进明细是一种滚动式规划的技术。 在PMI编制的PMBOK中，是一种对进度计划编制的技术，是指在项目进程中，随着信息越来越详细，估算越来越准确，持续改进和细化计划。细化是量化的基础，逐步细化我们的工作，可以提升项目计划的指导意义。最小可售功能（MMF）最小可售功能（MMF）是一个最小和可市场化的软件特征或者产品特佂，可以快速开发并为用户提供重要的价值。互联网时代的竞争中，第一个占领市场就可以抢占先机，即便这个功能可能还不完备，仅具备部分可用的功能。最小可售功能代表功能包足够完整到可以为用户或者市场提供价值，同时也足够小。在软件项目中，增量交付的方式让客户可以更早地获取可用功能，从而早期受益。增量交付在帮助团队获得早期投资回报的同时，也获得了早期的反馈，给后续功能开发提供了参考。怎么样，各位读者朋友，鱼和熊掌是不是可以兼得啦。在敏捷的开发中也许你还有会这样或那样鱼和熊掌的问题，那不妨来华为云的DevCloud专业服务转转，这里不仅提供了解决方案还有各种能力评估呢！在专业服务中针对不同的岗位提供了评估的能力，让开发者可以对号入座，并基于你所在的岗位、技术得到客观、全面、系统的测评以及名师般的学习引导。快来访问专业服务平台，通过个人能力评估，看看自己是什么水平吧！

CIO对这个问题很熟悉：“我们的技术策略是什么？”有时候，这个问题很宽泛，涉及制定总体技术战略，但更多时候这是针对特定的热键技术领域：“我们的云战略是什么？我们的DevOps战略是什么？我们的物联网战略是什么？”CIO对这个问题很熟悉：“我们的技术策略是什么?”有时候，这个问题很宽泛，涉及制定总体技术战略，但更多时候这是针对特定的热键技术领域：“我们的云战略是什么?我们的DevOps战略是什么?我们的物联网战略是什么?”无论是宽泛还是具体，这听起来都是非常合理的要求，而不是让CIO感到沮丧的要求。但是通常这个要求确实会让CIO感到沮丧，这有很多原因。问题在于，这个看似简单的问题其实包含很多内容。具体来说，“我们对XX技术的策略是什么?”通常是指：我们正在对该技术做什么?我们什么时候做?我们为什么这样做?这要花多少钱?这涉及哪些产品和供应商?这会为我们企业带来什么明显的好处，以及我们如何知道我们获得这些好处?这对我们的人员配备和培训有什么要求?我们忘记问但应该知道的是什么?这些都不是容易回答的问题，而且在很多企业中，这些都是高度政治化。回答这些问题可能是挑战，因此对于很多CIO来说，“我们的策略是什么?”感觉就像是持续进攻的第一个“凌空抽射”。但其实不需要这样。如何以正确的方式制定技术策略可以使流程非政治化。从首要原则开始(以及在流程中在正确时间让正确的人参与)可以最大程度地减少政治开销，并最大程度地提高该策略为上述问题提供正确答案的机会。步骤1：从一般到具体在制定总体技术战略之前，通常会通过针对特定技术制定战略来应对眼前的压力。但是，CIO应该避免这种做法。对于任何策略而言，关键要素之一就是从一般到具体的概念。也就是说，特定的技术策略应取决于整体技术策略—具体是指整体策略中定义和阐明的技术原则。CIO开始应该制定总体技术策略，在制定总体策略，并获得必要的支持后，CIO才应该着手针对技术的策略。步骤2：明确业务驱动力CIO及其团队应记录企业的主要业务推动力。根据企业的规模和重点(营利性或非营利性)，他们可以通过与其他高层和董事会交谈或查看财务报表等正式文件来获取这些驱动因素。令人惊讶的是，这是CIO和其他IT领导者经常跳过的步骤，因为他们认为业务原则非常明显，并不需要再次强调。但是，对于首席信息官来说，阐明业务驱动因素至关重要，因为技术原则取决于这些业务驱动因素。这里的关键在于以正确的粒度进行表达，这通常涉及深挖业务战略。例如，以营利为目的的企业的业务驱动因素，在最高层次上可能是“赚钱并为股东增加价值”。但是，特定的业务策略可能会继续–“通过收购在全球扩张”。这会显著影响技术战略，因为这让IT领导者了解到，他们需要专注于有效整合收购，并选择可在全球范围内发挥作用的技术，而不仅仅是在特定地理区域内。其他业务驱动因素可能包括：通过降低成本来提高盈利能力;通过吸引新客户来增加收入;通过撤离邻近地区，专注于核心竞争力;通过提高员工生产力来增加收入;通过自动化业务流程来提高敏捷性;此处的关键因素是“通过”后面的内容并驱动技术原则。例如，“…通过降低成本”将要求CIO部署技术以显着降低总拥有成本。当CIO及其团队明确业务驱动因素后，同样重要的是，获得其他业务负责人的支持。在阐明技术选择背后的逻辑并成功制定技术策略的过程中，这似乎是显而易见的步骤，但这也是重要的步骤。步骤3：选择技术原则当他们明确记录业务驱动因素，并且让其他高层管理人员签字确认后，技术团队就可以开始确定技术原则以支持这些特定业务驱动因素。例如，“提高敏捷性”的业务驱动因素自然适合于云计算等技术，该技术已被证明可提高敏捷性。因此，“云优先开发”可能是与该业务驱动程序保持一致的技术原则。选择技术原则的关键点包括：支持上一步骤中所述的业务驱动因素。 这里不必有1:1的比率，但每个技术原则都需要支持一个业务驱动因素，否则不应考虑;尽可能具体。“迁移到云端”可能是业务驱动因素，但“云优先开发”更清晰，因为这意味着新的开发工作应该在云端进行。另一个反例是，“尽可能集中，必要时分散”。技术独立。“云优先开发”有效，但“AWS优先开发”无效。为什么?通过指出云计算可实现敏捷性的方式，我们可以证明向云端迁移的合理性，但选择特定平台(无论是AWS还是任何其他云供应商)还为时过早，我们需要先确定具体选择标准，这通常发生在策略制定的后面阶段。涵盖所有战略技术。如果一项技术未包含在其中一项技术原则中，那么它就不会在清单中，也不是CIO计划投资的东西。了解这一点很重要-如果某些技术不符合技术原则，要么重新考虑原则，并确保将其与业务驱动力关联，要么将技术从清单中删除。对于“为什么不做X?”的问题，答案变成“它与我们的业务驱动力不符”，这是企业领导者可以理解和认可的语言。业务驱动因素和技术原则都应放在一张幻灯片上-CIO可以根据目标受众选择包含解释每种技术原则的要点。步骤4：完善策略、架构和路线图在首席信息官开始这个阶段时，他们已经对以下问题有了答案：“我们打算做什么?”和“我们为什么这样做?”此阶段的目标是完善技术原则–通过开发架构来显示所选技术如何组合，并补充该策略的某些细节。例如，如果目标是迁移到云端，那么下一步就是“开发云端卓越中心”。制定路线图也很关键，该路线图可以回答“我们何时进行?”这一问题。其中包括关键的里程碑，例如为供应商和产品选择制定选择标准，以及选择工作本身。与业务驱动因素和技术原则相比，策略、架构和路线图可能需要更深层次的细节，具体取决于主管和技术团队所需的细节水平。此外，如果存在特定于技术的策略，例如云计算、DevOps或IoT策略，则此阶段可以完善它们。步骤5：确定特定供应商和产品至关重要的是，企业必须在制定技术策略结束时完成供应商和产品选择，而不是在此之前。有关特定供应商工具的决定应由CIO评估得出，其中应包括特定的选择标准。这些选择标准实质上是对架构和技术原理的改进。例如，如果技术原则是“云优先”，则关键标准应该是“产品必须基于云”。这可避免技术决策中大部分政治辩论。作者：邹铮 编译来源：TechTarget中国

根据调研机构Forrester Research公司最近发布的一份调查报告，机器学习(ML)对于企业的业务获得成功至关重要。98%的IT领导者认为，机器学习运维(MLOps)将为自己的公司带来决定性的竞争优势。但是，只有6%的公司认为其机器学习运维(MLOps)功能已经很成熟，并且可以从中受益。根据调研机构Forrester Research公司最近发布的一份调查报告，机器学习(ML)对于企业的业务获得成功至关重要。98%的IT领导者认为，机器学习运维(MLOps)将为自己的公司带来决定性的竞争优势。但是，只有6%的公司认为其机器学习运维(MLOps)功能已经很成熟，并且可以从中受益。机器学习(ML)和机器学习运维(MLOps)到底是什么?为了找到答案，先从术语的定义开始。机器学习(ML)是一种可以在不需要人工干预的情况下从数据中学习的人工智能。致力获得成功的企业正在使用机器学习(ML)来优化其业务的各个方面：提高员工生产率、提高客户满意度，以及增加收入。虽然数据量在过去几年中几乎呈指数级增长，但使用机器学习(ML)组织和分析数据的能力却明显滞后。这成为了一个挑战。而面临的一个更大的挑战是将机器学习(ML)模型运用到生产环境中，使应用程序变得更加智能。Forrester公司在调查中发现，只有14%的受访者将机器学习(ML)模型运用到可重复且可靠的生产环境过程中。许多企业正在采取的一种方法是采用机器学习运维(MLOps)。机器学习运维(MLOps)是数据科学家和运营团队在机器学习生命周期中进行协作和通信的实践。在许多方面，机器学习运维(MLOps)正在努力获得与DevOps在敏捷软件开发中实现的机器学习生产率、效率和质量优势。只采用机器学习运维(MLOps)并不能解决企业尝试实施机器学习(ML)所面临的问题。而这是第一步，也是重要的一步，但还需要更多工作。成功采用机器学习(ML)能力的企业已经通过关键流程、工具和持续改进实践来加强机器学习运维(MLOps)。其中一些实践听起来很熟悉，因为它们直接来自工业制造行业中的经验和教训。精益制造的6个精髓50多年来，全球制造企业一直采用六西格码和精益制造技术来解决质量问题。如今，很多企业正在使用其中一些技术来从其数据中创造价值，并在本质上正在成为信息化工厂。(1)自动化(Jidoka)自动化在现代生产工程中起到至关重要的作用——提高产品质量、生产率和吞吐量。Jidoka这一日语术语描述的是具有人类智能的自动化，使机器设备和操作人员能够在发现问题时停止工作，然后立即解决问题，而不必等到生产线停止运行或生产结束。自动化(Jidoka)的概念可以为分析生产线做同样的事情。具有自动化(Jidoka)功能的自助服务可以为机器学习(ML)流程中涉及的每个角色提供基础设施、工具和数据需求。这种类型的自动化可以提高效率并确保符合标准。其结果是，不再浪费时间等待访问合适的环境或尝试配置从互联网下载的新工具。机器学习过程的每个阶段都可以自动调度，从而使整个系统可预测且高效。(2)工具(Tooling)工具在现代生产设备中起着基础性的作用。明智地使用工具可以帮助实现规模化。它可以减少所需的员工技能，同时提高质量，缩短实现价值的时间，提高生产率和速度。如今的信息工厂需要一系列工具来适应每个角色，并满足生产的每个阶段的需求。随着新的、更具挑战性的业务问题得到解决，将需要新的工具。这就引出了信息化工厂的下一个基本要素：研发实验室。(3)研发实验室(Research and development lab)直到现在，大多数机器学习(ML)工具几乎都只专注于模型开发，但这种情况正在发生变化。新的机器学习(ML)工具解决了操作流程和模型生命周期管理。这些新工具可以提高机器学习(ML)模型的效率，并支持下游操作、标准规范和模型治理。使用研发实验室，数据科学家可以在安全和可管理的环境中评估新工具，记录最佳实践并评估潜在收益。一旦被更广泛团队使用，新工具就可以集成在应用程序目录中，该目录可在自助服务提供过程中使用。(4)改善(Kaizen)Kaizen这一日语术语的意思是为了更好或不断改进而进行的更改。它更像是一种哲学而不是一种工作实践，它可以确保更高质量，消除浪费，提高效率。随着越来越多的企业开始扩展其数据科学能力，将会出现新的需求。这些可能包括更多标准化或自动化流程的机会。信息化工厂和相关团队(包括DataOps、数据科学、MLOps、DevOps、运营和商业智能)中工作的集成性使其适合改善(Kaizen)实践。每个人对面临挑战都有不同的看法，因此，应该鼓励他们不断评估如何改进信息化工厂的流程。(5)供应链(Supply chain)多年来，制造商通过使用准时制(JIT)方法进行零件交付来优化他们的供应链。准时制(JIT)将库存保持在最低水平，并消除了将零件移入和移出库存的时间和精力。信息化工厂需要以相同的方式处理数据。尽管大多数企业在多个数据仓库、操作性数据存储和数据池中都有大量的数据，但是发现和访问有用的数据通常是第一个挑战。在许多情况下，数据科学家需要数据工程师帮助复制大型数据集，因为需要读写访问来转换数据，并使其适合于机器学习(ML)模型的构建。这种延迟与理想的准时制(JIT)相比还相差甚远。在机器学习(ML)竞赛中获胜的企业将关注数据供应链，提供全面的数据目录和业务术语表。他们还定期评估和报告数据质量。大多数还使用只读快照，而不是复制数据。现在，许多人开始探索特定的机器学习(ML)特征存储，通过标准化数据的准备方式极大地加快了模型开发。(6)防错(Poka-yoke)最后一个是Poka-yoke，这一日语术语的意思是防错。手机中的SIM卡就是一个很好的例子，制造商将SIM卡去掉一个小角，以防止错误插入。防错(Poka-yoke)有助于防止缺陷的发生。这种类型的防错是以上描述的持续改进过程的一部分(Kaizen)。虽然防错措施的想法有些琐碎，但是想象一下如果把它嵌入到人们接触到的每个过程中，随着数据科学家使用更加自动化的工具实施更复杂的任务，防错措施将显现出其宝贵的价值。通过流程、工具和人才使机器学习(ML)获得成功机器学习(ML)和机器学习运维(MLOps)对于企业的业务成功至关重要，然而大多数企业都未能实现他们的目标。解决这一挑战的第一步是实施机器学习运维(MLOps)。然而，只依靠机器学习运维(MLOps)是不够的。通过获得以上六种行之有效的精髓，企业可以从数据中创造价值，从而获得更大的成功。原文标题：Becoming an ML information factory – 6 lessons we can learn from lean manufacturing，作者：Doug Cackett  来源：51CTO.com  李睿

【直播时间】12月5日10:00-12:00【课堂地址】https://bbs.huaweicloud.com/live/education_live/20201205.html【直播福利】请在完成以下准备，获得免费资源，参与直播学习与抽奖！！！1、在华为云官网完成实名认证。a.如果您没有华为云账号，请立即注册，相关操作请参见如何进行账号注册。b.注册后完成实名认证。 参考个人账号如何完成实名认证或企业账号如何完成实名认证。2、认证成功，扫码0元购开通DevCloud基础套餐，并保存支付完成截图。开通链接:（https://console.huaweicloud.com/devcloud/?region=cn-north-4&version=0&utm_source=kfz_bjjd&utm_medium=kfz_bbs#/order/periodApply）或手机扫码0元购开通：3、重要！！！保存支付成功订单截图（如下），上传到抽奖帖（https://bbs.huaweicloud.com/forum/thread-90536-1-1.html）抽奖。4、扫码添加小助手，根据小助手提示参与更多福利活动信息，有机会领取“新年红包”哦。抽奖礼品展示：

      11月21日，在成都锦城原舍酒店，成都HCDG联合DevOps社区举办了精益敏捷专场暨成都HCDG授旗仪式。本次活动历经3个多月的精心筹备，在成都HCDG核心组成员和志愿者们的付出和努力下，本次活动取得了圆满成功。      11月21日下午13；30，本次活动准时开启。在本次专题中，HCDG共邀请了两位讲师进行技术分享。首先进行分享的是52ABP框架创始人、华为云MVP梁桐铭老师，他分享的主题是《ASP.NET Core Blazor实践DevOps全流程分享》。梁老师的分享会围绕着“是否可以用一种语言或者框架就可以满足服务器和客户端的开发？”的主题进行激烈的讨论。大会最令人难忘的部分当属梁老师现场演示代码环节，把编码思维淋漓尽致地呈现在大家面前，更加地具象化。在大会的最后，梁老师还为现场的观众进行了解疑答惑，面对面地进行问题答疑。      成都HCDG授旗仪式在梁老师的分享会后隆重举行，成都HCDG核心成员历经三个月的精心准备，终于迎来了这一刻。全国HCDG运营组织者高欣对成都HCDG核心组以及志愿者表达了感谢，介绍并号召更多的开发者们加入HCDG大家庭中。      最后一个分享的内容是中韩未来革新加速器社长唐云峰带来的《JS Everything，前端语言应用拓展》。唐老师在分享会上表达：自己与其他开发者不同，自己在很用心做一个纯粹和开发者，而并不是为了利益。在唐老师风趣幽默的语言中能感受到他是一位资深JS专家，整个分享会过程都是诙谐幽默又不失专业性。“JS everthing”这句话深深地印在了在场每一位观众的脑海中。             历时三个月，成都HCDG顺利落成，HCDG在成都这座美丽的城市开启新的篇章。通过本次活动，核心组成员和志愿者们积极思维、热烈探讨、及时分工，每个人的辛勤付出才有了本次活动的圆满成功，特别感谢成都HCDG核心组成员以及支援者们。希望在今后的日子里，成都HCDG依然能保持热情，期待举办出更多精彩的活动。成都HCDG，雄起！PS：附件为讲师们分享的ppt，欢迎大家收藏~~HCDG社区—携手全球开发者 共建开放、创新、多元的开发者社区组织      HCDG是Huawei Cloud Developer Group的英文缩写，是华为云开发者生态面向全球开发者建立开放、创新、多元的开发者社区组织。      致力于帮助开发者学习提升、互动交流、挖掘机会，推动ICT、互联网等产业生态的建立和发展。      对云计算、IoT、人工智能、5G、区块链、鲲鹏、昇腾、软件开发与运维、开源等各技术领域感兴趣的开发者、软件工程师、创业者、运营人、产品人、大学生、老师等都可以参与到HCDG。      HCDG秉承开放、创新、多元的社区文化，完全由各地HCDG组织者、志愿者自发组建和领导。华为公司不直接参与HCDG组织建设和领导，只按需对HCDG社区活动提供必要的方向指导、资源支持、活动支撑等，并为各地HCDG组织者提供与全国组织者互动交流的机会。》期待您加入HCDG社区组织，点击申请报名《

当前全球的数字化浪潮逐步加深，云计算成为当今信息化发展的重要基础设施，云原生（Cloud Native）在数字化浪潮中的角色逐步提升，成为近几年云计算领域炙手可热的话题。首先我们来看看一张图，看看云原生产生的业务背景。商业模式决定了整个的研发模式，研发模式又决定了需要采用什么样的技术。从图中看出，传统应用、互联网应用、VUCA时代的应用，所处的不同时代引发的不同需求，由此带来对技术的不同要求。以往传统的应用需求是相对固定的，通常以项目化运作，用户的访问量可以预测，容量是有限的；而互联网应用的特征是，需求持续发展，产品化而非项目制，用户量并非线性往往会有陡增陡降，7x24小时是基本要求；逐渐到现在的VUCA时代，商业边界、业务层面是完全不可预知的，即便是对于互联网原住民都是巨大的挑战，要求快速地尝试、快速探测、快速的感知，应用是服务化的方式提供，业务敏捷性前提之下，对技术体系的持续发布、分布式海量并发、灰度发布和线上测试都是基本诉求。业务的敏捷性持续发布，应用平台的弹性诉求，商业环境的变化，这是整个云原生产生的业务背景。一个中心三个基本点，真正构建云原生能力云原生时代，在享受架构解耦与云端弹性带来的便利同时，对软件研发与交付模式提出了更高的要求。真正做到云原生的成功，我的总结是一个中心三个基本点：一个中心：以业务的价值交付为中心，达到快速与高效的交付价值，并且在规模化扩展的同时，兼顾可靠性、灵活性等。三个基本点：1、架构层面采用服务化架构/微服务架构实现全面解耦：把系统划分多个功能内聚、粒度合适、业务边界清晰、独立自治的服务/微服务。以（微）服务为单位演进系统架构，演进式的以绞杀者模式，而不是革命式的一次性改造；单个（微）服务以大于一个的无状态进程运行，实现自身的高可用和负载均衡；把业务数据分布到不同的（微）服务中实现数据的垂直切分；通过API，重用云原生公共服务提供的基础能力和架构能力：内部每个（微）服务须充分利用原原生的公共服务提供底层基础能力，例如微服务管控与生命周期管理服务、数据库服务、消息队列服务、缓存服务等；内部每个（微）服务须充分利用应用与资源编排服务，实现部署、配置自动化；通过API，打造生态化经济：API是非常重要的方式，除了定义服务之间的业务边界，更重要的是可以通过API的方式做整个生态，数字化转型中比如开放银行，都是这样的思路，搭一个平台，通过各种合作伙伴在不同的行业、不同的领域提供相关的服务，这些服务是相互进行连接，通过链接和网络的思维来去做这个事情。华为云也在打造自己的API生态。2、工程层面系统与环境、流程、配置解耦：与架构层面解耦相匹配，系统和环境、流程、配置等等需要解耦，工程层面也需要去相应的匹配跟解耦。开发、测试、生产环境等价，屏蔽环境差异性；采纳不可变的基础设施（immutable infrastructure）；构建端到端的DevOps研发体系：研发流程标准化、敏捷化；严格的区分构建、分布、运行的准入准出，并进行版本化和自动化；全自动化测试（单元测试、集成测试、自动生成Mock依赖服务）；一切皆代码，代码、配置与环境严格分离，并进行版本化和自动化；（微）服务持续交付流水线（按需发布版本）；研发运维一体化：运维和开发互相融合，高度协同，共担职责；自动监控，持续可视化反馈，并最终传导到开发团队；按需实时部署、配置热加载实时生效；使用自服务、敏捷的云化基础设施服务：基础设施以自服务的方式对开发团队提供。依赖底层云化基础设施的计算服务、存储服务、网络服务提供基础运行资源；使用云监控服务监控自身的运行状态包括基础资源使用状态、自身业务运行状态，同时根据自身运行状态触发相应的运维事件，实现弹性伸缩、故障自愈等关键架构特征；核心度量外部指标：业务层面的核心的一个业务指标叫TTM，在DevOps有另外一个词叫Lead Time，就是你的前置时间，从业务需求提出来那一刻起，到这个业务需求上线的时间叫前置时间，这个是可以被客户可知的，所以是端到端的业务指标。技术层面，对应的有多个前置时间，工程这一侧的，则是从提交代码那一刻起，一直到代码上线，这段时间是完全工程可控的，理论上应该是控制在分钟级。这个指标，也是华为云最为看重的一个。3、组织层面遵循康威定律：应用的架构和组织架构之间是高度的匹配，单体的应用，逐渐到服务化的方式，到逐渐分布式的模式。组织架构也是转移到自组织，没有一个唯一的中心在里面，自组织团队的敏捷性与多样性需要兼顾。整个团队的规模，典型的就是5-10人规模。全功能团队：从全功能团队一直到云化的运维团队。以服务为单位组织整个团队，涵盖设计、开发、测试、发布、部署、运维全流程职能；开发人员、发布工程师、IT和运维之间可信合作云化运维团队：基于云平台的提供的监控、报警等能力，成立专门的团队负责系统运行时的质量，保障系统可用性和业务无中断的升级、回滚自主经营，面向服务的全生命周期：逐渐转型为自主经营的全功能团队。除了技术栈是全功能以外，每一个服务化的团队都需要面向服务进行全生命周期的考虑，除了技术层面的怎么样去产品的设计、开发出来部署，架构层面保持优美，更多的还需要去考虑商业层面的东西，需要考虑服务定位，考虑产品上线以后，运营层面应该做什么事情，应该做什么样的拉新的活动，怎么样促活，怎么样留存。整个团队都需要有商业思维和产品运营的思维。这是整个思维上的转变，去考虑这个服务为什么这么做、谁去用、用的场景是什么，怎样完成商业的闭环。关注七大领域，持续优化交付粒度，加快交付速度，提升交付质量云原生架构下DevOps的落地与转型，是一个量变到质变的过程，需要从团队模型、分支模型、测试模型、技术架构、部署模型、基础设施、数据库模型等七大领域进行相应的匹配，持续优化交付粒度，加快交付速度，提升交付质量。以发布频度为抓手，从100天发布一次，逐步的十倍速增长，到10天发布一次。在这两个阶段点，从七个维度来看，需要匹配与采纳的实践是什么。这是一张能力演进的地图，我们可以清晰的看到自己业务当前所需要的发布节奏是怎样，当十倍速的走到下一个节点，方向在哪里，有的放矢的进行相应的采纳。持续交付实施框架华为内部有很多的优秀实践，华为云DevCloud就是生于云长于云的DevOps实践。华为云DevCloud从成立至今，软件的规模、团队的管理以及人员之间沟通的复杂性都急剧上升。通过云化、微服务化、容器化和流水线自动化等工程实践，以及敏捷、DevOps，全功能团队等管理实践，整体规模上升的同时，版本编译、版本构建成功率、系统回归测试、研发作业时间、资源复用率等指标不仅没有降低，反而得到了大幅度的提升，是支撑云原生架构的最佳组织和工程实践。

敏捷软件开发理念已渐渐被业界普遍接受，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专业服务还提供了开发者的相关能力评估，点亮象征着荣誉的开发者勋章，赶快来吧~~~~

上回书（【包不同的沙雕敏捷】第三集 小步快跑Scrum）说道：大师兄给团队介绍了一款主流的敏捷框架Scrum，并任命包不同为团队的Scrum Master，负责团队的敏捷转型。 “那我就任命你为咱们团队的Scrum Master吧！” 大师兄的话一直在包不同耳边回响。“我到底能不能成为合格的Scrum Master呢？”包不同薅了薅头顶那没剩多少的头发。“你好像很困惑，有心事？”一个声音幽幽的飘过来，是包不同团队中唯一的女成员——梅师姐。“啊，梅师姐，大师兄让我当咱们团队的Scrum Master，我没啥信心。”包不同微微有些失落。“正好我最近看了一篇关于敏捷教练的文章，Scrum Master也算是敏捷教练了，我来给你分析分析，看看你适不适合当敏捷教练。”梅师姐总是这么热心，说着就拿出了纸笔分析起来：1. 敏捷教练需要具备“读懂一个房间的能力”，就是说当敏捷教练走进一个房间就内，就可以get到房间内团队气氛是否正常；2. 敏捷教练关心人胜过关心产品，敏捷以人为本，团队中每个人都被鼓励被重视，团队通常会更加团结，同时也更容易开发出优秀的产品；3. 敏捷教练通常善于学习，通过学习不断的提高和完善自我。“我觉得我具备这些能力了，那我应该就是合格的敏捷教练了吧？”包不同问道。“不一定，具备这些能力，只能说明你有做教练的潜质，敏捷教练的学问可大着呢。”梅师姐神秘一笑，包不同就觉得有戏，求着梅师姐的指点。“梅师姐有什么秘诀快告诉我吧！”包不同激动的问道。梅师姐不紧不慢的说“而且，看到这个勋章了么？你运气不错，正好赶上华为云开发者福利季，华为云DevCloud专业服务平台对外提供各种的能力评估，就包括‘敏捷教练’，只要测评通过，就会点亮你的华为云开发者勋章。我已经通过了Java和前端的测评了，你去测一下，什么能力水平，查缺补漏就心里有数了。”“有这好事？这小勋章还挺好看的，我要拿十个！”包不同已经安耐不住心中的喜悦了。快来测一测吧：https://devcloud.huaweicloud.com/expert/assessment/skill

进群之后我才意识到，应该把我领导也拉进来——云享MindTalks第四期问答录“助手小妹妹”邀请“上海惠艾信息科技有限公司的黄灵”加入群聊工具人助手小妹妹：欢迎黄老师入群！围观群众1号发来【猫头惊喜.JPG】围观群众2号：冲冲冲冲。工具人助手小妹妹：小伙伴们我们还有十五分钟就要开始啦~巴拉巴拉，此处省略约一百五十个字的官方说辞。围观群众3号犹豫了一下，删掉了对话框里没打完的“欢迎……”点进了直播链接。黄灵老师：欢迎小伙伴们，今天我们来讨论《用户故事地图帮助梳理MVP》……分享结束后脑子里只剩下了领导的微信头像，拉他进来！让他给我听！交流者1号：敏捷实践大多是针对程序员的，如何在组织内平衡工作量呢？黄灵老师：@1号 你说的是基本的研发敏捷实践，我们正在努力让企业从管理层开始做领导力、文化和业务敏捷，只有研发敏捷是远远不够让企业变得更加有应对不确定性的能力的。交流者1号回复：【抱拳.JPG】，让敏捷贯穿管理的各个环节。黄灵老师：是的，研发端敏捷只能解决研发效能问题。但战略规划和业务响应，快速捕捉市场需要是更前端的事情，做什么没有搞正确，怎么做做得再好影响都是有限的。黄灵老师：而组织需要变得更敏捷，需要有一个信任和安全的试错氛围，这就需要领导者转变思维，并支持团队参与决策和挖掘潜能。交流者2号：现在两星期强迫结束的BUG我倒是觉得给未来挖坑，这个也是郁闷，为了敏捷而敏捷。黄灵老师：@2号，迭代关闭不代表所有的事情都必须结束和停下来。迭代是一个时间盒而已，我们需要看到在这个实践盒里我们计划了多少，完成了多少，为什么没有完成，在迭代回顾会去讨论原因，如有必要可以改进。交流者2号：可是迭代周期后的BUG处理不算工时，积累下来，工作就累了，前后处理。黄灵老师：设置一个时间盒让我们的工作更有节奏感，也更能掌握我们的产能到底是多少，产品和业务如何去规划业务活动和产品增量版本。迭代内没有达到上线标准或质量标准的，在新迭代去继续执行，但是会被可视化出来有多少工作是遗留的。交流者2号：如何避免开会形式化，总结形式化？黄灵老师：为了解决你的问题，在迭代计划中必须留一定的开发产能处理bug和突发事件。我一般会建议团队新功能开发占迭代总工时的60%到70%。交流者1号：对，产能不能排满。对！赶紧谁把领导拉进来交流交流吧~【祈求.JPG】交流者2号：一个项目到后面，就是200%了。黄灵老师：迭代回顾会需要SM花时间和心思设计，激发团队的凝聚力的同时，让大家敞开了讨论。以为我们是在多排，让大家产能超过能力，但实际上是在造成拥堵和浪费，消耗部分产能，我刚刚接手一个团队也在经历这种痛苦，所以我在帮助他们回到正轨上，不要贪多，嚼不烂，阻塞在产研通道上，既消磨了士气，又导致各种损害，得不偿失。研发团队永远在跌跌撞撞往前走，因为要抢时间，争机会，降成本。我们帮助不了解研发工作的业务和老板们明白研发生产有很多环节，每个环节都需要很多时间，还容易出错。所以，可视化，沟通，建立共同语言很重要~……黄老师讲得太好了，这是很多研发团队正在面临的难题，甚至是痛苦，真的好想把领导拉进来听听。什么？你问我直播分享内容？就是MVP一原则一定义一意义，用户故事地图五要素五步走，文末有PPT自取啦，本周四晚黄灵老师还有个亚太地区的“业务敏捷”分享，我想想咋子拉我领导去听……扫码加微信群，仅限200人开始时间11月17日 20:00活动介绍云享MindTalks是由华为云DevCloud团队携手云享专家共同策划进行的系列技术交流活动。各业界大咖纷纷现身群聊，以即时对话形式，来进行最直接的技术交流和思想碰撞。不同领域的专家，各样的业界话题尽在此处，为保证极简极高效，活动仅二十分钟，限量二百人，先进先得。此期活动，我们邀请了拥有多年敏捷转型经验的黄灵老师，她曾持续多年受全国性敏捷管理与软件行业大会邀请主题演讲。本次分享，她要为我们介绍借助用户故事地图拆解MVP，帮助大家树立软件产品需求的全景观与迭代演进思维，站在高处领略软件交付这一过程。专家介绍Hi-Agile 数字化转型总监企业级敏捷和精益转型专家敏捷文化及敏捷领导力赋能者业务敏捷倡导者及践行者CSM, CSP, CSPO, SPC, ACP, NPDP，Exin-Agile Coach活动规则1.扫码加入群聊，仅限200人，手慢者即无。2.未能即时回复问题，由助手收集集中回答。3.更多资源和活动于云享MindTalks VIP群。4.抽奖的奖品为华为云限定HE2E知识卡牌和专家推荐书籍《用户地图故事》。

如何应对频繁的需求变化，Scrum是一个好方法，快来跟包不同一起学习最主流的敏捷框架——Scrum吧如何应对频繁的需求变化，Scrum是一个好方法，快来跟包不同一起学习最主流的敏捷框架——Scrum吧视频贴如何应对频繁的需求变化，Scrum是一个好方法，快来和包不同一起学习最主流的敏捷框架——Scrum吧！

摘要：产品经理、开发、测试、运维、终端用户……DevoOps给这些角色带来什么优势？企业每天都面临着快速变化和高要求。现在的主力消费者比他们的上一辈对企业有着千变万化的要求和更高的期望。日益激烈的竞争意味着企业必须迅速而明智地采取行动，以保住自己的市场份额。企业不断与竞争对手竞争，努力为客户提供最好的产品。许多困难的根本原因是缺乏沟通，对于许多公司来说，DevOps是解除困境的方法。根据RightScale 2016年对1060名IT专业人士进行的云端状态调查，81%的大企业和70%的中小企业报告采用了DevOps。这种敏捷思维方法涉及到客户、产品管理、开发人员、QA和其他角色之间的协作，以便向更好的产品、服务和系统前进。DevOps带给不同角色的优势是什么？开发人员没有采用DevOps的开发人员可能会对构建和部署流程的日常任务感到沮丧。由于不得不一遍又一遍地完成相同的任务，他们会没有时间进行创新。而当有了DevOps和自动化，那些单调重复的任务就可以被消除！没有了这些耗时性项目，开发人员可以拥有更多的时间做自己喜欢的事情：研发。花更多的时间创新、更少的时间修理和维护是一种胜利。不想参与软件的运维？随着DevOps打通筒仓，增加合作，这种情况也在不远的将来向你招手了。运维人员对于运维来说，在未采用DevOps前，典型问题之一是从开发人员那里获取随机的、通常是错误百出的代码。由于沟通很少，达成决议需要更长的时间，也会让工作更加困难。运维所关心的是维护环境的稳定性，但这很难做到。有了DevOps，运维人员在计划外工作和返工上花费的时间减少了22%。这主要是由于增加了与开发人员的交流。更好的代码、共享的代码库和更稳定的操作环境使工作更加轻松。自动化和持续集成允许在不威胁稳定性的情况下交付新功能。产品经理当你的产品和服务需要更长的时间才能制造出来并付诸行动时，你就很难打败你的竞争对手。当你的软件有错误时，这尤其困难。DevOps鼓励协作环境。当在生产过程中有更多的交流，产出是更好的产品。当每个人都保持一致时，最终交付的产品一定会更好。DevOps带来的46倍的软件部署频率和440倍的变更前置时间会让运维的工作更加轻松。系统管理员要高效地管理一个从不沟通的团队几乎是不可能的。缺乏沟通使工作变得困难，因为软件有错误，反馈不及时，可见性低。协作是DevOps的关键要素之一。沟通会带来更好的产品和更好的系统。此外，它们的管理也不那么复杂。自动化减少了人为错误，且可使故障更改率降低3倍。DevOps还增加了整个软件开发过程的可见性。当能够检测错误、定位其根源并发现原因时，就可以迅速修复问题。DevOps使得故障修复速度快96倍。测试工程师如果你不知道问题是哪里产生的，是谁造成的，就很难解决问题。当找不出问题，无法解决问题，并且知道每一分钟都意味着越来越多的人感到不方便（可能还会为此烦恼）时，压力就来了。DevOps允许更快地解决问题。提高可见性和沟通对于解决问题至关重要。工程师可以使用实时数据来解决问题并了解应用程序更改的影响。当出现问题时，解决方案实施得越早越好。如果一个Bug变得太深，就更难修复了。QAQA的工作是确保产品和系统都运行良好，但这并不意味着他们喜欢错误缠身的软件和过程。如果没有沟通、协作和自动化（DevOps的所有支柱），错误就会泛滥成行。有了DevOps，团队成员可以一起工作来生产更好的产品，自动化可以减少容易避免的人为错误。结果就是出现更少的错误。并且，由于持续的集成、持续的交付以及频繁的小更改，错误也更小更容易修复。DevOps用户报告说，修复安全问题的时间减少了50%，故障恢复速度加快了96倍。客户服务任何在服务行业工作过的人，无论是在餐馆、零售还是客户服务，都知道与不满的顾客打交道的痛苦。当系统出现故障和错误时，用户会很不高兴。当然故障不是你创造的，但你必须处理它们。DevOps会导致更少的错误，这意味着用户的使用体验更加舒适。虽然仍然会接到用户的投诉电话，但这只会越来越少。此外，用户也不会因为反复经历相同的故障而暴躁。一个更具协作性的环境意味着你的工作更容易。终端用户改变的意义是为了更好的用户体验。采用DevOps不仅为自己简化了流程，这也意味着将有更多的时间为客户做出更多的改进。DevOps通过改进流程和应用程序使最终用户的体验更加一致。总的来说，让互动更愉快。所有角色都受益！综上所述，每个人都受益于DevOps的一些基石，如持续集成、持续交付、发布自动化、测试自动化和协作。持续集成几乎消除了发生大故障或错误的可能性。自动化流程消除了繁琐的手工任务。协作创建了一个协调的团队，并改进了最终产品。DevOps创造了更快乐、更高效的团队。人们不必一次又一次地完成同样无聊的任务，解决同样的问题。挫折感和不愉快的减少会让团队成员更有效率和效率。这样可以消除工作中一些不满意的地方，为组织增加价值。团队效率达到顶峰，有更多创造性和革新性的任务、集体责任和加强沟通。当筒仓被打破后，团队会对共同的目标和实现目标的计划有一个更清晰的认识。此外，增加透明度会带来更明智的决策。授权、自信和协作的团队行动得更快更有效，从而导致更快的发布和更智能的工作。如果出了问题或者有计划外的工作，沟通可以帮助团队管理意外的障碍。DevOps建立流程并明确优先级，以指导您和您的团队成员在继续执行原始计划的同时完成计划外的工作。当员工做他们喜欢做的事情时，他们会更投入，更快乐。DevOps不解决工具问题，它解决人的问题。快乐的员工带来快乐的顾客。公司也受益匪浅通过更好的流程和沟通环境，公司将受益匪浅。不仅在感情上每个人都是朋友的方式，在经济上也是如此。更满意的员工可以做他们喜欢做的事情，而客户得到了更好的体验，公司就会从中受益。由于DevOps节省了时间和资源，并提高了公司的速度和竞争力，因此ROI（投资回报率）有了切实的提高。由于持续集成、持续交付、发布自动化、测试自动化和协作，组织能够更快地交付特性并更快地进入市场。团队是主动的，而不是被动的，因为它能满足新的市场需求并应对安全威胁。持续的反馈使公司能够更频繁地听取客户的意见。因此，组织可以交付更及时、更具相关性的软件。这样就可以更快地响应客户不断变化的需求并改善用户体验。在现今社会下，每家公司本质上都是科技公司。如果没有快速的软件，将永远无法将自身产品推向市场。而没有DevOps，就无法拥有快速的软件。DevOps使IT与业务目标保持一致。它创造了一个专注于创造价值和持续改进组织的团队。创造最好的客户体验是头等大事，每个人都在一起创造和维护最好的产品和服务。DevOps将速度与方向结合起来，为企业带来利益。转自 csdn 华为云