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，可调整计划。敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要 设计->详细设计->开发->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷 开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。 敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化， 做出更高质量的软件。 |
|
|
