敏捷实践总结（三）——Scrum敏捷开发

采用敏捷开发进行项目开发已经有些天了，近几天又看了一本关于Scrum的书。在此跟大家分享一下感受。

scrum本意是橄榄球运动中的争球。在中国不兴打橄榄球，在我的印象中，橄榄球运动是非常野蛮的，球员目的非常明确——破门得分。你可以抱着球跑，可以传给队友……各种方式都可以，就是要快速得分。敏捷开发就是需要这种精神。

敏捷开发不同于以往的瀑布模型开发。

瀑布模型中有严格的文档要求（需求、概要、详细等）、对员工的工作量也有明确的定义与考量方法（代码量等等）。另外，瀑布模型对于开发者有着明确的分工：搞需求的专门搞需求，搞设计的搞设计，编码的只管编码，测试的只管测试。所以说，各部门之间的任务相对明确。但是沟通效率很低，由于文档的要求严格，各部门机制臃肿，彼此之间不能做到及时有效的沟通，不仅耗资巨大，而且延误交付日期。另外，由于一般都是架构师整好设计，下面培训一批写代码的，所以开发者只能被动接受任务，每天干着暗无天日重复搬砖的日子，所以开发的效率也很低。

但是瀑布模型相比与敏捷开发，无疑就成了重量级，而敏捷开发则是轻量级。

瀑布模型风险较大，在实际中，并不是每个项目在前期都能够做到需求明确，就像这样：

而敏捷开发则非常适合需求变动的情况，敏捷开发的工作量是随着需求的变化而不断发生变化的，所以整个过程中，浪费很少：

Scrum是最常用的敏捷开发（Agile）方法。下面我们来看一下Scrum大概的流程：

1、在一个Scrum项目中，产品负责人（Product Ower）建立待开发的产品条目（Product Backlog），并确定其优先级。开发中需求的改变也要写进去，对于调研、查阅资料、配置环境等也应考虑进去，因为这些也很占用时间，敏捷开发中不提倡冲刺，不提倡加班，讲究发挥团队最大价值；

2、根据所列Product Backlog情况，确定产品一个迭代（Sprint）所要完成的东西，每一个Sprint大概是2-6周的时间；

3、Sprint开始前，需要开一个迭代计划会议（Spint Planning Meeting）会议。会上，产品负责人（Product Owner）讲解本次开发要开发的条目（Story），将确定的Story放入Sprint Backlog中来；

4、Sprint开发过程中，团队每天都要开一个15以内的站立会议（Daily Stand-up Meeting），以便团队之间了解彼此的开发进度。

会议由Scrum Master主持，Scrum所有成员轮流回答三个问题：（1）昨天我完成了什么工作？（2）今天我打算做什么？（3）我遇到了什么障碍？会议的目的是团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。

5、Sprint结束之后，需要开评审会（Review Meeting），Scrum团队会在评审会议上把这个迭代的开发成功展示给大家；

6、之后还要开一个反思会（Restrospective Meeting），Scrum团队会回顾过去这个Sprint，从中总结经验教训。

会议围绕三个问题讨论：上次迭代有哪些事情坐的好，希望继续；哪些事情坐的不好，希望改进；有何改进计划。会议目的旨在帮助团队总结经验教训，分享经验，使团队持续成长。

上面就是Scrum的大概执行流程。

另外一些注意事项：

Scrum讲究开发团队坐在一起，有什么问题即时相互询问；

用拍扑克的方式角色每个story的开发时间；

测试要尽早加入到开发团队中来，可以与开发人员进行结对开发，尽早的了解需求，大大减少测试人员的工作量；

开发人员工作量的评定要主要以团队开发的质量为标准；

Scrum把软件开发中各种角色形象的分为两类：一类是“鸡”，一类是“猪”。这里源起于一个“肌肉火腿肠”的故事，不实际参与项目开的管理者称为“鸡”，全身心投入项目开发的团队成员称为“猪”；

刚开始实施起敏捷开发是比较困难的。很容易走教条主义的错误，机械的实施敏捷开发。注意，敏捷开发认为人与人之间有效的交流和协作是最重要的，透过一切流程和工具看本质，实际上就是使人能够协作开发软件。敏捷开发随时拥抱变化、相应变化，而不是恪守计划。总之，敏捷开发的本质：第一是一切活动以价值为导向；第二是以人为本。