华为云devops认证考试课堂笔记1

客官°小女子只卖身不卖艺 2022-11-11 05:54 643阅读 0赞

> 目前在备考华为云的devops认证考试，特把近期的笔记整理好，方便复习

### 文章目录 ###

*   *  持续规划和设计
     *   *  看板
         *  scrum
         *   *  scrum团队模型
             *  scrum三种工件
             *  scrum过程模型
         *  用户故事
         *   *  什么是用户故事
             *  描述用户故事
             *  项目流程
             *  创建角色
             *  搜集故事
             *  练习
             *  用户故事的层级关系
             *  优先级--渴望度Kano模型
             *  用户故事的优先级--MoSCoW原则
             *  用户故事的优势
             *  估算故事点
             *  DoR
             *  DoD
         *  scrum角色分工
         *   *  PO
             *  dev team
             *  scrum master
             *  scrum事件
             *  sprint
             *  sprint计划会议
             *  每日scrum站会
             *  sprint评审会议
             *  sprint回顾会议
     *  持续开发和持续集成
     *   *  git基本概念和操作
         *   *  git文件状态
             *  git配置
             *  初始化仓库
             *  远程仓库管理
             *  分支管理
             *  git分支

## 持续规划和设计 ##

### 看板 ###

精益制造通过看板形成拉动系统，带来控制库存、加速流通、灵活响应和促进改善的好处，最终让用户价值顺畅高质量的流动。

*  控制库存：下游需要时上游才开始生产，有效控制了库存。库存控制水平是工厂管理的核心指标。
 *  灵活响应：用户需求的变化通过看板形成的信息流快速传递到各个环节，系统做出最快的响应，同时低库存水平降低负载，让响应更迅捷和低成本。
 *  加速流动：进入生产环节的物料和半成品，很快被拉入下一环节，直至变成成品。实现保证安全库存的前提下物料最快的流动，提高了工厂的运转效率。
 *  促进改善：库存的降低和流动的加速，让生产环节的问题可在第一时间暴露，为现场现时的解决问题和发现问题背后的根本原因提供便利，也提升系统改进的动力。

### scrum ###

#### scrum团队模型 ####

scrum master

*  保证scrum团队可以遵守scrum的价值，实践和规范
 *  帮助scrum团队和组织采用scrum模式进行项目流程组织
 *  指导并带领团队变得更加高效，实现更高质量
 *  保护团队不受到外界因素的干扰
 *  保证各个不同角色之间的良好协作，消除障碍
 *  帮助PO更好的利用团队的能力
 *  **不要管理**团队

Product Owner

*  PO是一个人并且只能由一个人来担任
 *  负责管理产品待办事项表（product backlog）并保证其对于客户和团队保持透明度
 *  对产品待办事项表进行优先级排序
 *  与团队一起来进行工作量估算
 *  对于项目的成功负责并保证投资回报率（ROI）

团队

*  最佳团队大小：5-9人
 *  多功能团队：程序员、测试人员、设计师、DBA和架构师
 *  保证团队成员全职参与开发
 *  自我管理，没有头衔之分，不组建子团队
 *  成员更替只能在迭代之间进行，最佳方式是在发布之间进行

#### scrum三种工件 ####

产品backlog

*  产品需求变动的唯一来源
 *  动态，永不完整，持续更新
 *  有序，排序越高越清晰具体，排序越低，细节越少
 *  每个产品一个，与团队数量无关
 *  产品负责人负责管理其内容，可用性和排序

sprint backlog

*  包含产品待办事项列表中当前sprint的子集
 *  包含完成sprint目标所需的任务细节
 *  开发团队可视情况增加或移除任务

产品增量

*  当前sprint完成的产品待办事项列表，以及之前所产生增量的总和
 *  必须达到“完成”的标准
 *  无论是否发布，必须是可用的

#### scrum过程模型 ####

迭代计划会议

*  进行迭代规划
 *  PO向团队介绍产品待办事项表
 *  团队在PO的协助下充分了解产品待办事项
 *  确定迭代目标和迭代合约
 *  对产品待办事项进行细分并创建迭代待办事项

迭代合约

*  团队组成（成员列表，角色分配）
 *  完成规范
 *  团队对迭代目标的承诺
 *  迭代长度
 *  迭代待办事项的估算
 *  迭代评审和下次计划会议的时间和地点

回顾会议

*  哪些做得好
 *  哪些做得不好
 *  哪些可以改进
 *  仅团队成员参与

