目前在备考华为云的devops认证考试，特把近期的笔记整理好，方便复习
文章目录持续规划和设计看板scrumscrum团队模型scrum三种工件scrum过程模型 用户故事什么是用户故事描述用户故事项目流程创建角色搜集故事练习用户故事的层级关系优先级--渴望度Kano模型用户故事的优先级--MoSCoW原则用户故事的优势估算故事点DoRDoD scrum角色分工POdev teamscrum masterscrum事件sprintsprint计划会议每日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[达到什么目的或实现什么价值]客户最终需要的并不是文档，而是通过软件帮助其完成业务价值
短小精悍的故事可以帮助我们推进沟通，挖掘客户的真实需求。
相对于编写好的用户故事，产生和讨论的过程更加重要！
项目流程项目开始–创建角色–编写第一个用户故事–整理用户故事—确定优先级–估算用户故事–合并和拆分用户故事–估算速度–确定迭代计划
创建角色以开发招聘网站项目为例，这类网站会有很多不同类型的用户，编写用户故事的时候，所说的用户是谁呢？
一套方法：先头脑风暴，再整理角色，接下来再整合他们，最后提炼出来这个角色。
首先，头脑风暴环节。只创建角色，不讨论角色。团队所有人聚在一起，尽可能想跟这个网站相关的都有哪些角色？如有求职者，有猎头，如有人上来看看简历，如有失业了的人上来寻求岗位。不用想每个角色到底在这个网站上会做什么，也不用想角色之间是否有重复性，就是尽可能想所有的角色。
想出来的：大学毕业生、初次找工作、想换个工作地点的人、下岗人员、求职者、工作发布者、简历阅读者、招聘者、管理员
头脑风暴完毕，将这些角色放在一起分组，将有关系的角色的卡片进行重叠，如大学毕业生和初次找工作者，重叠度较高，如工作发布者和阅读者，其实都是招聘者所有的属性，和招聘者有一定的关系。用这个方法将卡片进行分组，分组后，进一步整合浓缩这些角色。每个卡片的作者再详细说下角色代表什么，以便团队进一步讨论角色之间的关系，再决定如何处理这些有重叠关系的卡片。如果两个重叠的卡片对我们来说意义等同，可保留一个丢弃一个，如大学毕业生和初次找工作者，整合为一个卡片。
整合之后：
求职者：初次找工作、下岗人员、想换工作地点的人招聘者：内部招聘者、外部招聘者管理员提炼角色类型
角色特征考虑方面：
操作计算机的熟练程度专业技术水平… 搜集故事用户访谈、问卷调查、观察、故事编写工作坊
练习用户故事—二手房交易网站
组内确定本项目可能出现的角色：买房客：初次买房的、已买过二手房的、浏览用户、囤房的、高端买房客
卖方客：初次卖房的、卖高价房的、只是有卖房意向的、虚假卖房的、多次交易卖房的
中介：一级中介、独立中介、中介公司、高端中介
管理员
描述尽可能多的用户故事 用户故事的层级关系 史诗Epic 大于一个或多个版本特性feature 大于一个迭代sprint故事story sprint内任务task 小时最重要的是根据业务价值确定优先级，即用户故事能给客户带来多少经济上的收入，以及成本。如登录时，页面加载需要控制在一秒钟之内，但这样需要一人周的工作量，用户考虑之后，决定降低它的优先级。风险，故事不能如期完成的风险。根据现状，是否能在当前迭代里完成这个需求？如果完不成会带来什么问题？这就是风险因素。
优先级–渴望度Kano模型当购买一件产品时，有哪些功能是理所当然应该有的？
哪些是越多越好的？
哪些是如果有的话会让我们觉得兴奋的？
如冰箱制冷，是基本功能。线性属性是产品应当有的，且产品的功能和客户满意度成线性的。如冰箱制冷时的噪音，噪音越小客户越满意。兴奋点属性，产品本身就没有，客户没有预期。如果有了，客户会非常兴奋。如冰箱可以播放音乐。
用户故事的优先级–MoSCoW原则业务需求：
MUST 占工作量的60% 基础功能一定要有
SHOULD 占80% 很重要，但是短期内有替代方案
应急计划：COULD 剩下的20% 如果没时间，可以不予以考虑
WON’T HAVE 客户希望有，但我们一定要同时承认它，需要在后续发布中实现。
用户故事的优势强调口头沟通、便于理解、大小适中、适合迭代开发、鼓励延迟细节、适应变化、参与性设计、传播隐性知识。
估算故事点如何确定估算值？
类比：在进行类比估算时，估算者将估算中的用户故事与一个或多个其他故事进行比较。如果这个故事大小约为其他故事的两倍，就分配两倍的估算值。
分解：将一个用户故事或特性分解为更小更易估算的部分。
专家意见：在基于专家意见的估算方法中，专家被问到某件事情需要多长时间或者他会有多大，专家根据他自己的直觉给出估算。
DoRdefinition of ready，敏捷开发发展后，发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，称为DoR
常见的DoR
用户故事澄清用户故事的故事点估算用户故事的验收条件 DoDdefinition of done，在敏捷软件开发中，常用 完成的定义 来表示工作是否已完成，不同的活动有不同的完成定义。
DoD类型常见规则用户故事用户故事最终的描述符合INVEST;用户故事得到测试用例的对应覆盖，用户故事得到对应的自动化测试用例；用户故事得到PO试用并初步认可迭代DoD所有代码通过静态检测，严重问题已修改；所有新增代码得到人工评审；测试用例都已执行发布DoD完成发布规划所要求的重点需求；至少通过一次全量回归测试；修复所有等级为1、2的缺陷；3、4的缺陷不超过20个版本DoD产品文档已全部更新；代码已部署到产品服务器上；运维在验收测试环境上冒烟通过；原始需求提交人对功能已经验收通过；对运维、市场、客服的新功能培训已完成每日DoD下班前检查当天编写的代码；当天的代码在当天或第二天邀请同伴进行代码评审；检入的功能代码要有对应的单元测试；每天晚上触发静态代码检查、自动化回归测试；当天持续集成、构建环境中的问题当天解决 scrum角色分工 POproduct owner 产品负责人
客户代表定义所有产品功能决定产品发布的内容以及日期对产品的投入产出负责根据市场变化对需要开发的功能排列优先顺序合理的调整产品功能和迭代顺序认同或者拒绝迭代的交付特征
一个人，而非一个委员会被授予产品决策权承诺投入到合作中并且在需要时被团队找到企业家、系统思考者、创新者驱动产品走向成功提供产品领导力和所有人合作理想情况下是真正的用户担任职责
产品经理 愿景和方向，结果负责需求分析 业务分析和需求分析需求管理 维护、终止和变更项目管理 优先级排序和项目状态跟踪质量保障 检查产品结果客户代表 产品体验/接受拒绝对外职责 老板、客户和用户、营销和销售…使命
建立产品愿景负责最大化投资回报从“为什么”开始定义产品功能（做什么）确保迭代输入准备好根据反馈，为最好的实现业务目标将产品backlog排定优先顺序和调整需求待办清单决定版本发布日期和内容参加各个sprint事件接受或退回工作成果 dev team团队自我组织和管理
没有管理者头衔全员负责制团队承担大部分微观管理工作并决定如何一起工作跨职能团队
具备不同的职能端到端的特性团队没有子团队，没有头衔T型人才，持续学习的通用专才使命
和客户紧密工作在一起决定迭代的工作容量每个迭代交付产品增量对怎么做和交付质量负责管理sprint backlog并跟踪进度找到团队内部合作的最佳方法与其他团队及相关方协作持续自我改进特性团队 feature team，区别于传统瀑布流的component team
其成功依赖于团队能力，以及团队对重构、持续集成和自动化测试等敏捷开发工具和实践的使用
而component team的组织方式导致瀑布流的开发流程，以便协调团队间的工作任务。
scrum master职责
并非传统的团队或项目经理，没有管理头衔和权力是一个具备影响力的仆人式leader面向管理层时代表团队；面向团队代表管理层领导团队完成scrum的实践以及体现其价值，不代表团队做出决定排除团队遇到的困难确保团队的胜任其工作，并保持高效的生产率使得团队紧密合作，使得团队个人具有多方面职能的工作能力保护团队不受到外来无端影响，被授权的牧羊犬团队和组织变革的代理人 scrum事件 sprintsprint计划会议 sprint planning每日scrum站会 daily scrumsprint评审会议 sprint reviewsprint回顾会议 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 yournamegit 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建立远程仓库的