ppt完整版下载地址：[hide]链接: https://pan.baidu.com/s/1oMsNXUQsOAu3EUwscX_QyA 提取码: pg47 [/hide]《华为云DevCloud大咖分享汇总（附PPT下载）》

【产品经理-全连接系列 之005】华为敏捷/DevOps实践一点一滴_如何开好一个敏捷回顾会议      大家好，我是软件开发服务 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）       作为布道师和产品经理，出差各地接触客户是常态，经常和华为云的客户交流、布道、技术沙龙，但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和考虑。      <恒少出品，必然妥妥干货，必定理论联系实践>，因为软件无银弹，探索始终在路上 -----------------------干货分割线--------------------------------------开篇小故事：前几年，一本叫《沉思录》的书在国内突然曝光度很多，因为前某国家领导人“摆案头，读百遍”。《沉思录》是古罗马皇帝马可·奥勒写给自己的书，内容大部分是在鞍马劳顿中写的。其实有一句“我们所听到的不过只是一个观点，而非事实     我们所看到的不过只是一个视角，而非真相” 全员都参加的回顾会议，其实就是希望能通过全员视角，全员的观点来回顾做的好的，做的不好的，改进之。从敏捷宣言，到敏捷的诸多实践（如Scrum），到DevOps，都一直提倡回顾这种形式。 其实回顾这种形式，并不是敏捷/DevOps专属的，在华为最早的CMM流程中，也有类似的活动。有时候团队碰到域郁闷，痛苦的时候，还会主动自发的开。 所以，回顾，我一直认为这是人类作为一个智慧物种相比其他生物的一个重要区别。我有的时候回通过回顾会议来判断这个团队会不会成功。最极端的，如果甚至都没有人想着要约大家一起回顾，这个团队极大概率要88了。 华为内部不仅研发交付团队，连一线的市场团队，在重大的市场项目，交付项目的过程中都会定期进行回顾会议，算是华为内部这么多年积累的一个很好的实践。 必须鲜明表达的观点——回顾有三个不是不是“回溯”。“顾”和“溯”一字之差，在中文的语境中，却会导致变成刨根问底。不是“批评与自我批评”。“批评与自我批评”是一个很好的形式，但是会导致团队陷入一种不必要的紧张和犯错感。不是“问责和处罚”。软件的不确定性，不可见性，复杂性，易变性决定了软件开发过程总会有些磕磕盼盼，我们提倡的是改进，不是惩罚从华为这么多年的实践来看，上面的三种情况都出现过，所以提醒大家要小心。 这么些年实践过来，我们发现出现以上情况，也是因为步子走得太快，低头玩手机^_^，忘了“回顾”的初心：For a better future;Learn from past;Take action in present. 回顾会议的基本原则对事不对人。举个例子，我们可以说“代码评审不充分，所以代码缺陷较高”，不能说“某帅哥评审不认真”，当然夸人帅还是可以的哈^_^。聚焦于下次能否做得更好。还举同样的例子，我们可以说“这个迭代代码评审不充分，下个迭代我们怎么才能保证更充分的评审”。从系统角度思考改进，而非个人。我们可以说“团队的工作安排上，导向上是不是不重视代码评审？”。 回顾会议的Step by Step确定参与人（Who）团队所有成员都参加。领导是否参加，试情况，如果领导参加利大于弊，就邀请，否则还是算了^_^如果是重大的项目发布或项目结束的回顾会议，还应该叫上所有对项目有付出的成员。建议指定一个会议引导人，可以是敏捷教练，也可以是团队成员轮流（团队成员建议熟读本文）选择合适的场所（Where）如果条件允许，离办公位尽可能远一点，避免有同学中途又回去处理工作了尽可能不要使用传统会议室的布局，围坐一个大桌子那种不好。可以拉几把椅子围成一个半圆形。需要有白板，或者墙壁可以贴个大白纸   3. 准备回顾的内容（What）      a) 准备上个迭代的客观数据，特性、需求、缺陷等数据，如果使用了像DevCloud这样的敏捷管理工具，准备数据其实很快的，甚至不用特别准备，现场打开就可以，类似如下这样           b) 团队成员上个迭代的感受，可以认为是主观数据的收集。      c) 每日站立会议的要点。每日站立会议中都会提出并跟踪解决一些问题，回顾这些问题也可以帮助我们审视过程中的情况。恒少之前专门写过如何开好站立会议的实践文章（此处应附上对应渠道的链接），可以参考      d) 准备一个规则，会议开始前贴出来或打印出来或投影仪投出来。规则是为了保证会议的纪律和效率，比如不能随便打断别人讲话，每人发言时长，会议时长（建议10~12人的团队，限定在1小时内）  4. 回顾会议的过程（How）        a) 准备和引导——明确目标。重申回顾会议的目标和原则，让成员重拾回顾的“初心”，发布公示如下的回顾宣言，重申会议纪律，时长。准备和引导环节是让大家放下手机，进入回顾会议状态的必要环节，无论开过多少次，都不应该省掉。                b) 数据、过程的回放——建立共同的全景。展示本迭代的度量数据，如果有使用类似DevCloud的敏捷管理工具，可以直接打开系统。全景的数据展示回顾，让视角更全面。对于一些“历经劫难”的迭代，可以画一个时间线，把这个迭代发生的重大的一些事件按照时间顺序展示出来，帮助团队成员回顾都发生了什么        c) 提出见解——我们如何才能做得更好。可以通过头脑风暴，全员参与，有很多种分类的方法，如下图中是分为“Good”（下个迭代哪些好的方法可以继续保持），“Could Better”（下个迭代可以哪些地方可以做得更好），Improvements（新的改进的具体想法）。可以采用“有限投票”的方式，每个成员有5票（比如小磁贴或直接记正字），大家共同团队层面需要重点改进的。其实投票未排进Top的改进，如果不需要组织和团队来推动，个人也可以实施的改进，也应该支持。              d) 确定措施——想清楚就干，才有诚信。识别了重点的改进项，为每一个改进项指定计划，执行的措施，需要更高层面去解决的措施需要单独列出来，项目Leader会后要发挥“死缠烂打”的精神去骚扰领导了，同时每个改进措施都应该明确一个责任人，如果没有明确的责任人，大家都会认为是别人的事情。       e) 结束会议——果断结束，绝不拖泥带水。将会议中达成共识的措施和计划整理记录下来，如果使用了敏捷管理的工具系统，可以直接输入到系统中，记录为Story或者任务。 来自实践中的一些坑和雷不持之以恒。那什么几天打鱼，几天晒网的可不行。恒少，恒少，就是能持之以恒，哈哈。理想主义。团队级的回顾会议应基于现实，而非理想，或者说理想可以有，诗和远方也可以有，但是回顾会议还是应接地气。沉迷于细节。程序员有的时候特别认真，容易把问题引入到技术细节，这样会导致议题发散。只开会，没有吃的，好饿。皮一下，为了调节会议氛围，可以准备些吃的，补充能量，大脑才能激发 最后的最后，每个迭代回顾会议，都不要忘了感谢辛苦码代码的自己，也不要忘了感谢为了心中教堂而努力的所有团队成员的。

