一 什么是Scrum?
Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。
Scrum的基本假设是：
开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。
Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。
二 Scrum较传统开发模型的优点
Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。
三 Scrum模型
一) 有关Scrum的几个名词
backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。
sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。
sprint backlog:一个sprint周期内所需要完成的任务。
scrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。
time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。
sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。
Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？ 是否遇到了障碍？ 即将要做什么？通过该会议，团队成员可以相互了解项目进度。
Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。
二）实施Scrum的过程简单介绍
1) 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
2) 召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。
3) 进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
4) 整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.
5) 团队成员最后召开Sprint retrospective meeting，总结问题和经验。
6) 这样周而复始，按照同样的步骤进行下一次Sprint.
其他一些内容：
Test-Driven Development，测试驱动开发，它是敏捷开发的最重要的部分。在ThoughtWorks，我们实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。
Continuous Integration，持续集成。在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码；编译源代码；运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。 在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。在持续集成上，我们公司使用的是自己开发的产品CruiseControl
Refactoring，重构。相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。
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，可调整计划。敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要设计->详细设计->开发->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。
敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化，做出更高质量的软件。
其实很早就了解这些了，最早接触的的是广联达的周金根上面的。产品研发的开发模式与传统的项目开发流程方式也是不一样的，所以，我没有自信，我怀疑我自己，更怀疑公司对产品研发的投入与一些方式方法上。我有无限的求知欲，我需要学习的东西太多（技术+业务+管理），但也许只能靠我自己，我真的希望有人来教教我。现在谁也不会，大家都在摸着石头过河。