迭代评审会议

*  团队展示完成的功能并收集反馈
 *  对未完成的功能进行描述并说明原因
 *  PO接受/不接受当前迭代
 *  邀请所有人，包括客户参与

迭代

*  团队用来实现迭代目标的时间区间
 *  迭代目标：可发布的软件产品
 *  1-4周，不多不少
 *  时间长度决定何时结束迭代，而不由工作量的完成决定
 *  为团队提供保障

每日站立会

*  站立进行，固定时间，固定地点进行
 *  3问题 昨天完成哪些工作？今天计划做哪些工作？遇到哪些障碍？
 *  信息沟通用途，不解决任何问题，不向任何人汇报

### 用户故事 ###

#### 什么是用户故事 ####

用户故事描述了对用户，系统或软件购买者有价值的功能，用户故事由三方面组成：

*  card：一份书面的故事描述卡片，用来做计划和作为提示
 *  conversation：有关故事的交流，用户具体化故事细节
 *  confirmation：测试，yoghurt记录和确认故事细节且可用于确定故事何时完成

用户故事是敏捷开发方法中用来定义系统需要提供的功能和作为需求管理条目化的基础

#### 描述用户故事 ####

as who, I want what so that why

*  作为X\[什么用户角色\]，
 *  我希望Y\[系统提供什么功能\]
 *  以便Z\[达到什么目的或实现什么价值\]

客户最终需要的并不是文档，而是通过软件帮助其完成业务价值

短小精悍的故事可以帮助我们推进沟通，挖掘客户的真实需求。

相对于编写好的用户故事，**产生和讨论**的过程更加重要！

#### 项目流程 ####

项目开始–创建角色–编写第一个用户故事–整理用户故事—确定优先级–估算用户故事–合并和拆分用户故事–估算速度–确定迭代计划

#### 创建角色 ####

以开发招聘网站项目为例，这类网站会有很多不同类型的用户，编写用户故事的时候，所说的用户是谁呢？

一套方法：先头脑风暴，再整理角色，接下来再整合他们，最后提炼出来这个角色。

首先，头脑风暴环节。只创建角色，不讨论角色。团队所有人聚在一起，尽可能想跟这个网站相关的都有哪些角色？如有求职者，有猎头，如有人上来看看简历，如有失业了的人上来寻求岗位。不用想每个角色到底在这个网站上会做什么，也不用想角色之间是否有重复性，就是尽可能想所有的角色。

> 想出来的：大学毕业生、初次找工作、想换个工作地点的人、下岗人员、求职者、工作发布者、简历阅读者、招聘者、管理员

头脑风暴完毕，将这些角色放在一起分组，将有关系的角色的卡片进行重叠，如大学毕业生和初次找工作者，重叠度较高，如工作发布者和阅读者，其实都是招聘者所有的属性，和招聘者有一定的关系。用这个方法将卡片进行分组，分组后，进一步整合浓缩这些角色。每个卡片的作者再详细说下角色代表什么，以便团队进一步讨论角色之间的关系，再决定如何处理这些有重叠关系的卡片。如果两个重叠的卡片对我们来说意义等同，可保留一个丢弃一个，如大学毕业生和初次找工作者，整合为一个卡片。

整合之后：

*  求职者：初次找工作、下岗人员、想换工作地点的人
 *  招聘者：内部招聘者、外部招聘者
 *  管理员

提炼角色类型

角色特征考虑方面：

*  操作计算机的熟练程度
 *  专业技术水平
 *  …

#### 搜集故事 ####

用户访谈、问卷调查、观察、故事编写工作坊

#### 练习 ####

用户故事—二手房交易网站

1.  组内确定本项目可能出现的角色：

买房客：初次买房的、已买过二手房的、浏览用户、囤房的、高端买房客

卖方客：初次卖房的、卖高价房的、只是有卖房意向的、虚假卖房的、多次交易卖房的

中介：一级中介、独立中介、中介公司、高端中介

管理员

1.  描述尽可能多的用户故事

#### 用户故事的层级关系 ####

*  史诗Epic 大于一个或多个版本
 *  特性feature 大于一个迭代sprint
 *  故事story sprint内
 *  任务task 小时

最重要的是根据业务价值确定优先级，即用户故事能给客户带来多少经济上的收入，以及成本。如登录时，页面加载需要控制在一秒钟之内，但这样需要一人周的工作量，用户考虑之后，决定降低它的优先级。风险，故事不能如期完成的风险。根据现状，是否能在当前迭代里完成这个需求？如果完不成会带来什么问题？这就是风险因素。