【摘要】 交付在云端-全云DevOps研发实践（演讲PPT）PPT下载地址：[hide]链接: https://pan.baidu.com/s/1gCAteT7M_0xEQudve7P4BQ 提取码: gbz7 [/hide]《华为云DevCloud大咖分享汇总（附PPT下载）》

【中国，深圳】2018年11月2日，DevOpsDays深圳站正式开启，数百位各行业开发者及DevOps的实践者们参会，华为云DevCloud专家团队受邀参会。华为云DevCloud CTO谈宗玮受邀参加本次大会，进行《DevOps云化发展的趋势》主题演讲，分享了DevOps云化发展的趋势，以及在云平台上的华为云DevCloud的DevOps实践。华为云DevCloud CTO 谈宗玮现场分享DevOps理念是Development+Operations的组合，旨在促进软件开发、技术运营和质量保障等部门间的沟通和协作，让开发团队具有5-10倍的TTM和效率优势。随着DevOps理念的发展，已经超越了一种研发模式的范畴，更是商业模式的变革。近年软件开发领域热点不断，服务化、云计算、大数据、微服务、人工智能、区块链等不胜枚举，对应于开发和运维的对象变化，研发模式也在逐步发生演进。通过践行DevOps，能够协助企业快速响应市场的变化、用户的诉求，提高企业软件交付效率，帮助企业IT实现数字化运营。谈宗玮讲述了华为的DevOps之路，华为向Cloud Native云原生转型，沉淀华为云DevCloud平台，DevOps是工程基础。DevOps的精髓和支柱包括四点：TATO（Team，Architecture, Tools,  Operations），谈宗玮从团队、架构、工具和运维四大方面，分享了华为在DevOps转型上的实践。团队上，伴随着云基础设施的兴起、云的基座和新的生产力手段的诞生，可以实现很多自主的开发、运维、测试过程，从而支撑了跨功能域的全功能团队。组织更加关注端到端产品的经营，而不仅仅是开发的过程，DevOps已经不单纯是开发的行为，而是商业行为。这是Team团队的转型变化。架构上，依托华为云DevCloud的基础服务，实现环境跟业务的解耦，创造出一种新的微服务开发模式，与微服务团队进行匹配。工具上，新的工具链支撑了生产力的变革，生产力的变革同时支撑新的生产关系，微服务的团队、全功能的团队的诞生。运维上，新的生产工具带来新的生产关系，基于华为云DevCloud运维服务，提供技术手段，让个别团队都能轻松的操作起来，这是Operations的变化。会上，华为云专家们还就华为云DevCloud前端性能优化实践、DevOps开放模式下的敏捷测试之道、基于Pipeline的DevOps实践以及在DevCloud时代怎么做DevOps的研发实践等方向也展开了分享讨论。华为云DevCloud专家DevOps转型的过程，依从于DevOps的快速交付，快速反馈，快速调整的过程。首先梳理紧迫感，建立强大的变革领导联盟，设计愿景战略，沟通变革愿景，授权赋能，积累短期胜利，促进变革深入，成果融入文化。八个步骤严格顺序执行，夯实每一步，方可进入下一步。华为的价值观是以客户为中心，以奋斗者为本。长期坚持艰苦奋斗，长期坚持自我批判。华为云DevCoud也将这种文化和价值观渗透到了产品中，在产品、技术和服务上形成合力，助力企业成功转型DevOps。那么同样，任何组织，形成自我批判、持续学习和实验的能力，也将是DevOps成功落地的关键因素。虽然很多企业已经在DevOps实践的道路上走了很远，但是对工具选用和能力建设方面仍可能存在迷茫和纠结。选择合适的工具来适应企业自身交付的服务或产品，可以更好地提升质量，提高效率。在云化服务交付增多的今天，采用全云化的研发工具成为趋势。华为云专家现场为开发者演示DevCloud产品华为云DevCloud是华为云的组成部分, 是华为30余年研发实践和前沿理念的结晶，为开发者提供一站式、轻量级的DevOps工具服务，同时，也是帮助企业修炼内功的一大利器，可以有效支撑企业DevOps落地，实现项目的高效、高质量迭代。未来，华为云DevCloud也将携手各企业各开发者，精诚合作互通，及时响应反馈，更好的为广大开发者提供稳定可靠的DevOps工具，助力软件企业专注业务创新。所有专家演讲的ppt完整版下载地址：[hide]1、华为云DevCloud CTO 谈宗玮：软件DevOps云化发展的趋势链接: https://pan.baidu.com/s/19q0qmgWPgSqrtB6utTXheQ 提取码: fduj 2、华为云DevCloud高级项目经理 侯凡：基于微前端架构的DevOps核心实践链接: https://pan.baidu.com/s/1hQvPPu-dwibFcURW**vNw 提取码: djp1 3、华为云DevCloud高级项目经理 安闻：DevOps敏捷测试之道链接: https://pan.baidu.com/s/1oqRQfrL6rcSfDACNGBi2yw 提取码: 35n3 4、华为云DevCloud高级项目经理 周宇：基于Pipeline的DevOps核心实践链接: https://pan.baidu.com/s/1wneVfOyKSDdXmDAZda3tRQ 提取码: bkf7 5、华为云DevCloud高级项目经理 赵彦：全云化DevOps该如何做链接: https://pan.baidu.com/s/1u4QonRAXhPq7NgZk5NqE8A 提取码: d4qs [/hide]《华为云DevCloud大咖分享汇总（附PPT下载）》

