fix(guide): simplify directory structure

guide/chinese/accessibility/accessibility-basics/index.md

@@ -0,0 +1,198 @@
+---
+title: Accessibility Basics
+localeTitle: 辅助功能基础知识
+---
+> “黑暗艺术是多种多样的，不断变化的，永恒的。对抗它们就像对抗一个多头的怪物，每次颈部被切断时，头发比以前更加凶猛，更加聪明。你正在与之抗争这是不固定的，变异的，坚不可摧的。“
+> 
+> \- 教授Severus Snape，哈利波特系列
+
+可访问性在开发中的作用基本上是了解用户的观点和需求，并且知道Web和应用程序是残障人士的解决方案。
+
+在这个时代，发明了越来越多的新技术，使开发人员和用户的生活更加轻松。在多大程度上，这是一件好事，是另一个时间的争论，现在只要说开发人员，尤其是网络开发人员的工具箱就像我们的朋友所谓的“黑暗艺术”一样不断变化就足够了。斯内普。
+
+该工具箱中的一个工具应该是可访问性。理想情况下，它应该是在编写任何形式的Web内容的最初步骤之一中使用的工具。但是，在大多数开发人员的工具箱中，这个工具通常都不是很好。这可能是由于一个简单的例子，即使不知道它甚至存在于极端情况下，例如不关心它。
+
+在我作为用户的生活中，以及后来的开发人员，他从任何形式的内容中获得可访问性，我已经看到了该频谱的两端。如果您正在阅读本文，我猜您属于以下类别之一：
+
+*   您是一名新手Web开发人员，希望了解有关可访问性的更多信息
+*   你是一个经验丰富的网络开发人员，已经迷失了方向（稍后会详细介绍）
+*   您认为工作中有法律义务，需要了解更多相关信息。
+
+如果您不属于这些相当广泛的类别，请告诉我。我总是喜欢听那些读我写的东西的人。实现可访问性会影响整个团队，从设计者选择的颜色，撰稿人写的副本，以及开发人员。
+
+## 那么，无论如何，什么是可访问性？
+
+可访问性本身有时是一个误导性的术语，特别是如果英语是你的第二语言。它有时被称为包容性设计。
+
+如果您的网站位于互联网上，任何拥有网络浏览器的人都可以访问该网站，从某种意义上说，每个人都可以通过网络浏览器访问该网站。
+
+但是，您网站上的所有内容实际上是否可读，可用并且对每个人都可以理解？是否没有限制条件阻止某些人“访问”您所暴露的所有信息？
+
+您可以问自己以下问题：
+
+*   如果您添加仅包含在音频文件中的信息，聋人是否仍能获得该信息？
+*   如果您用某种颜色表示您网站的重要部分，那么一个色盲的人会知道吗？
+*   如果您在网站上添加传达重要信息的图像，盲人或低视力人士将如何了解这些信息？
+*   如果你想用键盘或口棒浏览应用程序，它是否可行且可预测？
+*   您的应用程序是否采用设备的方向，以及如果用户无法进行物理更改，该怎么办？
+*   对于可能需要更多时间填写表单的人，您的申请是否有宽容的时间方面？
+*   假设JavaScript没有及时加载，您的应用程序是否仍然有效（渐进增强）？
+*   您甚至可以说，如果您的网站资源非常庞大，那么缓慢或有点连接的人是否能够阅读您的内容？
+
+这是可访问性发挥作用的地方。可访问性基本上需要使您的内容友好，尽可能容易“访问”最大数量的人。这包括耳聋，低视力，失明，阅读障碍，静音，慢速连接，色盲，患有癫痫，精神疲劳，年龄，身体限制等的人。
+
+## 为何实现可访问性？
+
+您可能认为可访问性不适用于您或您的用户，那么为什么要实现它？盲人用照片编辑工具做什么？
+
+事实是，你在某种程度上是正确的。如果您已经进行了细致的用户研究并排除了某些人访问您网站的机会，那么迎合这一群人的优先级就会降低很多。
+
+但是，做这项研究是实际捍卫这种说法的关键。你知道有[盲人游戏玩家吗？](http://audiogames.net)甚至是[盲人摄影师？](http://peteeckert.com/) 。也许你知道[音乐家可以聋](http://mentalfloss.com/article/25750/roll-over-beethoven-6-modern-deaf-musicians)吗？
+
+如果你这样做，对你有好处。如果没有，我想这更能激发我的观点。
+
+当我们查看实际上迫使您使某些网站和网络应用程序可访问的立法时，图片变得更加复杂。一个主要的例子是基于美国的[部分508](http://jimthatcher.com/webcourse1.htm) 。目前，这部法律主要是指政府组织，公共部门网站等。但是，法律也在变化。
+
+去年，航空公司网站被列入此列表，这意味着即使在欧洲，航空公司网站也开始争相使其内容可访问。不这样做可以让你的公司每天罚款几万美元，问题不是固定的。
+
+世界各地的这项立法有所不同，有些比其他立法更严重，包罗万象。遗憾的是，不知道这个事实并没有使诉讼消失。
+
+## 好的，所以可访问性是一个大问题。现在我们如何实现它？
+
+遗憾的是，这个问题难以回答。哈利波特在顶部的引用是有原因的，而不是我是一个狂热的幻想读者。
+
+如上所述，可访问性对于一大群不同的人来说非常重要，每个人都有自己的需求。让您的网站完全适合所有人，这是一项大型的，持续的任务。
+
+为了给疯狂带来一些方法，组成了Web内容可访问性指南或[WCAG](https://www.wuhcag.com/web-content-accessibility-guidelines/) 。本文档包含许多可用于检查网站的标准。现在，我将介绍一些最重要的基础知识。可以这么说，我会指出你那些悬而未决的成果。在随后的文章中，我将讨论更多高级技术，如\[WAI-ARIA\]，这对于基于JavaScript的应用程序非常重要。
+
+### 像当地人一样说话
+
+HTML规范是描述如何使用该语言来构建网站的文档。辅助技术，如屏幕阅读器，语音识别程序等，都知道这个文件。然而，Web开发人员通常不会，或者至少不够，并认为这样的事情是可以的：
+
+```html
+
+    <div class="awesome-button"></div> 
+ 
+    <span><strong>Huge heading I will style with CSS later</strong></span> 
+ 
+    <span class="clickable-with-JavaScript">English</span> 
+```
+
+你猜怎么了？所有这三个要素都打破了WCAG的几个标准，因此根本无法访问。
+
+第一个元素打破了所谓的“名称，角色，价值” - 标准，它指出网页上的所有元素都应该公开他们的名字，他们的角色（如按钮）及其价值（如编辑字段的内容）辅助技术。这个div实际上不提供三者中的任何一个，使其对屏幕阅读器不可见。
+
+在使用CSS设置样式后，第二个元素看起来像一个标题，但在语义上是一个跨度。因此，辅助技术不会知道它的标题。屏幕阅读器会将其读作常规文本而不是标题。屏幕阅读器通常有一个热键可以快速跳转到最近的标题，此标题不会包含在该范围内。
+
+例如，第三元素可以是用户可以单击以改变网站语言的元素。也许一个奇特的动画菜单会在点击时扩展。然而，这也是一个跨度，并没有暴露它的角色（链接或按钮），使得辅助技术认为这只是带有一些样式的英语这个词。
+
+跨度和div是非元素。它们意味着包含其他元素，而不是元素本身。您可以通过两种方式解决这些问题：
+
+*   您可以手动将ARIA属性添加到上面的元素。这是一个高级主题，超出了本文的范围。
+*   或者，您可以这样做：
+
+```html
+
+    <button>This is a button</button> 
+ 
+    <h2>Here's a heading level two</h2> 
+ 
+    <a href="JavascriptThing">English</a> 
+```
+
+繁荣。突然之间，只需使用原生HTML，所有这些元素现在都可以完全访问。换句话说，就像使用HTML一样。
+
+### 如果没有结构，基础就无法忍受
+
+稍早一点，我触摸了屏幕阅读器的热键，从标题跳到标题。实际上有许多这样的热键可以快速跳到最近的表格，形式字段，链接等。确保这些标题实际上在逻辑位置是一个很好的做法，真的会降低你的辅助技术用户的压力水平，这是好的如果您希望访问者继续回到您的网站。
+
+还记得标题是分层的。如果你使用h2，请确保跟随它的h3实际上与h2有关。对于最近的博客文章，请不要在h2下面输入h3作为联系方式。这里有一个很好的比喻是一本带章节的书，里面有小节。你不会在准备蔬菜章节的中间放一个关于烘烤饼干的部分......或者......你不会......对吗？
+
+### 有什么选择？
+
+网站上的图片很棒。他们为您的内容添加了一个新图层，可以真正让您的网站访问者体验更加身临其境的体验，并且通常只是在所有文本中看起来很好。一张图片可以说超过一千字，对吗？
+
+当然。也就是说，如果你能看到它们。在HTML5规范中，img-attribute必须始终具有alt-attribute。如果无法看到该属性，则该属性用作图像的替代。这对于您网站的盲人访问者来说都是如此，但是当您的图像由于某种原因无法加载时也是如此。因此，不向img-attribute添加alt-tag不仅会破坏可访问性，还会违反HTML5规范。
+
+我恳请任何抓住自己这样做的网络开发人员吃他们的程序员的帽子并在Windows 95上专门工作一周。时间结束后，写一篇关于你从这场考验中学到的东西的文章，这样我就可以在下午喝咖啡时大笑。
+
+现在，有一点需要注意。根据HTML5规范，Alt属性是强制性的，但实际填写它们并不是必须的。 `<img src="awesome-image.jpg", alt="">`因此是合法的HTML5代码。
+
+您是否应该为所有图像填写alt-tag？这取决于图像，真的。对于背景图像，答案通常是否定的，但无论如何都应该使用CSS。
+
+对于完全没有信息的纯装饰图像，您基本上可以自由选择。要么输入有用的描述性内容，要么根本没有内容。
+
+对于包含信息的图像，如小册子，地图，图表等，除非您提供文字替代方法，否则不添加替换文字会打破WCAG。这通常是alt属性，但也可以是图像正下方或旁边的文本块。
+
+对于文本图像，文本可以包含在alt属性中，也可以以某种替代方式提供。问题是在同一页面上添加文本替代方案基本上会使能够看到图像的人显示相同的内容两次，这就是为什么alt-attribute在这种情况下更好。
+
+文本应提供上下文和信息，这是查看图像的替代方法。写“热气球图像”根本不够 - 为什么那里有气球图片？如果图像是风格化的或传达了情感意义，那么这可以包括在内。
+
+### 儿子，我看不懂你的潦草
+
+即使是那些不戴眼镜也没有视力问题的人也会从易于阅读的字体和适当的对比中受益。如果你必须填写一个表格，在白色背景上放置浅黄色，无望的循环字母，我相信你会畏缩。例如，对于那些视力不如你奶奶的人来说，这变得无比糟糕。
+
+WCAG具有较小和较大字母的对比度，并且有大量工具可用于检查对比度是否足够强。信息和工具在那里，去使用它。
+
+开始检查颜色对比度的好地方是使用[WebAIM](https://webaim.org/resources/contrastchecker/)颜色对比度检查器。
+
+### 这个按钮做什么用的？
+
+当我们讨论表单的主题时，让我们快速浏览`input`标记。这个小家伙有点重要。
+
+当您在网页上放置一些输入字段时，您可以使用标签......以及......标记它们。但是，将它们放在一起并不够。您需要的属性是for-attribute，它获取后续输入字段的ID。通过这种方式，辅助技术可以知道与哪个表单字段相关联的标签。
+
+我想说明这个的最好方法是举一个例子：
+
+```html
+
+    <label for='username'> 
+ 
+    <input type='text' id='username'> 
+```
+
+这将使例如屏幕阅读器说“用户名，文本编辑字段”，而不是仅报告“文本编辑字段”并要求用户去寻找标签。这也真正帮助了使用语音识别软件的人。
+
+### 这是一个很高的要求
+
+我们稍作休息吧。我希望你去看一个设计精良的网页。它可以是任何页面。继续，我会等
+
+背部？太好了。现在，再次查看页面但禁用所有CSS。它看起来还不错吗？页面上的内容是否仍按逻辑顺序排列？如果是这样，很好。您找到了一个具有良好HTML结构的页面。 （轻松查看没有CSS的页面的一种方法是在WebAIM的[WAVE Web辅助功能评估工具中](http://wave.webaim.org)加载该站点。然后单击“无样式”选项卡以查看没有样式的页面。）
+
+如果不是，那很好。现在，当我遇到一个结构糟糕的网站时，你会得到我每天必须处理的印象。
+
+完全披露：当发生这种情况时，我倾向于诅咒。高声。充满活力。
+
+为什么这么重要？我会解释一下。
+
+_扰流警报！_对于那些到目前为止只涉及HTML / CSS课程的人，我们将稍微跳过一点。
+
+屏幕阅读器和其他辅助技术基于您网站的DOM呈现网页的自上而下的表示。在此版本的网页中忽略所有位置CSS。
+
+DOM代表文档对象模型，是网站HTML元素的树状结构。您的所有HTML元素都是基于您使用的HTML标记和JavaScript分层链接的节点。屏幕阅读器使用此DOM树来处理HTML代码。
+
+如果将元素放在元素的顶部，它也会显示在DOM树的顶部。因此，屏幕阅读器也会将它放在顶部，即使您使用CSS将其移动到页面底部。
+
+因此，我想给大家的最后一个提示是关注HTML的顺序，而不仅仅是添加了CSS的已完成的网站。没有CSS，它仍然有意义吗？大！
+
+哦......不是吗？在那种情况下......你可能有一天会在寒冷的微风中听到一声低沉的诅咒。那很可能是我，访问你的网站。
+
+在那种情况下，我真的只有两个字。当我写一些不好的代码时，我常常听到同样的两个字，而且我很高兴地告诉你：“去解决！”
+
+### 颜色对比
+
+对于普通文本，颜色对比度应至少为4.5：1，对于大文本，颜色对比度应至少为3：1。 “大文本”定义为至少18磅（24px）或14磅（18.66px）和粗体的文本。 [对比检查器](https://webaim.org/resources/contrastchecker/)
+
+## 结论
+
+我告诉过你关于可访问性，它是什么，它不是什么以及为什么它很重要。
+
+我还为您提供了获得正确无障碍的基础知识和基础知识。然而，这些基础知识非常强大，在编写可访问性时可以使您的生活更轻松。
+
+如果我们以FCC术语进行讨论，您应该在执行HTML / CSS课程以及JavaScript课程时牢记这些。  
+在随后的文章中，我将讨论一些更多的缺口主题。我将回答的一些问题是：
+
+*   添加结构化标题听起来是个好主意，但它们不适合我的设计。我该怎么办？
+*   有没有办法让我只写屏幕阅读器和其他辅助技术看到的内容？
+*   如何使自定义JavaScript组件可访问？
+*   除了包容性用户测试之外，还有哪些工具可用于为最大的用户群开发最强大和最易用的体验？

guide/chinese/accessibility/accessibility-examples/index.md

@@ -0,0 +1,66 @@
+---
+title: Accessibility Examples
+localeTitle: 辅助功能示例
+---
+## 实际应用中的可访问性示例
+
+我正在撰写此简短指南，以提供有关如何在网站中实现辅助功能的实际示例。在学校期间没有强调可访问性，也没有在Web开发的现实世界中充分强调它。我希望这篇文章以及其他许多文章将鼓励开发人员从现在开始创建可访问的网站。它总是帮助我实际掌握如何做事的例子。因此，本指南将重点介绍我作为Web开发人员在日常生活中遇到的真实世界示例。
+
+### 跳过导航
+
+为了让有视力的用户在您的网站上获得愉快的体验，他们需要能够快速有效地获取内容。如果您从未通过屏幕阅读器体验过网站，我建议您这样做。这是测试为无视用户导航网站的最佳方式的最佳方式。 NVDA是一款非常好的屏幕阅读器应用程序，免费提供。但是，如果您使用屏幕阅读器并发现它有用，请考虑向开发团队捐款。屏幕阅读器可以从[nvaccess.org](https://www.nvaccess.org/download/)下载。
+
+允许没视力的用户跳到网站的主要内容，并避免在所有主要导航链接中进行选项卡：
+
+1.  创建一个直接位于开始`body`标记下方的“跳过导航链接”。
+
+```html
+
+<a tabindex="0" class="skip-link" href="#main-content">Skip to Main Content</a> 
+```
+
+`tabindex="0"`以确保链接可在所有浏览器上进行键盘调焦。有关键盘可访问性的更多信息，请访问[webaim.org](https://webaim.org/techniques/keyboard/tabindex) 。
+
+2.  “跳过导航”链接需要使用ID标记与网页文档中的主html标记相关联。
+
+```html
+
+<main id="main-content"> 
+  ...page content 
+ </main> 
+```
+
+3.  默认情况下隐藏“跳过导航”链接。 这可确保链接仅在链接处于焦点时对有视力的用户可见。
+
+*   为可以使用CSS设置样式的链接创建一个类。在我的例子中，我添加了类`skip-link` 。
+
+```css
+.skip-link { 
+  position: absolute; 
+  width: 1px; 
+  height: 1px; 
+  padding: 0; 
+  overflow: hidden; 
+  clip: rect(0, 0, 0, 0); 
+  white-space: nowrap; 
+  -webkit-clip-path: inset(50%); 
+  clip-path: inset(50%); 
+  border: 0; 
+ } 
+ .skip-link:active, .skip-link:focus { 
+  position: static; 
+  width: auto; 
+  height: auto; 
+  overflow: visible; 
+  clip: auto; 
+  white-space: normal; 
+  -webkit-clip-path: none; 
+  clip-path: none; 
+ } 
+```
+
+这些CSS样式默认隐藏链接，仅在接收键盘焦点时显示链接。有关更多信息，请访问[a11yproject](http://a11yproject.com/posts/how-to-hide-content)和此[博客文章](http://hugogiraudel.com/2016/10/13/css-hide-and-seek/) 。
+
+### 无障碍表格
+
+### 无障碍标签

guide/chinese/accessibility/accessibility-tools-for-web-developers/index.md

@@ -0,0 +1,42 @@
+---
+title: Accessibility Tools for Web Developers
+localeTitle: Web开发人员的辅助功能工具
+---
+## Web开发人员的辅助功能工具
+
+有许多工具和在线资源可以帮助您确保您的Web应用程序满足所有可访问性要求。
+
+1.  **[辅助功能开发者工具](https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en)**
+    
+    这是Google Chrome扩展程序，会在“元素”标签中为Chrome开发人员工具添加新的辅助功能侧边栏窗格。此新窗格将显示与当前正在检查的元素的可访问性方面相关的任何属性。此扩展还添加了可访问性审核，可用于检查当前网页是否违反任何可访问性规则。
+    
+2.  **[斧头](https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)**
+    
+    此Google Chrome扩展程序可以在您的网页上找到辅助功能缺陷。
+    
+3.  **[颜色安全调色板生成器](http://colorsafe.co)**
+    
+    本网站可以帮助您创建基于WCAG文本和背景对比度指南的调色板。
+    
+4.  **[检查我的颜色](http://www.checkmycolours.com)**
+    
+    用于检查您现有网站是否符合颜色和对比度的可访问性要求的网站。
+    
+5.  **[颜色Oracle](http://colororacle.org)**
+    
+    一个模拟色盲的应用程序。它适用于Windows，Mac和Linux。
+    
+6.  **[tota11y](http://khan.github.io/tota11y/)**
+    
+    一种辅助功能可视化工具包，可检查您的网站如何使用辅助技术执行。
+    
+7.  **[AccessLint](https://www.accesslint.com)**
+    
+    一个GitHub应用程序，用于检查您对可访问性问题的拉取请求。
+    
+
+* * *
+
+#### 更多资源
+
+您可以在明尼苏达大学德卢斯分校的[这份名单](http://www.d.umn.edu/itss/training/online/webdesign/tools.html)上找到更多可访问网页设计的工具。

guide/chinese/accessibility/automated-testing/index.md

@@ -0,0 +1,11 @@
+---
+title: Automated Accessibility Testing Tools
+localeTitle: 自动化辅助功能测试工具
+---
+## 自动化可访问性测试
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/accessibility/automated-testing/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/accessibility/index.md

@@ -0,0 +1,27 @@
+---
+title: Accessibility
+localeTitle: 无障碍
+---
+## 无障碍
+
+**Web可访问性意味着残疾人可以使用Web** 。
+
+更具体地说，Web可访问性意味着残疾人可以感知，理解，导航和与Web交互，并且他们可以 为网络做出贡献。 Web可访问性也使其他人受益，包括具有不断变化的能力的[老年人](https://www.w3.org/WAI/bcase/soc.html#of) 由于老化。
+
+Web可访问性包括影响Web访问的所有残疾，包括视觉，听觉，身体，语言，认知和神经系统 残疾。 “ [残疾人如何使用网络](http://www.w3.org/WAI/intro/people-use-web/Overview.html) ”文件描述了不同之处 残疾会影响网络使用，并包括使用网络的残障人士的情景。
+
+网络可访问性也**使** _非_残疾人**受益** 。例如，Web可访问性的一个关键原则是设计Web站点和软件 灵活地满足不同的用户需求，偏好和情况。这种**灵活性**也使某些_非_残疾人受益 情况，例如使用慢速互联网连接的人，具有“临时残疾”的人，例如手臂骨折，以及能力发生变化的人 由于老化。 [为您的组织开发Web辅助功能业务案例](https://www.w3.org/WAI/bcase/Overview)的文档描述了许多内容 Web可访问性的不同好处，包括**组织的好处** 。
+
+Web可访问性还应包括无法访问Internet或计算机的人员。
+
+[Web可访问性倡议组织](https://www.w3.org/WAI/) [万维网联盟（W3C）](https://www.w3.org/)引入了一个突出的Web开发指南 从中我们获得了[WAI-ARIA](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics) ，Accessible Rich Internet Applications Suite。 在WAI处理html的语义以更容易地使用DOM树时，ARIA尝试制作网络应用程序，尤其是那些使用javascript和 AJAX，更容易访问。
+
+在网站上使用图像和图形会降低视力障碍者的可访问性。但是，这并不意味着设计师应该避免 使用这些视觉元素。如果使用得当，视觉元素可以向用户传达适当的外观和感觉，并且应该被使用 这样做。为了适当地使用这些元素，网页设计者必须使用替代文本将这些元素的信息传达给那些看不到的人 他们。替代文字应该简短并且要点 - 通常[不超过5到15个单词](https://www.thoughtco.com/writing-great-alt-text-3466185) 。如果一个 graphic用于传达超出alt文本限制的信息，该信息也应作为Web文本存在，以便通过屏幕读取 读者。 [详细了解替代文字](https://webaim.org/techniques/alttext/) 。
+
+就像Alt文本适用于视障人士一样，音频的成绩单适合那些无法听的人。提供书面文件或听力困难的人可以访问的内容的记录。
+
+版权所有©2005 [万维网联盟](http://www.w3.org) ，（ [麻省理工学院](http://www.csail.mit.edu/) ， [ERCIM](http://www.ercim.org) ， [京王](http://www.keio.ac.jp) ， [北京](http://ev.buaa.edu.cn) ）。 http://www.w3.org/Consortium/Legal/2015/doc-license
+
+### 更多信息：
+
+[w3.org可访问性介绍。](https://www.w3.org/WAI/intro/accessibility.php) [A11Y项目](http://a11yproject.com/)

guide/chinese/agile/acceptance-criteria/index.md

@@ -0,0 +1,21 @@
+---
+title: Acceptance Criteria
+localeTitle: 验收标准
+---
+## 验收标准
+
+用户素材作为待办事项中的项目，是对话的占位符。在这次谈话中， 产品负责人和交付团队了解所需的结果。
+
+验收标准告诉交付团队代码的行为方式。避免写出用户故事的**“如何”** ;坚持**“什么”** 。 如果团队遵循测试驱动开发（TDD），它可以为自动化测试提供框架。 接受标准将是QA团队测试计划的开始。
+
+最重要的是，如果故事不符合每个接受标准，那么产品负责人不应该在迭代结束时接受故事。
+
+验收标准可视为保护交付团队的工具。当交付团队在Sprint计划中承诺一组固定的故事时，他们也承诺修复一组验收标准。这有助于避免范围蔓延。
+
+请考虑以下情况：在接受用户故事时，产品负责人建议添加不在用户故事范围内的内容。在这种情况下，交付团队可以拒绝此请求（无论多么小），并要求产品所有者创建一个可以在另一个Sprint中处理的新用户故事。
+
+#### 更多信息：
+
+Nomad8提供了[关于验收标准](https://nomad8.com/acceptance_criteria/)的[常见问题解答](https://nomad8.com/acceptance_criteria/)
+
+在[接受标准](https://www.leadingagile.com/2014/09/acceptance-criteria/)上领先敏捷

guide/chinese/agile/acceptance-testing/index.md

@@ -0,0 +1,133 @@
+---
+title: Acceptance Testing
+localeTitle: 验收测试
+---
+## 验收测试
+
+验收测试，执行测试技术以确定软件系统是否符合要求规范。此测试的主要目的是评估系统是否符合业务要求，并验证其是否符合向最终用户交付的必要条件。
+
+有各种形式的验收测试：
+
+\- >用户验收测试
+
+\- >业务验收测试
+
+\- > Alpha测试
+
+\- > Beta测试
+
+# 验收标准
+
+验收标准是基于以下属性定义的
+
+\- >功能正确和完整
+
+\- >数据完整性
+
+\- >数据转换
+
+\- >可用性
+
+\- >性能
+
+\- >及时性
+
+\- >机密性和可用性
+
+\- >可安装性和可升级性
+
+\- >可扩展性
+
+\- >文档
+
+# 验收测试计划 - 属性
+
+验收测试活动分阶段进行。首先，执行基本测试，如果测试结果令人满意，则执行更复杂的场景。
+
+验收测试计划具有以下属性：
+
+\- >简介
+
+\- >验收测试类别
+
+\- >操作环境
+
+\- >测试用例ID
+
+\- >测试题目
+
+\- >测试目标
+
+\- >测试程序
+
+\- >测试时间表
+
+\- >资源
+
+\=>验收测试活动旨在得出以下结论之一：
+
+接受系统交付
+
+在请求的修改完成后接受系统
+
+不要接受系统
+
+# 验收测试报告 - 属性
+
+验收测试报告具有以下属性：
+
+\- >报告标识符
+
+\- >结果摘要
+
+\- >变化
+
+\- >建议
+
+\- > To-DO列表摘要
+
+# \- >批准决定
+
+验收测试侧重于检查开发的软件是否满足所有要求。其主要目的是检查开发的解决方案是否满足用户期望。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+验收测试是软件开发中的成熟实践。验收测试是代码功能测试的主要部分。
+
+验收测试测试代码按预期执行，即在给定预期输入的情况下产生预期输出。
+
+验收测试用于测试相对较大的软件功能块，即功能。
+
+### 例
+
+您创建了一个页面，要求用户首先在对话框中输入其名称，然后才能看到内容。您有一个受邀用户列表，因此任何其他用户都将返回错误。
+
+这里有多种方案，例如：
+
+*   每次加载页面时，都需要输入您的名字。
+*   如果您的名字在列表中，则对话框将消失，您将看到该文章。
+*   如果您的名称不在列表中，则对话框将显示错误。
+
+您可以为较大的对话框功能的每个子功能编写验收测试
+
+除了处理测试将如何执行的基础结构的代码之外，您对第一个场景的测试看起来像（在伪代码中）：
+
+鉴于该页面已打开 该对话框应该是可见的 对话框应包含一个输入框 并且输入框应该有占位符文本“你的名字，请！”
+
+### 笔记
+
+验收测试可以用任何语言编写，并使用各种可用的工具运行，这些工具可以处理上面提到的基础结构，例如打开浏览器，加载页面，提供访问页面元素的方法，断言库等等。
+
+每次你编写一个将再次使用的软件（即使是你自己），它也有助于为它编写测试。当您自己或其他人对此代码进行更改时，运行测试将确保您没有破坏现有功能。
+
+它通常由用户或主题专家执行。它也被称为用户验收测试（UAT）。 UAT涉及最常见的现实生活场景。与系统测试不同，它不关注错误或崩溃，而是关注功能。 UAT在测试生命周期结束时完成，并将决定软件是否移至下一个环境。
+
+定义应该编写哪些验收测试的好方法是为用户故事添加验收标准。使用验收标准，您可以定义用户故事何时可以部署，并根据您的意愿完成问题。
+
+在敏捷项目中，团队必须为所有用户故事定义验收标准。验收测试工作将使用定义的标准来评估交付的功能。当故事可以通过所有验收标准时，它就完成了。
+
+验收测试还可以验证完成的史诗/故事/任务是否满足定义的验收标准。与完成的定义相反，此标准可以涵盖团队想要解决的特定业务案例。这提供了良好的工作质量测量。
+
+#### 更多信息：
+
+*   [国际软件测试资格委员会](http://www.istqb.org/)

guide/chinese/agile/actual-time-estimation/index.md

@@ -0,0 +1,53 @@
+---
+title: Actual Time Estimation
+localeTitle: 实际时间估计
+---
+## 实际时间估计
+
+实际时间估计是预测基于不完整，不确定和嘈杂输入开发或维护软件所需的最实际的努力量（以人 - 小时或金钱表示）的过程。努力估算可用作项目计划，迭代计划，预算，投资分析，定价流程和投标轮次的输入。
+
+### 国家的实践
+
+已发布的估算实践调查表明，在评估软件开发工作时，专家评估是主要策略。
+
+通常情况下，工作量估算过于乐观，并且对其准确性存在强烈的过度信任。平均努力超支似乎约为30％而不会随着时间的推移而减少。有关工作量估算误差调查的评论，请参阅。但是，估算误差的测量存在问题，请参阅评估估算的准确性。平均而言，如果软件专业人员有90％的信心或“几乎肯定”将实际工作量包括在最小 - 最大间隔内，则可以看出，工作量估算准确性的强烈过度自信，包括实际工作量仅为60-70％。
+
+目前，“努力估计”一词用于表示不同的概念，如最有可能使用努力（模态值），相应于50％不超过（中位数）概率的努力，计划的努力，预算的努力或用于向客户提出出价或价格的努力。这被认为是不幸的，因为可能发生通信问题并且因为概念服务于不同的目标。
+
+### 历史
+
+自从至少20世纪60年代以来，软件研究人员和从业人员一直在解决软件开发项目的工作量估算问题;比如，见法尔和尼尔森的作品。
+
+大多数研究都集中在正式软件工作量估算模型的构建上。早期模型通常基于回归分析或数学上来自其他领域的理论。从那时起，已经评估了大量的模型构建方法，例如基于案例推理的方法，分类和回归树，模拟，神经网络，贝叶斯统计，需求规范的词汇分析，遗传编程，线性规划，经济生产模型，软计算，模糊逻辑建模，统计自举以及这些模型中的两个或更多个的组合。
+
+目前最常见的估计方法是参数估计模型COCOMO，SEER-SEM和SLIM。它们的基础是在20世纪70年代和80年代进行的估算研究，并且从那时起更新了新的校准数据，最后一个主要版本是2000年的COCOMO II。估算方法基于基于功能的尺寸测量，例如功能这一点也是基于20世纪70年代和80年代进行的研究，但是采用改进的尺寸测量和不同的计数方法进行了重新校准，例如20世纪90年代的用例点或对象点以及2000年代的COSMIC。
+
+实际时间估算是一种估算开发工作的基于时间的方法。
+
+能够估计敏捷项目的完成时间至关重要，遗憾的是，它也是规划敏捷项目最困难的部分之一。
+
+其目的是最好地估计完成给定开发任务所需的时间量。
+
+您可以使用的一种技术是估计完成用户故事所需的时间。当您这样做时，请记得咨询敏捷团队的其他成员。对于每个用户故事，请确保您估计一个现实可行的时间，但不要太多，以至于客户端因简单工作而被多收费用。咨询您团队的成员，以便您能够利用他们的专业知识来了解需要多少工作以及需要多长时间。当您对每个用户故事达成共识时，您可以累计时间来进行时间估算。
+
+随着项目要求的变化，您可以更新估算值。如果项目丢失了最初分配给它的一些资源，您可能需要剪切用户故事，以便能够在相同的总时间内完成它们。同样，如果您想提高应用程序的质量，您可能需要为每个用户故事分配更多时间，以确保您的团队有时间以所需的质量完成应用程序。
+
+通常，这些估算是使用理想的工程时间计算的。
+
+例子：
+
+**此任务将在10天内完成。**
+
+要么…
+
+**这项任务将于1月10日完成。**
+
+要么…
+
+**此任务需要25个开发时间才能完成。**
+
+### 更多信息：
+
+*   [敏捷约束](http://www.brighthubpm.com/agile/50212-the-agile-triangle-value-quality-and-constraints/)
+    
+*   [您如何评估敏捷项目？](http://info.thoughtworks.com/rs/thoughtworks2/images/twebook-perspectives-estimation_1.pdf)

guide/chinese/agile/alignment/index.md

@@ -0,0 +1,11 @@
+---
+title: Alignment
+localeTitle: 对准
+---
+## 对准
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/alignment/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/agile/application-lifecycle-management/index.md

@@ -0,0 +1,25 @@
+---
+title: Application Lifecycle Management
+localeTitle: 应用生命周期管理
+---
+## 应用生命周期管理
+
+应用程序生命周期管理（ALM）虽然通常与软件开发生命周期（SDLC）相关联，但它是一个更广泛的视角，可以更好地与产品生命周期的概念保持一致。开发（SDLC）只是应用程序生命周期的一部分，因此表示为ALM的一部分。
+
+ALM可分为三个不同的领域：治理，开发和运营：
+
+治理：包含该应用程序的所有决策和项目管理，并扩展了整个应用程序的存在。
+
+开发：实际创建应用程序的过程（SDLC）。对于大多数应用程序，开发过程在应用程序的生命周期中再次出现几次，包括错误修复，改进和新版本。
+
+操作：运行和管理应用程序所需的工作通常在部署之前不久开始，然后持续运行直到应用程序退役。有时与发展重叠。
+
+工具可用于管理ALM;一些比较受欢迎的选项包括：
+
+*   Atlassian [JIRA](http://atlassian.com/software/jira)
+*   CA Technologies [拉力赛](http://ca.com/us.html)
+*   [ThoughtWorks的](http://thoughtworks.com/products)
+
+#### 更多信息：
+
+InfoQ - Gartner和软件建议检查[敏捷生命周期管理工具](http://www.infoq.com/news/2015/02/agile-management-tools/)

guide/chinese/agile/architectural-runway/index.md

@@ -0,0 +1,5 @@
+---
+title: Architectural Runway
+localeTitle: 建筑跑道
+---
+建筑跑道设置项目启动前程序所需的一切。这使开发人员能够立即投入运行。

guide/chinese/agile/backlog-emergence-and-grooming/index.md

@@ -0,0 +1,20 @@
+---
+title: Backlog Emergence and Refinement
+localeTitle: 积压出现和改进
+---
+## 积压出现和改进
+
+产品待办事项细化是一个正在进行的过程，需要与产品发现过程保持同步。通常，Scrum团队将协作完善下两到三个冲刺的产品积压项目。
+
+产品所有者（负责澄清sprint目标的人员）通过识别和分类产品backlog中最有价值的用户故事来定义即将到来的sprint的范围。产品所有者不仅仅是产品积压的美化项目经理，而且代表利益相关者执行的角色不仅仅是用户故事。
+
+来自Scrum指南： 产品Backlog细化是向产品Backlog中的项添加细节，估计和订单的行为。这是一个持续的过程，产品负责人和开发团队在此过程中就Product Backlog项目的详细信息进行协作。在Product Backlog改进期间，将审查和修改项目。
+
+Scrum团队决定如何以及何时完成细化。细化通常不会超过开发团队容量的10％。但是，产品Backlog项目可以由产品负责人随时更新，也可以由产品负责人自行决定。改进的目标是为下一个Sprint的Sprint Planning提供足够的Product Backlog项目“Ready”。通常，Scrum团队将协作完善下两到三个sprint的产品积压项目。
+
+积压的出现和完善是每个Scrum团队的基本任务。产品负责人通过识别和分类产品待办事项中最有价值的用户故事来定义即将到来的冲刺的范围。虽然产品负责人负责将产品积压保持在最高价值交付，但他们需要整个Scrum团队的协助才能这样做。更改Sprint Backlog是正在进行的Sprint的一部分，不被视为精简。
+
+#### 更多信息：
+
+*   [优化产品Backlog改进](https://www.scrum.org/resources/blog/optimizing-product-backlog-refinement)
+*   Scrum指南（http://www.scrumguides.org/）

guide/chinese/agile/backlog-item-effort/index.md

@@ -0,0 +1,11 @@
+---
+title: Backlog Item Effort
+localeTitle: 积压项目努力
+---
+## 积压项目努力
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/backlog-item-effort/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/agile/behavior-driven-development/index.md

@@ -0,0 +1,60 @@
+---
+title: Behavior Driven Development
+localeTitle: 行为驱动的发展
+---
+## 行为驱动的发展
+
+行为驱动开发（BDD）是一个从中诞生的软件开发过程![测试驱动开发（TDD）](../test-driven-development/index.md) 。 行为驱动开发将TDD的一般技术和原则与域驱动设计和面向对象分析与设计的思想相结合，为软件开发和管理团队提供共享工具和共享流程，以协作进行软件开发。 它是一种软件开发方法，其中通过描述其行为应如何出现在外部观察者中来指定和设计应用程序。
+
+虽然BDD主要是关于如何通过商业利益和技术洞察来管理软件开发的想法，但BDD的做法确实假设使用专门的软件工具来支持开发过程。
+
+虽然这些工具通常专门用于BDD项目，但它们可以被视为支持测试驱动开发的工具的专用形式。这些工具用于为无处不在的语言添加自动化，这是BDD的核心主题。
+
+BDD专注于：
+
+*   从哪里开始
+*   测试什么和不测试什么
+*   一次性测试多少钱
+*   怎么称呼测试
+*   如何理解测试失败的原因
+
+BDD的核心是重新思考这些问题自然产生的单元测试和验收测试方法。 例如，BDD建议单元测试名称是以条件动词开头的整个句子（例如英语中的“should”），并且应按业务价值的顺序编写。 验收测试应该使用用户故事的标准敏捷框架编写：“作为一个_角色，_我想要_功能，_以便_获益_ ”。 接受标准应根据方案编写并作为类实现：给定_初始上下文_ ，何时_发生事件_ ，然后_确保一些结果_ 。
+
+例
+```
+Story: Returns go to stock 
+ 
+ As a store owner 
+ In order to keep track of stock 
+ I want to add items back to stock when they're returned. 
+ 
+ Scenario 1: Refunded items should be returned to stock 
+ Given that a customer previously bought a black sweater from me 
+ And I have three black sweaters in stock. 
+ When he returns the black sweater for a refund 
+ Then I should have four black sweaters in stock. 
+ 
+ Scenario 2: Replaced items should be returned to stock 
+ Given that a customer previously bought a blue garment from me 
+ And I have two blue garments in stock 
+ And three black garments in stock. 
+ When he returns the blue garment for a replacement in black 
+ Then I should have three blue garments in stock 
+ And two black garments in stock. 
+```
+
+除此之外还有一些好处：
+
+1.  所有开发工作都可以直接追溯到业务目标。
+2.  软件开发满足用户需求。满意的用户=良好的业务。
+3.  高效的优先级 - 首先提供关键业务功能。
+4.  各方对项目有共同的理解，可以参与沟通。
+5.  共享语言可确保每个人（技术与否）都能全面了解项目的进展。
+6.  产生的软件设计与现有产品相匹配，并支持即将到来的业
+7.  改进质量代码，降低维护成本，降低项目风险。
+
+## 更多信息
+
+*   Wiki上的[BDD](https://en.wikipedia.org/wiki/Behavior-driven_development)
+*   众所周知的行为驱动开发（BDD）框架是[Cucumber](https://cucumber.io/) 。 Cucumber支持许多编程语言，可以与许多框架集成;例如， [Ruby on Rails](http://rubyonrails.org/) ， [Spring Framework](http://spring.io/)和[Selenium](http://www.seleniumhq.org/)
+*   https://inviqa.com/blog/bdd-guide

guide/chinese/agile/build-measure-learn/index.md

@@ -0,0 +1,29 @@
+---
+title: Build Measure Learn
+localeTitle: 构建度量学习
+---
+## 构建度量学习
+
+Build-Measure-Learn循环是用于构建正确产品的方法。在Eric Reis撰写的“精益创业”一书中，循环实现了快速实验，其唯一目的是实现市场契合。换句话说，它是一个功能强大的系统，用于验证有关您要提供的产品的假设。分解循环，它由以下部分组成：
+
+![建设 - 测量 - 学习环](https://steveblank.files.wordpress.com/2015/05/ideas-build-code-measure.jpg)
+
+### 理念
+
+每个循环都以一个为某些用户提供商业价值的想法开始。这样的想法必须包括产品愿景 - 它将指导您构建什么，以及指出您对业务价值的假设是否正确的指标。
+
+### 建立
+
+为了验证您的想法，您打算构建一个最小可行产品（MVP），结合预定义的指标（首选一个），其目的是验证您的理论，并帮助您决定是应该保留还是转动。
+
+### 测量
+
+此阶段的重点是从MVP收集数据和指标。
+
+### 学习
+
+接下来，使用收集的数据，必须做出决定，无论您的产品是否被用户使用，因此您应该保留，或者用户是否对产品不感兴趣，因此您必须转动。因此，学习阶段以一个想法（如何扩展产品，或如何从原始产品转向）结束，适用于下一个Build Measure Learn循环。
+
+#### 更多信息：
+
+[为什么要建立，衡量，学习 - 不仅仅是把东西扔到墙上看看它们是否有效 - 最小的可行产品](https://steveblank.com/2015/05/06/build-measure-learn-throw-things-against-the-wall-and-see-if-they-work/) [构建 - 测量 - 学习反馈循环](https://www.mindtools.com/pages/article/build-measure-learn.htm)

guide/chinese/agile/burndown-charts-and-burnup-charts/index.md

@@ -0,0 +1,21 @@
+---
+title: Burndown Charts and Burnup Charts
+localeTitle: Burndown图表和Burnup图表
+---
+## Burndown图表和Burnup图表
+
+Burndown和burnup图表用于衡量项目的进度 - 通常是敏捷方法下的开发冲刺。两个图表在视觉上代表工作与时间。
+
+Burndown图表显示剩余的工作量与剩余时间相比还有多少工作要做。 Y轴表示要完成的工作 - 通常与分配给每个任务的时间估计有关，例如故事点 - 而X轴表示剩余时间。使用两条线;第一个 - “理想工作剩余线” - 代表理想的燃尽，每天完成与总时间成比例的工作量，从而形成一条直线。第二个“实际工作剩余线”用于绘制当开发进入完成状态时的实际进度。燃尽图的示例如下所示。
+
+![alt text](https://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png "图片来源：维基百科")
+
+许多Scrum团队使用燃尽图表来了解他们在冲刺期间的表现。平稳而稳定的燃尽可能表明这些故事很小且易于管理。如果一个团队在冲刺中间注意到“实际工作剩余线”高于“理想工作剩余线”，他们可以对范围进行调整：故事可以从冲刺中获取，或者故事的范围可以是做得更小在短跑结束时回顾期间观察燃尽可能会引发一些有趣的讨论并导致流程改进。
+
+Burnup图表非常相似，但它们显示已完成的工作与总工作量和剩余时间。使用三条线 - 理想线，完整的工作线和总工作线。在此图表中，总工作线应该在图表顶部稍微稳定，并且是范围变化的良好表示。完成的工作线应该稳定地向整个工作线移动一段时间 - 项目的理想轨迹由理想线显示。一个例子如下所示。
+
+![alt text](https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAljAAAAJGQ1ZDI2NzRkLWExYTQtNGI2OS1hZmZjLTM1NGMzYTk1NTEyNg.png "图片来源：Ala'a Elbeheri，LinkedIn")
+
+#### 更多信息：
+
+[Burndown图表 - 维基百科](https://en.wikipedia.org/wiki/Burn_down_chart) [烧毁vs烧毁图表 - LinkedIn](https://www.linkedin.com/pulse/burn-up-vs-down-chart-alaa-el-beheri-cisa-rmp-pmp-bcp-itil/)

guide/chinese/agile/business-value/index.md

@@ -0,0 +1,11 @@
+---
+title: Business Value
+localeTitle: 商业价值
+---
+## 商业价值
+
+商业价值是敏捷交付的重点。敏捷团队负责评估所有工作的业务价值。
+
+业务价值描述了客户将为特定工作获得的内容。
+
+通过与客户的对话和所涉及工作的分析来发现该值。业务利益相关者可能拥有量化已请求的给定功能的值的数据。产品所有者将使用各种可用信息来源，并花费大量时间来理解，评估和优先考虑客户为特定工作所获得的价值。

guide/chinese/agile/chickens-versus-pigs/index.md

@@ -0,0 +1,18 @@
+---
+title: Chickens Versus Pigs
+localeTitle: 鸡与猪
+---
+## 鸡与猪
+
+“鸡与猪”指的是关于鸡和猪的故事，鸡只建议他们开一家名为“Ham-n-Eggs”的餐馆。 猪拒绝，因为虽然鸡只需要产卵，但猪的危害更大。
+
+在敏捷软件开发项目中，软件开发人员就是猪。如果您未能完成工作，或未能做好， 你有很多危险。这可能是你的声誉，甚至可能是你的立场。其他团队成员也可能被视为猪， 取决于他们的利害关系。
+
+另一方面，许多团队成员都是鸡。例如，客户或高级项目经理不会真正受到影响 由于项目的失败。他们对它的成功感兴趣，并且可能会做出贡献，但却有较低的赌注 对项目的承诺要少得多。
+
+你应该努力成为一只猪而不是一只鸡。你可以受益于（但不应该依赖）鸡，以尽量减少风险和 保证项目尽可能高效地交付。
+
+#### 更多信息：
+
+[敏捷绝地：鸡与猪的故事](http://www.agilejedi.com/chickenandpig)  
+[维基百科：鸡与猪](https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig)

guide/chinese/agile/code-smells/index.md

@@ -0,0 +1,23 @@
+---
+title: Code Smells
+localeTitle: 代码闻起来
+---
+## 代码闻起来
+
+计算机编程中的代码气味表明您的系统和代码质量可能存在问题。此问题可能需要修复重构。
+
+重要的是要了解有臭味的代码有效，但质量不高。
+
+#### 例子
+
+1.  重复代码 - 已在代码库中复制的代码块。这可能表明您需要将代码概括为函数并在两个地方调用它，或者可能是代码在一个地方工作的方式与它在另一个地方的工作方式完全无关，尽管已被复制。
+2.  大类 - 具有太多代码行的类。这可能表明该类正在尝试做太多事情，需要分解成更小的类。
+
+#### 更多信息：
+
+*   _重构：改进现有代码的设计 - Kent Beck，Martin Fowler_
+*   _清洁代码：敏捷软件工艺手册 - Martin，Robert C.（2009）。_
+*   [维基百科上的代码闻起来](https://en.wikipedia.org/wiki/Code_smell)
+*   [代码闻到杰夫阿特伍德的博客（编码恐怖）](https://blog.codinghorror.com/code-smells/)
+*   [代码闻到了Ward Cunningham的C2 Wiki](http://wiki.c2.com/?CodeSmell)
+*   [Martin Fowler - 代码气味](https://martinfowler.com/bliki/CodeSmell.html)

guide/chinese/agile/colocation-vs-distributed/index.md

@@ -0,0 +1,10 @@
+---
+title: Collocation Vs Distributed
+localeTitle: 搭配与分布式
+---
+## 搭配与分布式
+
+*   同位置是指坐在一起的团队;同一个办公室理想情况下，每个人都坐在相邻的办公室或开放式工作区。
+*   分布式团队成员分散在地理位置;不同的建筑，城市，甚至国家。 对于分布式团队，基础设施应该促进流程，以便解决团队成员之间的时差和距离，从而提供一种有效的工作方式。
+
+#### 更多信息：

guide/chinese/agile/continuous-delivery/index.md

@@ -0,0 +1,9 @@
+---
+title: Continuous Delivery
+localeTitle: 持续交付
+---
+## 持续交付
+
+持续交付（CD）是一种软件工程方法，其中团队在短周期内生成软件，确保软件可以随时可靠地发布。 [1](https://en.wikipedia.org/wiki/Extreme_programming)
+
+它旨在更快，更频繁地构建，测试和发布软件。该方法允许对生产中的应用程序进行更多增量更新，从而有助于降低成本，时间和交付变更的风险。简单且可重复的部署过程对于持续交付非常重要。持续交付意味着团队确保每个变更都可以部署到生产中，但可能会选择不这样做，通常是出于商业原因

guide/chinese/agile/continuous-deployment/index.md

@@ -0,0 +1,13 @@
+---
+title: Continuous Deployment
+localeTitle: 持续部署
+---
+## 持续部署
+
+持续部署是一种现代软件工程过程，被认为是DevOps环境的一部分。它涉及开发人员团队在很短的周期内生成，更新和发布代码。这意味着开发人员会更频繁地提交更少量的代码。
+
+持续部署的目标是使代码处于持续可靠和可部署的状态，以便随时释放此代码。此过程旨在更快地发布代码。为了实现持续部署，开发团队依赖于基础架构，该基础架构可自动化并处理导致部署的各个步骤。这通常被称为基础设施代码（IaC）。
+
+持续部署的两个主要好处包括每个功能开发后的早期投资回报，因为较低的发布时间以及早期的新功能反馈。
+
+持续部署的其他好处包括提高代码质量，因为生产的错误更少，更可靠的代码发布以及更短的上市时间。

guide/chinese/agile/continuous-integration/index.md

@@ -0,0 +1,60 @@
+---
+title: Continuous Integration
+localeTitle: 持续集成
+---
+## 持续集成
+
+在最基本的情况下，持续集成（CI）是一种敏捷开发方法，开发人员定期将代码直接合并到主源，通常是远程`master`分支。为了确保不引入重大更改，在每个可能的构建上运行完整的测试套件以对新代码进行回归测试，即测试新代码不会破坏现有的工作特性。
+
+这种方法需要对代码库进行良好的测试覆盖，这意味着大多数（如果不是全部）代码都具有确保其功能完全正常运行的测试。理想情况下，持续集成将与完整的[测试驱动开发一起实施](https://guide.freecodecamp.org/agile/test-driven-development) 。
+
+### 主要步骤
+
+以下基本步骤是实现最标准的当前持续集成方法所必需的。
+
+1.  维护一个中央回购和一个活跃的`master`分支。
+
+必须有一个代码存储库，供每个人合并并从中提取变更。这可以在Github上或任意数量的代码存储服务上。
+
+2.  自动化构建。
+
+使用NPM脚本或更复杂的构建工具（如Yarn，Grunt，Webpack或[Gulp）](https://guide.freecodecamp.org/developer-tools/gulp) ，可以自动构建，以便单个命令可以构建产品的完整功能版本，随时可以在生产环境中部署。更好的是，将部署作为自动构建的一部分！
+
+3.  使构建运行所有测试。
+
+为了检查新代码中是否有任何内容破坏了现有功能，需要运行完整的测试套件，如果其中的任何测试失败，则构建需要失败。
+
+4.  每个人都必须每天将变更合并到`master` 。
+    
+5.  必须构建并完全测试每个合并到`master` 。
+    
+
+### 最佳实践
+
+还有一些最佳实践可以充分利用CI提供的内容及其带来的挑战，例如：
+
+1.  保持快速构建，这样就不会浪费大量的开发人员时间来等待构建。
+    
+2.  在生产环境的完整克隆中测试构建。
+    
+
+例如，如果您有一个部署在Heroku或Digital Ocean之类的应用程序，那么您可以在那里部署测试版本，以确保它们不仅可以在测试中工作，而且可以在真实的生产环境中工作。此测试环境应在功能上与实际生产环境相同，以确保测试准确。
+
+3.  让您轻松保持最新状态。
+
+编码员应定期从`master`分支中提取，以便将代码与其团队的更改集成在一起。回购也应该提供给产品经理，公司高管或有时是关键客户等利益相关者，以便每个人都能轻松地看到进展。
+
+4.  保留构建记录，以便每个人都可以看到任何给定构建的结果，无论是成功还是失败，以及引入新更改的人员或内容。
+    
+5.  自动部署。
+    
+
+在所有测试通过并且生产环境克隆中的测试部署成功后，通过在生产环境中自动部署作为构建过程的最后阶段，使您的应用程序与任何新更改保持最新。
+
+### CI服务
+
+存在大量服务来处理持续集成的过程，这使得建立可靠的CI管道或构建过程变得更加容易。在评估这些时，请考虑预算，构建速度以及您正在处理的项目类型等因素。一些服务，如[Travis CI](https://travis-ci.org)为开源项目提供免费服务，这可以使它们成为像这样的项目的简单选择，但它们可能比其他服务（如[Circle CI](https://circleci.com/)或[Codeship）的](https://codeship.com/)构建速度慢，仅举几例。
+
+#### 更多信息：
+
+关于[持续集成](https://en.wikipedia.org/wiki/Continuous_integration)的维基百科条目。

guide/chinese/agile/cross-functional-teams/index.md

@@ -0,0 +1,44 @@
+---
+title: Cross Functional Teams
+localeTitle: 跨职能团队
+---
+## 跨职能团队
+
+跨职能团队是一群具有不同职能专长的人，致力于实现共同目标。
+
+通常，它包括来自组织各级的员工。成员也可能来自组织外部（特别是来自供应商，主要客户或顾问）。跨职能团队通常作为分配到特定任务的自我指导团队，需要众多部门的投入和专业知识。
+
+将任务分配给由多学科个人组成的团队可以提高创造力和开箱即用的思维水平。
+
+每个成员都提供了对问题的替代视角以及对任务的潜在解决方案。在当今的业务中，创新是领先的竞争优势，跨职能团队通过创造性的协作流程促进创新。跨职能团队的成员必须精通多任务，因为他们同时负责他们的跨职能团队职责以及正常的日常工作任务。
+
+### 共同的目标
+
+*   对团队更好，对个人更好
+    
+*   改善协调和整合
+    
+*   跨越组织边界的工作
+    
+*   通过提高生产力来提高团队效率
+    
+*   通过为同一目标努力实现客户满意度
+    
+
+一些研究人员认为跨职能互动本质上是合作的或竞争性的，而其他人则认为组织的职能领域往往被迫彼此竞争和合作（“合作”），理解这些复杂关系如何相互作用至关重要。并影响公司业绩。
+
+### 跨职能团队技能组合
+
+组成跨职能团队的一个共同挑战是，团队中的每个技术成员都必须具备完成任何工作所需的所有技术技能。它有助于团队成员执行多项技术技能，但仍然可以聘请专家。当并非所有团队成员都是专家时，这是最好的。
+
+#### 更多信息：
+
+*   [17证明从一个跨职能团队中受益的方式](https://www.scoro.com/blog/improve-cross-team-collaboration/)
+    
+*   [使用跨职能团队的11个理由](https://blog.kainexus.com/employee-engagement/cross-functional-collaboration/cross-functional-teams/11-reasons)
+    
+*   [跨职能Scrum团队](https://www.scrumalliance.org/community/articles/2014/june/success-story-cross-functional-scrum-teams)
+    
+*   [交叉功能并不意味着每个人都可以做到一切](https://www.mountaingoatsoftware.com/blog/cross-functional-doesnt-mean-everyone-can-do-everything)
+    
+*   [跨职能团队](https://dzone.com/articles/cross-functional-scrum-teams)

guide/chinese/agile/crystal/index.md

@@ -0,0 +1,28 @@
+---
+title: Crystal
+localeTitle: 水晶
+---
+## 水晶
+
+它是一种方法，是一种非常适应性强，轻量级的软件开发方法。它是一系列敏捷方法，包括Crystal Clear，Crystal Yellow，Crystal Orange等。其中哪一个具有由许多因素驱动的独特属性，例如团队的规模，系统的重要程度以及项目的优先级。其中指出每个项目可能需要根据项目的独特特征制定不同的实践，规则和流程。 它们都是由Alistair Cockburn在20世纪90年代开发的。
+
+据他说，水晶的面孔被定义为方法论，技术和政策
+
+方法论 - 作为项目一部分的要素 技术 - 技能领域 政策 - 组织做和不做
+
+这些方法的重点是：
+
+1.  人
+2.  相互作用
+3.  社区
+4.  技能
+5.  人才
+6.  通讯
+
+！\[不同颜色\] https://upload.wikimedia.org/wikiversity/en/c/c5/Crystal _Family_ example.jpg
+
+移动世界需要不同的笔画，根据Crystal的说法，移动项目需要不同的颜色。
+
+#### 更多信息：
+
+\[Wikiversity Article\] https://en.wikiversity.org/wiki/Crystal\_Methods

guide/chinese/agile/customer-units/index.md

@@ -0,0 +1,15 @@
+---
+title: Customer Units
+localeTitle: 客户单位
+---
+## 客户单位
+
+在敏捷中，客户单位是代表语音的人和角色，是产品所针对的客户/市场的期望。
+
+负责用户体验产品的客户单位，产品愿景，产品路线图，创建和维护产品积压等等。
+
+示例人/角色： - >产品经理 - >销售 - >市场营销 - >最终用户
+
+#### 更多信息：
+
+客户单位： [解决方案](https://www.solutionsiq.com/agile-glossary/customer-unit/)

guide/chinese/agile/daily-standup-and-daily-scrum/index.md

@@ -0,0 +1,27 @@
+---
+title: Daily Stand-Up and Daily Scrum
+localeTitle: 每日站立和每日Scrum
+---
+## 每日站立和每日Scrum
+
+每日站立（DSU）或每日Scrum会议是Scrum方法的组成部分之一。
+
+顾名思义，您每天都会同时召开会议，并且对于位于同一地点的团队，您也可以在同一地点召开会议。会议应简短，不到15分钟即可完成。
+
+只有开发团队的成员才能参加每日站立。通常，Scrum Master和产品所有者也将参加，但不是必需的。
+
+每个人的标准议程是：
+
+*   自上次DSU以来你做了什么
+*   在这个DSU之后你在做什么
+*   阻碍您取得进步的主要障碍是什么？您需要哪些帮助
+
+团队成员应仔细聆听彼此的贡献，并尝试确定他们可以协助彼此进步的领域。站立会议还将展示需要在团队的不同成员之间进行的更长时间的讨论主题。然后应该暂停这些较长时间的讨论，并将其置于站立之外，仅涉及相关参与者，而不是整个团队。
+
+### 站立会议的例子
+
+https://www.youtube.com/watch?v=\_3VIC8u1UV8
+
+### 更多信息：
+
+站立会议： [维基百科](https://en.wikipedia.org/wiki/Stand-up_meeting)

guide/chinese/agile/delivery-team/index.md

@@ -0,0 +1,17 @@
+---
+title: Delivery Team
+localeTitle: 交付团队
+---
+## 交付团队
+
+Scrum团队由产品负责人（PO），Scrum Master（SM）和交付团队组成。
+
+交付团队是除了PO和SM之外的所有人;开发人员，测试人员，系统分析员，数据库分析师，UI / UX分析师等。
+
+为了使Scrum交付团队有效，它应该足够灵活（或敏捷！），以便快速达成一致的决策，同时具有足够的多样性，以便整个团队可以覆盖软件开发所需的绝大多数特定项目。理想情况下，一个3到9人之间的团队通常适合scrum开发团队。
+
+团队还必须通过团队的每个成员促进相互尊重。一个有效的Scrum团队将能够分担工作量，并将团队的成就放在个人成就之前。
+
+#### 更多信息：
+
+Atlassian关于Scrum的入门文章[。](https://www.atlassian.com/agile/scrum)

guide/chinese/agile/design-patterns/index.md

@@ -0,0 +1,31 @@
+---
+title: Design Patterns
+localeTitle: 设计模式
+---
+## 设计模式
+
+设计模式是解决常见设计问题的常见设计方案。相关字段或域的设计模式集合称为模式语言。请注意，其他级别也有模式：代码，并发，体系结构，交互设计......
+
+在软件工程中，软件设计模式是软件设计中给定上下文中常见问题的通用可重用解决方案。它不是可以直接转换为源代码或机器代码的完成设计。它是如何解决可在许多不同情况下使用的问题的描述或模板。设计模式是形式化的最佳实践，程序员可以在设计应用程序或系统时使用它来解决常见问题。
+
+面向对象的设计模式通常显示类或对象之间的关系和交互，而不指定所涉及的最终应用程序类或对象。暗示可变状态的模式可能不适合函数式编程语言，某些模式可能在内置支持解决他们试图解决的问题的语言中变得不必要，而面向对象的模式不一定适合非对象面向语言。
+
+设计模式可以被视为计算机编程的结构化方法，介于编程范例和具体算法之间。
+
+推广该领域的书是Gang of Four（GoF） **设计模式：可重用面向对象软件的元素** （1994）。它呈现了一系列（23）模式的传统（C ++）OO语言分为三种类型：
+
+*   **Creational** （创建对象）：抽象工厂，构建器，工厂方法，原型，单例。
+*   **结构** （组成对象）：适配器，桥，复合，装饰，立面，flyweight，代理。
+*   **行为** （在对象之间进行通信）：责任链，命令，解释器，迭代器，中介，备忘录，观察者，状态，策略，模板方法，访客。
+
+模式可用于多个目标（学习，沟通，改进工具），但在敏捷中，它们应该从具有技术债务的代码重构而不仅仅是在开始时添加（紧急设计/架构），因为最初您没有足够的知识关于即将发展的（未来）系统。请注意，可能不需要或者已经成为另一种语言或工具的一部分，需要语言或工具中的模式。框架是一组协作类，它们构成了特定类型软件的可重用设计，并且通常是模式繁重的。
+
+#### 更多信息：
+
+*   [维基百科的设计模式](https://en.wikipedia.org/wiki/Software_design_pattern)
+*   [关于GoF书的维基百科](https://en.wikipedia.org/wiki/Design_Patterns)
+*   [源制作设计模式](https://sourcemaking.com/design_patterns) ：在线提供的众所周知的模式列表
+*   [游戏编程模式](http://gameprogrammingpatterns.com/) ：关于游戏开发中常用的设计模式的书，可在线免费阅读
+*   [面向对象设计](http://www.oodesign.com/)
+*   [初学者设计模式指南](https://code.tutsplus.com/articles/a-beginners-guide-to-design-patterns--net-12752)
+*   [从设计模式到类别理论](http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory/)

guide/chinese/agile/dsdm/index.md

@@ -0,0 +1,22 @@
+---
+title: DSDM
+localeTitle: DSDM
+---
+## DSDM
+
+DSDM代表动态系统开发方法。它是一种敏捷快速开发方法，旨在解决开发信息系统所需时间的持续问题。 DSDM更像是一个框架，而不是一个定义明确的方法，而实际应该如何完成的大部分细节都由软件开发组织或个人来决定。 DSDM采用增量方法，并使用RAD（快速应用程序开发）时间盒概念。它还强调了人们在开发过程中的关键作用，并被描述为以用户为中心的方法。
+
+DSDM有9个核心原则，如下：
+
+1）积极的用户参与是必不可少的。 2）必须赋予团队决策权。赋权的四个关键变量是：权力，资源，信息和问责制。 3）频繁交付产品至关重要。 4）适合商业目的是接受可交付成果的基本标准。 5）迭代和增量开发对于汇聚准确的业务解决方案是必要的。 6）开发过程中的所有更改都是可逆的（即如果遇到问题，您不会沿着特定路径继续前进;您回溯到最后一个安全或约定点，然后开始新路径）。 7）要求基于高级别（即一旦达成一致，高级业务要求被冻结）。这基本上是项目的范围。 8）测试在整个生命周期中都是集成的（即在您进行测试时，而不是仅在经常被挤压的末端进行测试）。 9）所有利益相关者之间的协作和合作方法至关重要。
+
+DSDM开发周期的5个主要阶段是：
+
+1）可行性研究。 2）商业研究。 3）功能模型迭代。 4）系统设计和构建迭代。 5）实施。
+
+#### 更多信息：
+
+您可以阅读以下链接以了解更多信息。
+
+*   [敏捷业务 - 什么是DSDM？](https://www.agilebusiness.org/what-is-dsdm)
+*   [维基百科 - 动态系统开发方法](https://en.wikipedia.org/wiki/Dynamic_systems_development_method)

guide/chinese/agile/epics/index.md

@@ -0,0 +1,17 @@
+---
+title: Epics
+localeTitle: 史诗
+---
+## 史诗
+
+史诗是一个庞大的用户故事，无法在单个迭代中按定义传递，或者足够大，可以分成较小的用户故事。 Epics通常涵盖特定的角色，并全面了解对用户重要的内容。史诗可以进一步细分为各种用户故事，其显示角色/用户想要执行的各个任务。
+
+没有标准形式来代表史诗。有些团队使用熟悉的用户故事格式（作为A，我想要，所以或按顺序，作为A，我想要），而其他团队用短语代表史诗。
+
+*   虽然构成史诗的故事可以独立完成，但直到整个史诗完成才能实现其商业价值
+
+### 史诗般的例子
+
+在一个应用程序帮助自由职业画家跟踪他们的项目，一个可能的史诗可能是。
+
+Paul the Painter想要一种更简单的方法来管理他的项目，并为他的客户提供准确的更改并向他们开账单。

guide/chinese/agile/extreme-programming/index.md

@@ -0,0 +1,15 @@
+---
+title: Extreme Programming
+localeTitle: 极限编程
+---
+## 极限编程
+
+极限编程（XP）是一种软件开发方法，旨在提高软件质量和响应不断变化的客户需求。 [1](https://en.wikipedia.org/wiki/Extreme_programming)
+
+XP的基本优势是整个过程是可见的和负责任的。开发人员将对他们将要完成的工作做出具体承诺，以可部署软件的形式展示具体进展，当达到里程碑时，他们将准确描述他们做了什么，以及与计划有何不同之处。这使得以业务为导向的人能够自信地做出自己的业务承诺，充分利用机会，并快速，廉价地消除死胡同。 [2](http://wiki.c2.com/?ExtremeProgramming) - 肯特贝克
+
+[![XP-反馈](https://upload.wikimedia.org/wikipedia/commons/4/44/XP-feedback.gif)](https://commons.wikimedia.org/wiki/File%3AXP-feedback.gif "由DonWells（自己的工作）[CC BY 3.0（http://creativecommons.org/licenses/by/3.0）]，通过Wikimedia Commons")
+
+#### 更多信息：
+
+[极限编程规则](http://www.extremeprogramming.org/rules.html)

guide/chinese/agile/feature-based-planning/index.md

@@ -0,0 +1,13 @@
+---
+title: Feature Based Planning
+localeTitle: 基于特征的规划
+---
+## 基于特征的规划
+
+**基于特征的计划**是一种计划方法，可用于根据将提供给客户的功能来决定何时发布软件，而不是基于任意期限的发布。
+
+在这种发布计划方法中，团队决定应优先考虑哪些功能/特性。根据这些功能的范围，团队可以预测何时可以部署下一个版本。
+
+#### 更多信息：
+
+[功能驱动的开发](https://en.wikipedia.org/wiki/Feature-driven_development)

guide/chinese/agile/five-levels-of-agile-planning/index.md

@@ -0,0 +1,32 @@
+---
+title: Five Levels of Agile Planning
+localeTitle: 敏捷计划的五个层次
+---
+## 敏捷计划的五个层次
+
+产品所有者需要熟悉敏捷规划的五个级别：
+
+*   定义产品愿景
+*   定义产品路线图
+*   发布计划
+*   Sprint计划
+*   考虑每日scrums的结果
+
+敏捷计划始终是连续的，应至少每三个月进行一次修订。
+
+## 敏捷策划五个层次简要概述
+
+1.  产品愿景：什么（产品将提供的主要优势和特征摘要），谁（利益相关者），为什么（需要和机会），何时（项目安排和时间预期），约束和假设（影响风险和成本）。
+    
+2.  产品路线图：发布 - 日期，主题/功能集，目标，开发方法。
+    
+3.  发布计划：迭代，团队容量，故事，优先级，大小，估计，完成的定义。
+    
+4.  Sprint计划：故事 - 任务，完成的定义，努力程度，承诺
+    
+5.  每日计划：我昨天做了什么？我今天要做什么？是什么阻止了我？
+    
+
+#### 更多信息：
+
+[敏捷计划的五个层次](https://www.scrumalliance.org/why-scrum/agile-atlas/agile-atlas-common-practices/planning/january-2014/five-levels-of-agile-planning)

guide/chinese/agile/functional-managers/index.md

@@ -0,0 +1,12 @@
+---
+title: Functional Managers
+localeTitle: 职能经理
+---
+## 职能经理
+
+职能经理是对一群人具有管理权限的人。该权限来自该人员在组织中的正式职位（例如，部门主管，质量部门经理，开发团队经理）。职能经理的角色与项目经理或ScrumMaster不同，而不是基于项目。  
+在更敏捷的组织中，存在不同的模型。职能经理通常负责培养他们团队中的人员，确保人员的预算和时间。 然而，也有一些敏捷公司模型，其中通常分配给职能经理的职能分配给组织内的其他角色（例如，具有部落，公会，章节，小队的Spotify模型）。
+
+在传统的工作世界中，公司将人们组织成一个等级制度。具有类似工作角色的人员被分为功能区域，并由职能经理领导。职能经理通常负责直接向她报告的员工的指导和福祉。
+
+敏捷项目团队通常会与职能经理合作，他们负责控制团队完成工作所需的资源。一个例子是与采购中的职能经理合作，指派一个人与团队一起工作以获得软件许可。

guide/chinese/agile/index.md

@@ -0,0 +1,19 @@
+---
+title: Agile
+localeTitle: 敏捷
+---
+## 敏捷
+
+敏捷软件开发是用于管理开发团队的方法集合。它倡导适应性规划，演化发展，早期交付和持续改进，并鼓励对变化做出快速灵活的反应。人们和沟通被认为比工具和流程更重要。
+
+敏捷强调向最终用户询问他们想要什么，并经常向他们展示产品开发时的演示。这与“瀑布式”方法，规范驱动的开发以及敏捷实践者所称的“大型前端设计”形成鲜明对比。在这些方法中，功能在开发之前计划出来并编入预算。
+
+对于敏捷，重点是“敏捷性” - 能够快速响应用户的反馈和其他不断变化的环境。
+
+![来自Commitstrip.com的漫画，展示产品经理向开发人员解释他们正在转向敏捷，但随后要求开发人员预先计划一切](https://www.commitstrip.com/wp-content/uploads/2017/01/Strip-Budegt-fixe-pour-projet-flexible-english650-final.jpg)
+
+敏捷有许多不同的风格，包括Scrum和极限编程。
+
+### 更多信息
+
+[敏捷联盟的主页](https://www.agilealliance.org/)

guide/chinese/agile/integration-hell/index.md

@@ -0,0 +1,22 @@
+---
+title: Integration Hell
+localeTitle: 整合地狱
+---
+## 整合地狱
+
+Integration Hell是一个俚语，当开发团队的所有成员都经过随机时间实现代码的过程时，无法将不同的代码片段合并到一个无缝的代码中。开发团队将不得不花费几个小时或几天来测试和调整代码，以使其全部工作。
+
+实际上，较长的组件是孤立开发的，界面越容易偏离预期。当组件最终在项目结束时集成时，它将花费更多的时间而不是分配，通常会导致最后期限压力和难以集成。在项目结束时这种痛苦的整合工作是同名的地狱。
+
+持续集成，开发团队应该使用特定工具来“持续集成”他们每天多次处理的代码部分，以便工具可以将不同的“代码块”匹配在一起，以便更加无缝地集成比以前。
+
+代码存储库，像Git（它是我们都知道和喜欢的开源接口，GitHub）允许开发团队组织他们的工作，这样可以花更多的时间来编码，而不用担心代码的不同部分是否全部集成。
+
+[持续集成](https://guide.freecodecamp.org/agile/continuous-integration/)是解决这一问题的敏捷解决方案。集成仍然很痛苦，但至少每天这样做会使接口不会过分分散。
+
+#### 更多信息：
+
+*   [避免整合地狱](https://tobeagile.com/2017/03/08/avoiding-integration-hell/)
+*   [整合地狱](http://wiki.c2.com/?IntegrationHell)
+*   [通过持续集成避免“整合地狱”的五大提示](https://www.apicasystems.com/blog/top-5-tips-avoid-integration-hell-continuous-integration/)
+*   [D-Zone关于Integration Hell的文章以及Continous Integration如何帮助它几乎成为过去](https://dzone.com/articles/continuous-integration-how-0)

guide/chinese/agile/invest/index.md

@@ -0,0 +1,27 @@
+---
+title: INVEST
+localeTitle: 投资
+---
+## 投资
+
+**我** | **独立** ----- | -----  
+**N** | **面议** **V** | **有价值** **E** | **难能可贵** **S** | **小** **T** | **可测试**
+
+当您在积压中精炼和调整用户故事时，INVEST助记符可以帮助您确定它们是否已准备就绪
+
+*   独立
+*   故事尽可能与其他故事截然不同。避免“一层二层”。
+*   面议
+*   作为产品负责人和交付团队在整理期间对话的一部分，可以讨论，改进和改进故事的详细信息。验收标准可以根据客户需求和技术能力的波动和流量进行调整。
+*   有价值
+*   对客户有价值。通过实施故事赚取的钱，节省的时间，获得的效率，停止损失等。
+*   估
+*   在梳理期间，故事的描述和对话已经解决了交付团队的足够问题，他们可以自信而舒适地调整故事大小。
+*   小
+*   您可以在既定迭代中完成故事。
+*   可测试
+*   故事包括您将用于确认代码满足客户需求的验收标准。
+
+#### 更多信息：
+
+[谷歌很多](https://www.google.com/search?q=agile+invest+negotiable&ie=utf-8&oe=utf-8)

guide/chinese/agile/kano-analysis/index.md

@@ -0,0 +1,11 @@
+---
+title: Kano Analysis
+localeTitle: 卡诺分析
+---
+## 卡诺分析
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/kano-analysis/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/agile/lean-software-development/index.md

@@ -0,0 +1,38 @@
+---
+title: Lean Software Development
+localeTitle: 精益软件开发
+---
+## 精益软件开发
+
+### 介绍
+
+精益软件开发是构建软件的过程，重点是使用最小化额外工作和浪费精力的技术。这些技术借鉴了精益制造运动，并应用于软件开发的背景。
+
+### 关键概念
+
+该方法有七个原则，包括：
+
+1.  消除浪费
+2.  扩大学习
+3.  尽可能晚地决定
+4.  尽可能快地交付
+5.  赋予团队权力
+6.  建立诚信
+7.  看到整体
+
+### 隐喻
+
+编程行为被视为装配线，其中每个功能或错误修复称为“更改请求”。然后，该“更改请求”的组装线可以被视为“价值流”，其目标是最小化每个“变更请求”在交付之前在线上的时间。
+
+尚未交付的软件被视为“库存”，因为它尚未为公司或客户提供价值。这包括部分完成的任何软件。因此，为了最大化吞吐量，提供许多小型的完整工作软件非常重要。
+
+为了最大限度地减少“库存”，重要的是将控制权交给作为软件开发人员的“工人”，因为他们最适合创建自动化流程以“错误地证明”装配线的各个部分。
+
+### 参考
+
+关于精益技术的书面文档的最初来源是精益软件开发，Mary和Tom Poppendieck的敏捷工具包。
+
+作者的其他书籍包括：
+
+*   实施精益软件开发：从概念到现金Mary Poppendieck
+*   领先的精益软件开发：结果不是Mary Poppendieck的观点

guide/chinese/agile/meta-scrum/index.md

@@ -0,0 +1,11 @@
+---
+title: Meta Scrum
+localeTitle: Scrum的元
+---
+## 元Scrum
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/meta-scrum/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/agile/minimum-marketable-features/index.md

@@ -0,0 +1,25 @@
+---
+title: Minimum Marketable Features
+localeTitle: 最低市场特征
+---
+## 最低市场特征
+
+最小可销售特征（MMF）是一种独立的功能，可以快速开发并为用户提供重要价值。
+
+**需要注意的是：**最小可销售特征与最小可行产品（MVP）不同。它们是不同的概念。但是，两者对于支持开发人员应该努力实现最小功能以实现任何给定结果的想法至关重要。
+
+将MMF分解为其核心组件：
+
+**最小** - 绝对最小的功能集。这对于快速将任何特定功能推向市场至关重要
+
+**适销对路** - 向最终用户或组织销售该功能具有重要价值
+
+**功能** - 最终用户获得的值。它给了我什么？品牌认知度？更多收入？帮助削减成本？它能给我带来竞争优势吗？
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：
+
+### 来源
+
+1. [https://www.agilealliance.org/glossary/mmf/访问时间：2017年10月25日](https://www.agilealliance.org/glossary/mmf/) 2. [https://www.prokarma.com/blog/2015/10/23/minimum-marketable-features-agile-essential访问时间：2017年10月25日](https://www.prokarma.com/blog/2015/10/23/minimum-marketable-features-agile-essential)

guide/chinese/agile/minimum-viable-product/index.md

@@ -0,0 +1,15 @@
+---
+title: Minimum Viable Product
+localeTitle: 最小可行产品
+---
+## 最小可行产品
+
+我们的想法是快速构建一组最小的功能，这些功能足以部署产品并测试关于客户与产品交互的关键假设。
+
+#### 最小可行产品有三个主要特征：
+
+*   它具有足够的价值，人们愿意使用它或最初购买它。
+*   它表明了保留早期采用者的未来收益。
+*   它提供了一个反馈循环来指导未来的发展。
+
+了解有关MVP的更多信息： [什么是mvp？](https://youtu.be/MHJn_SubN4E)

guide/chinese/agile/moscow/index.md

@@ -0,0 +1,50 @@
+---
+title: Moscow
+localeTitle: 莫斯科
+---
+## 莫斯科
+
+## MoSCoW方法
+
+这个词的意思之一是MoSCoW方法 - 一种用于管理，业务分析，项目管理和软件开发的优先级技术，以便与利益相关者就每个需求的交付重要性达成共识 - 也称为MoSCoW优先级划分或MoSCoW分析。
+
+## 确定MoSCoW要求的优先顺序
+
+所有要求都很重要，但它们优先考虑尽早提供最大和最直接的商业利益。开发人员最初会尝试提供所有必需品，应该具有和可能有要求，但如果交货时间表看起来受到威胁，那么应该和可能的要求将是第一个被删除的要求。
+
+与高，中，低等替代方案相比，优先级类别的简单英语含义对于让客户更好地理解设置优先级的影响具有价值。
+
+这些类别通常被理解为：
+
+## 一定有
+```
+Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure. MUST can also be considered an acronym for the Minimum Usable SubseT. 
+```
+
+## 应该有
+```
+Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox. 
+```
+
+## 可以
+```
+Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit. 
+```
+
+## 不会
+```
+Requirements labeled as Won't have have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won't have requirements are not planned into the schedule for the next delivery timebox. Won't have requirements are either dropped or reconsidered for inclusion in a later timebox. 
+```
+
+MoSCoW是一种粗粒度方法，用于对产品Backlog项目（或需求，用例，用户故事......取决于所使用的方法）进行优先级排序（分类）。 MoSCoW经常与时间盒一起使用，其中最后期限是固定的，因此重点必须放在最重要的要求上。 术语MoSCoW本身是源自四个优先级类别（必须具有，应具有，可能具有和将不具有）的第一个字母的首字母缩略词：
+
+*   **必须** ：对当前交货时间箱至关重要，以使其成功。它通常是MVP（最小可行产品）的一部分。
+*   **应该具有** ：重要但不必在当前交货时间箱中交货。
+*   **可能有** ：理想但不是必要的改进。
+*   **不会** ：最不重要，回报最低的项目，或者此时不合适。
+
+通过以这种方式确定优先顺序，可以达到项目的共同定义，并相应地设定利益相关者的期望。请注意，MoSCoW对于如何区分项目的类别以及何时完成某些操作（如果不是在此时间框中）有点松懈。
+
+#### 更多信息：
+
+[维基百科](https://en.wikipedia.org/wiki/MoSCoW_method)

guide/chinese/agile/nonfunctional-requirements/index.md

@@ -0,0 +1,26 @@
+---
+title: Nonfunctional Requirements
+localeTitle: 非功能性要求
+---
+## 非功能性要求
+
+非功能性需求（NFR）是指定可用于判断系统操作的标准的要求，而不是特定行为（功能要求）。非功能性需求通常被称为“质量属性”，“约束”或“非行为要求”。
+
+非正式地，这些有时被称为“能力”，来自稳定性和可移植性等属性。 NFR可分为两大类：
+
+*   **执行质量** ，例如安全性，安全性和可用性，可在操作期间（运行时）观察到。
+*   **进化质量** ，例如可测试性，可维护性，可扩展性和可扩展性，它们体现在系统的静态结构中
+
+通常，您可以将非功能性需求细化为一组功能需求，作为详细说明和允许（部分）测试和验证的方法。
+
+### 例子：
+
+*   按下按钮后，打印机应打印5秒钟
+*   代码应该用Java编写
+*   用户界面应易于导航
+
+#### 更多信息：
+
+*   [维基百科文章](https://en.wikipedia.org/wiki/Non-functional_requirement)
+*   [ReQtest](http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/)解释功能和非功能需求之间的差异
+*   [Scaled Agile](http://www.scaledagileframework.com/nonfunctional-requirements/)通过从发现到测试非功能性需求的过程来工作

guide/chinese/agile/osmotic-communications/index.md

@@ -0,0 +1,12 @@
+---
+title: Osmotic Communications
+localeTitle: 渗透通讯
+---
+## 渗透通讯
+
+**渗透通信**是成功实施敏捷项目的重要因素之一。
+
+在敏捷项目中，团队成员通常在同一地点，一些团队成员之间的任何讨论都将流向其他团队成员。然后，他们可以获取相关信息，并在必要时加入讨论。
+
+#### 更多信息：
+

guide/chinese/agile/pair-programming/index.md

@@ -0,0 +1,12 @@
+---
+title: Pair Programming
+localeTitle: 配对编程
+---
+## 配对编程
+
+极限编程（XP）建议所有生产代码由两个程序员在同一台计算机上同时工作，然后轮流使用键盘。一些学术研究表明，结对编程可以减少错误并提高可维护性。结对编程还可以帮助在团队中传播知识，从而有助于提高[公交因素，](http://deviq.com/bus-factor/)并有助于促进[集体代码所有权](http://deviq.com/collective-code-ownership/) 。
+
+#### 更多信息：
+
+*   [配对编程基础（培训课程）](http://bit.ly/PS-PairProgramming)
+*   [敏捷软件编程最佳实践](https://www.versionone.com/agile-101/agile-software-programming-best-practices/pair-programming/)

guide/chinese/agile/parallel-development/index.md

@@ -0,0 +1,11 @@
+---
+title: Parallel Development
+localeTitle: 并行开发
+---
+## 并行开发
+
+Parallel Development代表开发过程分为多个分支，提供具有稳定版本和新功能的多功能产品。在更常见的简单软件开发过程中，您只有一个分支包含错误修复和改进，以及新功能。在并行开发中，多个分支可以共存。
+
+通常，并行开发包含一个主“master”分支，它是最稳定的，包含对现有代码的重要修复。从主分支创建更多分支以向现有代码添加新的“路径”。这些分支提供了新功能，但不包括从主分支同时应用的修复程序。客户了解这些版本并使用特殊设备或测试机器来测试新功能。当QA测试通过时，可以将side branch与主分支合并，以向发布版本引入新功能。
+
+#### 更多信息：

guide/chinese/agile/pirate-metrics/index.md

@@ -0,0 +1,19 @@
+---
+title: Pirate Metrics
+localeTitle: 盗版指标
+---
+## 盗版指标
+
+Dave McClure确定了五个对创业公司成功至关重要的高级指标类别： 获取，激活，保留，收入，转介。
+
+他从这五个指标类别（AARRR）的首字母缩写词中创造了“Pirate Metrics”一词。
+
+在他们的书“精益分析”中，Croll和Yoskovitz将这些指标直观地解释为漏斗： ![精益分析图5.1](https://github.com/yunChigewan/storage/blob/master/figure_5_1.jpg?raw=true) 精益分析，2013年
+
+并以更尖锐的解释作为表格： ![精益分析表5.1](https://github.com/yunChigewan/storage/blob/master/table_5_1.jpg?raw=true) 精益分析，2013年
+
+#### 更多信息：
+
+*   原始海盗指标幻灯片（McClure）https://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version
+*   精益分析书籍网站http://leananalyticsbook.com/
+*   Notion在他们的[网站](http://usenotion.com/aarrrt/)上有一个非常好的海盗度量指南（包括团队措施）

guide/chinese/agile/planning-poker/index.md

@@ -0,0 +1,39 @@
+---
+title: Planning Poker
+localeTitle: 计划扑克
+---
+## 计划扑克
+
+### 介绍
+
+规划扑克是敏捷开发模型中的估算和规划技术。它用于估计[用户故事](../user-stories/index.md)或功能所需的开发工作量。
+
+### 处理
+
+计划扑克一次只为一个用户故事完成。
+
+每个估算器都拥有一组相同的扑克牌，这些扑克牌由具有各种值的牌组成。卡值通常来自Fibonacci序列。用于值的单位可以是团队商定的天数，故事点或任何其他类型的估算单位。
+
+产品所有者（PO）或利益相关者解释了要估计的故事。
+
+该团队讨论了这个故事，询问他们可能有的任何澄清问题。这帮助球队拿到上PO想要_什么_更好的理解。
+
+在讨论结束时，每个人首先选择一张卡片（代表他们对故事的估计）而不向其他人展示。然后，他们同时展示他们的卡片。
+
+如果所有卡具有相同的值，则该值将成为故事的估计值。如果存在差异，团队会讨论他们所选择的值的原因。提供最低和最高估计的团队成员为其估计提供了理由，这具有很高的价值。
+
+在讨论之后，重复选择私人卡然后同时揭示卡的过程。这是在对估计达成共识之前完成的。
+
+因为计划扑克是一种调节_联合_专家评估的工具，它可以更好地理解并甚至改进特征请求。即使团队在No-Estimates模式下运行，它也具有很高的价值。
+
+主持人应尽量避免确认偏差。
+
+值得一提的事：
+
+*   由于每个团队都有自己的scala，因此团队之间的估算无法比较。
+*   估算应包括为完成一项工作而需要完成的所有工作：设计，编码，测试，沟通，代码审查（+所有可能的风险）
+*   使用计划扑克的价值在于最终的讨论，因为它们揭示了对可能实现的不同观点
+
+### 更多信息：
+
+*   规划扑克视频： [YouTube](https://www.youtube.com/watch?v=MrIZMuvjTws)

guide/chinese/agile/product-management/index.md

@@ -0,0 +1,52 @@
+---
+title: Product Management
+localeTitle: 产品管理
+---
+## 产品管理
+
+产品管理是一种组织功能，负责销售产品的整个生命周期。作为一项业务职能，产品管理负责为业务创造客户价值和可衡量的利益。
+
+在成熟的企业公司和初创公司中，大多数产品管理角色都有一些共同的核心职责。大多数情况下，产品管理负责了解客户需求，定义客户需求并确定其优先级，并与工程团队合作构建客户需求。制定战略和定义路线图通常被认为是入站工作，并且将产品推向市场通常被认为是“出站”。
+
+了解入站和出站产品管理之间的差异非常重要，因为优秀的产品经理拥有丰富多样的技能。
+
+产品管理和项目管理之间的区别在于规模和生命周期。项目经理确保向客户提供多个产品/服务/项目，而产品经理则超越开发并致力于产品/服务的长期性和操作性。
+
+在游戏开发中，由于游戏具有更详细的发布后计划和货币化策略，我们可以看到从项目到产品的明显转变。
+
+### 入站产品管理
+
+入站产品管理涉及收集客户研究，竞争情报和行业趋势，以及制定战略和管理产品路线图。
+
+产品策略和定义（入站）
+
+*   战略和愿景
+*   客户访谈
+*   定义功能和要求
+*   建立路线图
+*   发布管理
+*   转向工程资源
+*   销售和支持培训
+
+### 出站产品管理
+
+出站产品管理涉及产品营销职责，例如：消息和品牌，客户沟通，新产品发布，广告，公关和活动。根据组织的不同，这些角色可以由密切配合的同一个人或两个不同的人或团体执行。
+
+产品营销和上市（出境）
+
+*   竞争差异化
+*   定位和消息传递
+*   命名和品牌
+*   客户沟通
+*   产品发布
+*   新闻和分析师的关系
+
+### 产品经理
+
+产品管理作为一种职业继续扩展。对合格产品经理的需求在各个层面都在增长。根据经验水平，有各种各样的角色和责任。机会范围从副产品经理一直到CPO。
+
+大多数产品经理在其职业生涯早期担任过不同的职位。软件工程师，销售工程师或专业服务顾问经常成为产品经理的角色。但是在一些公司（例如Google，Facebook，......）中，初级产品经理是直接从校外招聘的，并得到职业计划的支持，以便在工作中教他们。
+
+#### 更多信息：
+
+维基百科页面：https：//en.wikipedia.org/wiki/Product\_management

guide/chinese/agile/product-owners/index.md

@@ -0,0 +1,33 @@
+---
+title: Product Owners
+localeTitle: 产品所有者
+---
+## 产品所有者
+
+产品所有者负责产品愿景和发布计划。他们负责定义功能，发布日期以及构成可发运产品的内容。产品负责人的目标是快速正确地构建正确的东西。
+
+在高级别，产品负责人负责以下事项：
+
+*   产品愿景的所有者
+*   引领发布计划
+*   定义发布的功能和内容
+*   管理团队对发布的理解
+*   创建并策划产品待办事项
+*   优先考虑产品积压
+*   指导团队完成发布周期
+*   做出权衡决定
+*   接受或拒绝工作
+
+产品负责人创建积压的项目，他们认为这些项目将成为一个好产品。这些知识基于他们对市场，用户测试和市场预测的理解。产品所有者根据用户和利益相关者的反馈调整产品的长期目标。他们还充当与利益相关者的联系点，管理范围和期望。
+
+一旦产品负责人收到各利益相关方的反馈，他们就会优化积压工作，尽可能多地添加详细信息，以便为该版本创建最小可行产品（MVP）。
+
+然后，产品负责人会优先考虑工作负载，以确保完成的故事同时满足业务价值和用户目标。此外，如果某些故事存在风险，产品负责人会将这些风险放在待办事项的首位，以便及早解决风险。
+
+与团队和Scrum Master合作，产品所有者参加sprint计划会议，将整齐的故事循环到sprint中。在整个sprint中，产品负责人确保团队根据完成定义（DoD）完成工作，回答可能出现的任何问题，并更新利益相关者。
+
+冲刺完成后，产品负责人与其他利益相关者一起参与Sprint审核。确保每个故事都符合国防部，产品负责人通过收集反馈并根据已完成的工作确定工作的优先级，为下一个冲刺做好准备。
+
+### 更多信息：
+
+*   坚果壳视频中的敏捷产品所有权： [YouTube](https://www.youtube.com/watch?v=502ILHjX9EE)

guide/chinese/agile/rapid-application-development/index.md

@@ -0,0 +1,14 @@
+---
+title: Rapid Application Development
+localeTitle: 快速应用开发
+---
+## 快速应用开发
+
+快速应用程序开发（RAD）被设计为对传统软件开发方法问题的反应，特别是长时间开发的问题。它还解决了与开发过程中需求变化相关的问题。
+
+RAD的主要原则如下： 1）增量发展。这是RAD处理不断变化的需求的主要手段。只有当用户看到并体验使用中的系统时，才会出现一些要求。要求从未被视为完整 - 由于环境的变化，它们会随着时间的推移而发展。 RAD流程从一个高级的，非特定的需求列表开始，这些需求在开发过程中得到了改进。 2）时间盒。通过时间框，系统可以分为多个单独开发的组件或时间盒。最重要的要求是在第一个时间框中开发的。功能快速而且经常提供。 3）帕累托原则。也称为80/20规则，这意味着大约80％的系统功能可以提供，占所需总工作量的20％左右。因此，最后（也是最复杂）20％的需求需要付出最大的努力和时间。因此，您应该在前几个时间框内选择尽可能多的80％。如果证明有必要，其余部分可以在随后的时间框中提供。 4）MoSCoW规则。 MoSCoW是一种用于在软件开发中确定工作项优先级的方法。项目被列为必须拥有，应拥有，可能拥有或希望具有的功能。必须具有必须包含在产品中以供其接受发布的项目，其他分类具有降序优先级。 5）JAD研讨会。联合应用程序开发（JAD）是一种促进会议，其中执行需求收集，特别是访问要开发的系统的用户。 JAD研讨会通常在开发过程的早期阶段进行，但如果在此过程中稍后需要，可以组织其他会议。 6）原型设计。构建原型有助于建立和阐明用户需求，并且在某些情况下，它会演变为系统本身。 7）赞助商和冠军。执行发起人是组织内需要系统的人，致力于实现该系统并准备为其提供资金。冠军是一个人，通常资历较低，而不是高管，他致力于该项目，并准备将其推进到完成阶段。 8）工具集。 RAD通常采用工具集作为加速开发过程和提高生产率的手段。工具可用于变更控制，配置管理和代码重用。
+
+#### 更多信息：
+
+*   https://en.wikipedia.org/wiki/Rapid _应用程序_开发 - 关于RAD的维基百科文章
+*   https://www.tutorialspoint.com/sdlc/sdlc _rad_ model.htm - RAD上的TutorialsPoint教程

guide/chinese/agile/rational-unified-process/index.md

@@ -0,0 +1,11 @@
+---
+title: Rational Unified Process
+localeTitle: Rational Unified Process
+---
+## Rational Unified Process
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/rational-unified-process/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/agile/release-planning/index.md

@@ -0,0 +1,11 @@
+---
+title: Release Planning
+localeTitle: 发布计划
+---
+## 发布计划
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/release-planning/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/agile/release-trains/index.md

@@ -0,0 +1,19 @@
+---
+title: Release Trains
+localeTitle: 发布火车
+---
+## 发布火车
+
+发布系列（也称为敏捷发布培训或ART）是一个长期存在的敏捷团队，与其他利益相关者一起，在程序增量中使用一系列固定长度的迭代，逐步开发和提供解决方案（ PI）时间盒。 ART将团队与共同的业务和技术使命联系起来。
+
+## 细节
+
+ART具有跨功能，并具有定义，实现，测试和部署新系统功能所需的所有功能 - 软件，硬件，固件和其他功能。 ART的目标是实现持续的价值流。
+
+ART包括定义，构建和测试功能和组件的团队。 SAFe团队可以选择敏捷实践，主要基于Scrum，XP和看板。软件质量实践包括持续集成，测试优先，重构，配对工作和集体所有权。探索性早期迭代，频繁的系统级集成，设计验证，建模和基于集合的设计支持硬件质量。
+
+敏捷架构支持软件和硬件质量。每个敏捷团队都有五到九个专门的个人贡献者，涵盖了为迭代构建高质量增值所需的所有角色。团队可以提供软件，硬件和任何组合。当然，ART中的敏捷团队本身就是跨职能的。
+
+#### 更多信息：
+
+[缩放敏捷](http://www.scaledagileframework.com/agile-release-train/) 。

guide/chinese/agile/retrospectives/index.md

@@ -0,0 +1,43 @@
+---
+title: Retrospectives
+localeTitle: 回顾展
+---
+## 回顾展
+
+Sprint回顾展可能是最有用和最重要的Scrum仪式。
+
+_“检查和适应”_的概念对于创建一个成功和蓬勃发展的团队至关重要。
+
+回顾展的标准议程是：
+
+*   我们一直在做什么？
+*   我们该怎么做？
+*   我们开始做什么？
+*   我们想说谁谢谢你？ （没有必要但是很好的做法）
+
+从这次讨论中，团队创建了一个他们共同工作的行为列表。
+
+在提交行动项目时，请确保将注意力集中在1 - 3上。最好完成一对，而不是做更多而不做。如果难以提出行动，请尝试运行实验：写下您将要做的事情以及您想要实现的目标。在下面的复古检查中，您所做的是否达到了您的计划。如果没有 - 您可以从实验中学习并尝试其他方法。
+
+找出应讨论哪些主题的好方法是_“讨论和提及”_ 。它包含一个板子，其中包含与团队中人员一样多的列（您可以使用Trello或仅使用常规白板）以及另外两个用于“讨论”和“被提及”的内容。每个人都有10分钟的时间来填充他们希望突出显示的最后一个sprint中的内容（这些内容用卡片或Post-it表示）。之后，每个团队成员解释他们自己的每个项目。最后，每个团队成员通过将卡片/帖子移动到相应的列来选择他们认为应该提及或讨论的主题。然后，团队决定应讨论哪些主题，并在大约10分钟内讨论它们。
+
+仅邀请scrum团队参加回顾展。 （交付团队，产品负责人，Scrum Master）。劝阻管理者，利益相关者，商业伙伴等。他们分散注意力，可能会妨碍团队需要的开放感。
+
+在进行回顾时，请确保在前5-10分钟内每个人都至少说几句话。当团队成员在会议开始时发言时，他们更有可能在整个会议期间做出贡献。
+
+在回顾期间，团队保持高效率非常重要。让人们保持积极情绪的一个简单方法是专注于团队控制的内容。
+
+*   对于一个位于同一地点的团队，索引卡和后期工作非常适合这个过程。
+*   对于分布式团队，有各种在线工具和应用程序可以促进讨论
+*   https://www.senseitool.com/home
+*   http://www.leancoffeetable.com/
+
+应在板上标注操作项，以使跟踪进度可视化并更加可区分。每次新的回顾都应该从审查_上一次_回顾期间决定的行动项目的状态开始。
+
+#### 更多信息：
+
+*   准备回顾的灵感：
+*   https://plans-for-retrospectives.com/en/
+*   http://www.funretrospectives.com/
+*   如何使用爆米花流程进行实验：
+*   https://www.slideshare.net/cperrone/popcornflow-continuous-evolution-through-ultrarapid-experimentation

guide/chinese/agile/safe/index.md

@@ -0,0 +1,39 @@
+---
+title: SAFe
+localeTitle: 安全
+---
+## 安全
+
+SAFe代表“Scaled Agile Framework”，是一个敏捷的软件开发框架，专为涉及许多团队的大规模敏捷开发而设计。
+
+主网站（ [http://www.scaledagileframework.com/](http://www.scaledagileframework.com/) ）是一个免费提供的有关实施SAFe的在线知识库。
+
+## 原则
+
+SAFe有九个基本原则
+
+1.  **从经济角度考虑** - 评估决策，发展和风险的经济成本
+2.  **应用系统思考** - 开发过程是工作者使用的系统之间的交互，因此需要通过系统思考来查看进度
+3.  **假设可变性;保留选项** - 需求变化，灵活，并使用经验数据来缩小焦点
+4.  **通过快速，集成的学习周期**逐步构建 - 快速，增量构建允许快速反馈，以便在必要时更改项目
+5.  **关于工作系统客观评估的基本里程碑** - 客观评估提供重要信息，如财务和治理作为反馈
+6.  **可视化和限制WIP，减少批量大小和管理队列长度** - 执行这些操作以实现连续流动以快速移动并可视化进度; WIP =正在进行中的工作
+7.  **应用节奏，与跨域规划同步** - 节奏是在某些事件发生时设置日期（例如每周发布）和同步确保每个人都有相同的目标
+8.  **释放知识工作者的内在动力** - 当您利用他们的个人动机时，人们会更好地工作
+9.  **分散决策** - 允许更快的行动，这可能不是最好的解决方案，但允许团队之间更快的沟通;对于更具战略性或全球性的决策，集中决策可能是必要的
+
+## 配置
+
+SAFe有四种变体，复杂性和项目需求各不相同：
+
+1.  必不可少的SAFe
+2.  投资组合SAFe
+3.  大溶液SAFe
+4.  完整的SAFe
+
+#### 更多信息：
+
+*   [扩展敏捷框架](https://en.wikipedia.org/wiki/Scaled_Agile_Framework)
+*   [什么是SAFe？](http://www.scaledagileframework.com/what-is-safe/)
+*   [十大要素](http://www.scaledagileframework.com/essential-safe/)
+*   [SAFe原则](http://www.scaledagileframework.com/safe-lean-agile-principles/)

guide/chinese/agile/scrum/index.md

@@ -0,0 +1,46 @@
+---
+title: Scrum
+localeTitle: 争球
+---
+## 争球
+
+Scrum是敏捷伞下的方法之一。这个名字来源于在橄榄球运动中恢复比赛的方法，整个球队一起移动到地面。同样，敏捷中的一个Scrum涉及团队的所有部分都在处理同一组目标。在scrum方法中，向团队呈现优先级的任务列表，并且在“sprint”（通常为两周）的过程中，这些任务由团队按顺序完成。这可确保在时间或资金耗尽之前完成最高优先级的任务或可交付成果。
+
+### Scrum的组件
+
+Scrum是敏捷伞下的方法之一。它起源于“scrummage”，这是橄榄球中用来表示球员挤在一起掌握球权的术语。 实践围绕着
+
+*   一组角色（交付团队，产品所有者和Scrum主管）
+*   仪式（冲刺计划，每日站立，冲刺回顾，冲刺回顾和积压修饰）
+*   工件（产品积压，sprint积压，产品增量，信息散热器和报告）。
+*   主要目标是使团队与项目进度保持一致，以促进快速迭代。
+*   许多组织都选择了Scrum，因为与瀑布模型不同，它确保了每个Sprint结束时的可交付成果。
+
+## 文物
+
+*   Sprint：这是一个团队努力实现或创建可交付成果的持续时间，主要是几周。可交付成果可以定义为团队希望实现的最终产品片段的一段代码。 Scrum建议将Sprint的持续时间保持在2-4周之间。
+*   产品待办事项：这是团队应该在当前Sprint中完成的任务列表。由产品负责人决定，与管理层和交付团队达成一致。
+
+## 角色
+
+*   产品负责人（PO）：管理层唯一负责任的人员。 PO决定进出Product Backlog的内容。
+*   交付团队：他们需要按照产品积压中的PO设置的任务工作，并在sprint结束时提供所需的可分发性。
+*   Scrum Master： - Scrum Master必须严格遵守Scrum指南，让团队了解在遵循Scrum时遵守Scrum指南的必要性。 Scrum Master的工作是确保所有Scrum仪式按时进行，并按照scrum指南由所有必需的人员参与。 SM必须确保每日Scrum定期进行并由团队积极参与。
+
+#### 更多信息：
+
+有几种在线工具可用于为您的团队进行scrum：
+
+*   [Scrum做](https://www.scrumdo.com/)
+*   [嘉尚](http://www.asana.com)
+*   [Trello](http://trello.com)
+*   [星期一](https://monday.com)
+*   [大本营](https://basecamp.com)
+*   [Airtable](https://airtable.com)
+*   [SmartSheet](https://www.smartsheet.com)
+
+这里有一些更多的资源：
+
+*   [为什么](https://www.scrumalliance.org/why-scrum)来自Scrum联盟的Scrum
+*   Scrum.org的[Scrum指南](http://www.scrumguides.org/scrum-guide.html)
+*   [做与敏捷](http://agilitrix.com/2016/04/doing-agile-vs-being-agile/)

guide/chinese/agile/scrummasters/index.md

@@ -0,0 +1,34 @@
+---
+title: Scrummasters
+localeTitle: 的ScrumMaster
+---
+## Scrum Master
+
+Scrum Master负责确保理解和制定Scrum。 Scrum Masters通过确保Scrum团队遵守Scrum理论，实践和规则来实现这一目标。
+
+Scrum Master是Scrum团队的仆人领导者。 Scrum Master帮助Scrum团队以外的人了解他们与Scrum团队的哪些互动是有用的，哪些不是。 Scrum Master帮助每个人改变这些交互，以最大化Scrum团队创造的价值。
+
+### Scrum Master的工作
+
+*   促进（不参与）每日站立
+*   帮助团队维持他们的燃尽图
+*   设置回顾，冲刺评论或冲刺计划会话
+*   在冲刺期间屏蔽团队免受干扰
+*   消除影响团队的障碍
+*   通过更多技术用户故事走向产品所有者
+*   鼓励Scrum团队与产品负责人之间的合作。
+
+通常，Scrummaster会询问以下问题：
+
+1.  你昨天做了什么？
+2.  你今天打算做什么？
+3.  有什么阻止你的进步吗？
+
+Scrum大师是敏捷团队的一员。他们可以是开发人员或其他功能成员（戴着多个帽子），也可以单独作为团队中的唯一角色。他们的主要目标是使用Scrum框架增强开发。
+
+他们的作用往往是：指导冲刺计划，监控每日站立，进行回顾，确保速度，帮助确定冲刺的范围。
+
+#### 更多信息：
+
+*   [什么是Scrum Master](https://www.scrum.org/resources/what-is-a-scrum-master)
+*   [Scrum指南](https://www.scrum.org/resources/scrum-guide)

guide/chinese/agile/self-organization/index.md

@@ -0,0 +1,25 @@
+---
+title: Self Organization
+localeTitle: 自组织
+---
+## 自组织
+
+为了保持已开发项目的高度动态性和敏捷性，所有团队成员都应谨慎分担对正在开发的产品的责任。
+
+垂直导向的组织结构证明了自己在很多层面的决策过程中变得缓慢而且不灵活。如果团队想要快速行动并对不断变化的环境做出动态反应，那么组织结构需要保持平稳，成员们对他们对项目的投入负有强烈责任。
+
+这并不意味着管理是敏捷的自组织团队中过时的过程。它只是具有与传统方法不同的特征（特别是在大型组织中，但不仅仅是），当比专制和直接更具支持性和建议性时，证明更有效。
+
+自组织的基础是团队成员的信任和承诺。
+
+据说Scrum团队是自我组织的。这意味着完成的工作和一般的工作方式由团队决定 - 他们是 他们的经理授权他们以最有效的方式指导自己。团队成员（交付团队，产品负责人和 Scrum Master）定期检查他们的行为以不断改进。
+
+在Sprint Planning期间，团队将查看产品待办事项（产品所有者将优先考虑）并确定他们的故事 将在即将到来的冲刺和需要完成的任务中继续工作以将故事标记为完成。该团队将估计该分数或大小 故事表示努力。
+
+在冲刺期间，团队成员可以选择sprint积压故事来处理，通常他们会选择他们认为可以的 实现。由于它是一个自组织团队，因此不应该由其他人为团队成员分配任务。
+
+#### 更多信息：
+
+*   [Scrum](https://www.scrum.org/resources/blog/how-does-scrum-promote-self-organization)上的[Scrum促进自组织](https://www.scrum.org/resources/blog/how-does-scrum-promote-self-organization)
+*   Scrum.org上的[Scrum角色促进了自我组织](https://www.scrum.org/resources/blog/how-do-3-scrum-roles-promote-self-organization)
+*   Scrum联盟关于[自组织的内容和方式](https://scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-how)

guide/chinese/agile/spikes/index.md

@@ -0,0 +1,22 @@
+---
+title: Spikes
+localeTitle: 钉鞋
+---
+## 钉鞋
+
+并非您的团队在Sprint期间所做的一切都是用户故事。有时，用户故事无法有效估计或需要进行研究。也许需要帮助来决定不同的架构，排除一些风险，或者可能是一个概念证明（POC）来展示一种能力。
+
+在这些情况下，Spike会添加到Sprint Backlog中。尖峰的接受标准应该是对提出的问题的回答。如果实验比预期的更困难，那么答案可能是否定的。 （这就是Spike应该及时限制的原因。）
+
+投入Spike的时间和精力是有意限制的，因此可以在Sprint内完成工作，而其他用户故事受到的影响微乎其微。 Spike通常不会收到故事点评估，但会给出固定的小时数。
+
+在Sprint评论中展示Spike的结果。根据新信息，原始问题在未来的Sprint中被重新定义为新的用户故事。
+
+您的团队获得了做出更好决策所需的信息;减少不确定性。通过少量的，可测量的资源来提高未来Sprint的工作质量和价值，而不是根据猜测工作做出决策。
+
+#### 更多信息：
+
+*   Mountain Goat软件[峰值](https://www.mountaingoatsoftware.com/blog/spikes)
+*   Scrum.org论坛[如何整合尖峰](https://www.scrum.org/forum/scrum-forum/5512/how-integrate-spike-scrum)
+*   Scrum联盟的[飙升和努力与悲伤的比率](https://www.scrumalliance.org/community/articles/2013/march/spikes-and-the-effort-to-grief-ratio)
+*   维基百科[穗](https://en.wikipedia.org/wiki/Spike_(software_development))

guide/chinese/agile/sprint-backlog/index.md

@@ -0,0 +1,13 @@
+---
+title: Sprint Backlog
+localeTitle: Sprint积压
+---
+## Sprint积压
+
+Sprint Backlog是Scrum团队在Scrum Sprint期间完成的任务列表。在Sprint计划会议期间，团队通常以用户故事的形式选择一些产品待办事项项，并确定完成每个用户故事所需的任务。
+
+团队自己选择Sprint Backlog的项目和大小至关重要。因为他们是实施/完成任务的人，所以他们必须是人们在Sprint期间选择他们正在预测的内容。
+
+#### 更多信息：
+
+[Scrum指南：Sprint Backlog](http://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)

guide/chinese/agile/sprint-planning-meetings/index.md

@@ -0,0 +1,30 @@
+---
+title: Sprint Planning Meeting
+localeTitle: Sprint计划会议
+---
+## Sprint计划会议
+
+Sprint Planning由团队的Scrum Master提供支持，由Scrum团队组成：开发团队，产品负责人（PO）和Scrum Master（SM）。它旨在将产品Backlog项目的子集计划为Sprint Backlog。 Scrum Sprint通常在Sprint计划会议之后启动。
+
+### 主要部分
+
+通过提出以下两个问题，团队分两部分参与会议具有很高的价值：
+
+*   团队应该为即将到来的Sprint **做些什么**计划？
+*   团队应该（大致） **如何**计划项目？
+
+#### 什么
+
+在什么阶段，团队从订购的产品Backlog的顶部开始。该团队至少通过预测他们可以在Sprint Backlog中采取的措施来隐式估计这些项目。如果需要，他们可以向PO询问/讨论项目，他们必须参加此次会议。
+
+#### 怎么样
+
+在如何阶段，团队将很快讨论每个选择的Sprint Backlog项目，重点是他们将如何获取它。 SM帮助团队深入研究讨论和实施细节。如果向PO提出更多问题或对项目进行改进，或者积压是由团队完成的，那么这是非常可能和好的。
+
+### 冲刺目标/结束
+
+团队应该为Sprint提供一个共享的Sprint目标，以便将焦点集中在Sprint时间框中。在Sprint计划结束时，团队预测他们可以实现Sprint目标并完成所有Sprint Backlog项目。 SM应通过提供有用的见解或统计数据来防止团队过高估计。
+
+#### 更多信息：
+
+[Scrum指南：Sprint计划](http://www.scrumguides.org/scrum-guide.html#events-planning) [Sprint计划会议的简单备忘单](https://www.leadingagile.com/2012/08/simple-cheat-sheet-to-sprint-planning-meeting/) [改善Sprint规划的四个步骤](https://www.atlassian.com/blog/agile/sprint-planning-atlassian)

guide/chinese/agile/sprint-planning/index.md

@@ -0,0 +1,19 @@
+---
+title: Sprint Planning
+localeTitle: Sprint计划
+---
+## Sprint计划
+
+在Scrum中，sprint计划会议由产品所有者ScrumMaster和整个Scrum团队参加。外部利益相关者可以通过团队的邀请参加，尽管这在大多数公司中很少见。 在sprint计划会议期间，产品所有者描述了团队的最高优先级功能。该团队提出了足够的问题，他们可以将产品积压的高级用户故事转变为sprint积压的更详细的任务。
+
+sprint计划会议产生两个已定义的工件：
+
+*   冲刺目标
+*   冲刺积压
+
+对于为期一个月的Sprint，Sprint Planning的时间限制最多为8小时。对于较短的Sprint，事件通常较短。 Scrum Master确保事件发生并且服务员了解其目的。 Scrum Master教Scrum团队将其保留在时间框内。
+
+#### 更多信息：
+
+*   https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-planning-meeting
+*   [Scrum指南](http://www.scrumguides.org/scrum-guide.html)

guide/chinese/agile/sprint-review/index.md

@@ -0,0 +1,29 @@
+---
+title: Sprint Review
+localeTitle: Sprint评论
+---
+## Sprint评论
+
+Sprint评论是Scrum的主要仪式之一（以及Sprint Planning，Daily Stand Up，Retrospective和Grooming）。
+
+在Sprint结束时，您的Scrum团队将举办“邀请世界”会议，以展示刚刚完成和接受的内容。受邀的是Scrum团队，利益相关者，经理，用户;任何对该项目感兴趣的人。
+
+每个Sprint举办这些会议非常重要。这可能是一种心态转变;向您的经理和利益相关者展示未完成的工作。但在“快速失败”的概念中，获得有关增量工作的反馈具有不可思议的价值。如有必要，您的团队可以进行课程更正，从而最大限
+
+由于产品负责人（PO）经常出现在Sprint评论中，Scrum Master通常会捕获反馈，可能会促进讨论，​​然后使用PO来将新的用户故事添加到Backlog并确定优先级。
+
+议程还可以包括对积压（包括价值和优先级）的审查，为下一个迭代计划的内容，以及可以从积压中删除的内容。
+
+**重要事项** Sprint Review与Retrospective完全不同。回顾是Scrum团队（Scrum Master，PO和交付团队）的严格要求。被邀请参加评审的其他各方可以免于参与回顾，并可能会干预回顾。 （是的，包括经理。）
+
+#### 更多信息：
+
+Innolution的Ken Rubin [停止打电话给您的Sprint评论演示](https://www.scrumalliance.org/community/spotlight/ken-rubin/january-2015/stop-calling-your-sprint-review-a-demo%E2%80%94words-matte)
+
+Scrum.org [什么是Sprint评论](https://www.scrum.org/resources/what-is-a-sprint-review)
+
+Mountain Goat Software [Sprint评审会议](https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-review-meeting)
+
+Atlassian [改善Sprint评论的三个步骤](https://www.atlassian.com/blog/agile/sprint-review-atlassian)
+
+产品[冲刺](https://age-of-product.com/sprint-review-anti-patterns/)时代[评论反模式](https://age-of-product.com/sprint-review-anti-patterns/)

guide/chinese/agile/sprints/index.md

@@ -0,0 +1,21 @@
+---
+title: Sprints
+localeTitle: 冲刺
+---
+## 冲刺
+
+在Scrum中， **Sprint**的工作时间通常为一到四周，交付团队负责您的项目。 Sprint是迭代的，并继续直到项目完成。每个sprint都以Sprint计划会话开始，并以Sprint Review和Retrospective会议结束。使用sprint而不是长达数月的瀑布或线性顺序开发方法，允许项目所有者和利益相关者之间定期反馈来自交付团队的输出。
+
+## Sprint的属性
+
+\- 在整个项目期间，图纸应保持相同的预定时间长度。 - 该团队致力于将用户故事分解为可在Sprint持续时间内完成的大小，而无需转移到下一个。 - “Sprint”和“Iteration”通常可互换使用。
+
+#### 更多信息：
+
+*   敏捷联盟的[迭代](https://www.agilealliance.org/glossary/iteration/)
+*   时间[盒上的](https://www.agilealliance.org/glossary/timebox/)敏捷联盟
+*   [Sprint与迭代的](http://agilecoach.typepad.com/agile-coaching/2014/02/sprint-vs-iteration.html)敏捷教练
+*   Scrum Alliance [Timeboxing作为一个激励因素](https://www.scrumalliance.org/community/articles/2014/february/timeboxing-a-motivational-factor-for-scrum-teams)
+*   Scrum Alliance [Sprint不仅仅是一个时间盒](https://www.scrumalliance.org/community/articles/2014/may/sprint-is-more-than-just-a-timebox)
+*   Scrum Inc [什么是Timeboxing](https://www.scruminc.com/what-is-timeboxing/)
+*   Scrum.org [什么是Scrum中的Sprint](https://www.scrum.org/resources/what-is-a-sprint-in-scrum)

guide/chinese/agile/stakeholders/index.md

@@ -0,0 +1,22 @@
+---
+title: Stakeholders
+localeTitle: 利益相关者
+---
+## 利益相关者
+
+利益相关者是将从您的项目中受益的人。产品负责人应了解利益相关方要求的结果，并将此需求传达给交付团队。 利益相关者可以由以下任何一方组成
+
+*   用户
+*   顾客
+*   经理
+*   资助者/投资者
+
+他们参与该项目对成功至关重要。
+
+例如，当您的团队执行Sprint审核会议时，项目的演示针对的是利益相关者，他们的反馈将被捕获并添加到积压工作中。
+
+#### 更多信息：
+
+*   Scrum研究Scrum中的[利益相关者](https://www.scrumstudy.com/blog/stakeholders-in-scrum/)
+*   Scrum.org [关键利益相关者](https://www.scrum.org/resources/blog/scrum-who-are-key-stakeholders-should-be-attending-every-sprint-review)
+*   敏捷建模[积极的利益相关者参与](http://agilemodeling.com/essays/activeStakeholderParticipation.htm)

guide/chinese/agile/story-points-and-complexity-points/index.md

@@ -0,0 +1,25 @@
+---
+title: Story Points and Complexity Points
+localeTitle: 故事点和复杂点
+---
+## 故事点和复杂点
+
+在Scrum / Agile中，通过用户可能告诉他们产品需要的**故事**来探索开发中产品的功能。当团队估计交付用户故事所需的工作量时，团队会使用**故事点** 。
+
+故事点的显着特征是它们：
+
+*   代表整个团队的贡献
+*   不要直接等同于任务可能花费的时间
+*   是规划目的的粗略衡量标准 - 类似于数量级
+*   以Fibonacci式序列分配：0,1,2,3,5,8,13,20,40,100
+*   估计故事_相对于彼此_的“大小”
+
+如果您不熟悉敏捷的做事方式，故事点的概念可能会非常难以捉摸。你会发现许多在线资源以不同的方式讨论故事点，很难清楚地知道它们是什么以及如何使用它们。
+
+当您了解Scrum等实践的原理和术语时，其中一些属性的原因将变得明显。故事点的使用，特别是在“计划扑克”等“仪式”中，通过观察或参与而不是书面解释更容易理解！
+
+### 更多信息：
+
+*   用户故事： [freeCodeCamp](https://guide.freecodecamp.org/agile/user-stories)
+*   使用故事点时常见的错误： [中等](https://medium.com/bynder-tech/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7)
+*   规划扑克： [Mountain Goat软件](https://www.mountaingoatsoftware.com/agile/planning-poker)

guide/chinese/agile/sustainable-pace/index.md

@@ -0,0 +1,11 @@
+---
+title: Sustainable Pace
+localeTitle: 可持续发展
+---
+## 可持续发展
+
+可持续发展的步伐是您和您的团队可以长时间工作的步伐，甚至是永远的。 它尊重您的周末，晚上，假期和假期。它允许必要的会议和个人发展时间。
+
+#### 更多信息：
+
+[什么是可持续发展的步伐？](http://www.sustainablepace.net/what-is-sustainable-pace)

guide/chinese/agile/task-boards-and-kanban/index.md

@@ -0,0 +1,35 @@
+---
+title: Task Boards and Kanban
+localeTitle: 任务板和看板
+---
+## 任务板和看板
+
+看板对于进行软件开发和个人跟踪个人任务的团队来说都是一种很好的方法。
+
+从日语术语“招牌”或“广告牌”派生来表示信号，关键原则是在给定时间将您的在制品（WIP）限制为有限数量的任务。可以进行的金额取决于团队（或个人）的约束能力。当一项任务完成后，这就是你将另一项任务转移到其位置的信号。
+
+您的看板任务将显示在任务板上的一系列列中，以显示任务的状态。在其最简单的形式中，使用三列
+
+*   去做
+*   干
+*   完成
+
+![看板板示例](https://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Simple-kanban-board-.jpg/600px-Simple-kanban-board-.jpg)
+
+_图片由[维基百科提供](https://en.wikipedia.org/wiki/Kanban_board)_
+
+但是可以添加许多其他列或状态。例如，软件团队还可以包括等待测试，完成或接受。
+
+![更复杂的例子](https://mktgcdn.leankit.com/uploads/images/general/_2048xAUTO_fit_center-center/1-SmalDevelopmentTeamKanbanBoard-eb79376d.png)
+
+_图片由[leankit提供](https://leankit.com/learn/kanban/kanban-board-examples-for-development-and-operations/)_
+
+### 更多信息：
+
+*   什么是看板： [Leankit](https://leankit.com/learn/kanban/what-is-kanban/)
+*   什么是看板： [Atlassian](https://www.atlassian.com/agile/kanban)
+
+一些在线板
+
+*   [Trello](https://trello.com/)
+*   [KanbanFlow](https://kanbanflow.com)

guide/chinese/agile/technical-debt/index.md

@@ -0,0 +1,16 @@
+---
+title: Technical Debt
+localeTitle: 技术债务
+---
+## 技术债务
+
+通常在敏捷开发中，如果您在“足够好”的实践中生产软件，那么您还将增加技术债务。这是捷径和解决方案的积累。
+
+把它与金钱相比较。当您通过信用卡收取费用时，您已承诺稍后付款。当您创建技术债务时，您的团队_应该_承诺按计划解决这些问题。
+
+迭代工作的好处之一是经常展示您的增量并收集反馈。如果您的第一次通过“足够好”，并且由于该反馈而需要进行更改，您可能已经避免了一些不必要的工作。在您的待办事项中捕获此信息，并在每个sprint中包含一部分进行重构或改进。
+
+#### 更多信息：
+
+*   敏捷[技术债务](https://www.agilealliance.org/introduction-to-the-technical-debt-concept/)联盟
+*   Scrum联盟[管理技术债务](https://www.scrumalliance.org/community/articles/2013/july/managing-technical-debt)

guide/chinese/agile/test-driven-development/index.md

@@ -0,0 +1,38 @@
+---
+title: Test Driven Development
+localeTitle: 测试驱动开发
+---
+## 测试驱动开发
+
+测试驱动开发（TDD）是敏捷软件开发方法之一。它基于这一概念
+
+> 您必须在编写代码之前为代码编写测试用例
+
+在这里，我们首先编写单元测试，然后编写代码以成功完成测试。这节省了执行单元测试和其他类似测试所花费的时间，因为我们正在进行成功的测试迭代以及在代码中实现模块化。 它基本上由4个步骤组成
+
+*   写一个测试用例
+    
+*   看测试失败（红色）
+    
+*   让测试通过，同时处理任何犯罪行为（绿色）
+    
+*   重构代码以达到标准（Refactor）
+    
+    这些步骤遵循Red-Green-Refactor的原则。 Red-Green确保您编写最简单的代码来解决问题，而最后一步确保您编写的代码符合标准。
+    
+
+系统的每个新功能都应遵循上述步骤。
+
+![tdd flow](http://www.agiledata.org/images/tddSteps.jpg)
+
+#### 更多信息：
+
+敏捷数据的[TDD简介](http://agiledata.org/essays/tdd.html)
+
+维基在[TDD上](https://en.wikipedia.org/wiki/Test-driven_development)
+
+Martin Fowler [是TDD死了？](https://martinfowler.com/articles/is-tdd-dead/) （关于这个主题的一系列录制对话）
+
+Kent Beck的书“ [测试驱动开发实例”](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530)
+
+鲍勃叔叔[的TDD周期](http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html)

guide/chinese/agile/the-agile-manifesto/index.md

@@ -0,0 +1,42 @@
+---
+title: The Manifesto
+localeTitle: 宣言
+---
+## 宣言
+
+### 起源
+
+> 2001年2月11日至13日，在犹他州瓦萨奇山区的雪鸟滑雪胜地洛奇酒店，有17人聚在一起聊天，滑雪，放松，并试图寻找共同点 - 当然，还要吃饭。 \[...\]现在，很难找到一个更大的组织无政府主义者聚会，所以从这次会议中产生的是象征性的 - 一个由所有参与者签署的敏捷软件开发宣言。 （1）
+
+### 敏捷软件开发宣言
+
+我们正在通过这样做并帮助其他人来实现软件开发的更好方法。
+
+通过这项工作，我们已经开始重视
+
+*   **个人和**流程与工具**之间的互动** 。
+*   **工作软件**综合文档。
+*   合同谈判中的**客户协作** 。
+*   **响应**遵循计划的**变更** 。
+
+也就是说，虽然右边的项目有价值，但我们更重视左边的项目。
+
+### 敏捷软件的十二个原则
+
+1.  我们的首要任务是通过早期和持续交付有价值的软件来满足客户。
+2.  欢迎不断变化的要求，甚至是开发后期。敏捷流程利用变化来实现客户的竞争优势。
+3.  经常提供工作软件，从几周到几个月，优先考虑更短的时间尺度。
+4.  业务人员和开发人员必须在整个项目中每天一起工作。
+5.  围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。
+6.  向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交谈。
+7.  工作软件是进步的主要衡量标准。
+8.  敏捷过程促进可持续发展。赞助商，开发者和用户应该能够无限期地保持稳定的步伐。
+9.  持续关注技术卓越和良好的设计可提高灵活性。
+10.  简单性 - 最大化未完成工作量的艺术 - 至关重要。
+11.  最好的架构，要求和设计来自自组织团队。
+12.  团队定期反思如何变得更有效，然后相应地调整和调整其行为。
+
+#### 更多信息：
+
+*   [（1）历史：敏捷宣言](http://agilemanifesto.org/history.html)
+*   [敏捷宣言](http://agilemanifesto.org/)

guide/chinese/agile/user-acceptance-tests/index.md

@@ -0,0 +1,54 @@
+---
+title: User Acceptance Tests
+localeTitle: 用户验收测试
+---
+## 用户验收测试
+
+在工程及其各个分支学科中，验收测试是为了确定是否满足规范或合同的要求而进行的测试。它可能涉及化学测试，物理测试或性能测试。
+
+在系统工程中，它可能涉及在交付之前在系统上执行的黑盒测试（例如：一个软件，许多制造的机械部件或批量的化学产品）。
+
+在软件测试中，ISTQB将接受定义为：针对用户需求，要求和业务流程进行的正式测试，以确定系统是否满足验收标准并使用户，客户或其他授权实体能够确定是否接受系统。验收测试也称为用户验收测试（UAT），最终用户测试，操作验收测试（OAT）或现场（验收）测试。
+
+在将软件构建引入主要测试过程之前，可以使用烟雾测试作为验收测试。
+
+软件测试的最后一步是用户验收测试（UAT）。 UAT确保实际用户可以使用该软件。也称为beta，应用程序和最终用户测试。
+
+UAT检查一切正常并且没有崩溃。那些目标受众应该完成测试;这可能包括许多参与该过程的人以及能够在上线前进行测试的任何人。此测试的反馈将转发给开发团队以进行任何特定更改。
+
+#### 为什么我们需要UAT
+
+*   需求更改可能未与开发人员通信
+    
+*   该软件可能无法实际提供它的意义
+    
+*   某些逻辑或业务流程可能需要用户的注意
+    
+
+#### 在我们开始UAT之前需要什么
+
+*   签署完整的请求，并按照文件提供
+    
+*   代码处于工作状态或处于可演示状态
+    
+*   UAT是环境准备好访问
+    
+*   不应该有任何会破坏代码的缺陷
+    
+*   根据LIVE scneario准备的测试数据
+    
+
+#### 使用的框架和工具
+
+*   FitNesse的
+
+#### 关于UAT的文章
+
+*   [7成功完成用户验收测试](http://blog.debugme.eu/successful-user-acceptance-testing/)
+    
+*   [AgileUAT：用户验收测试框架 基于用户故事和接受标准](http://research.ijcaonline.org/volume120/number10/pxc3903533.pdf)
+    
+
+#### 更多信息：
+
+https://en.wikipedia.org/wiki/Acceptance\_testing

guide/chinese/agile/user-stories/index.md

@@ -0,0 +1,28 @@
+---
+title: User Stories
+localeTitle: 用户故事
+---
+用户故事是敏捷方法的一部分，有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包括一两句话，更重要的是，有关所需功能的一系列对话。
+
+用户故事通常使用以下模式编写：
+
+#### 作为\[用户类型\]，我想\[某个目标\]以便\[某些原因或需要\]
+
+用户故事应该从用户的角度以非技术术语编写。故事应该强调用户的需要，而不是如何。用户故事中不应该提供解决方案。
+
+编写用户故事时遇到的一个常见错误是从开发人员或解决方案的角度编写。请务必说明目标和需求，以及稍后的功能要求。
+
+#### 调整用户故事：史诗和更小的故事
+
+史诗是一个大而粗糙的故事。它通常会随着时间的推移分成几个用户故事 - 利用用户对早期原型和产品增量的反馈。您可以将其视为更详细故事的标题和占位符。
+
+从epics开始，您可以绘制产品功能，而无需提交详细信息。这对于描述新产品和功能特别有用：它允许您捕获粗略的范围，并且您可以花时间了解有关如何最好地满足用户需求的更多信息。
+
+它还减少了整合新见解所需的时间和精力。如果您在产品待办事项中有许多详细的故事，那么将反馈与相应的项目相关联通常会非常棘手且耗时，并且存在引入不一致的风险。
+
+在考虑可能的故事时，考虑“误用户案例”和“不愉快路径”故事也很重要。系统如何处理异常？您将向用户提供什么样的消息？恶意用户如何滥用此应用程序功能？这些故事可以节省返工，并成为QA中的有用测试用例。
+
+#### 更多信息：
+
+*   [Mountain Goat软件用户故事指南](https://www.mountaingoatsoftware.com/agile/user-stories)
+*   [Roman Pichler用户故事指南](http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/)

guide/chinese/agile/value-stream-mapping/index.md

@@ -0,0 +1,17 @@
+---
+title: Value Stream Mapping
+localeTitle: 价值流图
+---
+## 价值流图
+
+**价值流映射**是一种精益软件开发技术。它有助于在材料，工作量，成本和时间方面识别资源中的浪费。
+
+计算过程循环效率是了解AS-IS过程效率的方法之一。
+
+**过程循环效率=增加的花费时间/总循环时间。**
+
+值越高，效率越高。
+
+#### 更多信息：
+
+*   [维基百科](https://en.wikipedia.org/wiki/Value_stream_mapping)

guide/chinese/agile/vanity-metrics/index.md

@@ -0,0 +1,27 @@
+---
+title: Vanity Metrics
+localeTitle: 虚荣指标
+---
+## 虚荣指标
+
+虚荣是外观与质量的价值，虚荣指标是在没有上下文或解释的情况下用于使某人或某事看起来很好的测量。在“ [哈佛商业评论”](https://hbr.org/2010/02/entrepreneurs-beware-of-vanity-metrics) （ [Harvard Business Review）上](https://hbr.org/2010/02/entrepreneurs-beware-of-vanity-metrics)发帖的埃里克·里斯（Eric Ries）表示，衡量标准应具有可**操作性** ， **可访问性**和**可审**
+
+![虚荣指标](https://i.pinimg.com/originals/d4/ea/9a/d4ea9ade0de05a5707e11b325a37d5fb.jpg)
+
+例子：
+
+*   注册用户与活跃用户
+*   接受的用户故事与交付给客户的价值
+*   Twitter粉丝与转推
+
+![价值至关重要](https://blog.kissmetrics.com/wp-content/uploads/2012/01/increasing-pageviews-flat-revenues.png) _图像通过kissmetrics_
+
+#### 更多信息：
+
+关于[Actionable vs Vanity Metrics的失败](https://fizzle.co/sparkline/vanity-vs-actionable-metrics)
+
+关于[虚荣指标的](https://hbr.org/2010/02/entrepreneurs-beware-of-vanity-metrics)哈佛商业评论
+
+福布斯[忽视虚荣指标并专注于参与](https://www.forbes.com/sites/sujanpatel/2015/05/13/why-you-should-ignore-vanity-metrics-focus-on-engagement-metrics-instead/#1342fdeb12a9)
+
+kissmetrics [扔掉虚荣指标](https://blog.kissmetrics.com/throw-away-vanity-metrics/)

guide/chinese/agile/velocity/index.md

@@ -0,0 +1,13 @@
+---
+title: Velocity
+localeTitle: 速度
+---
+## 速度
+
+在Scrum团队中，您可以确定每次迭代结束时的速度。它只是时间框内完成的故事点的总和。
+
+拥有可预测的，一致的速度，您的团队可以放心地计划您的迭代，可持续地工作，并使用经验数据预测每个版本中包含的范围数量。
+
+#### 更多信息：
+
+Scrum [速度](https://www.scrumalliance.org/community/articles/2014/february/velocity)联盟

guide/chinese/agile/voice-of-the-customer/index.md

@@ -0,0 +1,14 @@
+---
+title: Voice of the Customer
+localeTitle: 客户之声
+---
+## 客户之声
+
+作为产品负责人（PO），您是交付团队的客户之声。当团队需要澄清故事时，为了更好地理解什么和为什么，他们会问你。  
+您可以了解客户在项目长度变化时的需求，动机和预期结果。
+
+#### 更多信息：
+
+[产品负责人的](https://www.scrumalliance.org/community/articles/2014/july/who-is-your-product-owner) Scrum联盟
+
+[产品负责人的](https://www.agilealliance.org/glossary/product-owner/)敏捷联盟

guide/chinese/algorithms/algorithm-design-patterns/behavioral-patterns/index.md

@@ -0,0 +1,31 @@
+---
+title: Behavioral patterns
+localeTitle: 行为模式
+---
+## 行为模式
+
+行为设计模式是识别对象之间的常见通信问题并实现这些模式的设计模式。通过这样做，这些模式增加了执行此通信的灵活性，使得软件更可靠且易于保持。
+
+此类设计模式的示例包括：
+
+1.  **责任链模式** ：通过包含逻辑的处理对象处理或传递命令对象到其他对象。
+2.  **命令模式** ：命令对象封装操作及其参数。
+3.  **解释器模式** ：实现专门的计算机语言，以快速解决一组特定的问题。
+4.  **迭代器模式** ：迭代器用于顺序访问聚合对象的元素，而不暴露其底层表示。
+5.  **中介模式** ：为子系统中的一组接口提供统一接口。
+6.  **Memento模式** ：提供将对象恢复到其先前状态（回滚）的功能。
+7.  **空对象模式** ：设计用作对象的默认值。
+8.  **观察者模式** ：又名P **ublish / Subscribe**或**Event Listener** 。对象注册以观察可能由另一个对象引发的事件。
+9.  **弱参考模式** ：将观察者与观察者分离。
+10.  **协议栈** ：通信由多个层处理，形成封装层次结构。
+11.  **计划任务模式** ：计划以特定间隔或时钟时间执行任务（用于实时计算）。
+12.  **单服务访问者模式** ：优化分配的访问者的实现，仅使用一次，然后删除。
+13.  **规范模式** ：布尔方式的可重组业务逻辑。
+14.  **状态模式** ：对象在运行时部分更改其类型的简洁方法。
+15.  **策略模式** ：可以动态选择算法。
+16.  **模板方法模式** ：描述程序的程序框架。
+17.  **访问者模式** ：一种将算法与对象分开的方法。
+
+### 来源
+
+[https://en.wikipedia.org/wiki/Behavioral\_pattern](https://en.wikipedia.org/wiki/Behavioral_pattern)

guide/chinese/algorithms/algorithm-design-patterns/creational-patterns/index.md

@@ -0,0 +1,21 @@
+---
+title: Creational patterns
+localeTitle: 创作模式
+---
+## 创作模式
+
+创建设计模式是处理对象创建机制的设计模式，试图以适合于该情况的方式创建对象。对象创建的基本形式可能导致设计问题或设计的复杂性增加。创建设计模式通过某种方式控制此对象创建来解决此问题。
+
+创作设计模式由两个主导思想组成。一个是封装有关系统使用哪些具体类的知识。另一个是隐藏如何创建和组合这些具体类的实例。
+
+五种着名的设计模式是创作模式的一部分：
+
+1.  **抽象工厂模式** ，它提供用于创建相关或从属对象的接口，而无需指定对象的具体类。
+2.  **构建器模式** ，它将复杂对象的构造与其表示分开，以便相同的构造过程可以创建不同的表示。
+3.  **工厂方法模式** ，允许类将实例化推迟到子类。
+4.  **原型模式** ，它指定使用原型实例创建的对象类型，并通过克隆此原型来创建新对象。
+5.  **单例模式** ，确保一个类只有一个实例，并提供一个全局访问点。
+
+### 来源
+
+1.  [Gamma，Erich;理查德，赫尔姆;约翰逊，拉尔夫; Vlissides，John（1995）。设计模式。马萨诸塞州：Addison-Wesley。页。 81.ISBN 978-0-201-63361-0。检索2015-05-22。](http://www.pearsoned.co.uk/bookshop/detail.asp?item=171742)

guide/chinese/algorithms/algorithm-design-patterns/index.md

@@ -0,0 +1,27 @@
+---
+title: Algorithm Design Patterns
+localeTitle: 算法设计模式
+---
+## 算法设计模式
+
+在软件工程中，设计模式是软件设计中常见问题的通用可重复解决方案。设计模式不是可以直接转换为代码的完成设计。它是如何解决可在许多不同情况下使用的问题的描述或模板。
+
+设计模式可以通过提供经过验证的经过验证的开发范例来加速开发过程。
+
+这种模式分为三大类：
+
+### 创作模式
+
+这些是处理对象创建机制的设计模式，试图以适合于该情况的方式创建对象。对象创建的基本形式可能导致设计问题或设计的复杂性增加。创建设计模式通过某种方式控制此对象创建来解决此问题。
+
+### 结构模式
+
+这些是通过识别实现实体之间关系的简单方法来简化设计的设计模式。
+
+### 行为模式
+
+这些是识别对象之间的通用通信模式并实现这些模式的设计模式。通过这样做，这些模式增加了进行该通信的灵活性。
+
+#### 更多信息：
+
+[设计模式 - 维基百科](https://en.wikipedia.org/wiki/Design_Patterns)

guide/chinese/algorithms/algorithm-design-patterns/structual-patterns/index.md

@@ -0,0 +1,29 @@
+---
+title: Structural patterns
+localeTitle: 结构模式
+---
+## 结构模式
+
+结构设计模式是通过识别实现实体之间关系的简单方法来简化设计的设计模式，并负责在不同类之间构建简单有效的类层次结构。
+
+结构模式的示例包括：
+
+1.  **适配器模式** ：将一个类的接口“调整”为客户期望的接口。
+2.  **适配器管道** ：使用多个适配器进行调试。
+3.  **Retrofit Interface Pattern** ：一个适配器，可以同时用作多个类的新接口。
+4.  **聚合模式** ：Composite模式的一个版本，带有聚合子项的方法。
+5.  **桥接模式** ：将抽象与其实现分离，以便两者可以独立变化。
+6.  **墓碑** ：中间“查找”对象包含对象的真实位置。
+7.  **复合模式** ：对象的树结构，其中每个对象具有相同的接口。
+8.  **装饰器模式** ：在运行时向类添加附加功能，其中子类化将导致新类的指数上升。
+9.  **可扩展性模式** ：aka Framework - 隐藏简单接口背后的复杂代码。
+10.  **Facade模式** ：创建现有界面的简化界面，以方便常见任务的使用。
+11.  **Flyweight模式** ：大量对象共享一个公共属性对象以节省空间。
+12.  **标记模式** ：将元数据与类关联的空接口。
+13.  **管道和过滤器** ：一系列进程，其中每个进程的输出是下一个进程的输入。
+14.  **不透明指针** ：指向未声明或私有类型的指针，用于隐藏实现细节。
+15.  **代理模式**一个类作为另一个东西的接口。
+
+### 来源
+
+[https://en.wikipedia.org/wiki/Structural\_pattern](https://en.wikipedia.org/wiki/Structural_pattern)

guide/chinese/algorithms/algorithm-performance/index.md

@@ -0,0 +1,93 @@
+---
+title: Algorithm Performance
+localeTitle: 算法性能
+---
+在数学中，big-O表示法是用于描述和比较函数的_限制行为_的象征。  
+函数的限制行为是函数的行为方式，因为它趋向于特定的值，而在大O符号中，它通常是趋向于无穷大。  
+简而言之，big-O表示法用于描述函数的增长或下降，通常与另一个函数有关。
+
+在算法设计中，我们通常使用big-O表示法，因为我们可以看到算法在最差模式下有多么糟糕或不好。但请记住，情况并非总是如此，因为最坏的情况可能是超级罕见的，在这种情况下我们计算平均情况。现在，以免欺骗大O符号。
+
+在数学中，big-O表示法是用于描述和比较函数的_限制行为_的象征。
+
+函数的限制行为是函数在趋向特定值时的行为方式，而在大O符号中，它通常随着趋势向无穷大趋势而变化。
+
+简而言之，big-O表示法用于描述函数的增长或下降，通常与另一个函数有关。
+
+注意：x ^ 2相当于x \* x或'x-squared'\]
+
+例如，对于所有x> 1，我们说x = O（x ^ 2），换句话说，x ^ 2是x的上限，因此它增长得更快。  
+对于所有x> _n，_ x = 0（x ^ 2）的权利要求的符号可以用x <= x ^ 2代替所有x> _n_ ，其中_n_是满足权利要求的最小数，在这种情况下为1。
+
+实际上，我们说函数f（x）是O（g（x））比g（x）慢得多。
+
+相比之下，在计算机科学和软件开发中，我们可以使用big-O表示法来描述算法通过其时间和空间复杂性的效率。
+
+**空间**算法的**复杂性**是指其相对于输入大小的内存占用。
+
+特别是当使用big-O表示法时，我们描述了算法相对于输入的效率： _n_ ，通常当_n_接近无穷大时。  
+在检查算法时，我们通常希望降低时间和空间复杂度。 o（1）的时间复杂度表示恒定时间。
+
+通过算法的比较和分析，我们能够创建更高效​​的应用程序。
+
+对于算法性能，我们有两个主要因素：
+
+*   **时间** ：我们需要知道为我们的数据运行算法需要多长时间以及它将如何根据数据大小（或在某些情况下其他因素，如数字位数等）增长。
+    
+*   **空间** ：我们的记忆是最终的，所以我们必须知道这个算法需要多少可用空间，以及我们需要能够跟踪其增长的时间。
+    
+
+以下3种符号主要用于表示算法的时间复杂度：
+
+1.  **Θ表示法** ：theta表示法从上方和下方界定函数，因此它定义了确切的行为。我们可以说，当最坏情况和最佳情况相同时，我们有theta符号。
+    
+    > Θ（g（n））= {f（n）：存在正常数c1，c2和n0，使得0 <= c1 _g（n）<= f（n）<= c2_ g（n）对于所有n> = n0}
+    
+2.  **Big O表示法** ：Big O表示法定义算法的上限。例如，插入排序在最佳情况下采用线性时间，在最坏情况下采用二次时间。我们可以有把握地说插入排序的时间复杂度是_O_ （ _n ^ 2_ ）。
+    
+    > O（g（n））= {f（n）：存在正常数c和n0，使得对于所有n> = n0，0 <= f（n）<= cg（n）
+    
+3.  **Ω表示法** ：Ω表示法提供算法的下限。它显示了该算法最快的答案。 >Ω（g（n））= {f（n）：存在正常数c和n0，使得对于所有n> = n0}，0 <= cg（n）<= f（n）。
+    
+
+## 例子
+
+例如，我们可以检查[\[冒泡排序\]](https://github.com/FreeCodeCamp/wiki/blob/master/Algorithms-Bubble-Sort.md#algorithm-bubble-sort)算法的时间复杂度，并使用big-O表示法表达它。
+
+#### 冒泡排序：
+
+```javascript
+    // Function to implement bubble sort 
+    void bubble_sort(int array<a href='http://bigocheatsheet.com/' target='_blank' rel='nofollow'>], int n) 
+    { 
+        // Here n is the number of elements in array 
+        int temp; 
+        for(int i = 0; i < n-1; i++) 
+        { 
+            // Last i elements are already in place 
+            for(int j = 0; j < ni-1; j++) 
+            { 
+                if (array[j] > array[j+1]) 
+                { 
+                    // swap elements at index j and j+1 
+                    temp = array[j]; 
+                    array[j] = array[j+1]; 
+                    array[j+1] = temp; 
+                } 
+            } 
+        } 
+    } 
+```
+
+看一下这段代码，我们可以看到，在数组已经排序的最佳情况下，程序只进行_n次_比较，因为不会发生交换。  
+因此我们可以说冒泡排序的最佳案例时间复杂度是O（ _n_ ）。
+
+检查阵列顺序相反的最坏情况，第一次迭代将进行_n次_比较，而下一次迭代必须进行_n_ - 1次比较，依此类推，直到只进行1次比较。  
+因此，对于这种情况的大O符号是_n_ \* \[（ _n_ -1）/ 2\]，其中= 0.5 _n_ ^ 2 - 0.5 _n_ = O（ _n_ ^ 2），因为_n_ ^ 2项主导了函数，这使我们能够忽略函数中的其他术语。
+
+我们可以使用\[这个方便的大O作弊表来确认这个分析，它具有许多常用数据结构和算法的大O时间复杂性
+
+很明显，虽然对于小用例，这个时间复杂性可能没有问题，但是大规模的冒泡排序根本不是排序的好方法。  
+这是big-O表示法的强大功能：它允许开发人员轻松查看其应用程序的潜在瓶颈，并采取措施使这些更具可伸缩性。
+
+有关为什么big-O表示法和算法分析很重要的更多信息，请访问此[视频挑战](https://www.freecodecamp.com/videos/big-o-notation-what-it-is-and-why-you-should-care) ！

guide/chinese/algorithms/avl-trees/index.md

@@ -0,0 +1,52 @@
+---
+title: AVL Trees
+localeTitle: AVL树
+---
+## AVL树
+
+AVL树是二叉搜索树的子类型。
+
+BST是由节点组成的数据结构。它有以下保证：
+
+1.  每棵树都有一个根节点（在顶部）。
+2.  根节点具有零个或多个子节点。
+3.  每个子节点都有零个或多个子节点，依此类推。
+4.  每个节点最多有两个孩子。
+5.  对于每个节点，其左后代小于当前节点，该节点小于正确的后代。
+
+AVL树有额外的保证：
+
+6.  右子树和左子树深度之间的差异不能超过一。为了保持这种保证，AVL的实现将包括在添加附加元素时重新平衡树的算法将扰乱该保证。
+
+AVL树的最坏情况查找，插入和删除时间为O（log n）。
+
+### 右转
+
+![AVL树右旋转](https://raw.githubusercontent.com/HebleV/valet_parking/master/images/avl_right_rotation.jpg)
+
+### 左转
+
+![AVL树左旋转](https://raw.githubusercontent.com/HebleV/valet_parking/master/images/avl_left_rotation.jpg)
+
+### AVL插入过程
+
+您将执行类似于普通二进制搜索树插入的插入。插入后，使用向左或向右旋转修复AVL属性。
+
+*   如果右子树的左子节点存在不平衡，则执行左右旋转。
+*   如果左子树的左子节点存在不平衡，则执行右旋转。
+*   如果右子树的右子项存在不平衡，则执行左旋转。
+*   如果左子树的右子项存在不平衡，则执行左右旋转。
+
+#### 更多信息：
+
+[YouTube - AVL树](https://www.youtube.com/watch?v=7m94k2Qhg68)
+
+AVL树是自平衡二叉搜索树。 AVL树是二叉搜索树，具有以下属性： - >每个节点的子树的高度最多为1。 - >每个子树都是一个AVL树。
+
+AVL树检查左侧和右侧子树的高度，并确保差异不大于1.这种差异称为平衡因子。 AVL树的高度始终为O（Logn），其中n是树中的节点数。
+
+AVL树轮换： -
+
+在AVL树中，在执行插入和删除等每个操作后，我们需要检查树中每个节点的平衡因子。如果每个节点都满足平衡因子条件，那么我们就结束操作，否则我们必须使其平衡。当树由于任何操作而变得不平衡时，我们使用旋转操作来使树平衡。
+
+旋转操作用于使树平衡。有四种旋转，它们分为两种类型： - >单左旋转（LL旋转） 在LL旋转中，每个节点从当前位置向左移动一个位置。 - >单右旋转（RR旋转） 在RR Rotation中，每个节点从当前位置向右移动一个位置。 - >左右旋转（LR旋转） LR旋转是单个左旋转然后单个右旋转的组合。在LR Rotation中，首先每个节点从当前位置向左移动一个位置，然后向右移动一个位置。 - >左右旋转（RL旋转） RL旋转是单右旋转然后单左旋转的组合。在RL旋转中，首先每个节点从当前位置向右移动一个位置然后向左移动一个位置。

guide/chinese/algorithms/b-trees/index.md

@@ -0,0 +1,15 @@
+---
+title: B Trees
+localeTitle: B树
+---
+## B树
+
+# 介绍
+
+B-Tree是一种自我平衡的搜索树。在大多数其他自平衡搜索树（如AVL和红黑树）中，假设一切都在主存储器中。要理解B树的使用，我们必须考虑大量的数据，这些数据不适合主存。当键数很高时，以块的形式从磁盘读取数据。与主存储器访问时间相比，磁盘访问时间非常长。使用B-Trees的主要思想是减少磁盘访问次数。大多数树操作（搜索，插入，删除，最大，最小，..等）需要O（h）磁盘访问，其中h是树的高度。 B树是一棵肥胖的树。通过在B树节点中放置最大可能密钥，B树的高度保持较低。通常，B树节点大小保持等于磁盘块大小。由于B-Tree的h值较低，因此与平衡二进制搜索树（如AVL树，红黑树，等等）相比，大多数操作的总磁盘访问量显着减少。
+
+B树的属性： 1）所有叶子处于同一水平。 2）B树由术语最小度't'定义。 t的值取决于磁盘块大小。 3）除root之外的每个节点必须至少包含t-1个密钥。 Root可能包含最少1个密钥。 4）所有节点（包括根）最多可包含2t - 1个密钥。 5）节点的子节点数等于其中的键数加1。 6）节点的所有密钥按递增顺序排序。两个键k1和k2之间的子包含范围为k1和k2的所有键。 7）B-Tree从根增长和缩小，这与二进制搜索树不同。二元搜索树向下生长，也从向下收缩。 8）与其他平衡二进制搜索树一样，搜索，插入和删除的时间复杂度为O（Logn）。
+
+搜索： 搜索类似于二进制搜索树中的搜索。让要搜索的密钥为k。我们从root开始，递归地遍历。对于每个访问过的非叶节点，如果节点有密钥，我们只返回节点。否则，我们将重复到节点的适当子节点（就在第一个更大的键之前的子节点）。如果我们到达叶节点并且在叶节点中找不到k，则返回NULL。
+
+穿越： 遍历也类似于二叉树的Inorder遍历。我们从最左边的孩子开始，递归地打印最左边的孩子，然后对剩余的孩子和钥匙重复相同的过程。最后，递归打印最右边的孩子。

guide/chinese/algorithms/backtracking-algorithms/index.md

@@ -0,0 +1,53 @@
+---
+title: Backtracking Algorithms
+localeTitle: 回溯算法
+---
+# 回溯算法
+
+回溯是一种通用算法，用于查找某些计算问题的所有（或某些）解决方案，特别是约束满足问题，逐步构建候选解决方案，并在确定候选不能时立即放弃每个部分候选_（“回溯”）_可能完成一个有效的解决方案。
+
+### 示例问题（骑士游览问题）
+
+_骑士被放置在空板的第一块上，按照国际象棋的规则移动，必须完全访问每个方块一次。_
+
+###路径跟随Knight覆盖所有细胞 以下是8 x 8单元的棋盘。单元格中的数字表示骑士的移动数量。 [![骑士的旅行解决方案 - 由欧拉](https://upload.wikimedia.org/wikipedia/commons/d/df/Knights_tour_%28Euler%29.png)](https://commons.wikimedia.org/wiki/File:Knights_tour_(Euler).png)
+
+### 骑士之旅的天真算法
+
+朴素算法是逐个生成所有游览并检查生成的游览是否满足约束。
+```
+while there are untried tours 
+ { 
+   generate the next tour 
+   if this tour covers all squares 
+   { 
+      print this path; 
+   } 
+ } 
+```
+
+### 骑士巡回赛的回溯算法
+
+以下是奈特巡回赛问题的回溯算法。
+```
+If all squares are visited 
+    print the solution 
+ Else 
+   a) Add one of the next moves to solution vector and recursively 
+   check if this move leads to a solution. (A Knight can make maximum 
+   eight moves. We choose one of the 8 moves in this step). 
+   b) If the move chosen in the above step doesn't lead to a solution 
+   then remove this move from the solution vector and try other 
+   alternative moves. 
+   c) If none of the alternatives work then return false (Returning false 
+   will remove the previously added item in recursion and if false is 
+   returned by the initial call of recursion then "no solution exists" ) 
+```
+
+### 更多信息
+
+[维基百科](https://en.wikipedia.org/wiki/Backtracking)
+
+[极客4极客](http://www.geeksforgeeks.org/backtracking-set-1-the-knights-tour-problem/)
+
+[一个非常有趣的回溯介绍](https://www.hackerearth.com/practice/basic-programming/recursion/recursion-and-backtracking/tutorial/)

guide/chinese/algorithms/binary-search-trees/index.md

@@ -0,0 +1,269 @@
+---
+title: Binary Search Trees
+localeTitle: 二叉搜索树
+---
+## 二叉搜索树
+
+![二叉搜索树](https://cdn-images-1.medium.com/max/1320/0*x5o1G1UpM1RfLpyx.png)
+
+树是由具有以下特征的节点组成的数据结构：
+
+1.  每棵树都有一个根节点（在顶部）有一些值。
+2.  根节点具有零个或多个子节点。
+3.  每个子节点都有零个或多个子节点，依此类推。这会在树中创建一个子树。每个节点都有自己的子树，由他的孩子和他们的孩子等组成。这意味着每个节点本身都可以是一棵树。
+
+二叉搜索树（BST）添加了以下两个特征：
+
+1.  每个节点最多包含两个子节点。
+2.  对于每个节点，其左后代节点的值小于当前节点的值，而当前节点的值小于右后代节点（如果有的话）。
+
+BST建立在[二进制搜索](https://guide.freecodecamp.org/algorithms/search-algorithms/binary-search)算法的基础上，允许快速查找，插入和删除节点。它们的设置方式意味着，平均而言，每次比较都允许操作跳过大约一半的树，因此每次查找，插入或删除都需要与树中存储的项目数的对数成比例的时间， `O(log n)` 。然而，有时候最糟糕的情况可能发生，当树不平衡时，所有这三个函数的时间复杂度都是`O(n)` 。这就是为什么自平衡树（AVL，红黑等）比基本BST更有效的原因。
+
+**最糟糕的情况示例：**当您继续添加_始终_大于节点之前的节点（它的父节点）时会发生这种情况，当您始终添加值低于其父节点的节点时，也会发生同样的情况。
+
+### BST的基本操作
+
+*   创建：创建一个空树。
+*   插入：在树中插入一个节点。
+*   搜索：在树中搜索节点。
+*   删除：从树中删除节点。
+
+#### 创建
+
+最初创建没有任何节点的空树。必须指向根节点的变量/标识符用`NULL`值初始化。
+
+#### 搜索
+
+您总是开始在根节点搜索树并从那里向下移动。您将每个节点中的数据与您要查找的数据进行比较。如果比较的节点不匹配，那么您可以继续使用右子项或左子项，这取决于以下比较的结果：如果您要搜索的节点低于您要比较的节点，你继续前往左边的孩子，否则（如果它更大）你会去找右边的孩子。为什么？因为BST是结构化的（根据其定义），正确的孩子总是比父母大，而左孩子总是较小。
+
+#### 插入
+
+它与搜索功能非常相似。您再次从树的根开始并递归下去，搜索插入新节点的正确位置，方法与搜索功能中说明的相同。如果树中已存在具有相同值的节点，则可以选择是否插入副本。有些树允许重复，有些则不允许。这取决于具体的实施。
+
+#### 删除
+
+当您尝试删除节点时，可能会发生3种情况。如果有，
+
+1.  没有子树（没有孩子）：这个是最简单的子树。您只需删除节点，无需任何其他操作。
+2.  一个子树（一个子树）：您必须确保在删除节点后，其子节点将连接到已删除节点的父节点。
+3.  两个子树（两个子节点）：您必须找到并替换要删除的节点及其后续节点（右侧子树中最常用的节点）。
+
+创建树的时间复杂度为`O(1)` 。搜索，插入或删除节点的时间复杂度取决于树`h`的高度，因此最坏的情况是`O(h)` 。
+
+#### 节点的前身
+
+前置任务可以被描述为在您当前所在节点之前的节点。要查找当前节点的前一个节点，请查看左子树中最右侧/最大的叶节点。
+
+#### 节点的后继者
+
+后继者可以被描述为在您当前所在节点之后的节点。要查找当前节点的后继节点，请查看右侧子树中最左侧/最小的叶节点。
+
+### 特殊类型的BT
+
+*   堆
+*   红黑树
+*   B树
+*   Splay树
+*   N-ary树
+*   Trie（基数树）
+
+### 运行
+
+**数据结构：数组**
+
+*   最坏情况表现： `O(log n)`
+*   最佳表现： `O(1)`
+*   平均表现： `O(log n)`
+*   最坏情况的空间复杂度： `O(1)`
+
+其中`n`是BST中的节点数。
+
+### BST的实施
+
+这是一个BST节点的定义，它有一些数据，引用它的左右子节点。
+
+```c
+struct node { 
+   int data; 
+   struct node *leftChild; 
+   struct node *rightChild; 
+ }; 
+```
+
+#### 搜索操作
+
+每当要搜索元素时，从根节点开始搜索。然后，如果数据小于键值，则在左子树中搜索元素。否则，搜索右子树中的元素。对每个节点遵循相同的算法。
+
+```c
+struct node* search(int data){ 
+   struct node *current = root; 
+   printf("Visiting elements: "); 
+ 
+   while(current->data != data){ 
+ 
+      if(current != NULL) { 
+         printf("%d ",current->data); 
+ 
+         //go to left tree 
+         if(current->data > data){ 
+            current = current->leftChild; 
+         }//else go to right tree 
+         else { 
+            current = current->rightChild; 
+         } 
+ 
+         //not found 
+         if(current == NULL){ 
+            return NULL; 
+         } 
+      } 
+   } 
+   return current; 
+ } 
+```
+
+#### 插入操作
+
+无论何时插入元素，首先要找到其正确的位置。从根节点开始搜索，然后如果数据小于键值，则在左子树中搜索空位置并插入数据。否则，在右子树中搜索空位置并插入数据。
+
+```c
+void insert(int data) { 
+   struct node *tempNode = (struct node*) malloc(sizeof(struct node)); 
+   struct node *current; 
+   struct node *parent; 
+ 
+   tempNode->data = data; 
+   tempNode->leftChild = NULL; 
+   tempNode->rightChild = NULL; 
+ 
+   //if tree is empty 
+   if(root == NULL) { 
+      root = tempNode; 
+   } else { 
+      current = root; 
+      parent = NULL; 
+ 
+      while(1) { 
+         parent = current; 
+ 
+         //go to left of the tree 
+         if(data < parent->data) { 
+            current = current->leftChild; 
+            //insert to the left 
+ 
+            if(current == NULL) { 
+               parent->leftChild = tempNode; 
+               return; 
+            } 
+         }//go to right of the tree 
+         else { 
+            current = current->rightChild; 
+ 
+            //insert to the right 
+            if(current == NULL) { 
+               parent->rightChild = tempNode; 
+               return; 
+            } 
+         } 
+      } 
+   } 
+ } 
+```
+
+二进制搜索树（BST）还使我们能够快速访问前辈和后继者。 前置任务可以被描述为在您当前所在节点之前的节点。
+
+*   要查找当前节点的前任，请查看左子树中最右边/最大的叶节点。 后继者可以被描述为在您当前所在节点之后的节点。
+*   要查找当前节点的后继节点，请查看右子树中最左侧/最小的叶节点。
+
+### 让我们看一下在树上运行的几个过程。
+
+由于树是递归定义的，因此编写在树本身上递归的例程是很常见的。
+
+因此，例如，如果我们想要计算树的高度，即根节点的高度，我们可以继续并递归地执行，通过树。所以我们可以说：
+
+*   例如，如果我们有一个nil树，那么它的高度为0。
+*   否则，我们是1加上左子树和右子树的最大值。
+*   因此，如果我们查看一个叶子，例如，那个高度将是1，因为左子的高度是nil，是0，nil右子的高度也是0.所以最大值是0，然后是1加0。
+
+#### 高度（树）算法
+```
+if tree = nil: 
+    return 0 
+ return 1 + Max(Height(tree.left),Height(tree.right)) 
+```
+
+#### 这是C ++中的代码
+```
+int maxDepth(struct node* node) 
+ { 
+    if (node==NULL) 
+        return 0; 
+   else 
+   { 
+       int rDepth = maxDepth(node->right); 
+       int lDepth = maxDepth(node->left); 
+ 
+       if (lDepth > rDepth) 
+       { 
+           return(lDepth+1); 
+       } 
+       else 
+       { 
+            return(rDepth+1); 
+       } 
+   } 
+ } 
+```
+
+我们还可以考虑计算树的大小，即树的节点数。
+
+*   同样，如果我们有一个零树，我们有零节点。
+*   否则，我们有左子节点中的节点数加上我们自己的1节点加上右子节点中的节点数。所以1加上左树的大小加上右树的大小。
+
+#### 大小（树）算法
+```
+if tree = nil 
+    return 0 
+ return 1 + Size(tree.left) + Size(tree.right) 
+```
+
+#### 这是C ++中的代码
+```
+int treeSize(struct node* node) 
+ { 
+    if (node==NULL) 
+        return 0; 
+    else 
+        return 1+(treeSize(node->left) + treeSize(node->right)); 
+ } 
+```
+
+### 关于freeCodeCamp YouTube频道的相关视频
+
+*   [二叉搜索树](https://youtu.be/5cU1ILGy6dM)
+*   [二叉搜索树：遍历和高度](https://youtu.be/Aagf3RyK3Lw)
+
+### 以下是常见的二叉树类型：
+
+完整二叉树/严格二叉树：如果每个节点只有0或2个子节点，则二叉树已满或严格。
+```
+           18 
+       /       \ 
+     15         30 
+    /  \        /  \ 
+  40    50    100   40 
+```
+
+在完全二进制树中，叶节点的数量等于内部节点的数量加1。
+
+完整的二进制树：二进制树是完整的二进制树，如果所有级别都被完全填充，除了可能是最后一级，最后一级是尽可能保留所有键
+```
+           18 
+       /       \ 
+     15         30 
+    /  \        /  \ 
+  40    50    100   40 
+ /  \   / 
+ 8   7  9 
+
+```

guide/chinese/algorithms/boundary-fill/index.md

@@ -0,0 +1,43 @@
+---
+title: Boundary Fill
+localeTitle: 边界填充
+---
+## 边界填充
+
+边界填充是计算机图形中经常使用的算法，用于在具有相同边界的闭合多边形内填充所需颜色 所有方面的颜色。
+
+最接近的算法实现是基于堆栈的递归函数。
+
+### 工作：
+
+问题非常简单，通常遵循以下步骤：
+
+1.  取起点和边界颜色的位置。
+2.  决定是否想要沿4个方向（N，S，W，E）或8个方向（N，S，W，E，NW，NE，SW，SE）行进。
+3.  选择填充颜色。
+4.  沿着那些方向旅行。
+5.  如果您着陆的像素不是填充颜色或边界颜色，请将其替换为填充颜色。
+6.  重复4和5，直到你到达边界内的任何地方。
+
+### 某些限制：
+
+*   对于多边形的所有边，边界颜色应该相同。
+*   起点应在多边形内。
+
+### 代码片段：
+```
+void boundary_fill(int pos_x, int pos_y, int boundary_color, int fill_color) 
+ { 
+   current_color= getpixel(pos_x,pos_y);  //get the color of the current pixel position 
+   if( current_color!= boundary_color || currrent_color != fill_color) // if pixel not already filled or part of the boundary then 
+   { 
+     putpixel(pos_x,pos_y,fill_color);  //change the color for this pixel to the desired fill_color 
+     boundary_fill(pos_x + 1, pos_y,boundary_color,fill_color);  // perform same function for the east pixel 
+     boundary_fill(pos_x - 1, pos_y,boundary_color,fill_color);  // perform same function for the west pixel 
+     boundary_fill(pos_x, pos_y + 1,boundary_color,fill_color);  // perform same function for the north pixel 
+     boundary_fill(pos_x, pos_y - 1,boundary_color,fill_color);  // perform same function for the south pixel 
+    } 
+ } 
+```
+
+从给定的代码中，您可以看到，对于您登陆的任何像素，首先要检查是否可以将其更改为fill\_color，然后执行此操作 对于它的邻居，直到检查了边界内的所有像素。

guide/chinese/algorithms/brute-force-algorithms/index.md

@@ -0,0 +1,17 @@
+---
+title: Brute Force Algorithms
+localeTitle: 蛮力算法
+---
+## 蛮力算法
+
+暴力算法指的是一种编程风格，它不包括任何提高性能的快捷方式，而是依靠纯粹的计算能力来尝试所有可能性，直到找到问题的解决方案。
+
+一个典型的例子是旅行商问题（TSP）。假设销售人员需要访问全国10个城市。如何确定访问城市的顺序，以使旅行的总距离最小化？蛮力解决方案只是计算每条可能路线的总距离，然后选择最短的路线。这不是特别有效，因为可以通过巧妙的算法消除许多可能的路线。
+
+另一个例子：5位密码，在最坏的情况下，需要10 5次尝试才能破解。
+
+蛮力的时间复杂度为**O（n \* m）** 。因此，如果我们使用暴力搜索一串'm'字符中的'n'个字符串，那么我们需要尝试n \* m次。
+
+#### 更多信息：
+
+[维基百科](https://en.wikipedia.org/wiki/Brute-force_search)

guide/chinese/algorithms/divide-and-conquer-algorithms/index.md

@@ -0,0 +1,33 @@
+---
+title: Divide and Conquer Algorithms
+localeTitle: 划分和征服算法
+---
+## 划分和征服算法
+
+分而治之| （介绍） 像贪婪和动态编程一样，分而治之是一种算法范式。典型的Divide and Conquer算法使用以下三个步骤解决了问题。
+
+1.  除以：将给定问题分解为相同类型的子问题。
+2.  征服：递归解决这些子问题
+3.  结合：适当地结合答案
+
+以下是一些标准算法，即Divide和Conquer算法。
+
+1）二进制搜索是一种搜索算法。在每个步骤中，算法将输入元素x与数组中的中间元素的值进行比较。如果值匹配，则返回middle的索引。否则，如果x小于中间元素，则算法在中间元素的左侧重复，否则在中间元素的右侧重复。
+
+2）Quicksort是一种排序算法。该算法选择一个枢轴元素，重新排列数组元素，使得小于拾取的枢轴元素的所有元素移动到枢轴的左侧，并且所有更大的元素移动到右侧。最后，算法递归地对枢轴元素左右两侧的子阵列进行排序。
+
+3）Merge Sort也是一种排序算法。算法将数组分成两半，递归地对它们进行排序，最后合并两个排序的一半。
+
+4）最近的一对点问题是在xy平面中的一组点中找到最接近的点对。通过计算每对点的距离并比较距离以找到最小值，可以在O（n ^ 2）时间内解决该问题。 Divide and Conquer算法解决了O（nLogn）时间内的问题。
+
+5）Strassen算法是一种有效的算法来乘以两个矩阵。一个乘以两个矩阵的简单方法需要3个嵌套循环，并且是O（n ^ 3）。 Strassen算法在O（n ^ 2.8974）时间内乘以两个矩阵。
+
+6）Cooley-Tukey快速傅里叶变换（FFT）算法是最常用的FFT算法。它是一种分而治之的算法，适用于O（nlogn）时间。
+
+7）Karatsuba算法是第一个比二次“小学”算法渐近快的乘法算法。它将两个n位数字的乘法减少到最多n ^ 1.585（这是基数2中3的log的近似值）单位数产品。因此，它比传统算法更快，后者需要n ^ 2个单位数产品。
+
+### 分而治之（D＆C）与动态编程（DP）
+
+两种范式（D＆C和DP）将给定问题划分为子问题并解决子问题。如何针对特定问题选择其中一个？当多次评估相同的子问题时，应使用Divide and Conquer。否则应使用动态编程或记忆。
+
+例如，二进制搜索是一种Divide and Conquer算法，我们再也不会评估相同的子问题。另一方面，为了计算第n个斐波那契数，应该首选动态规划。

guide/chinese/algorithms/embarassingly-parallel-algorithms/index.md

@@ -0,0 +1,16 @@
+---
+title: Embarassingly Parallel Algorithms
+localeTitle: 令人尴尬的并行算法
+---
+## 令人尴尬的并行算法
+
+在并行编程中，令人尴尬的并行算法是在进程之间不需要通信或依赖的算法。与需要在任务之间进行通信的分布式计算问题（尤其是中间结果）不同，令人尴尬的并行算法很容易在缺乏真正超级计算机集群中使用的特殊基础结构的服务器场上执行。由于令人尴尬的并行算法的性质，它们非常适合基于互联网的大型分布式平台，并且不会受到并行减速的影响。令人尴尬的并行问题的反面是固有的串行问题，根本无法并行化。 令人尴尬的并行算法的理想情况可归纳如下：
+
+*   在计算开始之前定义所有子问题或任务。
+*   所有子解决方案都存储在独立的存储器位置（变量，数组元素）中。
+*   因此，子解决方案的计算是完全独立的。
+*   如果计算需要一些初始或最终的通信，那么我们称之为几乎令人尴尬的并行。
+
+许多人可能会想到“令人尴尬”一词的词源。在这种情况下，令人尴尬的是与尴尬无关;事实上，这意味着过多 - 这里指的是“令人尴尬的容易”的并行化问题。
+
+令人尴尬的并行问题的一个常见例子是由图形处理单元处理的3d视频渲染，其中每个帧或像素可以在没有相互依赖性的情况下处理。其他一些例子是蛋白质折叠软件，可以在任何计算机上运行，​​每台机器完成一小部分工作，生成所有子集，随机数和蒙特卡罗模拟。

guide/chinese/algorithms/evaluating-polynomials-direct-analysis/index.md

@@ -0,0 +1,11 @@
+---
+title: Evaluating Polynomials Direct Analysis
+localeTitle: 评估多项式直接分析
+---
+## 评估多项式直接分析
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/algorithms/evaluating-polynomials-direct-analysis/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/algorithms/evaluating-polynomials-synthetic-division/index.md

@@ -0,0 +1,11 @@
+---
+title: Evaluating Polynomials Synthetic Division
+localeTitle: 评估多项式综合分裂
+---
+## 评估多项式综合分裂
+
+这是一个存根。 [帮助我们的社区扩展它](https://github.com/freecodecamp/guides/tree/master/src/pages/algorithms/evaluating-polynomials-synthetic-division/index.md) 。
+
+[这种快速风格指南有助于确保您的拉取请求被接受](https://github.com/freecodecamp/guides/blob/master/README.md) 。
+
+#### 更多信息：

guide/chinese/algorithms/exponentiation/index.md

@@ -0,0 +1,61 @@
+---
+title: Exponentiation
+localeTitle: 幂
+---
+## 幂
+
+给定两个整数a和n，写一个函数来计算^ n。
+
+#### 码
+
+算法范式：分而治之。
+
+```C
+int power(int x, unsigned int y) { 
+    if (y == 0) 
+        return 1; 
+    else if (y%2 == 0) 
+        return power(x, y/2)*power(x, y/2); 
+    else 
+        return x*power(x, y/2)*power(x, y/2); 
+ } 
+```
+
+时间复杂度：O（n）|空间复杂度：O（1）
+
+#### 优化的解决方案：O（logn）
+
+```C
+int power(int x, unsigned int y) { 
+    int temp; 
+    if( y == 0) 
+        return 1; 
+    temp = power(x, y/2); 
+    if (y%2 == 0) 
+        return temp*temp; 
+    else 
+        return x*temp*temp; 
+ } 
+```
+
+## 模块化指数
+
+给定三个数字x，y和p，计算（x ^ y）％p
+
+```C
+int power(int x, unsigned int y, int p) { 
+    int res = 1; 
+    x = x % p; 
+    while (y > 0) { 
+        if (y & 1) 
+            res = (res*x) % p; 
+ 
+        // y must be even now 
+        y = y>>1; 
+        x = (x*x) % p; 
+    } 
+    return res; 
+ } 
+```
+
+时间复杂度：O（Log y）。

guide/chinese/algorithms/flood-fill/index.md

@@ -0,0 +1,100 @@
+---
+title: Flood Fill Algorithm
+localeTitle: 洪水填充算法
+---
+## 洪水填充算法
+
+洪水填充是一种主要用于确定连接到多维阵列中给定节点的有界区域的算法。它是 与绘图程序中的桶工具非常相似。
+
+最接近的算法实现是基于堆栈的递归函数，这就是我们要谈的内容 下一个。
+
+### 它是如何工作的？
+
+问题非常简单，通常遵循以下步骤：
+
+1.  采取起点的位置。
+2.  决定是否想要沿4个方向（ **N，S，W，E** ）或8个方向（ **N，S，W，E，NW，NE，SW，SE** ）行进。
+3.  选择替换颜色和目标颜色。
+4.  沿着那些方向旅行。
+5.  如果您着陆的瓷砖是目标，请使用所选颜色重新获得。
+6.  重复4和5，直到你到达边界内的任何地方。
+
+我们以下面的数组为例：
+
+![替代文字](https://github.com/firealex2/Codingame/blob/master/small%208%20grid%20paintefffd.png)
+
+红色方块是起点，灰色方块是所谓的墙。
+
+有关更多详细信息，请参阅此处描述该函数的代码：
+
+```c++
+int wall = -1; 
+ 
+ void flood_fill(int pos_x, int pos_y, int target_color, int color) 
+ { 
+ 
+   if(a[pos_x][pos_y] == wall || a[pos_x][pos_y] == color) // if there is no wall or if i haven't been there 
+      return;                                              // already go back 
+ 
+   if(a[pos_x][pos_y] != target_color) // if it's not color go back 
+      return; 
+ 
+   a[pos_x][pos_y] = color; // mark the point so that I know if I passed through it. 
+ 
+   flood_fill(pos_x + 1, pos_y, color);  // then i can either go south 
+   flood_fill(pos_x - 1, pos_y, color);  // or north 
+   flood_fill(pos_x, pos_y + 1, color);  // or east 
+   flood_fill(pos_x, pos_y - 1, color);  // or west 
+ 
+   return; 
+ 
+ } 
+```
+
+如上所示，我的出发点是（4,4）。在调用起始坐标**x = 4**和**y = 4**的函数后， 我可以开始检查当场是否有墙壁或颜色。如果这是有效的我用一个**“颜色”**标记斑点 并开始检查其他的adiacent正方形。
+
+向南走，我们将指向（5,4）并且该功能再次运行。
+
+### 运动问题
+
+我一直认为使用新学习的算法解决（或更多）问题是完全理解的最佳方式 这个概念。
+
+所以这是一个：
+
+**声明：**
+
+在二维数组中，您将获得n个**“孤岛”** 。试着找到岛上最大的区域 相应的岛号。 0标记水和1和n之间的任何其他x标记距表面对应的一个方格 到岛屿x。
+
+**输入**
+
+*   **n** - 岛屿数量。
+*   **l，c** - 矩阵的尺寸。
+*   接下来的**l**行， **c**号给出矩阵的第**l**行。
+
+**产量**
+
+*   **i** - 面积最大的岛屿数量。
+*   **A** - **我**岛的**一个**区域。
+
+**例如：**
+
+您有以下输入：
+
+```c++
+2 4 4 
+ 0 0 0 1 
+ 0 0 1 1 
+ 0 0 0 2 
+ 2 2 2 2 
+```
+
+你会得到岛屿没有。 2作为最大的岛屿，面积为5平方。
+
+### 提示
+
+问题很简单，但这里有一些提示：
+```
+1. Use the flood-fill algorithm whenever you encounter a new island. 
+ 2. As opposed to the sample code, you should go through the area of the island and not on the ocean (0 tiles). 
+
+```

guide/chinese/algorithms/graph-algorithms/breadth-first-search/index.md

@@ -0,0 +1,125 @@
+---
+title: Breadth First Search (BFS)
+localeTitle: 广度优先搜索（BFS）
+---
+## 广度优先搜索（BFS）
+
+广度优先搜索是最简单的图算法之一。它首先检查当前节点，然后通过将其后继添加到下一级别来扩展它，从而遍历图形。在移动到下一级别之前，对当前级别中的所有节点重复该过程。如果找到解决方案，搜索将停止。
+
+### 可视化
+
+![](https://upload.wikimedia.org/wikipedia/commons/4/46/Animated_BFS.gif)
+
+### 评估
+
+空间复杂度：O（n）
+
+更糟糕的案例时间复杂性：O（n）
+
+广度优先搜索在有限的节点集上完成，并且如果从一个节点移动到另一个节点的成本是恒定的则是最优的。
+
+### BFS实现的C ++代码
+
+```cpp
+// Program to print BFS traversal from a given 
+ // source vertex. BFS(int s) traverses vertices 
+ // reachable from s. 
+ #include<iostream> 
+ #include <list> 
+ 
+ using namespace std; 
+ 
+ // This class represents a directed graph using 
+ // adjacency list representation 
+ class Graph 
+ { 
+    int V;    // No. of vertices 
+ 
+    // Pointer to an array containing adjacency 
+    // lists 
+    list<int> *adj; 
+ public: 
+    Graph(int V);  // Constructor 
+ 
+    // function to add an edge to graph 
+    void addEdge(int v, int w); 
+ 
+    // prints BFS traversal from a given source s 
+    void BFS(int s); 
+ }; 
+ 
+ Graph::Graph(int V) 
+ { 
+    this->V = V; 
+    adj = new list<int>[V]; 
+ } 
+ 
+ void Graph::addEdge(int v, int w) 
+ { 
+    adj[v].push_back(w); // Add w to v's list. 
+ } 
+ 
+ void Graph::BFS(int s) 
+ { 
+    // Mark all the vertices as not visited 
+    bool *visited = new bool[V]; 
+    for(int i = 0; i < V; i++) 
+        visited[i] = false; 
+ 
+    // Create a queue for BFS 
+    list<int> queue; 
+ 
+    // Mark the current node as visited and enqueue it 
+    visited[s] = true; 
+    queue.push_back(s); 
+ 
+    // 'i' will be used to get all adjacent 
+    // vertices of a vertex 
+    list<int>::iterator i; 
+ 
+    while(!queue.empty()) 
+    { 
+        // Dequeue a vertex from queue and print it 
+        s = queue.front(); 
+        cout << s << " "; 
+        queue.pop_front(); 
+ 
+        // Get all adjacent vertices of the dequeued 
+        // vertex s. If a adjacent has not been visited, 
+        // then mark it visited and enqueue it 
+        for (i = adj[s].begin(); i != adj[s].end(); ++i) 
+        { 
+            if (!visited[*i]) 
+            { 
+                visited[*i] = true; 
+                queue.push_back(*i); 
+            } 
+        } 
+    } 
+ } 
+ 
+ // Driver program to test methods of graph class 
+ int main() 
+ { 
+    // Create a graph given in the above diagram 
+    Graph g(4); 
+    g.addEdge(0, 1); 
+    g.addEdge(0, 2); 
+    g.addEdge(1, 2); 
+    g.addEdge(2, 0); 
+    g.addEdge(2, 3); 
+    g.addEdge(3, 3); 
+ 
+    cout << "Following is Breadth First Traversal " 
+         << "(starting from vertex 2) \n"; 
+    g.BFS(2); 
+ 
+    return 0; 
+ } 
+```
+
+#### 更多信息：
+
+[图表](https://github.com/freecodecamp/guides/computer-science/data-structures/graphs/index.md)
+
+[深度优先搜索（DFS）](https://github.com/freecodecamp/guides/tree/master/src/pages/algorithms/graph-algorithms/depth-first-search/index.md)

guide/chinese/algorithms/graph-algorithms/depth-first-search/index.md

@@ -0,0 +1,105 @@
+---
+title: Depth First Search (DFS)
+localeTitle: 深度优先搜索（DFS）
+---
+## 深度优先搜索（DFS）
+
+深度优先搜索是最简单的图算法之一。它通过首先检查当前节点然后移动到其中一个成员来重复该过程来遍历图形。如果当前节点没有要检查的进程，我们将返回其前身并继续进程（通过移动到另一个进程）。如果找到解决方案，搜索将停止。
+
+### 可视化
+
+![](https://upload.wikimedia.org/wikipedia/commons/7/7f/Depth-First-Search.gif)
+
+### 实现（C ++ 14）
+
+\`\`\`C ++
+
+# 包括
+
+# 包括
+
+# 包括
+
+# 包括
+
+使用命名空间std;
+
+class Graph { int v; //顶点数
+```
+// pointer to a vector containing adjacency lists 
+ vector < int > *adj; 
+```
+
+上市： 图（int v）; //构造函数
+```
+// function to add an edge to graph 
+ void add_edge(int v, int w); 
+ 
+ // prints dfs traversal from a given source `s` 
+ void dfs(); 
+ void dfs_util(int s, vector < bool> &visited); 
+```
+
+};
+
+Graph :: Graph（int v）{ 这 - > v = v; adj = new vector <int> \[v\]; }
+
+void Graph :: add _edge（int u，int v）{ adj \[u\] .push_ back（v）; //将v添加到你的列表中 adj \[v\] .push _back（v）; //将你添加到v的列表中（如果图表被定向，则删除此语句！） } void Graph :: dfs（）{ //访问过的向量 - 跟踪DFS期间访问的节点 vector <bool> visit（v，false）; //将所有节点/顶点标记为未访问 for（int i = 0; i <v; i ++） 如果（！参观\[1\]） dfs_ util（i，visited）; } //注意这里使用call-by-reference的用法！ void Graph :: dfs\_util（int s，vector <bool>＆visited）{ //将当前节点/顶点标记为已访问 访问过\[s\] =真; //将其输出到标准输出（屏幕） cout << s <<“”;
+```
+// traverse its adjacency list and recursively call dfs_util for all of its neighbours! 
+ // (only if the neighbour has not been visited yet!) 
+ for(vector < int > :: iterator itr = adj[s].begin(); itr != adj[s].end(); itr++) 
+    if(!visited[*itr]) 
+        dfs_util(*itr, visited); 
+```
+
+}
+
+int main（） { //使用我们上面定义的Graph类创建图形 图g（4）; g.add _edge（0,1）; g.add_ edge（0,2）; g.add _edge（1,2）; g.add_ edge（2,0）; g.add _edge（2,3）; g.add_ edge（3,3）;
+```
+cout << "Following is the Depth First Traversal of the provided graph" 
+     << "(starting from vertex 0): "; 
+ g.dfs(); 
+ // output would be: 0 1 2 3 
+ return 0; 
+```
+
+}
+```
+### Evaluation 
+ 
+ Space Complexity: O(n) 
+ 
+ Worse Case Time Complexity: O(n) 
+ Depth First Search is complete on a finite set of nodes. I works better on shallow trees. 
+ 
+ ### Implementation of DFS in C++ 
+```
+
+C ++
+
+# 包括
+
+# 包括
+
+# 包括
+
+使用命名空间std;
+
+struct Graph { int v; bool \* _adj; 上市： Graph（int vcount）; void addEdge（int u，int v）; void deleteEdge（int u，int v）; 向量_ _DFS（int s）; void DFSUtil（int s，vector_ _＆DFS，矢量_ _＆访问）; }; Graph :: Graph（int vcount）{ this-> v = vcount; this-> adj = new bool_ \[vcount\]; for（int i = 0; i
+
+void Graph :: addEdge（int u，int w）{ 这 - >形容词\[U\] \[W\] = TRUE; 这 - >形容词\[W\] \[U\] = TRUE; }
+
+void Graph :: deleteEdge（int u，int w）{ 这 - >形容词\[U\] \[W\] = FALSE; 这 - >形容词\[W\] \[U\] = FALSE; }
+
+void Graph :: DFSUtil（int s，vector ＆dfs，矢量 ＆访问）{ 访问了\[S\] = TRUE; dfs.push\_back（一个或多个）; for（int i = 0; i V;我++）{ if（this-> adj \[s\] \[i\] == true && visited \[i\] == false） DFSUtil（I，DFS，访问）; } }
+
+向量 Graph :: DFS（int s）{ 向量访问（这 - > v）的; 向量 DFS; DFSUtil（S，DFS，访问）; return dfs; } \`\`\`
+
+#### 更多信息：
+
+[图表](https://github.com/freecodecamp/guides/computer-science/data-structures/graphs/index.md)
+
+[广度优先搜索（BFS）](https://github.com/freecodecamp/guides/tree/master/src/pages/algorithms/graph-algorithms/breadth-first-search/index.md)
+
+[深度优先搜索（DFS） - 维基百科](https://en.wikipedia.org/wiki/Depth-first_search)

guide/chinese/algorithms/graph-algorithms/dijkstra/index.md

@@ -0,0 +1,95 @@
+---
+title: Dijkstra's Algorithm
+localeTitle: Dijkstra的算法
+---
+# Dijkstra的算法
+
+Dijkstra算法是由EW Dijkstra提出的图算法。它在具有非负边的图中找到单源最短路径。（为什么？）
+
+我们创建了2个数组：visit和distance，它们分别记录是否访问了顶点以及距离源顶点的最小距离。最初访问的数组被指定为false，距离指定为无限。
+
+我们从源顶点开始。设当前顶点为u，其相邻顶点为v。现在对于与u相邻的每个v，如果之前未访问过该距离并且距离u的距离小于其当前距离，则更新距离。然后我们选择距离最小且未访问过的下一个顶点。
+
+优先级队列通常用于在最短的时间内满足最后的要求。下面是使用Java中的优先级队列实现相同的想法。
+
+```java
+import java.util.*; 
+ public class Dijkstra { 
+    class Graph { 
+    LinkedList<Pair<Integer>> adj[]; 
+    int n; // Number of vertices. 
+    Graph(int n) { 
+        this.n = n; 
+        adj = new LinkedList[n]; 
+        for(int i = 0;i<n;i++) adj[i] = new LinkedList<>(); 
+    } 
+    // add a directed edge between vertices a and b with cost as weight 
+    public void addEdgeDirected(int a, int b, int cost) { 
+        adj[a].add(new Pair(b, cost)); 
+    } 
+    public void addEdgeUndirected(int a, int b, int cost) { 
+        addEdgeDirected(a, b, cost); 
+        addEdgeDirected(b, a, cost); 
+    } 
+    } 
+    class Pair<E> { 
+    E first; 
+    E second; 
+    Pair(E f, E s) { 
+        first = f; 
+        second = s; 
+    } 
+    } 
+ 
+    // Comparator to sort Pairs in Priority Queue 
+    class PairComparator implements Comparator<Pair<Integer>> { 
+    public int compare(Pair<Integer> a, Pair<Integer> b) { 
+        return a.second - b.second; 
+    } 
+    } 
+ 
+    // Calculates shortest path to each vertex from source and returns the distance 
+    public int[] dijkstra(Graph g, int src) { 
+    int distance[] = new int[gn]; // shortest distance of each vertex from src 
+    boolean visited[] = new boolean[gn]; // vertex is visited or not 
+    Arrays.fill(distance, Integer.MAX_VALUE); 
+    Arrays.fill(visited, false); 
+    PriorityQueue<Pair<Integer>> pq = new PriorityQueue<>(100, new PairComparator()); 
+        pq.add(new Pair<Integer>(src, 0)); 
+    distance[src] = 0; 
+    while(!pq.isEmpty()) { 
+        Pair<Integer> x = pq.remove(); // Extract vertex with shortest distance from src 
+        int u = x.first; 
+        visited[u] = true; 
+        Iterator<Pair<Integer>> iter = g.adj[u].listIterator(); 
+        // Iterate over neighbours of u and update their distances 
+        while(iter.hasNext()) { 
+        Pair<Integer> y = iter.next(); 
+        int v = y.first; 
+        int weight = y.second; 
+        // Check if vertex v is not visited 
+        // If new path through u offers less cost then update distance array and add to pq 
+        if(!visited[v] && distance[u]+weight<distance[v]) { 
+            distance[v] = distance[u]+weight; 
+            pq.add(new Pair(v, distance[v])); 
+        } 
+        } 
+    } 
+    return distance; 
+    } 
+ 
+    public static void main(String args[]) { 
+    Dijkstra d = new Dijkstra(); 
+    Dijkstra.Graph g = d.new Graph(4); 
+    g.addEdgeUndirected(0, 1, 2); 
+    g.addEdgeUndirected(1, 2, 1); 
+    g.addEdgeUndirected(0, 3, 6); 
+    g.addEdgeUndirected(2, 3, 1); 
+    g.addEdgeUndirected(1, 3, 3); 
+ 
+    int dist[] = d.dijkstra(g, 0); 
+    System.out.println(Arrays.toString(dist)); 
+    } 
+ } 
+
+```