#### 优先级–渴望度Kano模型 ####

*  当购买一件产品时，有哪些功能是理所当然应该有的？
 *  哪些是越多越好的？
 *  哪些是如果有的话会让我们觉得兴奋的？
    
    如冰箱制冷，是基本功能。线性属性是产品应当有的，且产品的功能和客户满意度成线性的。如冰箱制冷时的噪音，噪音越小客户越满意。兴奋点属性，产品本身就没有，客户没有预期。如果有了，客户会非常兴奋。如冰箱可以播放音乐。

#### 用户故事的优先级–MoSCoW原则 ####

业务需求：

MUST 占工作量的60% 基础功能一定要有

SHOULD 占80% 很重要，但是短期内有替代方案

应急计划：COULD 剩下的20% 如果没时间，可以不予以考虑

WON’T HAVE 客户希望有，但我们一定要同时承认它，需要在后续发布中实现。

#### 用户故事的优势 ####

强调口头沟通、便于理解、大小适中、适合迭代开发、鼓励延迟细节、适应变化、参与性设计、传播隐性知识。

#### 估算故事点 ####

如何确定估算值？

类比：在进行类比估算时，估算者将估算中的用户故事与一个或多个其他故事进行比较。如果这个故事大小约为其他故事的两倍，就分配两倍的估算值。

分解：将一个用户故事或特性分解为更小更易估算的部分。

专家意见：在基于专家意见的估算方法中，专家被问到某件事情需要多长时间或者他会有多大，专家根据他自己的直觉给出估算。

#### DoR ####

definition of ready，敏捷开发发展后，发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，称为DoR

常见的DoR

*  用户故事澄清
 *  用户故事的故事点估算
 *  用户故事的验收条件

#### DoD ####

definition of done，在敏捷软件开发中，常用 完成的定义 来表示工作是否已完成，不同的活动有不同的完成定义。

<table> 
 <thead> 
  <tr> 
   <th>DoD类型</th> 
   <th>常见规则</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>用户故事</td> 
   <td>用户故事最终的描述符合INVEST;用户故事得到测试用例的对应覆盖，用户故事得到对应的自动化测试用例；用户故事得到PO试用并初步认可</td> 
  </tr> 
  <tr> 
   <td>迭代DoD</td> 
   <td>所有代码通过静态检测，严重问题已修改；所有新增代码得到人工评审；测试用例都已执行</td> 
  </tr> 
  <tr> 
   <td>发布DoD</td> 
   <td>完成发布规划所要求的重点需求；至少通过一次全量回归测试；修复所有等级为1、2的缺陷；3、4的缺陷不超过20个</td> 
  </tr> 
  <tr> 
   <td>版本DoD</td> 
   <td>产品文档已全部更新；代码已部署到产品服务器上；运维在验收测试环境上冒烟通过；原始需求提交人对功能已经验收通过；对运维、市场、客服的新功能培训已完成</td> 
  </tr> 
  <tr> 
   <td>每日DoD</td> 
   <td>下班前检查当天编写的代码；当天的代码在当天或第二天邀请同伴进行代码评审；检入的功能代码要有对应的单元测试；每天晚上触发静态代码检查、自动化回归测试；当天持续集成、构建环境中的问题当天解决</td> 
  </tr> 
 </tbody> 
</table>

### scrum角色分工 ###

#### PO ####

product owner 产品负责人

*  客户代表
 *  定义所有产品功能
 *  决定产品发布的内容以及日期
 *  对产品的投入产出负责
 *  根据市场变化对需要开发的功能排列优先顺序
 *  合理的调整产品功能和迭代顺序
 *  认同或者拒绝迭代的交付

特征

*  一个人，而非一个委员会
 *  被授予产品决策权
 *  承诺投入到合作中并且在需要时被团队找到
 *  企业家、系统思考者、创新者
 *  驱动产品走向成功
 *  提供产品领导力
 *  和所有人合作
 *  理想情况下是真正的用户担任

职责

*  产品经理 愿景和方向，结果负责
 *  需求分析 业务分析和需求分析
 *  需求管理 维护、终止和变更
 *  项目管理 优先级排序和项目状态跟踪
 *  质量保障 检查产品结果
 *  客户代表 产品体验/接受拒绝
 *  对外职责 老板、客户和用户、营销和销售…

使命

