敏捷开发流程

一、敏捷起源

2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

（1） 预定义型过程控制(发射火箭) (2) 经验性过程控制(开车)

软件研发的主要效率来源于团队协作和互动

文档作用: (1) 沟通 (2)知识回溯

效率: 单个步骤的开发的时间 → 响应力: 达到目标所需要的时间

邓巴数理论(150):社交网络给了我们联系，却未必给了我们交流；拉近了我们的距离，却未必增加我们的亲密；激发了我们社交的天性，却可能磨平了我们沟通的能力。社交的幸福感来自社交的质量而不是数量，来自于沟通的深度而不是频率。

二、敏捷12条原则

1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4、项目过程中，业务人员与开发人员必须在一起工作。

5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

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

12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

三、Scrum的3355理论（3个角色，3个工件，5个价值观，5个仪式/事件）

(1) 3个角色

1.1.Product Owner

产品所有人，简称PO，主要职责是负责Product Backlog和Sprint Backlog。PO不仅要决定选择做什么，还要能从商业价值的角度解释为什么做这些。PO的日常工作主要有：

• 在产品团队中扮演业务的发言人，是项目的客户或者代表
• 有充足的知识和授权
• 定义业务需求，定义产品的最高优先级的特征和功能
• 根据需求的商业价值对其进行优先级排序
• 确定发布日期和发布内容
• 根据需要调整每个Sprint的需求和优先级
• 在Sprint交界处可以变更功能和优先级
• 定义验收标准
• 接受或者推翻工作成果
• 对于每个敏捷团队做的所有工作的价值、优先级和细节拥有最终的权威
• 对于业务目标和期望的最终结果的深层的了解使得其拥有此权威
• 与团队一起更紧密地工作

1.2.Scrum Master

Scrum教练或者Scrum大师，简称SM，主要职责是传播敏捷的思想，保证Scrum的流程。日常工作主要有：

• 促进团队的工作
• 精心组织Scrum的各种仪式
• 负责设定Scrum的价值和实践
• 确保团队的组件完整性且保证效率高产
• 促成所有角色和职能之间的紧密协作
• 排除障碍
• 保护团队不受外界干扰

1.3.The Team

研发团队，是任务执行团队，一般是一个跨职能团队（一般包括前后台研发、测试等），能够切实提供一个可用产品的团队。团队主要有以下特征：

• 典型团队通常为5-9个人
• 跨职能团队，囊括了开发人员、测试人员、业务分析师等开发最终软件所必需的角色
• 团队成员应该是全职的。也可能有特殊情况 (例如, 数据库管理员DBA等兼职)
• 保持纪律，遵守承诺，按时交付软件成果
• 自组织、自管理的团队

(2) 3个工件

2.1.Product Backlog

产品待办事项集合，整个产品的用户故事集合，这些用户故事可以来自甲方客户、终端用户、PO自己对产品的理解、研发团队等。它具有以下特点：

• 是项目的需求列表
• 以用户故事的形式表示
• 包含功能性以及非功能性需求
• 每项需求应该描述其商业价值
• PO负责进行对Product Backlog Item（产品待办事项）优先级排序
• 每个Sprint开始之前要重新进行排序，以确定最重要的事项
• 随着项目的进行，可能新增、变更或减少条目

2.2.Sprint Backlog

冲刺待办事项列表，一个冲刺目标阶段内的用户故事列表。
这些用户故事来自Product Backlog，每次冲刺前，PO根据交付价值，将优先级最高的用户故事放入迭代。它具有如下特点：

• 从产品Backlog中取出前面若干项，在当前Sprint中被实现
• 每个用户故事应该能够在当前Sprint中被实现
• 每一个用户故事都会被分解并关联到若干个子任务（Task）
• 团队成员自愿挑选任务
• 每日更新任务剩余时间
• 团队成员均可按需在Sprint Backlog中增加、修改、删除任务
• 如果Sprint工作不清晰，创建Sprint Backlog时先估算一个比较大的时间段，在后续阶段再做进一步的缩短
• 伴随着任务的逐步清晰化，及时更新剩余时间
• 对于用户故事的完成，团队一起定义“完成”的标准（DoD）
• DoD代表了各种用于确保sprint backlog中质量、准确性、业务关联性活动

2.3.Increment

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的、可检