Scrum敏捷开发

Pair-Programming，结对编程。在敏捷开发中，作任何事情都是Pair 的，包括分析、写测试、写实现代码或
者重构。Pair 作事有不少好处，两我的在一块儿探讨很容易产生思想的火花，也不容易走上偏路。在咱们公司，还
有不少事都是Pair 来作，好比Pair 学习，Pair 翻译，Pair 作PPT，关于这个话题，钱钱同窗有一篇颇有名的文章
对它进行介绍，名为Pair Programming (结对编程)。
Stand up，站立会议。天天早上，项目组的全部成员都会站立进行一次会议，因为是站立的，因此时间不会
很长，通常来讲是15-20 分钟。会议的内容并非需求分析、任务分配等，而是每一个人都回答三个问题：1. 你昨
天作了什么？2. 你今天要作什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工做内容，
若是有人曾经遇到过和你相似的问题，那么在站立会议后，他就会和你进行讨论。
Frequent Releases，小版本发布。在敏捷开发中，不会出现这种状况，拿到需求之后就闭门造车，直到最后才
将产品交付给客户，而是尽可能多的产品发布，通常以周、月为单位。这样，客户每隔一段时间就会拿到发布的产
品进行试用，而咱们能够从客户那获得更多的反馈来改进产品。正由于发布频繁，每个版本新增的功能简单，
不须要复杂的设计，这样文档和设计就在很大程度上简化了。又由于简单设计，没有复杂的架构，因此客户有新
的需求或者需求进行变更，也能很快的适应。
Minimal Documentation，较少的文档。其实敏捷开发中并非没有文档，而是有大量的文档，即测试。这些
测试代码真实的反应了客户的需求以及系统API 的用法，若是有新人加入团队，最快的熟悉项目的方法就是给他
看测试代码，而比一边看着文档一边进行debug 要高效。若是用书面文档或者注释，某天代码变化了，须要对这
些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的状况，这更加会让人迷惑。而在敏捷中并不
会出现，由于只有测试变化了，代码才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？
通常来讲好的代码不是须要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就能
够看懂，这时候根本不须要对代码进行任何注释。若你以为这段代码不加注释的话别人可能看不懂，就表示设计
还不够简单，须要对它进行重构。
Collaborative Focus，以合做为中心，表现为代码共享。在敏捷开发中，代码是归团队全部而不是哪些模块的
代码属于哪些人，每一个人都有权利得到系统任何一部分的代码而后修改它，若是有人看到某些代码不爽的话，那
他可以对这部分代码重构而不须要征求代码做者的赞成，极可能也不知道是谁写的这部分代码。这样每一个人都能
熟悉系统的代码，即便团队的人员变更，也没有风险。
Customer Engagement ，现场客户。敏捷开发中，客户是与开发团队一块儿工做的，团队到客户现场进行开发
或者邀请客户到团队公司里来开发。若是开发过程当中有什么问题或者产品通过一个迭代后，可以以最快速度获得
客户的反馈。
Automated Testing ，自动化测试。为了减少人力或者重复劳动，全部的测试包括单元测试、功能测试或集成
测试等都是自动化的，这对QA 人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，可以编写自动
化测试脚本或者用工具录制。咱们公司在自动化测试上作了大量的工做，包括Selenium 开源项目。
Adaptive Planning，可调整计划。敏捷开发中计划是可调整的，并非像以往的开发过程当中，需求分析->概要
设计->详细设计->开发->测试->交付，每个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷
开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时做出相应的调整和变化。
敏捷开发过程与传统的开发过程有很大不一样，在这过程当中，团队是有激情有活力的，可以适应更大的变化，
作出更高质量的软件。

持续集成.

主要是短平快的开发模式，原型模式开发。反复交流，肯定。项目持续发布集成。

其余参考:https://www.jianshu.com/p/89e59933caad>https://www.jianshu.com/p/89e59933caad