公司所有开发组目前都在提倡敏捷开发，我所在的开发组也没有out，刚刚发版的产品我们就引入了敏捷开发的一些概念--虽然还比较粗糙，但整体感觉还是蛮好的。发版后，有一段空闲期，闲来无事，看到同事桌上有本《轻松Scrum之旅--敏捷开发故事》，就借过来读了一下，通篇就是一个产品的敏捷开发过程，从概念和使用方法上看，能有不小收获。这次就写一下自己初次体验敏捷的一些感受和这本书的一点读后感。
先说一下自己在实际开发中的一些感受吧。
敏捷开发整体来说是一种思想，但凡是思想的东西就不会局限于某种或某几种应用之上。敏捷也不例外，软件开发作为一种智力工程，只是敏捷的一个应用而已。具体到实际的应用，思想就会被具化为一些行之有效的手段和指导原则。敏捷在实际软件开发有XP,RUP,Scrum等多种应用框架，这些框架基本都是一些指导原则的集合，我们实际开发中采用了Scrum,但中间也采用了其他框架的一些非常优秀的指导原则！这其实也体现了敏捷的部分思想：不拘泥于形式！
使用Scrum，首先要有功能看板，现在有很多软件形式的看板，我们第一次使用敏捷，果断没有使用这种看板，而是采用了更具视觉冲击力的实物看板，我们开发经理用周末打造了如下看板：
上面就是我们组大而帅的功能看板，那他的作用是啥呢？上面在不同格子上贴的便签又是啥呢？我先简介概括一下我们使用敏捷的步骤，这些问题你就会有了答案的。
我们第一次是这样使用Scrum的（其中的一些步骤和涉及到的用词和标准Scrum有所区别，这个我后面会分析）：
1》 部门经理，开发经理，需求人员将产品进行分解，分解为一些较大的点，然后根据重要性和难易度将这些点分为3个迭代周期，即3个迭代周期后，产品整体及出炉了。
2》 开始每一次迭代前，部门经理，开发经理会将这个迭代的大点进行细分成一些小点，大小通常控制在1~3天。
3》 开始具体一次迭代，我们首先会开一个任务分配会议，时长大约1个多小时，开发经理给出所有的上述分解出的小点，挨个“招标”。如果有人感兴趣，举手示意即可，对于没人认领的点，开发经理最后会根据时间，强制分配给某人。
4》 开始迭代，首先所有人将自己的开发点写在便签上，并且贴在上述看板自己对应行的【准备】列中。这个看板“行”是和开发人员对应的，一人一行。“列”是和任务过程对应的，通常包括：准备；进行中；自测；完成。
5》 每天早晨9:00，开发经理会组织所有开发人员在看板前集合，举行每日例会，时长通常在20-30分钟。每个开发人员必须发言，发言内容为：昨天我做了什么事情，我遇到了什么困难，今天我要做什么事情。说的过程，同时移动任务便签到看板相应的列上。每个任务便签上都写有该任务的完成时间，如果开发时间和进度不匹配，开发经理会立即发现并进行沟通。
6》 一次迭代完成后，部门经理，开发经理，需求人员，所有开发人员，测试人员会开一次评审会议，时长大约2个小时，这期间主要是开发人员向所有与会者展示这次迭代的开发成果。测试人员也了解一下产品的使用方法，便于马上开展的测试工作。
这就是我们的敏捷过程，借用部门经理的话，这就是“山寨版”敏捷......但我们还是在这几条步骤下，经过3次迭代，产品成功发版了。其中也遇到了一些问题，比较典型的如下：
1》 任务分解粒度太粗！2~3天的任务，通常会产生拖延，因为这个时间本身就是估算的，任务时间长，说明其包含的功能点多，每个功能点有一点延迟，整个任务就有延迟，一个任务有延迟，最后往往会波及到整个迭代的时长！我们这3个迭代最后多出现了延时情况。
2》 任务粒度太粗还有另一个问题时，功能点的遗漏！这个问题甚至会拖延到测试时才被发现，只能临时将其添加到下次迭代中，影响了下次迭代的开发。
3》 开发人员受外界影响太大！我们开发人员不仅要参与这个产品的发版，同时还要参与维护以前的产品。这种时间没法计算到迭代周期中，但同样会影响迭代周期的计划时长。
4》 分解任务分配时间时，代码评审和自测的时间估量的太少，导致每次迭代后交付给测试的产品小问题太多。虽然整体流程可以走通，但仍热让测试团队怨气颇大！
这就是我们第一次自我敏捷的过程和期间产生的一些问题。如果仅仅从“敏捷的实施”这个角度看，我们的敏捷是失败的。因为我们没有按时优质的交付每一次迭代成果，最后的产品也产生了拖延。
然后再说一下我读完《轻松Scrum之旅--敏捷开发故事》一书后，对Scrum的一些收获吧，其中还有和我自己的敏捷开发进行的对比。先说一下Scrum中涉及到的一些名词：
1》 Product Owner：产品所有者，这个人发起一个产品的开发，并且负责将产品通过User Story的形式进行描述，并对所有User Story按优先级排序，给出一个大概的开发时间。我上述描述中“部门经理”就是我们那个产品的Produce Owner。
2》 Product Backlog：产品的功能点的总纲，即所有的User Story。最后Scrum是否完成，就看这个Backlog中是否还有剩余User Story。敏捷中允许Product Backlog发生变化，这分为两点：一是前面迭代中完成的部分发生了需求变化，则将这部分放到未完成的Backlog中，另一个是没有开发的部分发生变化。并且如果Scrum的整体周期很难变化，可以视开发进度从Product Backlog中将部分User Story移出。
3》 User Story：产品的一个开发点，通常是一个较大的点，从用户角度进行描述。一个大的User Story通常会包括多个较小的User Story。较小的User Story会包含多个Task。
4》 Task：产品的一个小的开发点，我们进行开发忘功能看板上贴便签上，写得就应该是Task。每个Task的时长通常为0.5~1天。从这个角度看，我上述描述的自己的敏捷对Task的大小没有控制好，这点确实对开发影响很大！
5》 Scrum Master：Scrum团队的负责人。负责一个Scrum团队和Product Owner交流的一个人。Scrum强调团队的自我管理性，即开始Scrum后，这个团队就相对封闭了，不应受外界影响。这个团队的一个开放口就是Scrum Master 。这个人负责团队与外界沟通，并且阻止外界对团队的影响。我上述描述自己的敏捷中，开发经理就相当这个角色。
6》 Sprint：中文翻译就是“冲刺”， 我上面描述自己的敏捷提到的“迭代”就等同于Sprint。实际实施Scrum中，就是要完成几个Sprint。一个Sprint时间通常为2周~2个月，这个视产品大小而定。
7》 Sprint Backlog：一个迭代过程中需要完成的功能点列表。这个列表就是从Product Backlog中挑选出来的。
8》 Sprint Planning Meeting：Sprint计划会议。这个会议是开始一个Sprint的标志会议。通常分为两部分，第一是Product Owner，Scrum Master，所有开发人员，用户（如果有的话最好）同时参加，共同决定这次Sprint中要完成Product Backlog中哪些功能，如果此刻又不明白的地方，Scrum Master和开发人员必须和Product Owner进行充分沟通，直到明白为止。第二是Scrum
Master 和所有开发人员参加，将这次Sprint中的User Story分解为Story，每个Story完成时间控制在0.5~1天，并且由开发人员按兴趣领取相应的Task。注意代码评审和自测也要分别作为一个Task存在。
9》 Daily Scrum Meeting：每日例会。由Scrum Master和所有开发人员参与的例会。这个是Scrum的精髓，Scrum Master控制一个Spint的进度就是根据这个会议。
10》 Sprint Review Meeting： Sprint评审会议。每次Sprint后对整个Sprint的成果向Product Owner，测试进行演示的一个会议，是一个Sprint完成的标志。
11》 Sprint Retrospective Meeting：Sprint回顾会议。这个会议由Scrum Master 和全体开发人员参加，大家讨论一下在刚刚结束的一个Sprint中的所得和所失。是一个Scrum团队自我成长和进步的最好的方式，大家互相提出自己的建议并发现问题，进行团队经验累积。我上述自己的敏捷没有这个会议，这个是一大损失！
这些都是这本书提到的一些Scrum概念，在实际应用中，我们的一些东西和这个肯定会略有不同，这个无关紧要，但其中一些重要的步骤，比如最后8~11 这个4个，是不可或缺的！
Scrum是软件开发中对敏捷的一组具体的应用指导原则，他强调面对面的沟通（一个Scrum团队最好保持在6~8人，并且大家办公位置能在一起），欢迎变化，弱化文档（他强调代码和注释是最好的文档），并且不提倡加班（对于视加班为常态的广大IT“民工”真是一大福音啊）。
实施Scrum中，有几点是要提前有所防备的。Scrum欢迎变化，所以我们就不可避免会有一些需求的变动或开发人员请假的一些情况，所以我们在安排时间时尽可能留一些预留时间，这个长度视经验而定。如果在实施过程中，预感到进度出现滞后的现象，Scrum Master要及时和Product Owner进行沟通，暴露问题所在，提前做出调整，如延长一定时间或者去掉一些User Story。
Scrum中涉及一个功能看板，这个看板很重要，可以用实物看板（我上述描述的敏捷过程所用），目前也有很多Scrum实施软件，如ScrumWorks（这本书中使用的软件），这个软件好像是收费的，所以我也没用过，但貌似功能很强大！不仅能有实物看板一切功能，而且还支持自动绘制“燃尽图”，这是一个整个项目进度的可视化显示，从网上找到的燃尽图，大家可以看一下：
红线表示计划进度路线，蓝线表示实际进度路线。蓝线在上面，表示进度有所滞后，蓝线在下面表示进度有所加快。如果不用ScrumWorks这类软件，我们如果需要这种可视化图片，需要自己手动进行。
这就是自己先糊里糊涂经历过敏捷而后又细细品味后敏捷的一点入门小得，总结一下，敏捷就是一种思想，是一种以人为出发点的一种管理哲学，可以应用在各种领域。在软件工程领域，Scrum是一组具体的敏捷实施指导原则，概念清晰，比较适合初次采用敏捷的开发团队使用。