软件开发 迭代-敏捷迭代开发

说到这里，就不得不提到科学管理之父泰勒，以及他的科学管理理论。 科学管理和泰勒主义的哲学是：

敏捷方法需要用实用的方法来解决这些问题。 例如，响应变化，在XP方法中，如果一个用户故事（在迭代中）没有实现，允许考虑用另一个用户故事替换它。 之后不允许再添加需求，需要ScrumMaster来检查。

少数精英负责制定标准的工作流程、工具操作、过程质量，然后由管理层完成监督管理工作。 大量的蓝领工人不用动脑筋、不用思考就能完成符合质量标准的工作，从而产生合格的工人。 产品。 我想大家一定记得K12课本上出现过的一句话：“我需要的是一双手，而不是一个人”。

客观地说，科学管理的提出和应用，确实​​加快了工业制造的发展软件开发 迭代，解决了生产力不足、不能满足市场需求的问题。 这也是工业革命后不可逆转的趋势。 但科学管理并不总是万能的。

后科学管理时代的探索：敏捷

20世纪后，行业面临的挑战逐渐从“生产力不足，无法满足市场的功能需求”转变为“灵活性不足，无法满足消费者创新定制的需求”。 “快速、残酷和不确定的变化”将是未来制造业面临的常态挑战。每个行业都开始强调变化，问题的本质在今天仍然适用

对于软件工程领域来说，Agile/敏捷是关于企业如何在动荡和竞争激烈的商业环境中获得利润。 与“科学时代的软件”的区别在于：

敏捷方法需要用实用的方法来解决这些问题。 例如，响应变化，在XP方法中，如果一个用户故事（在迭代中）没有实现，允许考虑用另一个用户故事替换它。 之后不允许再添加需求，需要ScrumMaster来检查。

●市场的要求和意识。 承认变化，接受变化，不要认为客户的需求可以一口气研究完，然后完全获得。

●对待生产和工作方法的态度。 接受错误，乐于尝试和犯错，迅速调整，持续优化。

●对待生产资料的态度。 承认个人的能力和价值，“让前线喊炮”，而不是“精英定规则，生产线只需要一双手”。

当然，以上并没有完全否定Waterfall和CMM的价值和意义。 但是，在当前的世界和环境下，CMM和瀑布并不能彻底解决我们的问题，所以我们还是要继续寻找“银弹”。

2. 理解敏捷的诞生

众所周知，2001 年 2 月，在盐湖城外 25 公里的滑雪胜地雪鸟，17 位行业先驱齐聚一堂，制定并签署了行业历史上最重要的文件之一：敏捷宣言。 随后，他们共同探讨了12条敏捷原则，并进一步解读了宣言。

敏捷，另一种软件工程方法

方法论是关于“如何开发软件系统”的行为框架，包括如何组建团队、如何制定项目计划、如何与团队成员和跨团队沟通、如何控制项目进度和质量。

在“雪鸟大会”之前，已经存在很多这种被称为“轻量级”的软件开发方式。 雪鸟会议的结果是正式将这些方法称为“敏捷（Agile）”软件世界开发方法。

一些“敏捷”的软件工程实践

不同敏捷方法的共同特征

不同的新方法有一些共同的特点。 例如，强调适应性而不是可预测性。 所以敏捷主义者会说“拥抱变化”，敏捷宣言中也有“响应变化比遵循计划更重要”这句话。

可能有人会说，这样的话，充满了变化，不按计划，没有边界，项目怎么能做呢？ 敏捷方法需要用实用的方法来解决这些问题。 例如，响应变化，在XP方法中，如果一个用户故事（在迭代中）没有实现，允许考虑用另一个用户故事替换它。 之后不允许再添加需求，需要ScrumMaster来检查。

再比如强调以人为本而不是过程为本。 强调人的作用和价值。 所以敏捷宣言会说“个人和交互比流程和工具更重要”。

可能还有人会说，你敏捷不写文档是不是也可以？ 其实不是我完全不写文档，而是为了减少浪费，减少在准备文档、沟通信息、理解文档上花费的时间和人力。 不要把时间浪费在对客户没有价值的事情上。 这就是“不写文档就敏捷”的真谛。 在这个原则的指导下，用户故事/需求、架构图、复杂的业务/计算逻辑等等，从代码上是看不出来的，这才是需要写的。 但高保真设计、数据库表结构、伪代码等可以简化或不写。

敏捷起点

敏捷方法的出发点是使用一些更有效的方法（工程实践）来交付高价值、高质量的软件。

敏捷方法需要用实用的方法来解决这些问题。 例如，响应变化，在XP方法中，如果一个用户故事（在迭代中）没有实现，允许考虑用另一个用户故事替换它。 之后不允许再添加需求，需要ScrumMaster来检查。

