document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

PRF

Browse Source 
PART 1
This commit is contained in:
Xingyu Wang 2020-03-23 09:46:25 +08:00
parent e57903075f
commit 3a12536ae2
1 changed files with 36 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
translated/tech/20200204 DevOps vs Agile- What-s the difference.md
View File

@ -1,73 +1,59 @@
[#]: collector: "lujun9972"
[#]: translator: "messon007"
[#]: reviewer: " "
[#]: reviewer: "wxy"
[#]: publisher: " "
[#]: url: " "
[#]: subject: "DevOps vs Agile: What's the difference?"
[#]: via: "https://opensource.com/article/20/2/devops-vs-agile"
[#]: author: "Taz Brown https://opensource.com/users/heronthecli"
DevOps和敏捷: 究竟有什么区别?
DevOps 和敏捷: 究竟有什么区别?
======
两者之间的区别在于开发完毕之后发生的事情。
> 两者之间的区别在于开发完毕之后发生的事情。
![Pair programming][1]
早期, 软件开发并没有特定的管理流程。随后出现了[瀑布开发流程][2], 它提出软件开发活动可以被开发和构建应用所耗费的时间来定义。
早期，软件开发并没有特定的管理流程。随后出现了<ruby>[瀑布开发流程][2]<rt>Waterfall</rt></ruby>，它提出软件开发活动可以用开发和构建应用所耗费的时间来定义。
那时候, 由于在开发流程中没有审查环节和权衡考虑, 常常需要花费很长的时间来开发, 测试和部署软件。交付的软件也是带有缺陷和Bug的质量较差的软件, 而且交付时间也不满足要求。那时候软件项目管理的重点是长期计划。
那时候，由于在开发流程中没有审查环节和权衡考虑，常常需要花费很长的时间来开发、测试和部署软件。交付的软件也是带有缺陷和 Bug 的质量较差的软件，而且交付时间也不满足要求。那时候软件项目管理的重点是长期而拖沓的计划。
瀑布流程与[三重约束模型][3]相关, 三重约束模型也称为项目管理三角形。三角形的每一个边代表项目管理三要素的一个要素: **范围, 时间和成本**. 正如[Angelo Baretta写到][4], 三重约束模型认为成本是时间和范围的函数, 这三个约束以一种确定的, 可预测的方式相互作用。如果我们想缩短时间, 就必须增加成本。如果我们想增加范围, 就必须增加成本或时间。
瀑布流程与<ruby>[三重约束模型][3]<rt>triple constraint model</rt></ruby>相关，三重约束模型也称为<ruby>项目管理三角形<rt>project management triangle</rt></ruby>。三角形的每一个边代表项目管理三要素的一个要素: **范围、时间和成本**。正如 [Angelo Baretta 写到][4]，三重约束模型“认为成本是时间和范围的函数，这三个约束以一种确定的、可预测的方式相互作用。……如果我们想缩短时间表（时间），就必须增加成本。如果我们想增加范围，就必须增加成本或时间。”
### 从瀑布流程过渡到敏捷开发
瀑布流程来源于生产和工程领域, 这些领域适合线性化的流程: 正如房屋封顶之前需要先盖好支撑墙。 相似地, 软件开发问题被认为可以通过提前做好计划来解决。从头到尾，开发流程被路线图清晰地定义，顺从路线图就可以得到最终交付的产品。
瀑布流程来源于生产和工程领域，这些领域适合线性化的流程：正如房屋封顶之前需要先盖好支撑墙。相似地，软件开发问题被认为可以通过提前做好计划来解决。从头到尾，开发流程均由路线图清晰地定义，沿着路线图就可以得到最终交付的产品。
最终, 瀑布模型被认为对软件开发是不利的而且违反人的直觉, 因为直到开发流程的最后才能体现出其价值, 这导致许多项目最终都以失败告终。而且, 在项目结束前客户看不到任何可以工作的软件。
最终，瀑布模型被认为对软件开发是不利的而且违反人的直觉，因为通常直到开发流程的最后才能体现出项目的价值，这导致许多项目最终都以失败告终。而且，在项目结束前客户看不到任何可以工作的软件。
敏捷采用了一种不同的方法, 它抛弃了规划整个项目, 承诺估计的时间点, 简单的遵循计划。与瀑布流程相反, 它假设和拥抱不确定性。它的理念是以响应变化代替讨论过去, 它认为变更是客户需求的一部分。
<ruby>敏捷<rt>Agile</rt></ruby>采用了一种不同的方法，它抛弃了规划整个项目，承诺估计的时间点，简单的遵循计划。与瀑布流程相反，它假设和拥抱不确定性。它的理念是以响应变化代替讨论过去，它认为变更是客户需求的一部分。
### 敏捷价值观
敏捷由敏捷宣言代言, 敏捷宣言定义了[12条原则][5]:
敏捷由<ruby>敏捷宣言<rt>Agile Manifesto</rt></ruby>代言，敏捷宣言定义了 [12 条原则][5]（LCTT 译注：此处没有采用本文原本的简略句式，而是摘录了来自敏捷软件开发宣言官方的[中文译本][14]）：
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。
3. 经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 面对面沟通是传递信息的最佳的也是效率最高的方法。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷流程倡导可持续的开发，责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构，需求和设计出自自组织团队
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
2. 欣然面对需求变化，即使在开发后期也一样。
敏捷的四个[核心价值观][6]是（LCTT 译注：[此处译文][15]同样来自敏捷软件开发宣言官方）：
3. 经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
* **个体和互动** 高于 流程和工具
* **工作的软件** 高于 详尽的文档
* **客户合作** 高于 合同谈判
* **响应变化** 高于 遵循计划
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 面对面沟通是传递信息的最佳的也是效率最高的方法。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷流程倡导可持续的开发，责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构, 需求和设计出自自组织团队
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
敏捷的四个[核心价值观][6]是:
* **个体和互动** 高于 流程和工具
* **工作的软件** 高于 详尽的文档
* **客户合作** 高于 合同谈判
* **响应变化** 高于 遵循计划
这与瀑布流程死板的计划风格相反。在敏捷流程中，客户是开发团队的一员，而不仅仅是在项目开始时参与项目需求的定义, 在项目结束时验收最终的产品。客户帮忙团队完成[准入标准][7]，保持参与整个流程。另外，敏捷需要整个组织的变化和持续的改进。开发团队和其他团队一起合作, 包括项目管理团队和测试团队。做什么和计划什么时候做由指定的角色领导, 并由整个团队同意。
这与瀑布流程死板的计划风格相反。在敏捷流程中，客户是开发团队的一员，而不仅仅是在项目开始时参与项目需求的定义，在项目结束时验收最终的产品。客户帮忙团队完成[验收标准][7]，并在整个过程中保持投入。另外，敏捷需要整个组织的变化和持续的改进。开发团队和其他团队一起合作，包括项目管理团队和测试团队。做什么和计划什么时候做由指定的角色领导，并由整个团队同意。
### 敏捷软件开发
@ -86,15 +72,15 @@ DevOps和敏捷: 究竟有什么区别?
所有这些已经被单独用于或一起用于开发和部署软件。最常用的是[scrum][8], kanban(或scrumban)和DevOps.
所有这些已经被单独用于或一起用于开发和部署软件。最常用的是[scrum][8]，kanban(或scrumban)和DevOps.
[Scrum][9]是一个框架, 采用该框架的团队通常由一个scrum教练, 产品经理和开发人员组成, 该功能团队采用自主的工作方式, 能够加快软件交付速度从而给客户带来巨大的商业价值。其关注点是[较小增量][10]的快速迭代。
[Scrum][9]是一个框架，采用该框架的团队通常由一个scrum教练，产品经理和开发人员组成，该功能团队采用自主的工作方式，能够加快软件交付速度从而给客户带来巨大的商业价值。其关注点是[较小增量][10]的快速迭代。
[Kanban][11]是一个敏捷框架，有时也叫工作流管理系统，它能帮助团队可视化他们的工作从而最大化效率。Kanban通常由数字或物理展示板来呈现。团队的工作移到展示板上，例如未启动，进行中, 测试中, 已完成。Kanban使得每个团队成员可以随时看到所有工作的状态。
[Kanban][11]是一个敏捷框架，有时也叫工作流管理系统，它能帮助团队可视化他们的工作从而最大化效率。Kanban通常由数字或物理展示板来呈现。团队的工作移到展示板上，例如未启动，进行中，测试中，已完成。Kanban使得每个团队成员可以随时看到所有工作的状态。
### DevOps价值观
DevOps是一种文化, 思维状态, 一种软件开发的方式或者基础设施开发的方式，一种软件和应用被构建和部署的方式。它假设开发和运维之间没有隔阂, 他们一起合作，没有矛盾。
DevOps是一种文化，思维状态，一种软件开发的方式或者基础设施开发的方式，一种软件和应用被构建和部署的方式。它假设开发和运维之间没有隔阂，他们一起合作，没有矛盾。
DevOps基于两个其他实践: 精益和敏捷。DevOps不是一个公司内的岗位或角色；它是一个组织或团队对持续交付，持续部署和持续集成的坚持不懈的追求。[Gene Kim][12](Phoenix项目和Unicorn项目的作者)认为，有三种方式定义DevOps的理念：
@ -108,7 +94,7 @@ DevOps基于两个其他实践: 精益和敏捷。DevOps不是一个公司内的
DevOps不会凭空产生；它是一种灵活的实践，它的本质是一种关于软件开发和IT基础设施实施的共享文化和思想。
当你想到自动化，云，微服务时，你会想到DevOps。在一次[访谈][13]中, "*加速构建和扩张高性能技术组织*"的作者Nicol Forsgren, Jez Humble和Gene Kim这样解释到：
当你想到自动化，云，微服务时，你会想到DevOps。在一次[访谈][13]中，"*加速构建和扩张高性能技术组织*"的作者Nicol Forsgren，Jez Humble和Gene Kim这样解释到：
> * 软件交付能力关系到甚至极大地影响到组织结果例如利润，市场份额，质量，客户满意度以及达成组织的战略目标。
> * 优秀的团队能达到很高的交付量，稳定性和质量；他们并没有为了获得这些属性而进行取舍。
@ -170,7 +156,7 @@ via: https://opensource.com/article/20/2/devops-vs-agile
[2]: http://www.agilenutshell.com/agile_vs_waterfall
[3]: https://en.wikipedia.org/wiki/Project_management_triangle
[4]: https://www.pmi.org/learning/library/triple-constraint-erroneous-useless-value-8024
[5]: https://agilemanifesto.org/principles.html
[5]: http://agilemanifesto.org/principles.html
[6]: https://agilemanifesto.org/
[7]: https://www.productplan.com/glossary/acceptance-criteria/
[8]: https://opensource.com/article/19/8/scrum-vs-kanban
@ -179,3 +165,5 @@ via: https://opensource.com/article/20/2/devops-vs-agile
[11]: https://www.atlassian.com/agile/kanban
[12]: https://itrevolution.com/the-unicorn-project/
[13]: https://www.infoq.com/articles/book-review-accelerate/
[14]: http://agilemanifesto.org/iso/zhchs/principles.html
[15]: http://agilemanifesto.org/iso/zhchs/manifesto.html