敏捷项目管理

 

一、 什么是Scrum?
Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。
Scrum的基本假设是：
开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

 

Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。

 

二、Scrum较传统开发模型的优点

 
Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。

 

 

 

下图是Scrum模型和传统模型的对比：

 

 

 

三、 Scrum模型

1、有关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进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。

 
2、实施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.
整个过程如下图所示：  

 

   

 

 

 

四、敏捷强调：

 

1、  敏捷强调，客户们需要在开发过程中自始至终都和项目紧密配合。拥抱变更，且非常欢迎客户的反馈。在项目所有的“检核和适应”这一环节上，都期望客户能够参与并提供宝贵意见，降低风险，为客户和利益相关者提供选择空间。它强调当项目的需求发生了变化，团队能够迅速适应。主要靠频繁地小规模发布软件，也就是短的迭代完成的，敏捷方法在几周或者几个月的时间内就完成相对较小的功能，尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

 

2、  敏捷强调，面对面的交流，而不是用多而复杂的文档。“客户需要的是支持，而不是文档。很多时候我们有一个错误的理解，文档等于支持，但事实上，文档并不等于支持。”

 

3、   敏捷强调，计划会议上，客户应该和开发负责人一起定义User Story，并在计划会议上给出详细说明。

 

4、  敏捷强调，客户应该和开发负责人一起为Backlog定出优先级。

 

5、  敏捷强调，客户和利益相关者要参与Sprint尾声的产品演示。根据客户和产品负责人的关系，客户甚至可以参加Sprint回顾会议。

  

 

五、敏捷宣言：

 

1、 人和交互重于过程和工具。

 

2、 可以工作的软件重于求全责备的文档。

 

3、 客户合作重于合同谈判。

 

4、 随时应对变化重于循规蹈矩。

 

5、 敏捷宣言遵循的

 

六、12条原则：

1、 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

 

2、 即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。

 

3、 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

 

4、 在整个项目开发期间，业务人员（客户）和开发人员必须天天都在一起工作。

 

5、 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

 

6、 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。

 

7、 工作的软件是首要的进度度量标准。

 

8、 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

 

9、 不断地关注优秀的技能和好的设计会增强敏捷能力。

 

10、      简单—使未完成的工作最大化的艺术—是根本的。

 

11、      最好的构架、需求和设计出自于自组织的团队。

 

12、      每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

 

 

转载于:https://www.cnblogs.com/jerry_cong/archive/2010/05/12/1734034.html