什么是高价值软件？ 更强的商业价值创造能力。 因此，在使用用户故事这个工具时，其描述规范是“可以实现xxx商业价值”。

什么是优质软件？ 更稳定，更灵活，易维护，易扩展。

敏捷实践总结：通过一系列可以实施并紧密协同的敏捷实践，可以生产出高价值、高质量的软件。

敏捷方法需要用实用的方法来解决这些问题。 例如，响应变化，在XP方法中，如果一个用户故事（在迭代中）没有实现，允许考虑用另一个用户故事替换它。 之后不允许再添加需求，需要ScrumMaster来检查。

什么是紧身？ 比如简单的设计之后如何进一步优化？ 那么就必须使用重构。 如何让重构成为一种频繁、快速、有效的开发方式？ 单元测试代码的开发是必不可少的一步，测试驱动开发是其最佳实践。 如何让持续集成顺利运行？ 必须推行统一的编码标准，必须有一套自动化的测试用例。

敏捷通用工程实践用户故事，使需求识别过程成为一种协作方法

敏捷软件开发方法的需求整理工作一般以用户故事的形式进行。

在《用户故事实战》一书中，US的特点总结为“3C”：Card、Conversation、Confirmation。 后两个C反映了US作为一种书写方式的定位（而不是传统的需求文档试图描述完整的需求）。

另外，从需求交付和跟踪的角度来看，Story Backlog和Kanban都是常用的工具，但各有各的应用场景。 从最初的场景来看，看板更适合连续不断的工作项跟踪，而用户故事Backlog则以迭代为单位，批量消化不同的需求。

● 重构，在不改变软件行为的情况下优化软件内部结构

重构是敏捷软件开发方法中非常核心的实践之一，它强调在不改变软件行为的情况下优化软件的内部结构。 一个小的更名工作是通过“煮小鲜肉”等一系列动作完成的。 看似琐碎，实则严谨、细小、可控。 通过这一系列的操作，大大降低了重构的难度（对原代码可观察行为的影响）。 特别是在复杂的软件项目中，这种高可操作性可能具有很大的价值。

在 IDE 高度进化的今天，像这样的重构场景，甚至更复杂的重构场景，都可以通过现代 IDE 的内置功能来完成，让重构变得更简单、更快捷、更易用。

●单元测试/自动化测试让持续重构成为可能

重构可以提高软件的内部质量，同时保持行为不变。 但是如何验证软件的行为是否发生了变化只能靠测试。 试想，如果你是通过重构来完成代码开发，这个过程如何验证软件在修改前后是否真的“行为不变”？ 只有通过考试。 而高频重构/修改意味着需要高频测试。 对于高频测试，自动化是不可避免的。

自动化就够了吗，或者如何更好的做自动化测试，比如自动化测试、单元测试、契约测试？ 它们之间有什么区别和联系？ 这是自动化测试的另一种敏捷实践。

●持续集成，基于配置/源代码管理

如何保证软件质量？ XP的方法是从可观察性来区分，外部质量靠自动化测试，内部质量靠重构。 但对于一个中大型项目团队来说，通常要持续数月甚至数年的交付过程如何坚持下去？ 这依赖于持续集成。 持续集成的工程实践包括一系列的工具和方法：

敏捷方法需要用实用的方法来解决这些问题。 例如，响应变化，在XP方法中，如果一个用户故事（在迭代中）没有实现，允许考虑用另一个用户故事替换它。 之后不允许再添加需求，需要ScrumMaster来检查。

●迭代，旧瀑布模型的升级版

团队需要在指定时间段内完成一系列工作项的过程称为迭代。 迭代的持续时间通常由团队和产品负责人决定。

在 Scrum 框架中，迭代称为 Sprint。 Scrum 项目流程由一系列 Sprint 组成。 Sprint的时长一般控制在2-4周，通过固定的周期保持良好的节奏。 产品设计、开发和测试都在 Sprint 期间完成。 在 Sprint 结束时交付工作软件。 在整个Sprint期间（计划会议确定工作项内容后）不允许有任何变更。

敏捷和CMM的本质区别是什么？

一般而言，CMM 更像是一种预定义的固化模型。 敏捷是一种经验性的、灵活的模型。 软件开发本质上是一个解决复杂和未知问题的过程。 用实证过程解决此类问题更为有效。

但在当前较新版本的 CMMI 中，还增加了对使用敏捷方法的组织的指导。 以下是CMMI V1.3中敏捷描述的片段。

敏捷

经验值

用户故事

3. 理解DevOps 从敏捷到DevOps，有什么区别？

从研发管理的角度来看，敏捷已经涵盖了过程、方法、实践、文化，甚至一些工具。 Scrum 框架实际上是轻量级过程方法的集合。 另一方面，XP 更加强调许多良好的工程实践。 敏捷宣言本身就是敏捷文化的体现，甚至带有敏捷先驱者的浪漫情怀。 持续集成的工程实践离不开工具。 然而，敏捷的种种言论并没有真正完成“尽快交付业务价值”的最后一公里，所以完整的工具链和生产环境管理必须要到DevOps中去寻找答案。

