Scrum敏捷开发沉思录

　　计算机科学的诞生，是世人为了用数字手段解决实际生活中的问题。随着时代的发展，技术的进步，人们对于现实世界中的问题理解越来越深刻，描述也越来越抽象，于是对计算机软件的需求也越来越高，越来越复杂，变化也越来越频繁。
　　而软件技术的发展也是随着人们认知水平和抽象能力的不断提高，从面向过程编程，进化到了面向对象编程，再到日渐红火的面向服务的编程。伴随着思维的不断进步，实现软件的技术手段也随之变迁，从最古老的瀑布流程，到RUP统一过程，到敏捷软件开发，它们的出现无一不体现了需求，变化，效率，时间与质量的多方博弈。
　　今天，我们的主角就是炙手可热的敏捷软件开发。敏捷软件开发老早就炒的如火如荼了，本人历经几家公司，也都在不同程度上受到这个理念的波及。

敏捷思想

　　传统瀑布模型的弊端很明显：过于强调文档，开发和测试介入较晚、风险高，无法快速响应反馈，修改和重构成本过高。敏捷开发就是针对传统的瀑布开发模式的这些弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。
　　敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

　　为了了解敏捷开发，需要先了解敏捷开发宣言，为了表示对各位先驱的尊重，特抄录在这里：

个体和交互 > 过程和工具
可以工作的软件 > 面面俱到的文档
客户合作 > 合同谈判
响应变化 > 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。

　　然后需要了解一下敏捷开发的核心价值观：

沟通：不但包括团队内部的开发人员之间沟通、还包括团队和利益相关人员之间的沟通。
简单：简单的实现和设计。正因为简单，随着对软件理解的加深，也更容易的改进。
反馈：更早更快速的从用户获得反馈，这样能保证软件在做正确的事。
勇气：当需要做出重大的决策，放弃或重构(refactor)你的工作，修正你的方向时，勇敢去做。
谦逊：尊重每一个参与项目的人，无论是团队，还是客户，甚至其他的利益相关人员，他们对项目都有价值。

　　纯理论的不想说太多，当你实践过敏捷开发以后再回头来看看这些简单的字眼，你会发现它们简直就是至理名言(不管你信不信，反正我是信了)。

敏捷实践
　　伟大的哲学家王守仁先生最伟大的观点就是：知行合一，所以接下来就来看看敏捷开发的实践。
　　践行敏捷开发理论的流程很多，但是要说最有名的，那应该还是Scrum和XP(极限编程)，前者重在管理流程，后者重在编程实践。实际使用中，能把这两者结合起来的公司是少之又少，大多数的公司都是使用Scrum去管理项目，而XP，更多的是程序员们自己的兴趣和爱好。由于本文重在管理，所以重点解析Scrum流程。
　　Scrum的流程基本可以用下图来概括：

按照传统的记叙文的写作方式(时间、地点、人物，事情的起因、经过、结果)来描述一下Scrum流程就是：

时间：每个Release和每个Sprint
地点：办公室，这个毋庸置疑，至于站着还是坐着，那就看个人爱好了
人物：整个团队，包括管理人员，市场人员，客户代表，程序员，测试人员，设计人员，通常分为3类：
    Product Owner：通常包括产品经理，产品负责人，运营人员；
    Scrum Master：通常包括项目经理，项目负责人；
    Team Member：通常包括开发人员、测试人员、美工设计等全职能性团队。
事情的起因：客户或客户代表提出需求或者产品的反馈，公司研究决定推出新产品或新版本。
经过：
    .Product Owner把需求和反馈转化成User Story放到Backlog中；
    .规划Roadmap，然后集合Team所有人员讨论决定最终Overview；
    .Product Owner规划Release Plan，根据Plan中的时间划分Sprint；
    .开始每个Sprint(2-6周不等，视实际情况而定)：
        ).Plan Meeting (可进行多次)：
            a).整个团队根据Product Owner设定的任务优先级，选定该Sprint中需要完成的User Story和要处理的Bug。
            b).整个团队讨论选定的任务中的功能，确保每个人对功能的表现都有相同的认识。
            c).Scrum Master与开发团队拿出扑克牌，估算每个任务的时间和难点。
            d).开发人员领取任务(先估算，后领取是有道理的)。
            e).测试团队根据每个任务的描述，设定验收的标准和案例。
        ).编码与测试
            a).开发完成功能，进行单元测试。
            b).测试完成功能测试，有问题的报Bug。
        ).Standup Meeting (每天，或每几天一次)
            a).Scrum Master与开发团队，测试团队一起同步一下开发与测试的进度。
        ).Review Meeting (可进行多次)
            a).整个团队讨论一下该Sprint的执行情况，验收完成的功能，需要调整的方面加入到Backlog中或Bug中。
            b).整个团队反思与总结一下该Sprint的经验、教训。
            c).根据反思的结果，指定一些Action Item，分配给相关人执行。
结果：Release新产品或新版本
道具：这个通常很重要，这里主要是管理Backlog和Bug的工具，比如我用过的JIRA，Rally等等，当然看板，燃尽图等工具也很有意义，不管使用何种方式，目的都是管理项目的进度。

Scrum反思

1.产品与文档
　　瀑布模型的弱点之一就在于文档驱动；能工作的产品才是王道，但是简明扼要，清晰的文档也还是很有必要的，特别是对于团队的新人来说，但是文档的作用又不仅限于此。很多时候，一份好的WIKI Page可以让其他的人快速的了解产品的设计与功能。