*  建立产品愿景
 *  负责最大化投资回报
 *  从“为什么”开始
 *  定义产品功能（做什么）
 *  确保迭代输入准备好
 *  根据反馈，为最好的实现业务目标将产品backlog排定优先顺序和调整需求待办清单
 *  决定版本发布日期和内容
 *  参加各个sprint事件
 *  接受或退回工作成果

#### dev team ####

团队自我组织和管理

*  没有管理者头衔
 *  全员负责制
 *  团队承担大部分微观管理工作并决定如何一起工作

跨职能团队

*  具备不同的职能
 *  端到端的特性团队
 *  没有子团队，没有头衔
 *  T型人才，持续学习的通用专才

使命

*  和客户紧密工作在一起
 *  决定迭代的工作容量
 *  每个迭代交付产品增量
 *  对怎么做和交付质量负责
 *  管理sprint backlog并跟踪进度
 *  找到团队内部合作的最佳方法
 *  与其他团队及相关方协作
 *  持续自我改进

特性团队 feature team，区别于传统瀑布流的component team

其成功依赖于团队能力，以及团队对重构、持续集成和自动化测试等敏捷开发工具和实践的使用

而component team的组织方式导致瀑布流的开发流程，以便协调团队间的工作任务。

#### scrum master ####

职责

*  并非传统的团队或项目经理，没有管理头衔和权力
 *  是一个具备影响力的仆人式leader
 *  面向管理层时代表团队；面向团队代表管理层
 *  领导团队完成scrum的实践以及体现其价值，不代表团队做出决定
 *  排除团队遇到的困难
 *  确保团队的胜任其工作，并保持高效的生产率
 *  使得团队紧密合作，使得团队个人具有多方面职能的工作能力
 *  保护团队不受到外来无端影响，被授权的牧羊犬
 *  团队和组织变革的代理人

#### scrum事件 ####

*  sprint
 *  sprint计划会议 sprint planning
 *  每日scrum站会 daily scrum
 *  sprint评审会议 sprint review
 *  sprint回顾会议 sprint retrospective

#### sprint ####

*  scrum项目周期以一组迭代周期sprints组成，可以和极限开发的迭代周期类比
 *  典型的迭代周期为2-4周或者最多一个自然月
 *  一个固定的周期能够创造出项目更优美的节奏感
 *  产品的设计、开发、测试全部都在一个迭代内完成

#### sprint计划会议 ####

什么是sprint计划会议？

每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品backlog，输出是团队迭代backlog

分两个阶段

*  第一个阶段：选取用户故事，确定迭代目标 PO与团队一起从product backlog中选择待完成的用户故事
 *  第二个阶段：拆分任务，创建迭代backlog 团队拆分和确认任务，给出工作量估算

sprint计划会议的好处：

*  通过充分讨论，使得团队成员对任务和完成标准理解一致
 *  团队共同参与，促进团队成员更认真对待自己的承诺

sprint计划会议的关键点

*  充分参与：scrum master确保PO和team充分参与讨论，达成理解一致
 *  相互承诺：team承诺完成迭代backlog中的需求并达到“完成标准”，PO承诺在短迭代周期不增加需求（2-4周）
 *  确定内部任务：team和PO协商把一些内部任务放入迭代中（如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序

#### 每日scrum站会 ####

执行

*  每天都会开
 *  15min结束
 *  站着开会

不是为了解决问题

*  所有相关的人被邀请
 *  只有scrum master，团队成员能够在会上发言

避免无关的讨论

更新sprint backlog，包括增减任务项，更新任务进度和状态

每日站会的好处：

*  增加团队凝聚力，产生积极的工作氛围
 *  及时暴露风险和问题
 *  促进团队内成员的沟通和协调

每日站会的关键要点：

*  准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯
 *  高效会议：会议限时15min，每个人都站立，依次发言，不讨论和会议主题无关的事情（如技术解决方案等）
 *  问题跟踪：scrum master应该记录下所有的问题并跟踪解决
 *  每日站会促进团队沟通协调，及时暴露问题

#### sprint评审会议 ####

什么是sprint验收？

