云服务器内容精选
-
08 什么是故事点？ 在Scrum中使用用户故事（情景）作为描述一个产品特性的方式，同时使用“故事点”作为这个产品特性大小的定量估算单位，故事点的大小标识了一个产品特性的开发难度和所需要的投入（小时/人天等）。但我们一般不使用直接的小时或人天等时间单位来表示这个值，而是使用斐波纳奇数列中的数值来标识不同特性的相对大小，这样做的好处时我们可以屏蔽直接使用时间单位所造成的主观差异，更快更准确的进行评估（因为在没有进行实际开发之前是很难直接估算时间，但是不同特性的相对大小是比较容易评估的）。最终，我们可以使用数据分析手段在故事点单位和时间单位之间建立换算关系，帮助我们掌控项目进度。 在CodeArts中，可以通过需求的“详细信息”页面中编辑分配给它的故事点。
-
21 Scrum的不足 对于目标不够清晰的项目，Scrum Master比较难以把控。 Daily Scrum在开始阶段会让团队感受比较大的压力，并占用一定的工作时间。 对于团队成员的技术水平、协作水平有较高要求。 Scrum中对于变更的容忍度非常高，但这也会让项目干系人感受比较大的不安。 会暴露非常多的问题，如果组织对于变化的接受度不高，会有很大的组织性冲击。 会引发很多变革的发生，一定程度造成混乱的局面。
-
22 在什么情况下Scrum并不适用？ Scrum模式并不适用于所有的团队，特别当团队规模很大（几十上百上千）的时候，我们无法在整个团队范围内实施Scrum，而必须将团队分割成5-10人的小团队，并在团队间进行Scrum of Scrum 的实施。 Scrum也不适合跨部门、跨职能的协作，如果团队成员分散于不同的地理位置或者不同的部门，我们需要首先在组织结构上进行调整，至少需要合并开发和测试部门，组成按照特性或产品领导的团队，同时从其他不同部门抽调人员组成团队。
-
18 什么是Sashimi和Impediments？ Sashimi的原意是“生鱼片”，在Scrum中是团队用来表达“完成”的一种说法。不同团队对于“完成”的定义可以是不一样的，但在一个团队内必须统一，在Scrum中一个团队需要定义不同级别的“完成规范”来统一这个概念。“完成规范”可以是任务级别的，团队级别的或者产品特定级别的。 Impediments的意思是“障碍”，是团队在向着“完成规范”所定义的状态努力过程中遇到的阻碍。一般来说，Scrum Master需要作为消除障碍的主要负责人。
-
14 Scrum中的冲刺和迭代有什么区别？ 迭代（Iteration）是一个通用词汇，表达的是开发过程中的某个循环过程的单元。这个单元可以是开发人员编写代码时的编写、编译、调试、重构，也可以是一个开发周期的规划、开发、测试、回归、发布。也就是说，这个单元可大可小，都可以使用迭代来进行描述。 冲刺（Sprint）特指在Scrum中的某个产品开发周期，是一个2-4周的规划、开发、测试、回归和发布过程。
-
09 什么是Scrum扑克？ Scrum 扑克（计划扑克）是一种进行量化估算的方法和工具。 在团队进行规划的过程中需要对工作量（故事点）、商业价值等进行量化评估，为了达到“评估结果是团队的集体决策结果”的目的，Scrum中发明了这种方法和附带的工具（一种扑克），在扑克上使用斐波纳奇数列标识每张扑克，在进行规划的时候每个成员按照自己理解出牌，并由数值最大和最小的两名成员进行解释，大家进行讨论后得出最终的数值估计。 斐波纳奇数列的特性决定了每个数字之间的差异会越来越大，这对于我们进行相对值评估非常有效。
-
19 什么是Daily Scrum？ Daily Scrum 是一个简短的团队会议，由团队的所有成员在每天固定的时间和地点进行，会议上每个成员需要回答3个问题： 你昨天做了什么？ 今天计划做什么？ 是否遇到了障碍，需要其他人的帮助？ Daily Scrum 不是一个汇报会议，因为所有的参与者都必须抱着平等的心态参加，你所回答的3个问题是说给所有人听的，所有人的3个问题也都是说给你听的。Daily Scrum一般由Scrum Master进行协调和组织，但Scrum Master并不对成员所描述的业务特性/任务内容进行评价，而只关注会议本身是否高效。 Daily Scrum必须站立进行，所以很多人称之为Daliy stand-up，站立的目的是为了让会议高效并让每个人都集中精力，放下手头的工作。
-
敏捷开发方法 除了《敏捷软件开发宣言》内所提到的价值观和原则以外，敏捷开发并没有一个完整的方法列表，因为所有的敏捷开发方法都是广大开发人员在日常的工作中摸索出来的，针对某种特定场景适用的方法。也就是说，以下所列出的敏捷开发方法并不一定适用于你的团队或者你的问题，但是敏捷鼓励所有人按照自己的方式尝试任何的方法，只要这种方法遵循以上价值观和原则，那么它就是一种敏捷方法。 Scrum Kanban（看板方法） Agile Modeling（敏捷建模） FDD（Feature-driven development，特性驱动开发） TDD（Test-driven development，测试驱动开发） XP（eXtreme Programming，极限编程） Lean Development（精益开发） Microsoft Solution Framework (MSF) for Agile（微软解决方案框架敏捷版） Agile Data Method（敏捷数据方法） ASD（Adaptive Software Development，自适应软件开发） Six Sigma Crystal（水晶方法） BDD（Behavior-driven development，行为驱动开发） DSDM（Dynamic Systems Development Method，动态系统开发方法） Exploratory Testing（探索性测试） 《2019年中国DevOps现状报告》中，针对国内各种敏捷开发方法的调研结果显示：在所有敏捷方法中，Scrum、看板方法、自定义混合模式是最受企业欢迎的前三种敏捷开发方法，占比分别为45.41%、41.23%、31.46%。 由CollabNet VersionOne发布的《第13届年度敏捷状态报告》中，敏捷方法应用状况的调研结果显示：Scrum和Scrum/XP混合（64%）仍然是受访者组织使用的最常见的敏捷方法。
-
为什么敏捷开发可以帮到你？ 误解：敏捷开发是为了快速交付？ 敏捷开发不是一种为了快速交付而出现的方法，它之所以比较快则是因为避开了许多浪费的处理方式。 那么，敏捷改善了些什么？ 前置时间：传统开发法依循计划、分析、设计、程序开发、测试再进行修改整合后发布的步骤进行，是一种顺序性的开发模式，当前一个步骤用掉越多时间时，后面步骤的前置时间就会越长，而形成时间上越多的浪费。反观敏捷开发，实行的是一种务实的做法，当收集到足够一次迭代开发的需求时即向下一个步骤前进，尽量缩短前置时间的浪费，然后将"分析、设计、开发与测试"形成一个开发步骤，减少了步骤与步骤之间的衔接时间。 首次发布：敏捷开发采用迭代的开发方式，每个循环都会有一个潜在可发布版本用来展示开发成果，这种展示给了客户进行回馈和改进的机会，让客户体会开发成果的作法同时也给予了客户决定开发方向的绝对主权。 需求过程：敏捷开发不作完整的需求分析（因为计划总是赶不上变化的），当需求的搜集量和内容质量已经达到一定要求，已经足够一个开发周期的工作量时就可以开始开发工作。 测试方法：敏捷开发对软件带来的最大影响便是测试了。传统的α（内部测试）、β（交付客户测试）、γ测试（优化处理）方式在采用敏捷开发后几乎不存在了，因为敏捷开发在开发周期内不断的进行测试工作，因此也就没有了在交付做α、β、γ测试时必须停止开发、冻结开发的时间浪费了。
-
敏捷宣言 “敏捷”一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。雪鸟会议共同起草了《敏捷软件开发宣言》，其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述。 价值观 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，尽管右项有其价值，我们更重视左项的价值。 原则 敏捷宣言中还包括以下原则： 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。 可以工作的软件是进度的主要度量标准。 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。 对卓越技术与良好设计的不断追求将有助于提高敏捷性。 简单——尽可能减少工作量的艺术至关重要。 最好的架构、需求和设计都源自自我组织的团队。 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
-
对持续交付与持续部署的解读 对于持续交付以及持续部署等概念的解读，核心就是一句话：将技术行为与业务决策解耦。持续集成是一个开发实践，持续部署是一个技术操作，持续交付是一个业务行为。 “持续交付是指，所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常工作时段里按需进行一键式发布。开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），都能快速得到反馈。一旦发现这类问题，就立即加以解决，从而保持主干始终处于可部署状态。” “持续部署是指，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署优质的构建版本，这通常意味着每天每人至少做一次生产环境部署，甚至每当开发人员提交代码变更时，就触发一次自动化部署。” “持续交付是持续部署的前提，就像持续集成是持续交付的前提条件一样。” 这里面涉及到的有几个概念：持续集成、持续交付、持续部署，以及持续发布。
-
小结 持续交付、持续部署、持续发布，更多的是技术行为与业务决策的区别。 解耦不是分家，最终整体团队的衡量，还是要由业务形成闭环。持续发布是以持续部署为基础，持续部署提供技术能力，使得业务可以根据市场需要，随时进行特性发布，或是进行特性实验。 正是因为技术的支持，持续部署到生产环境，才能让业务前所未有的具备如此灵活的能力，任何业务的决策，可以不再如此紧耦合的依赖于IT。 这也是DevOps Handbook全书的重点，关注在“部署前置时间”，而并非前置时间。即全书都在围绕着代码提交那一刻往后的过程，因为作者们认为，在提交前的阶段，需要更多的创造性，具有更多不确定因素。而提交后的阶段，则相对是确定的，力求可预见性和自动化，将可变现降到最低，以此来支撑业务需要。
-
技术域 “客户并不一定需要每一个green build，PM/发布经理按业务需求可选择任意一个，在任何时候自动化交付给客户；在部署、交付、发布的上下文里，dev和ops的最高境界是无为，赋能PO那帮人做业务决策，别烦我。”——Martin Liu。 从这句话中我们可以看出，从业务上，并非每一个功能都需要发布给每一位用户，而是根据不同的业务上下文，来决定哪些功能发布出来，针对哪些用户进行开放。发布决策，由业务来做。而技术需要的，是提供高效的交付能力，并保持随时可发布的版本状态。 技术层面的核心，在于保障价值的交付能够顺畅、频繁且快速的通过整个价值交付流水线 。 SAFe的持续交付流水线 下面让我们看看SAFe对持续交付流水线的划分，事实上，“Develop on Cadence, Release on Demand”也是来自于SAFe的内容。中间的持续集成与持续交付，正是关系部署前置时间的部分。前端的持续探索，属于产品、设计与开发内容，而这三部分，组成了技术域的发布火车。后面何时发布、如何发布，则是按业务的需求决定。 聚焦于部署前置时间 "How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?" ——Mary Poppendieck 修改一行代码，上线需要多少时间？这一指标决定了你能多持续、多稳定的交付，决定了MTTR，多久服务可以恢复、多快能够上线一个严重的缺陷修复、多快能够发布一个服务并获取价值反馈。这一指标，就是部署的前置时间。 部署前置时间，开始于工程师在版本控制系统中提交一个变更，截止到变更成功的在生产环境中运行、为客户提供价值，并生成有效的反馈和监控信息为止。 部署前置时间将整个价值流交付过程分成了两段，前一段的活动，主要是产品、设计和开发，具有高度的不确定性和变化性，需要创造性的工作，且很多工作无法复制。后一段的活动，主要在集成、测试和部署运维，相比起来，相对技术更可控。 所以部署前置时间的核心，是把可控的部分做到极限，力求可预见性和自动化，将可变性降到最低，来支撑变化的部分。 目标是分钟级的部署前置时间 通过小批量代码交付，在不同环境中通过不同层级的自动化测试与探索性测试，快速进行验证，同时持续将成功验证的变更部署到下一环境，从而在DTAP（开发、测试、验收、生产）不同环境中形成自动化的测试和部署节奏，这也就是部署流水线的概念。为实现部署流水线，需要版本管理、自动化测试、持续集成、自动化部署、环境管理，以及松耦合架构等的协调统一。 分层分级的部署流水线 “高质量的交付”，质量如何界定？功能和非功能的都算上，质量验证的手段也是分层的，验证就是反馈，为了快速获取反馈，这些手段分布在整个流水线的各个阶段。 部署流水线，是保障质量并缩短部署前置时间的有效支撑。同时，部署流水线，是分层分级的。 从影响范围来看，分为个人级、项目级、版本级、解决方案级的流水线。 执行的频度单位，分别是分钟级、小时级、以天为单位、和以周为单位。 分别对应不同的环境（DTAP）：Development、Testing、Acceptance、Production。 各个层级，在不同的环境上，执行不同的测试，这也与理想的测试金字塔分层测试相互对应。 每个层级的目的、和预设的反馈回路、涉及的范围、验证的方法与内容、定位问题区间都有所不同。 流水线越来越成为开发运维一体化的代名词 开发与运维之间“不可调和的矛盾”，可以通过流水线来解耦。流水线成为开发和运维人员最常使用的平台，从日常的提交代码自测，到提交到主干的持续集成，到测试和准生产环境的自动化与手工的验证，以及各级环境之间的部署和环境拉平。 很多人对于自动化都喜欢强调或追求“一键”的概念，然而一键只是方式，不是目的，更不是唯一。事实上，在部署流水线里面，甚至可以消除掉一键那个动作。 流水线的存在，接管了底层的基础设施，包括计算、存储、网络，无论是On Premise，还是On Cloud；接管了PaaS层，开发人员无需太关注是虚拟机，还是容器，也不必太多了解K8s的配置和编排，以及DTAP不同的环境的配置和差异；甚至接管了上面使用的自动化工具，包括版本库、制品库、持续集成、自动化构建、自动化测试工具、自动化部署工具。 这些都将成为流水线的一部分，所以流水线越来越不可或缺。不同的语言也好、架构也好、环境也好、容器也好、微服务也好、K8s也好，都可以往流水线上挂，流水线也就成为Dev to Ops事实上的标配和代名词。 所以流水线的作用，第一，接管和屏蔽底层环境的差异；第二，自动化流程引擎；第三，挂载执行分层分级的流水线任务。 流水线也是“持续稳定可重复的提供高质量的价值”的重要不可或缺的实践，服务于持续交付，同时也是DevOps的最终目标。 流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。 所有在流水线上面挂载的任务，理论上都应该服务于这一目的，所有不对这一目的提供价值的任务，理论上都不应该存在于流水线之上，都应该被消灭。 说到这里就不得不说一说能支持自动化部署流水线的工具——CodeArts。 在流水线方面，CodeArts提供可完全自定义的自动化部署流水线，关联版本库、编译构建、部署等多环节的功能，提交代码自动触发流水线，帮助团队轻松实现持续交付。任务配置中支持挂载子流水线，流水线分层分级管控。 解决开发与运维之间“根本的、长期的冲突” 通过流水线，让部署成为日常的、低风险的工作，来解决开发与运维之间“根本的、长期的冲突”：开发负责对市场变化做出响应，以最快的速度将新功能或者变更上线，而IT运维则需要为客户提供稳定、可靠和安全的IT服务；同时公司对不同部门的考核和激励不同，更是让开发部门与运维部门的目标和动因之间存在巨大的冲突。 通过小批量的、独立的快速交付周期，让各个功能/服务团队之间彼此解耦，快速获取反馈，快速验证问题，DevOps并不能解决问题，它只是让你快速失败，If you fail，fail fast。（所以在DevOps里，失败原本就是学习的一种方式） 通过频繁、快速的生产环境部署，保证稳定可重复的自动化部署。 通过Feature Toggle（功能开关/特性开关）、Dark Launch（灰度上线），让功能早在发布之前，就已经部署到生产环境中，并已经进行了多次小范围验证。为下游工作而优化，从而在业务需要时，可以不依赖于技术，可以自行进行功能的发布。 因此技术提供给业务的是一个自服务平台，正如将运维能力封装成自服务提供给开发一样。
-
业务域 我们再来看看业务域。 “持续交付跟这三个（持续集成、持续部署、持续发布）都不同，它是一种组织的能力，这种能力让组织可以持续的交付价值，具体是否采用以上三种技术实践并不一定，而且还必须考虑其他非技术因素，比如团队管理模型，需求结构，项目管理方式，人员能力等等。所以这个持续交付和以上3个不是一个层次的问题，但他们之间确实有互相推动影响的关系。”——徐磊 发布策略与发布节奏 持续集成与持续部署是技术域的事情，持续交付是业务域的。而持续发布，本文认为两者都有，但偏业务层面多一些。按需发布，因此发布还是业务的决策。 业务需要决定发布策略： 什么时候发布？ 发布哪些特性？ 发给哪些用户？ 发布节奏不需要与开发节奏保持一致，开发保证环境和功能是随时可用的，业务来决定发布策略。 假设驱动开发 持续交付流水线是Flow，是价值交付的过程，但如何确定交付的就是客户想要的价值？ 所有交付的功能特性都是基于假设：We believe that [building this feature] [for these people] will achieve [this outcome]. We will know we are successful when we see [this signal from the market]. 这就是假设驱动开发的概念。所以单向的不叫持续交付（价值），要实现闭环还需要反馈回路来验证假设。完整的闭环才是价值交付的过程，只有验证了假设，才能说将价值交付给了客户。通过发布，获取反馈，验证假设，进一步完善价值，进而提出新的需求（假设）。 SAFe的DevOps理论，大多来自于DevOps Handbook。SAFe的模型，是DevOps Handbook三步工作法的另一种解读。 多快的频度算是持续 什么叫持续交付？多快的频度算是持续？一周一个版本还是一天多个版本？ 视不同类型的产品，在类生产环境验证之后，有两条路径：一条是传统的软件模式，部署到生产环境，或是商业软件产品的客户交付过程，就意味着发布给最终客户，那么这里需要有一个业务的决策过程，是否可以将特性交付给最终客户。另一条是通过技术解偶的手段，实现即使是部署到了生产环境，也并不意味着发布给了最终客户，例如特性开关和Dark Launch。相较于第一种，这里业务决策过程就相对灵活一些。 以上两条路径，均需要技术手段来支撑，实现将特性先行发布给一部分用户，以及功能对用户是否可见。 持续部署对业务的赋能 “黑启动已经让每个人的信心达到几乎对它冷漠的程度…...大家根本就不担心…...我不知道，在过去5年里的每一天中，发生过多少次代码部署…...我根本就不在乎，因为生产环境中的变更产生问题的概率极低……”，John Allspaw在Flickr担任运营副总裁时说了上述的话，随后他发表了一天十次部署的著名演讲，随后他来到Etsy，Etsy的自助式部署流水线，使得“任何想要执行部署的人都能直接部署……董事会成员也可以执行部署……甚至连小狗都可以！……在一个普通的工作日里，刚到上午8点整，就有大约15个人和小狗开始排队……” 2010年时，Etsy的持续部署流水线工具已经将ChatOps集成进去，“提交代码之前，在自己开发环境执行了4500多个单元测试……UT运行仅需要不到1分钟，外部调用打桩……提交到主干后，CI服务器上立即执行7000多个自动化测试用例…...通过并行测试，11分钟执行完毕，MTTR20分钟……到2011年，每天25-50次部署”。 从上述的例子，可以看出技术对业务极大的赋能。如果我们能做到每天几十次的部署到生产环境，那么每次的变更又能有多大，一个月一次的版本，发布的时候的确需要严格审核，一天几十次呢？不难想象，此时的业务决策该有多简单，甚至可能不需要决策过程，这就是技术能力赋能给业务决策的体现，也是精益中强调小批量的原因。 低风险发布 按需发布，让特性发布成为业务和市场决策，而不是技术决策。 通过金丝雀发布，可以小批量的选择环境进行试验，待金丝雀验证通过再发全量。而滚动发布，使得这一流量切换过程更加平缓，一旦出现问题，可以自动回滚。 通过特性开关，可以保证应用上线后，功能开关先不打开，然后由业务人员根据场景进行决策，通过开关中心打开新功能，经过流量验证新功能。特性开关将部署与特性发布解耦，结合基于环境和用户群的蓝绿或是滚动发布，可以实现对不同的用户群进行不同功能的投放，实现A/B测试，进一步增强了假设驱动开发的能力，可以基于不同的假设路径，进行快速灵活的发布验证。
-
小结 量变产生质变，每100天一次发布，与每天100次发布，无论是从技术上、实践上，还是对业务的帮助上，都不可同日而语。更重要的，是mindset的转变，做具体的一个工程实践不难，但要把它做好做到极限很难，这里面的困难更多不是技术本身，而是思维方式的转变。 持续交付流水线，将整个价值交付过程贯穿起来，即使只是后半段的DevOps实践，也同样的牵一发动全身，发布频度这一个关键指标，就需要分支策略、测试自动化、部署自动化、架构解耦、发布策略、数据库等多方面的支持。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
