HCIP-Cloud+Service+DevOps+Engineer+V2.0第二章持续规划与设计

学习总结，思维导图整理，免费分享。侵权删除

本博文为HCIP-Cloud Service DevOps Engineer V2.0培训系列内容，[完整学习路径](https://education.huaweicloud.com/programs/ff24fd88-c9f3-4045-9ecd-94afb7eac6ba/about)；

想进一步考取华为认证云服务DevOps高级工程师HCIP-Cloud Service DevOps Engineer，请点击查看[职业认证考取流程](https://edu.huaweicloud.com/training/cssde.html)。

持续规划与设计
    敏捷项目管理理念与方法实践
        **敏捷软件开发宣言：**
            个体和互动高于流程和工具
            工作的软件高于详尽的文档
            客户合作高于合同谈判
            响应变化高于遵循计划
        敏捷开发的一个核心思维模式的转换
            从瀑布式开发所代表的“Fix Scope，Flex time”（固定范围，弹性时间）转向“Fix time，Flex Scope”（固定时间，弹性范围）
        敏捷开发主张的方法论
            以Scrum为基础的方法论（包括5crum、Scrum/XP混合等）体系仍然居于主流地位，使用率最高。其他还有：看板方法、精益创业、极限编程等。
        敏捷开发实践举例
            用户故事地图
                用户故事地图（User Story Mapping）是一门在需求拆分过程中保持全景图的技术。它可以使我们专注于用户和用户体验，产生更好的沟通效果，最终做出更好的产品。
            影响地图
                影响地图（Impact Mapping）由高级技术和业务人员协作创建，它可视化了产品范围（需求）及其背后的假设。
            ATDD流程
                接收/验收测试驱动开发（Acceptance Test Driven Development）。
            实例化需求
                实例化需求说明（Specification by Example）是一组过程模式，它帮助团队构建正确的软件产品。
    规划与设计
        什么是增量式交付
            增量式交付：起步于粗糙的产品原型/框架、细节功能不完善，但可以验证用户的整体使用场景、每增加一点功能，用户都能体会到价值的提升、与用户一同找寻最终的产品。
            **敏捷开发的基石是“增量式交付”。增量交付是指为及时反馈和接纳，频繁向客户交付连续改善的工作产品。**
            **增量交付是指为及时反馈和接纳频繁向客户交付连续改善的工作产品**，我们需要措施，确保我们按照用户可用的场景去交付
        影响地图
            影响地图可以通过可视化的方式，建立商业目标和产品功能的关联，并将联系背后的假设，可视化出来，实现将概念进行可视化
            **实践影响地图-通过四个问题达成统一认知：为什么（Why）、谁(Who)、怎样（How）、什么(What)。**
                ·为什么（Why）：地图的中心描述了我们为什么做这些？也就是我们试图达成的目标是什么
                谁(Who）：地图的第一层描述了谁能产生所需要的效果？谁会阻碍它？谁是我们产品的消费者或用户？谁会被他影响？也就是那些角色会影响结果
                怎样（How）：地图的第二层描述了角色的行为是怎样被改变？他们怎样说明我们达成目标？他们怎样帮助或妨碍我们取得成功？也就是我们想要产生什么影响
                什么（What）：地图的第三层描述了我们可以做什么，来支持第二层中所列出的影响的实现
            通过影响地图解决了业务和技术之间无法对话的问题，打通了业务和开发部门之间的墙，增量式交付
        用户故事地图
            用户故事地图：透过可视化的方式，建立用户场景与技术规格之间的联系，并辅助团队有效沟通。让用户在产品还没有做出来之前就可以体验到产品所提供的功能，并以二维结构呈现产品的主线功能和辅助功能，帮助设计者决策。
    敏捷项目管理的方法、模型
        看板
            精益制造体系通过看板形成拉动系统，带来控制库存、加速流通、灵活响应和促进改善等好处，最终让用户价值顺畅高质量地流动。
            看板源自精益制造
            建立和运作看板的五大实践
                可视化价值流动
                    可视化价值流动是看板方法中最基础的实践，它涉及可视化用户价值、价值的流动过程，以及价值流动过程中的问题和瓶颈等方面。
                显式化流程规则
                    显式化流程规则是指明确价值流转和团队协作的规则并达成共识。显式化的流程规则是团队协作的依据，更是团队改进的基线
                    流转规则
                        在什么条件下卡片可以进入下一环节
                    分类规则
                        何种类型的工作使用何种颜色的卡片，进入哪条泳道，采用什么样的优先级
                    工作节奏
                        团队以怎样的节奏接受新的工作，怎样的节奏更新看板，怎样的节奏对外发布
                控制在制品数量
                    控制在制品数量让环节内并行工作减少，单个工作项的完成加等待时间缩短，工作项从进入看板系统到完成交付的时间随之缩短。
                        在制品是指特定环节内所有的工作项：包括进行中和等待的；
                    **控制在制品数量加速了用户价值的流动，对产品开发的敏捷性至关重要。**
                管理工作项流动
                    ·管理工作流是为了让用户价值顺畅和高质量地流动
                    它包含三个分项实践：就绪队列填充活动、看板站会、发布评审，分别对应着用户价值的输入、中间过程和输出。
                        就绪队列填充活动：就绪队列是看板系统的输入环节和价值流动的源头，管理好就绪队列的填充对价值的顺畅流动和质量非常重要。
                        看板站会：站会是管理价值流动过程的活动，一个典型的看板站会发生在每个工作日、同一时间、同一地点（看板墙前），团队成员从右至左走读看板墙上的卡片，重点关注价值流动过程中问题和阻碍，处理这些问题或提出跟踪方案。
                        发布评审：发布评审是需求发布前的计划活动，决定上线或发布哪些需求以及相关发布策略等。发布评审是一个可选的活动，如在持续交付的模式下，它很可能被例行机制所替代。
                    建立反馈，持续改进
                        流动是否顺畅的反馈，如：阻碍问题分类，影响和原因分析。·质量问题的反馈，如开发环节和测试环节遗漏缺陷的分析等。
            看板展示核心元素
                看板中，通常存在分层、泳道、列、价值流、在制品（WIP）、风险&瓶颈、拉动式开发等核心元素
            看板分层架构
                产品级看板：基于产品视角看到的研发价值流，这是每个项目开展精益看板时，首先要分析和建立的看板系统。管理产品特性的流动。
                团队级看板：基于设计团队、开发团队、SIT测试团队的价值流视图，这是团队开展和改进的视图。精细化管理需求在设计阶段、Story开发、需求测试的流动。
            看板度量指标和方法
                看板度量主要指标：
                    前置时间（Lead Time）：又称为交付时间（Delivery time）
                    吞吐量（Throughput）
                        FE流动效率。准时交付率
                    流动性&波动性
                看板度量主要方法
                    价值流图
                    累积流图
                        累积流程图（CFD）是可以快速概述项目或产品工作中发生的情况的图表之一；CFD中找到有关工作状态的典型信息：已完成的工作量，正在进行的工作以及未完成的工作，进度如何等
                    控制图
                    直方图（（weibu分布图）
        Scrum
            Scrum是一个轻量级的项目管理的框架，它的核心在于迭代
            Scrum是一个包括了一系列实践和预定义角色的过程框架。任何的软件开发过程框架都可以由最基本的三个要素组成：角色（人）、活动及其输入输出的工件
            Scrum 三大特点
                “可能性的”艺术
                团队自组织，自管理
                面对面沟通
            Scrum框架
                3种角色
                    产品负责人
                    Scrum Master
                    开发团队
                3种工件
                    产品待办列表Product Backlog
                    Sprint待办列表Sprint Backlog
                    增量Increment
                5个活动
                    Sprint
                    Sprint计划会议Sprint planning
                    每日Scrum站会Dally Scrum
                    Sprint评审会议Spint Revlew
                    Sprint回画会议 Sprint Retrospectie
                5个价值观
                    承诺 Commitment
                    勇气Courage
                    专注Focus
                    开放Opennes
                    尊重Respect
                    scrum的价值观承诺是愿意对目标作出承诺，专注是把你的心思和能力都用到你承诺的工作上去，勇气是要有勇气作出承诺，并且要履行承诺，接受别人的尊重。开放是scrum让把项目当中的一切都开放给每个人看，尊重是每个人都有他独特的背景和经验，我们都要给予尊重。
            Scrum 三大支柱
                透明、检视和适应
                    透明就是通过任务板的形式，把项目中的任务和资源等进行可视化，在每日站会评审和回顾等环节都是进行解释的环节。在检视过程当中发现了偏差，就要进行调整，以适应当前的情况。
     敏捷需求管理
        用户故事
            用户故事描述了对用户，系统或软件购买者有价值的功能
            ·用户故事是敏捷开发方法中用来定义系统需要提供的功能和做为需求管理条目化的基础。
            用户故事的核心
                AS who，I want to what？so that why。
            搜集故事
            角色类型的创建
                头脑风暴
                    只创造角色
                    不讨论角色
                整理角色类型集合
                整合角色类型
            INVEST原则
                Independent 独立的 
                Negotiable可讨论的
                Valuabe有价值的
                 Estimable可估计的
                Small合适的小
                Testable可测试的
            用户故事的层级关系
                史诗、特性、故事、任务
                    史诗一般是大于一个或多个版本才能完成的。而特性一般都是在多个迭代完成。故事的话我们一般都是在一个迭代内完成，尽量不要让用故事跨迭代。最后的这个任务，它就是最小一级的，它都是按几个小时来计算的。
            用户故事的优先级
                考虑因素
                    风险、价值、成本、新知识
                渴望度Kano模型
                    有哪些功能是我们觉得理所应该有的？
                MoSCoW原则
                    moscow原则主要分为四个方向。must should could have won't have this time。
                        must have。基础功能是一定要有的。should have是很重要，但是短期内有替代方案。如果项目没有时间约束的话，这部分功能是认为应该有的。could have。如果没有时间就可以在现在的项目中不予考虑。won't have客户希望拥有，但是我们一定要同时承认它需要在后续发布中实现。这次发布中是不会有的。
            用户故事的优势
                强调口头沟通
                便于理解
                大小适中
                适合迭代开发
                鼓励延迟细节
                适应变化
                参与性设计
                传播隐性知识
            用户故事出现问题的迹象
                故事太小
                很难排优先级
                故事互相依赖
                想的太远
                不愿排优先级
                过早考虑界面细书
                细节太多
        相对估算与故事点
            相对估算
                当我们根据户型图来预估粉刷每个房间工作量时，是否能准确说出每个房间会耗费多少时间？
            故事点：用于表达用户故事、特性或其他工作总体大小的度量单位。
                ·故事点-不变的。
                ·理想人天可能改变-人员熟练。
                    更容易跟团队外的人解释
                    ·估算更容易开始
                    ·便于预测速度
        估算方法-原则
            如何确定估算值
                估算扑克是一个辅助工具，具体玩法是在护送过程中每个人手持一套牌，估算完毕。所有人亮手中的牌，然后得出团队的估算值。这里的重点在扑克牌的面值，不是连续数字，而是斐波那契数列。为什么要这么做呢？因为用户故事的估算并不要求很精确，不推荐在这上面花太多的功夫。所以当你在纠结这个故事点是3还是4的时候，问题解决了。扑克牌里没有4，只有3和5，所以你很容易判断出来应该给几个故事点。
            分解用户故事
                何时分解
                    当我们成功编写了一个用户故事以后，由于各种原因，我们往往需要把一个用户故事分解成多个更小的部分
            分解用户故事的方法-数据边界分解
                按照用户故事所支持的数据边界来分解大型用户故事
            分解用户故事的方法-操作边界分解
                按照大型用户故事中进行的操作对齐进行分解
            估算速度-使用历史值
            估算速度-预测
                估算个人可用小时数
                估算迭代可用时长
                选择故事填充可用时长
            案例模拟-项目流程
                开始估算
                创建角色
                编写第一个用户故事
                整理用户故事
                确定优先级
                估算用户故事
                合并和拆分用户故事
                估算速度
                确定迭代计划
     团队与协作
        Scrum中的角色
            Scrum Master
                Scrum Master 职责
                    并非传统的团队或项目经理，没有管理头衔和权力。
                    是一个具备影响力的仆人式Leader（非Manager）。
                    面向管理层时代表团队；面向团队代表管理层。
                    领导团队完成Scrum的实践以及体现其价值，不代表团队做出决定。
                    排除团队遇到的困难。
                    确保团队的胜任其工作，并保持高效的生产率。
                    使得团队紧密合作，使得团队个人具有多方面职能的工作能力。
                    保护团队不受到外来无端影响，被授权的“牧羊犬”。
                    团队和组织变革的代理人。
                    ·听多于说，思维开放，敏捷者。
                    ·专注并细心，团队合作，善于解决问题。
                    ·灵活运用Scrum模式，准备好挑战他人并接受他人的挑战。
                    ·持续改进自我的愿望。
                    ·开放心态，积极探索，愿意分享和帮助他人。
                    ·经历过转型或至少了解组织政治生态，善用权力但不渴望权力。
                    ·中等偏上的技术和产品知识水平。·具备沟通能力和意愿包括影响力。·从性格像限看，友善或表现型偏多。
                Scrum Master 核心能力
                    培训
                    专业辅导
                    敏捷精益实践者
                    引导
                    技术
                    业务
                    变革
            Product Owner
                Product Owner-产品负责人
                    客户代表
                    ·定义所有产品功能
                    ·决定产品发布的内容以及日期
                    ·对产品的投入产出负责
                    ·根据市场变化对需要开发的功能排列优先顺序
                    ·合理的调整产品功能和迭代顺序
                    ·认同或者拒绝迭代的交付
                Product Owner-特征
                    ·“一”个人，而非一个委员会
                    ·被授与产品（“做什么”）决策权
                    ·承诺投入到合作中并且在需要时被团队找到
                    ·企业家、系统思考者、创新者
                    ·驱动产品走向成功
                    ·提供产品领导力
                    ·和所有人合作
                    ·理想情况下是真正的用户来担任
                Product Owner-职责
                    Product Owner-使命
                        ·建立产品愿景
                        ·负责最大化投资回报
                        ·从“为什么”开始
                        ·定义产品功能（“做什么”）
                        ·确保迭代输入准备好
                        ·根据反馈，为最好地实现业务目标将产品Backlog排定优先顺序和调整需求待办清单
                        ·决定版本发布日期和内容
                        ·参加各个Sprint事件
                        ·接受或退回工作成果
            Dev Team
                Dev Team-开发团队
                    经典团队拥有5-9人
                    跨职能团队
                        具备不同的职能
                        端到端的特性团队
                        没有子团队，没有头衔
                        T-Shape人才，持续学习的通用专才
                    全职投入且长期存在
                    特殊职能可以例外（例如，数据库管理员）
                    团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整
                    团队自我组织和管理
                    没有管理者头衔
                    全员负责制
                    团队承担大部分微观管理工作并决定如何一起工作
                Dev Team-使命
                    ·与客户紧密工作在一起
                    ·决定迭代的工作容量
                    ·每个迭代交付产品增量
                    ·对“怎样做”和交付质量负责
                    ·管理Sprint Backlog并跟踪进度
                    ·找到团队内部合作的最佳方法
                    ·与其他团队及相关方协作
                    ·持续自我改进
                Dev Team 全栈工程师
                Scrum团队文化
                    共赢的文化
                    团队成功
                    个人发展
                    立足现实
                    挑战极限
        Sprint
            Scrum 项目周期以一组迭代周期“Sprints”组成
            Sprint 计划会议
                每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog
                第一个阶段：选取用户故事，确定迭代目标
                    PO与团队一起从Product Backlog中选择待完成的用户故事
                第二个阶段：拆分任务，创建迭代backog
                    团队拆分和确认任务，给出工作量估算选出的BackI0g选代ackl0g注：Sprint Backlog是团队协作的结果，不是只由SM和PO来决定产品Backlog
                Sprint计划会议的好处
                    通过充分讨论，使团队成员对任务和完成标准理解一致；
                    通过充分讨论，使团队成员对任务和完成标准理解一致；
                    团队共同参与，促进团队成员更认真对待自己的承诺。
                关键要点
                    充分参与
                        Scrum Master确保PO和Team充分参与讨论，达成理解一致。
                    相互承诺
                        Team承诺完成迭代Backlog中的需求并达到”完成标准“，PO承诺在短迭代周期不增加需求（2-4周）。
                    确定内部任务
                        Team和PO协商把一些内部任务放入迭代中（例如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序。
            Sprint 验收
                每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求；
                由Scrum Master 组织，PO和用户代表（外部或内部利益相关人）负责验收、Team负责演示可工作软件。
                迭代验收的好处
                    通过演示可工作的软件来确认项目的进度，具有真实性。能尽早的获得用户对产品的反馈，使产品更加贴近客户需求。
            Sprint 回顾会议
                不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩
                周期性的回顾，总结工作中的经验和教训。
                关键要点
                    ·会议气氛：Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因。
                    ·关注重点：Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）。
                    ·会议结论要跟踪闭环：可以放入迭代backlog中。
                    ·迭代回顾会议的好处
                    ·激励团队成员；
                    ·帮助团队挖掘优秀经验并继承；
                    ·避免团队犯重复的错误；
                    ·营造团队自主改进的氛围。
        每日Scrum站会
            执行
                每天都会开
                15分钟结束
                站着开会
                不是为了解决问题
                所有相关的人被邀请
                只有Scrum master，团队成员能够在会上发言
                避免无关的讨论
                更新Sprint Backlog，包括增减任务项、更新任务进度和状态
            好处
                增加团队凝聚力，产生积极的工作氛围。
                及时暴露风险和问题。
                促进团队内成员的沟通和协调。
            关键要点
                准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯。
                高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）。
                问题跟踪：Scrum Master应该记录下所有的问题并跟踪解决。
                每日站立会议促进团队沟通协调，及时暴露问题。
    华为敏捷项目管理企业实践
        华为对敏捷的统一认识
            敏捷包括3个层次
                理念（敏捷核心思想）
                优秀实践（敏捷的经验积累）
                具体应用（能够结合自身灵活应用才是真正敏捷）
        华为敏捷迭代流程
            产品经理进行需求规划
            产品经理创建工作项
            产品经理+开发Leader进行迭代计划
            开发Leader+开发人员/测试人员自定义流程
                每日站会、迭代开发、发布
            产品经理进行验收
            所有团队成员进行迭代回顾
                上线客户反馈问题后开始新一轮的迭代
        项目管理服务
            1.创建项目
                Scrum
                    标准的Scrum敏捷管理流程和实践
                看板
                    轻量级，事务管理
                DevOps全流程样例项目
                    预置工作项，代码仓，一键可发布的在线商城的样例项目
            2.规划和分解
                思维导图的形式
                    结构化分解需求
                图形化快速录入
                图形化快速拖动
                    调整需求父子关系
            3.工作项管理
                填写工作项描述
                可指定模块，优先级，迭代，重要程度，抄送人等
                可指定预计工时
            4.Backlog管理
                管理文档附件
                    工作项关联文档
                    方便查看工作项的设计、分析文档
            5.迭代计划
            6.自定义作业流
            7.迭代回顾

自己整理的思维导图链接：https://download.csdn.net/download/qq_42704442/87809414?spm=1001.2014.3001.5503m

免费下载