*  每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求
 *  由scrum master组织，PO和用户代表（外部或内部利益相关人员）负责验收、team负责演示可工作软件
 *  非正式的 2小时的提前准备，不需要正式演示文档
 *  整个团队都要参加
 *  邀请所有关注产品的人参加
 *  团队按照backlog中的问题，逐个介绍这次sprint的结果，和演示新功能
 *  如果产品负责人想要改变功能，添加一个新问题到产品backlog中
 *  如果对功能有个新的想法，添加一个新问题到产品backlog中
 *  如果小组报告项目遇到阻碍现在还没能解决，把该障碍加入到障碍backlog
 *  团队达成对这次sprint的结果和整个产品的开发状态的共识
 *  展示真实的产品：team应该在真实环境中展示可运行的软件，判断是否达到完成标准
 *  收集反馈：PO根据验收情况和客户反馈意见，及时调整产品backlog

迭代验收的好处：

通过演示可工作的软件来确认项目的进度，具有真实性

能尽早的获取用户对产品的反馈，使产品更贴近客户需求

#### sprint回顾会议 ####

回顾会议

*  在每个sprint结束后，对当前的迭代周期做个阶段性的总结，包括好的方面和不好的方面，帮助团队在下个迭代中扬长避短，健康发展

从以下方面回顾：

*  开发团队效率如何
 *  开发团队合作如何
 *  项目进展曲线是否平稳
 *  开发团队前端和后端的分工如何
 *  测试团队的缺陷报告率如何
 *  开发周期中有没有被严重block的因素
 *  有没有需求方面的不明确导致rework
 *  在任务分配方面有没有不均衡，导致个别人太忙或太闲

## 持续开发和持续集成 ##

持续开发和集成在软件项目开发中的应用时遇到的关键问题有哪些？应该如何解决？应用持续开发和集成时可采用的辅助工具有哪些？工具软件之间的相互关系和协作方法又是什么？

### git基本概念和操作 ###

#### git文件状态 ####

一次代码修改被成功的提交到远端仓库会经历4个阶段。本地工作区、暂存区、本地版本库、远端版本库。通过相应的git命令，文件在4个区域跳转，并呈现不同的状态

文件的三种状态：

*  已修改 包括三种文件，新增文件、被修改的文件或被删除的文件。修改后的git仓库的文件
 *  已暂存 git add ‘已修改’文件 文件进入暂存区
 *  已提交 git commit ‘已暂存’文件 文件进入本地版本仓库。如果想把本地的代码同步到远端仓库，使用git push命令

#### git配置 ####

查看Git版本 `git --version`

配置用户名和email

*  `git config --global user.name yourname`
 *  `git config --global user.email name@mail.com`

查看配置信息

*  `git config -l` 也就是list，查看用户名邮箱信息

https配置

*  `git config --global credential.helper "cache"` 将用户名密码存储起来，减少每次授信的重复操作

ssh配置

*  生成ssh-key `ssh-keygen` 公钥是.pub后缀文件
 *  将public key添加到remote仓库
 *  添加ssh配置（~/.ssh/config）

配置忽略文件

*  .gitignore 文件的位置

#### 初始化仓库 ####

创建第一个代码库 `git init`

从远端克隆仓库到本地 `git clone ssh或https`

#### 远程仓库管理 ####

通过git remote建立远程仓库的链接

查看所有的远程仓库 `git remote -v`

添加远程仓库 `git remote add remote-name remote-url`

修改远程仓库命名 `git remote rename old-remote-name new-remote-name`

删除远程仓库 `git remote remove remote-name`

#### 分支管理 ####

查看所有分支

*  `git branch`
 *  \-v 查看分支的最新的提交
 *  \-a 查看所有分支包括远程分支切换分支(如果查看所有远程分支，需要`git fetch remote-name` 获取remote仓库的信息)
 *  `git checkout branch_name`

创建新分支

*  `git checkout -b new_branch` 创建一个分支与当前分支相同的分支
 *  `git branch new_branch --track remote-name/remote-branch` 创建一个分支

删除分支

*  `git branch -d branch_name`

#### git分支 ####

*  本质上仅仅是指向commit对象的可移动指针，git使用master作为分支的默认名字
 *  每次提交的时候都会自动向前移动，在若干次提交后，就有了一个指向最后一次提交对象的master分支。
 *  分支的本质是指针，新建一个分支，就等同于新建一个指针。如在master最新提交的基础上，通过`git branch testing` 命令即可新拉取一个testing分支。
 *  HEAD指针，用来识别当前指针，想在哪个分支操作，让HEAD指针指向谁
 *  如HEAD指向master，表明当前分支是master分支，所有的修改提交都是master上的，执行`git checkout testing` HEAD指向testing分支的最后一次提交，表明当前分支是testing
 *  如何识别当前分支 `git checkout master` 切换回master分支