从应用管理的角度来说，我们在实践DevOps的时候，多半会用到Agile中的很多流程、方法和实践。 比如我们在做需求的时候，经常会用到用户故事和看板； 我们在做设计的时候也强调简单的设计，避免过度设计； 整个开发过程采用迭代的方式进行管理、测试和部署。 分支机构和管道管理策略等。 而且上线之后，包括上线之后，还会有一些更重要的内容在Agile,Ops里面没有说清楚。

通过上面的观察，我们会发现Agile和DevOps是密不可分的，它们本质上都在做一件事，就是软件工程。

当然，对于不同的行业，DevOps 可能还是有很多差异的。 例如，在受到高度监管的金融机构中，测试环境和生产环境之间可能始终存在不可逾越的高墙。 而这对于很多互联网公司或者普通企业来说，并不是特别致命的问题。

不管有什么样的区别，不管我们把我们做的事情叫Agile还是DevOps，甚至以后会出现什么新名字，我们其实都是在解决软件工程领域的问题。 质量、效率和成本的铁三角是这个领域的永恒命题。

工具链集成，建立高效的开发协同体系

工具链的集成构建是DevOps实施过程中非常重要的工作。 整个工具链的串联会涉及到很多工具。 我们可以从两个维度列出一些常用的工具：

研发工程维度（软件交付过程）：

基础设施维度（周边配套系统）：

可编程流水线

如果没有流水线，就无法完成自动化的 CI/CD 过程，更谈不上“持续”二字。 以博云的BeyondDevOps产品为例，基于Jenkins，提供产品和服务两级流水线自定义编排能力。

同时，通过任务模板和“流水线、步骤、任务”的多级模板，提供“乐高”式的流水线搭建体验。 并且平台内置了各种常用模板：从代码构建、代码扫描、产品/镜像拉取、自动化测试，到产品部署。 如果现有模板不够用，还可以使用自定义模板功能，实现新模板的开发和接入。

代码分支管理规范

代码分支策略和分支管理规范是DevOps中SCM领域的核心实践。 常见的代码分支策略包括 Git Flow、GitHub Flow、TBD Flow 等。 不同类型的公司、产品、系统和项目不一定具有相同的分支策略。 一个好的DevOps平台可以适应不同的代码分支管理策略，通过平台和工具链帮助客户完成对SCM的整体管理。 例如，在某些场景下，可以将某个分支机构的管理规范形成一个Template，固化到平台中。 帮助研发团队降低使用复杂分支策略的门槛。

产品管理规范

工件是软件开发过程的核心产出，是产生最终商业价值的载体。 对于企业来说，建立组织级统一的产品管理体系是非常有必要的。 其中包括产品命名标准、二方包管理规范、第三方包管理规范、生产/非生产产品包管理规范、产品推广方式以及相应的安全策略。

自动化生产级应用程序发布流程

生产环境的发布和运维是一个非常严谨的工作。 与大多数企业和互联网公司相比，金融机构对生产和发布的要求更高。 包括在线申请表、资源协同激活、产品管理、可定义自动发布流程、应用配置中心等。特别是在很多传统金融机构，生产环境的发布也意味着多部门协作、多系统调用、多-网络环境协作等。 博云的BeyondDevOps整体解决方案就是在这种复杂的业务场景下打造的。

4、博云DevOps整体解决方案概览咨询+产品+实施

DevOps作为当前软件工程行业最佳实践的集大成者软件开发 迭代，确实是一种热门的研发管理方式。 但只要是管理，就有千差万别。 对于想要实施DevOps的团队和组织来说，行业、组织文化、软件形态、团队状态、内部环境等因素都会导致其研发管理和工程实践的差异。

如何在充分考虑现实因素（目标、时间、成本、资源）的情况下选择有效的路径和解决方案，是DevOps项目成功的关键。 所以对于一个 DevOps 项目来说，不仅仅是购买一套产品。 博云结合自身在金融、工业、企业、政务等行业的经验，总结出一套可以针对不同行业客户实施的交付解决方案，愿与各行业朋友继续交流。

项目建设路径

冰冻三尺非一日之寒，DevOps作为研发管理的重要工具，也不是一蹴而就的。 对于大多数组织来说，构建和应用完整的DevOps体系的道路是需要规划好的。 特别是一些公司除了DevOps的实际应用之外，还对信通院的能力成熟度模型有需求。 为评估工作留出足够的时间。

在目前很多企业年度预算制的支出框架下，DevOps项目需要有一个好的规划和路径，才能有明确的短期和场景目标和实现路径，才能更好的完成项目，达到预期.