2.合作的真意与以人为本
　　这是我所在团队做的很不足的一点，很多时候QA(测试人员)并不知道某一个Feature(功能)的设计与表现是什么样的，往往是在测试的时候才会去向Dev(开发人员)了解该Feature的全部情况。而且很多时候，PD(美工人员)与Dev在商量Feature的表现的时候，QA并没有参与进来。我们也想了很多的办法去改善这种情况，比如一个Feature完成的时候，Dev给PD，QA一起演示一下Demo，但最终这个方法并没有得到执行，原因很多，大家的时间安排也不一样。
　　看样还是符合那句老话：计划容易执行难。人天生就是懒的，特别是IT人士，如何提高团队的认识和执行力还真是一个问题。不论什么做法，前提还是需要得到大家的一致认同，这样才会有基本的执行力。

　　我认为，敏捷开发中合作的真意就在于那份人的责任感，那份以人为本的核心理念。大部分敏捷开发中的问题就是由于Team中的许多人还不是具有“敏捷”思维的人所造成的。没有敏捷开发的思维，没有工作的激情，只有领导自以为是的指示，和拼命赶进度的急促步伐，这可能是很多国内开发者与国外的敏捷团队最大的差别，这也是国内很多敏捷项目失败的根本原因。

3.Meeting的频率与内容
　　开会很多时候是很无聊的，这个大家一定深有体会了；但是Sprint中的各个会不应该是这样的。在敏捷团队的会议中，不存在领导驱动问答的形式，而是整个团队针对会议议题畅所欲言，主体明确，目的达到以后就应该结束。这样就能提高开会的效率。而开会的频率，特别是Standup Meeting的频率，很多团队固守每天一次的频率，个人觉得没什么太大的必要，我们采取的就是两天一次，觉得感觉很好。

4.User Story和Developer Story
　　User Story自然不必说，那大多数来自客户的需求或者是Team的反馈。还有一些任务是来自QA或者是Dev的需要，比如自动化测试，框架的探索与设计，这些我们通常是处理成Developer Story，也算有点道理，不过感觉总是怪怪的，因为从我的角度来说，这些应该是分解，合并到各自的User Story中去的。

　　此外，由于User Story基本都是Product Owner添加的，所以开发中的的很多情况它们并不完全清楚，因此整个团队在每个Sprint之前需要对这个Sprint中所有的任务进行讨论和初步的可行性研究。

5.简单设计，迭代，重构与演进式架构
　　按照敏捷开发的核心价值观，代码应该尽量简单直接，不用太多的去考虑以后的扩展性，因为未来是不确定的。这么说是不是就不用考虑软件的架构了呢？答案当然是否定的。
　　架构与开发流程根本就是两个不同的概念，架构是软件的骨架，而敏捷开发是构建软件的过程，敏捷开发可以影响架构的最终面貌，但是却不能消灭它。敏捷开发出现后，软件架构设计的方式只不过是产生了如下的变化：敏捷开发把原先软件过程前期的架构设计，分散到了整个敏捷开发软件过程中，也就是每次迭代中。
　　在每次的迭代中，随着功能的增加，需要不断的重构以便使代码满足扩展性的需求。在先让软件运行，再重构其代码的过程中，软件的架构随着重构自然而然的在软件过程中产生，这中做法通常就称为演进式架构，以前是设计完后开发，现在是边设计边开发。

6.臆想的需求
　　在软件的开发过程中，我们团队经常使用的一个口头禅就是“如果客户这么做了，就有....问题了”，但是客户是不是真的会这么做吗？这么做对客户有什么实际意义吗？我们不知道，测试人员也不知道。这种工作我称之为“臆想的需求”。有的时候，臆想出来的需求真的是会耗费太多的时间和成本。我想，敏捷开发中让软件尽早能工作，让客户或客户代表参与到开发中，就是为了让软件能正确的工作，为了提高工作的效率，这些臆想出来的东西还是尽量少有吧，即使搞一些BrainStorm，如果真的要加入到软件中，还是需要依靠真实的客户数据去严密论证。

7.尽早的测试与反馈
　　这一点的重要性就不必说了，尽量早的发现软件的问题，收到客户的反馈，然后根据这些真实的数据做出调整，规避完败的风险，这是相对于瀑布开发来说最自然的想法之一。

8.持续编译与集成
　　可工作的软件是软件工程最重要的产出，持续的集成，持续的编译，持续的测试，持续的反馈，持续的迭代，持续的重构，这是敏捷开发的核心，也是每个Sprint保证质量的前提。

9.应对变化
　　变化是唯一的不变，这又是我们常用的一句口头禅。确实，变化发展是唯物主义最重要的观点之一，拥抱变化不仅对人来说是一件困难的事，对于软件来说，也是一大挑战。为了满足需求的频繁变更，软件工程不断研究应对变化的策略，敏捷开发的核心思想就是改善流程，应对变化，规避风险。对于软件技术来说，应对变化与重用也是其向前发展的最原始的动力，从过程的重用，到算法的重用，到对象的重用，再到方案的重用(设计模式)，这个过程中最根本的导因就是变化。

最后是一些参考的链接：

http://developer.51cto.com/art/200803/68222.htm

http://dearymz.blog.163.com/blog/static/2056574200881235317338/