大家好，我是软件开发服务 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）作为布道师和产品经理，出差各地接触客户是常态，经常和华为云的客户交流、布道、技术沙龙，但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和考虑。      <恒少出品，必然妥妥干货，必定理论联系实践>，因为软件无银弹，探索始终在路上-----------------------干货分割线--------------------------------------例行的开篇小故事：在西方的传统传说中，狼人可以说是比较可怕排行榜靠前的，除了破坏性大，还有出乎意料性，传说月圆之夜，会出乎意料的从熟悉的正常人变成可怕的怪物。软件从诞生那一天前，就注定是个“狼人”。比如，好好的程序内测测试环境验证OK，可是一上线到生产环境，问题不断；再比如，项目规划的好好，需求分解得好好的，每个人的任务都安排的妥妥的，可是就是延期，延期，延期….—— 软件是狼人，来自《人月神话》的《没有银弹，软件工程的根本和次要问题》正文开始啰嗦 很多小型的软件企业，都比较喜欢用excel类似的办公工具来管理软件项目的需求，缺陷，进展，风险和人员。所以，时不时有些同学会觉得，Excel也是可以妥妥的制服软件这个“狼人”。但是从我个人的经历来看，很早之前的我可能会认同这个观点，但是现在的我，比较大不认同这个观点。有人会说，你又在装“老红军”：）嘿嘿，就从我在华为亲身经历的，参与的，旁观的，变革的众多软件项目的一些经验，不成系统的扯扯。首先，必须得100%承认，几大平台的主流办公工具，都是异常优秀的，如微软的office系列，Google的Docs系列，，Apple的办公套件（Keynote，Numbers，Pages）。基本的办公软件相当长时间都是是刚需，在各个行业都有非常广的应用。Excel早期在华为也有比较多的应用，华为内部有不少Excel高手，可以通过Excel内嵌的功能，做成非常强大的数据透视，数据报表，牛逼的不行不行。连我这样的小咖，都会玩各种Excel的小工具，让我得了不少华为的QCC奖励（Quality Control Circle，一种从基础组织发起的自我改进）。当时业界还没有专门用于软件管理的工具，我们的项目运作，也确实主要通过Excel的，记录所有的需求以及需求的分解，需求的责任人，需求的进展，缺陷的进展，风险的进展，甚至形成了大量的Excel模板，下个版本或项目通常还可以继续使用。后来，随着华为开始集团级的引入敏捷开发，工欲善其事必先利其器，业界也与之匹配的出现了更专业的敏捷协同和管理工具，承载了敏捷的思维（Mindsets），价值观（Values），原则（Principes）和实践（Practices），华为的敏捷，乃至DevOps变革之路，也伴随着研发工具的变革<插个话题：我经常叨叨：从IPD，敏捷，DevOps，每个跨代的研发理念和实践的落地，在华为内部都是当做变革（Transform）去对待的，变革最难的是什么，变革最难的是“对既有利益集团的破局”，中国的**这样，研发的变革也是如此。>所以，客观的说，我们还是花了些时间，最终实现了越来越少使用excel、越来越多使用专业敏捷、DevOps工具的变化的，现在华为内部无论大小项目，首先使用专业的敏捷管理工具服务是一个默认的习惯<华为内部早已经实现了工具的云化/服务化，一站式使用，Web访问/App访问即可，Anywhere, Anytime, 非常便利>这个过程的变迁，发生的悄无声息，也从没有想过为什么，因为有论坛用户问，我就整理了一下，分享几个可能比较片面的观点：因为专一，所以精彩。随着敏捷在全球的应用，用户越来越多，敏捷实践越来越来丰富，专业的敏捷协同和管理工具也在持续的完善，越来越懂敏捷软件开发，越来越懂开发者。因为通用，所以无法在每个细分领域都做到最懂。Excel多年的发展，功能越来越强大，尤其是Office365 云端提供后，便利性更好，但是它始终是个通用的表格数据软件，它甚至很多时候更懂财务，但是始终谈不上最懂软件开发。不是最懂又会导致什么呢？体验不到软件开发新的理念、方法和实践。大量的新的软件开发实践，无法通过Excel来体验，比如看板的方法，Scrum的燃尽图，思维导图的规划需求。如果外面的世界更精彩，去软件行业其他企业应聘，经验中有通过excel管理开发项目或被Excel管理，在业界总不能算是一个应聘的加分项。开发人员会觉得管理方式比较Low。Excel管理软件开发，通常会把开发人员当成一个萝卜一个坑，开发人员会觉得自己只是一个绿色表格中的一个选项，而缺少开发人员的主动反馈和互动，这也是为什么很多的专业工具都让开发人员可以评论，可以@，大家对于需求的安排、需求的进展可以动态的反馈和社交讨论。敏捷的理念，重视协同，看板的价值观中也在推荐开发人员Pull任务，而不是Leader 单纯的Push任务。软件开发至今还是智力活动，智力活动需要激发，需要协同，交流，软件开发人员不能当成生产线的装配机器人，虽然很多企业管理者都梦想这样。。。：）单机版不利于团队共享试用。“那谁，最新的需求Excel表格给我发一下”，“那谁，你刚刚更新的缺陷Excel表格发给我没有？”，“那谁，你这个表格不对吧，我昨天更新的需求状态被你覆盖了”，“那谁，你这个表格不是不是最新的”，“最新的风险表格在哪儿？”，“项目例会上，这个表格不是最新的，最新的在我电脑那儿，你等一下，我发给你，然后大家都等啊等”，“张三，李四，王五，你们更新一下表格中的需求状态，邮件发给我啊”，“张三，李四，王五你们更新的表格没有发给我啊，等等，哦，我收到你昨天邮件了，哦，李四你没有使用张三最新的啊”……..，如果团队超过5个人以上，使用Excel管理需求和项目，以上场景很常见吧？我不知道你会不会烦，我当时做项目经理，带团队时，最讨论，最烦就是这个，因为Excel是文件传递，只能通过邮件或者社交软件传递，经常冲突，经常使用得不是最新的，我还得从邮件拆附件，从社交软件拆附件，从其中挑选最新的行，一个个的合并为最新的Excle表格。我觉得这是在浪费生命，也对不住公司聘用我的成本啊，公司聘用我不是让我整理表格的啊：（。不利于并行协作。Excel文件可以以云盘或者文件服务器的方式或者代码库集中存储，团队成员可以修改同一个地方的文件，虽然可以一定程度解决上面的问题，但是通常而言，是文件级的锁，一个成员修改，其他成员是无法并行修改的，如果某个成员编辑一半，没有提交，其他人就等啊等啊。而专业的工具其实基于工作项粒度（Epic，Feature，Story，Bug，Task，需求）来控制并行修改的，这样并行修改的效率更高，即使不同的人修改同一个工作项，基于数据库的事务性，也会让用户基本无感知且保证事务性和一致性。微软最新的Office365，是云端协同，华为内部也使用了，但是从解决多人协同的冲突上，依然还是无法适用软件开发过程，因为它始终理解的只是一个表格中的行，列或者格子，而专业的敏捷工具它们理解的是工作项、迭代这样的软件对象。不利于自定义、升级和统一。如果需要增加需求的一个属性，得修改需求的Excel 模板，修改后还得通知所有的团队成员，更新为新的模板，尤其是单机版的Excel，让团队统一为新模板，劳神劳嗓子也劳键盘。而现在的云端的敏捷管理工具服务，都提供了丰富的自定义字段的功能，一次修改，全员都可以马上使用，不用耗费时间在统一新模板上了。不利于形成研发作业流。软件开发就像一个流，规划，需求分析，方案设计，代码编码，测试，缺陷解决。。。，而Excel只是一个或多个文件，本身也不是作业流，也没有承载作业流。久而久之，会让所有软件开发成员，认为软件开发就是围绕着几个Excel文件在工作，无法畅快的体会作业流，无法体会到需求不断交付上线的感觉。不利于和周边系统的集成。一般软件企业里面总有一个集中的员工管理系统，通常也有编译构建的工具系统，Excel作为一个办公工具，和这些系统的集成有许多天然的困难，无法通过Excel看到需求有哪些测试用例，这些测试用例执行的情况如何，员工的新增或离职，Excel中业务无法自动同步，Excel需求分配任务给这些员工就会失效或者找不到人。诚然，很多高手，可以把Excel这样的办公工具发挥到极致，无限接近，但是这样的高手其实还不如让他去投入真正的产品的开发与交付呢：），能把Excel玩出高水平的软件工程师，大概率都是高水平的程序员：）当然，并不是敏捷管理工具说可以完全替代Excel，Excel这样的工具在数字的统计分析上，有着其强大的功能，对于纯粹数字的分析、归类、透视，可以把需求、缺陷等数据从专业的敏捷工具中导出，在项目结束后，加以数字的分析，也是一种很好的互补。华为这么多年研发效能的持续投入，积累了丰富的实践经验，这背后有一个基础的理念：软件研发工程师是宝贵的（说直白点，成本挺高的，真贵o(*￣︶￣*)o），学历都不低（说直白点，还很傲娇，^_^），吸引优先人才竞争还激烈（不爽就键盘党狂吐槽，或者另谋高就(#^.^#)）。所以应该让广大的软研发工程师去专注业务的规划、交付，让他们做有价值，有挑战，让他们感觉有成长的事情，而不是让他们成为工具的仆人。始终给他们装备最懂软件开发，最懂开发者，最高效的，最少操心的研发工具，才是正道。如果把研发团队比作作战团队，应该让他们使用最先进战场装备，而不是让他们自己去研究定制一个坦克，他们只需要提需求给专业的服务商就可以了。像华为这样想的企业，越来越多。所以现在业界有很多像DevCloud这样的专业的敏捷管理工具服务，运行在云端，Anywhere and Anytime 可以使用，同时还有专业的团队来提供专业的服务，他们更懂软件研发，更懂开发人员的苦恼，更懂敏捷/DevOps。随着云成为新的基础设施，云上的敏捷管理也必然会越来越会成为软件管理的基础设施。啰里啰嗦的，我自己都嫌弃自己，视野有限，读书少，观点片面，如有不对，还望大家指正、交流、讨论：）

      大家好，我是软件开发服务 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）       作为布道师和产品经理，出差各地接触客户是常态，经常和华为云的客户交流、布道、技术沙龙，但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和考虑。      <恒少出品，必然妥妥干货，必定理论联系实践>，因为软件无银弹，探索始终在路上-----------------------干货分割线--------------------------------------理论总是美好的，现实却又是骨感的，很多华为云DevCloud的客户特别想知道How to，接下来恒少会陆续分享一些非常小的华为敏捷/DevOps的实践，点点滴滴。开篇小故事：巴别塔，也叫通天塔；是《圣经·旧约·创世记》第11章记载，当时人类联合起来兴建希望能通往天堂的高塔，高塔越来越接近天堂，上帝紧张了，他看到人们这样齐心协力，统一强大，心想：如果人类真的修成宏伟的通天塔，那以后还有什么事干不成呢？一定得想办法阻止他们；为了阻止人类的计划，上帝让人类说不同的语言，使人类相互之间不能沟通，并让人类分散世界各地，最终巴别塔没有建成。————以上摘自互联网：）这个小的宗教故事，揭示如果语言相通，目标一致产生的巨大作用，都可以建成一个通天塔：）。而软件开发的过程却又是一个离不开协作、沟通的过程。一个缺乏良好协作，沟通、理解和目标一致的软件团队，是很难高质高效的交付的。敏捷的众多实践中，有一个为了提升团队协作的经典实践：站立会议，本篇即介绍一下，融入华为的一些具体实践和“坑”和“雷”：）站立会议的关键词：每天，例行，简短（15mins内必须结束），全体成员，站立站立会议的目的：增进互相了解，互相理解，及早暴露风险，促进沟通和协调，建造“通天塔”站立会议的过程：全员到场轮流发言，记住是轮流，轮流，轮流（重要的事情说三遍）每个同学的发言简短，可以参考下面的提纲昨天我负责的工作项的进展；今天我计划开展，或可以完成哪些工作项；我遇到的困难、风险，是否需要帮助，需要谁的帮助；我收获的经验，快速分享发言时，可同步刷新工作项的进展（可以通过任一敏捷管理工具，比如华为云的DevCloud）会议上识别的新的工作项，Leader应该记录增加到Backlog中。华为站立会议实践的经验（keng）教训（lei）：Leader叽叽哇哇，成员一片沉默拘谨，觉得不自在，无话可说，不愿意先说总有同学打断别人的发言变成“批斗”会议，你怎么又延期了？你怎么不早说？变成一言堂和Push任务的会议。那谁谁你今天做这个，那谁谁你今天必须把这个交付了。变成了汇报会议，议题得提前申报，甚至还要准备PPT变成进度检查会议，只关注进度有没有完成变成一个小时的会议，讨论技术，讨论方案，发散不受控变成了不愿意参加的会议，不仅浪费时间，提出的风险和求助也得不到跟踪和解决，久而久之就失去了参加的主动性....以上摘自华为这些年常见的一些现象，所以华为其实也不是高高在上的，华为的研发也很很多企业是一样的，都是一把鼻涕一把泪的。华为站立会议填坑排雷的一些小点滴1. 站位，不要走101火箭少女的C位，也就是不要如左图这样围着C位，而是推荐围成圈或围着Backlog（如有条件可以使用电子白板），这样可以保证每个成员的发言都是面向整个团队，而不是面向C位2. 发言棒（**ing Stick）。可以用个简单道具、玩具，或者尖**都可以，接力传棒，拿到发言棒的同学才能说话，其他同学闭嘴，为了活跃气氛，避免机械，可以将道具抛起，落到谁那儿谁发言。总体就是创造轻松，舒服的氛围3. 团队成员提出的困难、风险、求助，应得到跟踪并解决，下次的站立会议持续更新，让团队成员感受到效果，也更愿意参与这个会议，因为有帮助4. 尝试Pull，而不是Push，对于一些新的工作项，风险，挑战，鼓励大家Pull任务，而不是由Leader Push任务。5. 使用工具系统，当场刷新进展，记录新的工作项，而不是后续把卡片再记录到系统，容易遗忘和遗漏6. 对了，华为DevCloud在wiki内嵌了站立会议的纪要模板，可以参考，使用wiki简单记录站立的纪要和要点，也是我们常用的，如下：最后，为什么要站立开会呢？因为站在累，所以时间久了，就开不下去了，哈哈哈。。。愿大家能够更好的开好站立会议，提升团队成员的协同，建造自己的巴别塔：）本系列未完待续，To be continued.....

        前言：时间即效率，如今软件及互联网产品的开发迭代流程及开发时间在不断地优化，企业掌握研发环节上的时间效率主动权，就占据了市场的先机。中小企业常常面临产品发布、交付等生产节奏难以把控的问题，如何解决？除了反省和梳理自身工作流程，也需借助外部开发工具来优化。以下来自企业开发者常遇到的开发经历：做为一名程序员，我们会时常听到“别的公司”每周发布，甚至一天多次发布。交付速度快、上线频率高，质量还特好。可是轮到自己，现实却是残酷的。实施敏捷前，半年升次级一次还好点，现在敏捷了，每周五晚上１２点开始升级，２点全员开测，４点前修复问题，修复不了必须于５点前回滚，周末补觉或者继续改问题。要是中间再来个紧急ｂｕｇ修复，上线一次补丁包就更惨了。每周如此，整个团队累惨了，兄弟们女朋友都要跑光，坑爹的破敏捷、ＤｅｖＯｐｓ。自己搭一条流水线，ｊｉｒａ、Ｔｒｅｌｌｏ、ｗｉｋｉ、ｇｉｔｌａｂ、ｓｏｎａｒ、ｆｉｎｄｂｕｇｓ、ｍａｖｅｎ、Ｊｅｎｋｉｎｓ、ｎｅｘｕｓ、ｊｆｒｏｇ、ａｎｓｉｂｌｅ、ｐｕｐｐｅｔ…，各种开源工具扒拉对比选型，花费大量时间人力好不容易搭起来，刚开始还可以满足，但随着团队规模和产品规模的增长，经常出问题导致工作阻塞，整个开发团队炸锅，搭好的流水线不敢轻易升级或变更。内部需求响应越来越不及时、各方指责接踵而来，真是鸭梨山大。关键自己还不在业务主航道上，年底考评发现个人绩效伤不起啊伤不起……更恐怖的是，这些故事每天都在发生。毕竟，我们手工拷包部署，几次下来总会出现拷错包、部错机器的情况。手工测试，总有遗漏一些核心基线用例的时候。更不要说性能、可靠性测试每次手工执行的枯燥和易错。而且所有活动，无论流程设计如何完美，工具如何完备，如果不能够将人工操作（除了必要的Ｒｅｖｉｅｗ和发布审核）降到最低，各个工具编排、触发、调度运转，无论是效率还是质量均会受到较大影响。一个团队的自动化程度越低，如果采用ＤｅｖＯｐｓ开发模式，交付速度越快，则团队出错的几率越大、疲惫度越高、出错几率也越大。以上，便是企业开发过程常常面临的窘境。面对这些扑面而来的问题，光有好的ＤｅｖＯｐｓ理念、方法论、技术、流程是绝对不行的，还得要有好的工具——即持续交付流水线，来承载、固化、可视化这些方法和理念。就像福特、丰田的伟大离不开创建出当时世界上最好的生产流水线一样，软件开发当然也离不开良好的持续交付流水线。作为ＤｅｖＯｐｓ的核心工程实践，持续交付驱动着研发、测试与运维的正常流转，其中Ｐｉｐｅｌｉｎｅ流水线又是核心中的核心：· 理念：ＤｅｖＯｐｓ实现持续交付的理念和方法论· 流程：价值快速流动的持续交付流程· 技术：快速持续交付所需的基本技术准备，如微服务化架构解耦、特性分支、提交代码自动触发、安全扫描、分钟级构建、自动部署、自动化测试、质量门禁、灰度发布等· 实践：处于不同行业、成熟度阶段的企业，选择的不同方法和技术实践的组合· 工具：Ｐｉｐｅｌｉｎｅ流水线拉通调度的持续交付工具链· 组织与文化：实施ＤｅｖＯｐｓ需要的团队文化理念转变，以及组织变革如上图所示，所有的理念、方法论、流程、技术、实践、文化，最终都需要通过工具平台进行固化、可视化下来，使得价值流可见、交付可复制（重复执行），确保交付结果可预测，这样才能够确保在ＤｅｖＯｐｓ实践下，更快速迭代的同时，保持更高质量。程序员朋友们，你的日常交付中，是否也正在面临这些困扰：通宵熬夜加班升级赚的熊猫眼、交付速度越快越手忙脚乱越出错、自己搭建的交付流水线久久不敢升级？如果有，请来参加２０１８华为全联接大会，听一堂精彩的《基于Ｐｉｐｅｌｉｎｅ的ＤｅｖＯｐｓ核心实践》演讲，与华为云ＤｅｖＣｌｏｕｄ项目创始人及首席体验官交流如何通过Ｐｉｐｅｌｉｎｅ实践，更好的去解决这些问题。大会议程：https://agenda.events.huawei.com/2018/cn/minisite/agenda.html#dayTab=day7&tagName=%7B%22language%22%3A%22Cn%22%7D&seminarId=141友情链接：http://news.yesky.com/hotnews/377/50305377.shtml

第一种，文化使然，开发主导模式。最典型的就是Netflix的“Freedom and Responsibility”，Netflix号称是没有运维岗位的，连SRE角色也只有极少数，与此类似的还有Amzon，他们的运维工作基本都是由开发自助完成。无论极致的Netflix，还是大名鼎鼎的Google，还是老牌的Amzon，正是在这种自由和责任共存的文化驱动下，无论开发还是架构师，天然地对自己的系统、平台甚至是应用端到端负责，从而逐步构建起了能够支撑海量业务的基础设施和服务平台。这样到了后期，很多繁杂和重复的工作，开发都可以基于平台自助完成，而不是依赖运维的人来完成。所以，我们仔细观察，你会发现，国外的大厂其实极少提DevOps这个概念，因为他们天然就是这么干的，是理所当然的一种研发模式。这种模式对于组织来讲是最为高效的，但是文化导向之所以能够发挥这么大的作用，也有一个极为重要的前提就是技术团队和人才的能力问题，只有当团队能力足够强的时候，才能够支撑起如此完善的体系建设，再加上国外强烈的工程师文化，让他们能够耐住性子，沉下心来，稳扎稳打。反观国内，一个是技术人才的能力还达不到这个程度，再就是，国内的公司和产品往往追求业务增速和发展，往往会牺牲一些非功能性的能力。单纯从技术角度来看，国内公司在这方面很明显是落后很多的。第二种，自上而下的决策，开发和运维“被动”执行模式。最典型的就是阿里的DevOps转型，阿里应该是在2015年左右，甚至更早，就启动了DevOps转型。体现在组织架构上，最明显的就是取消了PE应用运维这个岗位。这个转型有两个必要因素：第一个，多年技术积累，基础设施和平台非常完善。原来基础能力不够的时候，很多运维工作也是要依赖PE这样的角色人肉去完成，但随着平台不断完善，有很多事情，开发完全可以基于平台自助完成，而不再需要多一个PE这样的环节去做。所以，从技术角度，阿里已经完全具备了DevOps的基础条件，从组织效率角度，提升研发整体的交付效率也势在必行。第二个，也是最关键的一点，自上而下的决策执行。虽然基础条件具备了，这时无论是开发还是运维，都不具备能力去做组织层面的调整和融合。但是，从研发高层的角度，当意识到DevOps转型时机成熟，且经过论证和实践是可以带来效率极大提升的时候（国外大厂的模式已经证明），组织上的职责和岗位调整，就势在必行了。我在几个大会上听到的分享，以及线下与经历DevOps转型的工程师交流，可以看到，上面的决策一下达，研发团队就制定了非常详细的交接和培训计划，原PE团队职责逐步交接到开发团队，经过多轮培训和交接后，历时两年左右，完成了整个DevOps的转型。讲到这里，我们可以看到，对于两个团队来说，都有一些被动的意味。但是，这个结果的达成，是离不开前期这么多年，技术能力不断积累完善这个前提条件的。所以，准确一点讲，应该是结果达成的阶段相对被动，但是前期的准备和积累阶段，都是主动的。稍微总结一下，以上两种模式的案例，我们可以看到都是大厂的案例，他们有一个共同的规律，就是基础设施和基础平台完善且强大到一定程度后，DevOps转型和落地更多的是水到渠成的结果。但是，上面的案例已经是结果，但是对于一般企业，DevOps的演进过程应该什么样的，这个过程中，开发应该怎么做？运维应该怎么做？下面我就结合蘑菇街的案例讲一些更细节的部分。第三种，技术战略项目切入，开发和运维合作共建所谓技术战略项目，可以理解为当业务发展到一定程度或某个阶段时，技术层面为了更好的适应业务趋势和场景，而做出的一些整体技术架构调整，这里可能包括软件架构、研发组织架构、基础设施建设等等。我回顾了下，蘑菇街整个DevOps体系的逐步形成，基本就是在这些技术战略项目的执行中，不断形成和完善的。第一个，Java服务化体系的建设2015年初，蘑菇街研发部启动业务架构的服务化项目，对原来的PHP单体架构改造。当时，这个项目是为了能够快速响应业务变化而做出的改变，并不是单纯为了DevOps的目的。不过，后来项目进行过程中，我们遇到了分布式架构体系下的一系列效率问题，比如应用发布、资源申请，快速扩容、问题定位以及故障响应等，统统跟不上节奏了。到了这个阶段，我们发现效率上不去，工具跟不上，最关键的问题就在于各种标准缺失。所以，我们花了大量时间和精力做了标准制定，从机型选择、OS版本、系统参数、到应用命名、部署目录、依赖管理，配置管理再到后面分布式组件和框架的标准约束等等。再往后，我们开始基于标准又配套提供了很多解决棘手问题的工具平台，一开始这些平台很简陋，但是能解决问题，再往后慢慢完善和重构，能力就越来越强大了，比如持续交付系统。开发在这个阶段，最主要的作用就是与开发共同制定标准，并在后续的架构设计和研发过程中，严格遵从标准，否则，接入不了工具平台，效率和稳定也就谈不上了。一开始强制约束，不按标准来，不给资源、不给发布，开发感觉非常不灵活，被限制了创造力，但是随着后来效率的提升，大家都慢慢认可了这种模式，而且会主动执行。这个过程下来，我们所理解的DevOps，其实是被现实场景倒逼出来的，开发和运维必须更紧密的合作，一步步尝试和探索，才能让团队运转下去，其它别无选择。第二个，电商大促的常态化电商企业的大促越来越频繁，已经呈现出日常化的形态。蘑菇街也不例外，为了保证业务峰值状态下的稳定，技术手段上，对线上压测、故障模拟、预案演练以及容量评估等，提出了更高的要求，从这个维度，又在驱动着整个稳定系体系的不断完善。这里要做的非常关键的一点，稳定性的标准化，并且在开发阶段严格执行。举个例子，我们要做限流，在开发的代码中，哪些API、函数需要限流？限流的阈值多少？限流对外部的影响是什么？这就需要对业务和代码都非常熟悉才可以，不然限流的点的方式不对，稳定性就无从谈起。对于容量评估、全链路压测等等也是一样，只懂技术，不了解业务场景和模型，就没法有效实施。所以，在这种场景下，开发是要发挥核心作用的，运维可以通过指标和模拟等手段去推到，但是始终是黑盒，作用终究有限。第一和第二个项目中涉及的平台建设细节，我就不再赘述了，大家如果感兴趣可以看我公众号的文章或者极客时间专栏文章。第三个项目，业务上云到了2018年，我们决定业务整体上云，依托于腾讯云完善的基础设施体系，将更多的精力专注在业务研发领域。这里带来的一个变化就是，很多服务都是现成的，如云主机、缓存、消息、数据库等等，申请即用，大大提升了我们资源和服务交付的效率，但是面临的问题，就是大量的服务实例成本如何管理的问题。最简单的方式，就是将能力暴露出来，由开发自助使用，而不是再通过运维审核或控制，最终通过成本分摊来控制合理使用。之前，自建IDC模式，服务器一旦采购，成本就已经形成，用与不用，成本并不会有差别。但是上云之后，按需付费，开发就要开始形成成本意识，必须要对自己所做事情，对自己的设计和写的代码的的ROI，有明确的分析。场景不同，要求也就完全不一样了。限于篇幅原因，这部分内容，包括我们在云上的双活站点建设，我会再开新文章来介绍我们的经验。三个部分做个总结，我们可以看到运维更像是技术运营，在驱动一些事情，但是真正的落地和执行，仍然在开发。同时，我们可以感受到，双方合作是否顺畅和紧密，心态和意愿，也是关键的要素。最后，总结上述的过程，如果倒过来看，其实就是一个公司随着业务发展和增长，技术体系演进的一个缩影。也就是，业务场景驱动，组织手段推进，文化导向覆盖。蘑菇街从无到有的建设，随着体系完善，终究会走向阿里DevOps转型后的模式，而阿里随着转型的完成，更深入的发展，必然会朝着Netflix的文化导向的趋势发展，让团队中每一个技术人员都能够具备端到端意识。所以，DevOps的实施和落地，不是某个点的改变，它必然一个体系的要求，比如业务上，体量和场景达到一定规模，技术层面必须达到一定高度，组织层面必须具备足够的力度和决心，同时文化宣导上覆盖要足够广，足够彻底。而开发在这个过程中的落地执行，无疑又有着决定性的作用。

      大家好，我是软件开发服务 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）       作为布道师和产品经理，出差各地接触客户是常态，经常和华为云的客户交流、布道、技术沙龙，但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和考虑。      -----------------------干货分割线--------------------------------------                   敏捷，精益看板，DevOps..... 技术在发展，研发的流程，方法，理念和工具也在不断发展。相信未来也会不断有新的软件研发理念，方法出现，因为软件这个复杂的怪兽，离征服还远着呢。。。：）       我在和很多企业交流的时候，总是会提到一个最重要观点：要把敏捷、DevOps这样的新研发方法当做变革来做，为什么呢？改革或者变革最困难的是什么，也是很多变革失败的原因其实都一条：破除即有的利益。熟悉中国这些年的**，应该很容易理解。       敏捷，DevOps，甚至新的配置管理工具Git，对于现有的很多企业都是一个巨大的转型，很多企业在原有的模式下已经形成了自己的组织，流程，文化和工具系统，各方利益已经固化。       我们引用DevOps（Patrick Dubois ）的一个经典图，如下图（Wall of Confusion），来感受一下变革是怎样触动即有“利益”的。产品和开发同学希望尽快的上线变更，这是产品和开发的天生诉求，而运维同学却希望越少的变更越好，因为保证现网的稳定性是他们的天生职责。开发和运维同学的主要冲突：不同的世界观：运维人员要求稳定可靠，认为变更充满风险，开发人员则被鼓励频繁发布新代码，认为运维部门对流程的坚持，阻碍了开发的速度；它在我的机器上没有问题！：常常听开发人员这么说，而运维团队的确遇到了麻烦，因为开发和运维之间的脚本、配置、过程和环境存在差别；沟通壁垒：开发和运维团队通常处于公司组织的不同部门，通常有不同的管理者，通常是不信任的关系，并且通常工作在不同的地点      这样天生的即有利益的冲突，是所有研发变革最大的挑战，也是导致失败的最大因素，怎么办呢？且听恒少下次分解         恒少，写于2018/9/27 华为广州办出差中：）

近日，DevOpsDays北京站正式开启，数百位各行业开发者及DevOps的实践者们参会，共同探讨学习DevOps在企业精益开发中的应用。华为云专家受邀参加本次大会，做了《华为云DevCloud百人大规模精益DevOps转型》主题演讲，分享了如何规模化转型精益DevOps与企业八步转型DevOps策略。　　DevOps理念是Development+Operations的组合，旨在促进软件开发、技术运营和质量保障等部门间的沟通和协作，让开发团队具有5-10倍的TTM和效率优势。通过践行DevOps，能够协助企业快速响应企业对于市场的变化、用户的诉求，提高企业软件交付效率，帮助企业IT实现数字化运营。　　从20世纪80年代到现在，华为的研发模式先后经历了游击队（软件作坊），正规军（软件过程控制，重型控制）以及特种兵（敏捷，精益，DevOps）三个阶段，从自身研发模式的演进过程中，华为也产生了对DevOps的更深层次的理解：随着DevOps理念的发展，它已经超越了一种研发模式的范畴，更是商业模式的变革，很多行业也会走向DevOps模式，比如，装备制造业可以从卖制造设备走向卖制造服务，如同云服务的客户从购买产品走向购买服务一样，这种大服务的模式将重新构建客户和供应商之间商业关系。　　正是基于对DevOps的深层次理解，华为在自身做大做强的同时，通过华为云DevCloud开放华为研发实践，助力软件企业专注业务创新。华为云DevCloud是一站式云端DevOps平台，集华为研发实践、前沿研发理念、先进研发工具为一体，面向开发者提供研发工具服务，让软件开发简单高效。开发者可以在华为云DevCloud上进行Web开发，微服务开发，移动应用开发，游戏动漫开发等。　　华为云专家现场就"全功能"团队这一概念与实践者们展开了探讨。华为对全功能团队的定义：是能够对特性、部件或者架构完整的实施规划、需求、设计、开发、测试并独立交付、运维（DevOps场景）的项目型团队。而DevOps正好可以协助组织打造全功能团队，随时随地实现代码托管、代码检查、编译、部署，最后一键上传到云端，并通过流水线，为端到端交付提供持续反馈，大幅提升团队整体的软件研发效率。　　最后，专家结合华为DevOps流程，总结了实现规模化精益DevOps八步走策略：梳理紧迫感，建立强大的变革领导联盟，设计愿景战略，沟通变革愿景，授权赋能，积累短期胜利，促进变革深入，成果融入文化。八个步骤严格顺序执行，夯实每一步，方可进入下一步。华为的价值观是以客户为中心，以奋斗者为本。长期坚持艰苦奋斗，长期坚持自我批判。华为云DevCoud也将这种文化和价值观渗透到了产品中，在产品、技术和服务上形成合力，助力企业成功转型DevOps。那么同样，任何组织，形成自我批判、持续学习和实验的能力，也将是DevOps成功落地的关键因素。　　华为云DevCloud是作为华为云的组成部分,是华为30余年研发实践和前沿理念的结晶，为开发者提供一站式、轻量级的DevOps工具服务，同时，也是帮助企业修炼内功的一大利器，可以有效支撑企业DevOps落地，实现项目的高效、高质量迭代。未来，华为云DevCloud也将携手各企业各开发者，精诚合作互通，及时响应反馈，更好的为广大开发者提供稳定可靠的DevOps工具，助力软件企业专注业务创新。　　点击了解华为云DevOps：https://www.huaweicloud.com/devcloud/

14941 2018年4月26日议题： DevOps-软件研发效能提升之道 讲师：华为云DevCloud高级产品经理/瞿然 PDF下载：14942 视频回看：https://bbs.huaweicloud.com/videos/3bfca69135e24513a020c33ca4185a99 一站式微服务与云中间件实践分享 讲师：华为云PaaS高级架构师/黄靖凯 PDF下载：14946 视频回看：https://bbs.huaweicloud.com/videos/7b36dbca0189478792e5209fa4067210 揭秘Serverless与NoOps关键技术 讲师：华为云Serverless产品经理/胡桂兵 PDF下载：14945 视频回看：https://bbs.huaweicloud.com/videos/b764fa8932dd4f769388abeb3dab3dc7 Kubernetes全栈容器技术剖析 讲师：华为云PaaS高级解决方案经理/陈弘 PDF下载：14944 视频回看：https://bbs.huaweicloud.com/videos/008f94ee8d92485ba089b9ae3e4c27dc 基于容器部署的DevOps 讲师：华为云DevCloud高级产品经理/羊振华 PDF下载：14943 视频回看：https://bbs.huaweicloud.com/videos/10ea6b01a4b24149a1d6ba96e472f6fb

今天已经是第11天了，随着进度的扩展，难度也随之提高了不少。 在第一期的实训营群里，被这一关难到的有不少。 1478114782 同时群内热心帮忙的大神也同样多，问题都被一一解决了。 现在我把我第11天编译构建的流程放上来，供大家批评指正。 ps：git大神请轻喷，纯小白一枚，零基础学习devops。 进入正题： 一、获取编译构建练习代码 还记得前面课程我们接的作业吗？ 作业地址>>https://dl.devcloud.huaweicloud. ... 7b74?sptype=special 14791 应用3，项目交付中刚好有编译构建的练习。 二、进行编译构建 选择这个项目（作业） 14792 选择构建&发布中的编译选项 14794 点击操作中的“开始构建”按钮。 或者直接点击链接：https://dl.devcloud.huaweicloud.com/codeci/home 点击小箭头。 14795 三、打卡 等待编辑成功，再次选择项目 14796 截图打卡 14797 这样，编辑构建的流程就被简化了。2333 估计后面的课程深度会来越来深，希望大神们多多指路。我现在把我今天课程完成的步骤贴出来，大家也多分享分享。

Hello DevClouder！各位云端开发者们，大家好。春回大地，万物复苏。又到了……咳咳，不好意思，拿错剧本所谓一年之计在于春，春不立，则一年无望。盼望着，盼望着……21天DevOps训练营第一期终于迎来开门接客的日子！在这里你不但有华为大咖带你学习前沿的DevOps知识，依托DevCloud一站式云端DevOps平台，你还可以动手实践，向DevOps Master的荣耀发起挑战！面向人群：所有渴望学习DevOps的朋友们参与方式1）扫描二维码，添加群助手微信，回复“21”，即可报名实战营144452）每日完成学习、实践、打卡任务，即可领取奖品3）优秀参与者将会获得荣誉勋章 项目预览 1234567W1 敏捷和DevOps项目管理 初识敏捷传统开发VS敏捷开发如何组织需求讨论会如何编写用户故事制作用户故事地图产品迭代正确开始DevOps W2 产品开发代码托管 初识Git Git迁移 Devcloud代码仓库功能介绍代码检查编译构建测试部署发布W3 持续交付流水线CloudIDE持续交付游戏开发解决方案软件实训解决方案电商双交付解决方案反馈和 度量本主题由 DevCloud 于 2018-4-16 08:53 设置高亮

14271

Hello DevClouder！各位云端开发者们，大家好。春回大地，万物复苏。又到了……咳咳，不好意思，拿错剧本所谓一年之计在于春，春不立，则一年无望。盼望着，盼望着……21天DevOps训练营第一期终于迎来开门接客的日子！在这里你不但有华为大咖带你学习前沿的DevOps知识，依托DevCloud一站式云端DevOps平台，你还可以动手实践，向DevOps Master的荣耀发起挑战！面向人群：所有渴望学习DevOps的朋友们项目预览    1234567W1  敏捷和DevOps项目管理  初识敏捷传统开发VS敏捷开发如何组织需求讨论会如何编写用户故事制作用户故事地图产品迭代正确开始DevOps  W2  产品开发代码托管  初识Git    Git迁移  Devcloud代码仓库功能介绍代码检查编译构建测试部署发布W3  持续交付流水线CloudIDE持续交付游戏开发解决方案软件实训解决方案电商双交付解决方案反馈和  度量