敏捷流程开发

• 了解敏捷流程产生的背景

有几个原因导致敏捷在互联网时代出现：

最初的软件（20 世纪六七十年代）的顾客都是大型研究机构、军方、美国航空航天局、大型股票交易公司，他们需要通过软件系统来搞科学计算、军方项目、登月项目、股票交易系统等超级复杂的项目。这些项目对功能的要求非常严格，对计算的准确度要求相当高。

20 世纪八九十年代，软件进入桌面软件时代，开发周期明显缩短，各种新的方法开始进入实用阶段。但是软件发布的媒介还是软盘、CD、 DVD，做好一个发布需要较大的经济投入，不能频繁更新版本。

互联网时代，大部分的服务是通过网络服务器端实现，在客户端有各种方便的推送（Push）渠道。一般消费者成为主要用户。网络的传播速度和广度，使得知识的获取变得更加容易，很多软件服务可以由一个小团队来实现。同时，技术更新的速度在加快，用户需求的变化也在加快，开发流程必须跟上这些快速变化的节奏。于是敏捷就产生了。

• 理解敏捷流程和传统做法的区别

从 2001 年 开始，一些软件界的专家开始倡导“敏捷”的价值观和流程，他们肯定了当时流行做法（传统做法）的价值（左列），但是强调敏捷的做法（右列）更能带来价值。

传统的做法	敏捷的做法
流程和工具	个人和交流
完备的文档	可用的软件
为合同谈判	与客户合作
执行原定计划	响应变化

• 理解敏捷流程的原则

敏捷宣言：

尽早并持续地交付有价值的软件以满足顾客需求。 - 客户为先

敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。- 拥抱变化

经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。-短迭代交付

业务人员和开发人员在项目开发过程中应该每天共同工作。- 业务参与

以有进取心的人为项目核心，充分支持信任他们。- 以人为本

无论团队内外，面对面的交流始终是最有效的沟通方式。- 面对面沟通

可用的软件是衡量项目进展的主要指标。-成果导向

敏捷流程应能保持可持续的发展。 领导、团队和用户应该能按照目前步调持续合作下去。 - 保持节凑

只有不断关注技术和设计才能越来越敏捷。-追求卓越

保持简明 - 尽可能简化工作量的技艺 - 极为重要。-简单务实

只有能自我管理的团队才能创造优秀的架构, 需求和设计。-团队自组织

时时总结如何提高团队效率, 并付诸行动。-持续改进

敏捷开发十二原则

我们遵循以下原则：

我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

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

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

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

团队定期地反思如何能提高成效，并依此调整自身的行为表现。

• 理解SCRUM的角色以及流程

SCRUM是一种迭代的增量项目管理方法，常见于敏捷软件开发中。
角色：
维护流程的“ScrumMaster”（项目经理）
“产品负责人”，代表利益相关者和业务
“团队”，一个跨职能的小组，进行实际分析、设计、实施、测试等。
 

流程：

第一步：

找出完成产品需要做的事情 — Product Backlog.

产品负责人领导大家对于这个 Backlog中的条目进行分析，细化，理清相互关系，估计工作量，等工作。每一项工作的时间估计单位为“天”。

第二步：

决定当前的冲刺（Sprint）需要解决的事情 — Sprint Backlog。 整个产品的实现被划分为几个互相联系的冲刺（Sprint）。产品订单上的任务被进 一步细化了，被分解为以小时为单位（参见 WBS 工作划分的办法）。如果一个任务的估计时间太长（如超过 16 个小时），那么它就应该被进一步分解。

订单上的任务是团队成员根据自己的情况来认领。

团队成员能主导任务的估计和分配，他们的能动性得到较大的发挥。

第三步：

冲刺（Sprint）。

团队按照backlog 任务执行

在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum 大师（Scrum Master）来完成。

第四步：

得到软件的一个增量版本，发布给用户。

然后在此基础上又进一步计划增量的新功能和改进。

• 敏捷和计划驱动的适用范围

瀑布模型适合于不注重改变需求的项目，例如：
  1.由提案请求(RFP)发起的项目，客户有非常清晰的文档化需求
  2.关键任务项目，比如航天飞机
  3.嵌入式系统。