99) 敏捷开发笔记

1- 敏捷开发：

一套与产品开发相关的原则和价值

1.1- 流程

• 1.1.1 现根据主路径，完成主要功能
• 1.1.2 再通过不断迭代，完善工作
• 1.1.3 产生变化时，推翻的工作量少，可以很快的完成新的需求变更

1.2- 优势

• 1.2.1 开发的阶段性成果会在开发过程中尽早的进行审查，项目的风险会降低
• 1.2.2 适用于需求不明确情况，因为需求不明确，所以需要在不断迭代的过程中来逐步理清需求。
• 1.2.3 灵活性较高，几乎可以在任何时间进行需求变更
• 1.2.4 鼓励开发人员与业务用户之间进行多频次的沟通，业务用户的不合理需求以及开发人员的错
• 误理解都会在这些频繁的沟通中进行不断审查和更新
• 1.2.5 协作通常要高得多，通常能开发出更高质量的产品
• 1.2.6 适用于快速变化的项目，特别是面向前端业务人员的CRM项目更容易根据业务的变化而变化。
• 1.2.7 早期交付，降低后续成本
• 1.2.8 及时了解市场需求，降低风险

1.3- 劣势

• 1.3.1 概念接受度还不算太高
• 1.3.2 最终交付的内容无法预测，预期和实际完成的内容经常会有很大差异
• 1.3.3 业务和IT人员在沟通前需要做大量的准备工作，但很多情况下业务的沟通时间无法保证
• 1.3.4 存在乙方供应商的情况，客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高；
• 1.3.5 最大的问题可能是业务部门永远不希望有最终的截止时间

1.4- 核心：

• 1.4.1 迭代开发
  将开发过程拆分成多个小周期，每次小开发都是同样的流程。
  将一个大任务，分解成多次连续的开发，本质就是逐步改进。
  目的：不断改进产品，添加新功能。通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。
• 1.4.2 增量开发
  软件每个版本，都会新增一个用户可以感知的完整功能
• 1.4.3 步骤
  需求分析（requirements analysis）
  设计（design）
  编码（coding）
  测试（testing）
  部署和评估（deployment / evaluation）

1.5- 价值观和原则

• 1.5.1 价值观
  程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
  软件能够运行，优于详尽的文档。
  跟客户的密切协作，优于合同和谈判。
  能够响应变化，优于遵循计划。
• 1.5.2 原则
  通过早期和持续交付有价值的软件，实现客户满意度。
  欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
  不断交付可用的软件，周期通常是几周，越短越好。
  项目过程中，业务人员与开发人员必须在一起工作。
  项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
  面对面交谈是最好的沟通方式。
  可用性是衡量进度的主要指标。
  提倡可持续的开发，保持稳定的进展速度。
  不断关注技术是否优秀，设计是否良好。
  简单性至关重要，尽最大可能减少不必要的工作。
  最好的架构、要求和设计，来自团队内部自发的认识。
  团队要定期反思如何更有效，并相应地进行调整。

1.6- 实现分类

• 1.6.1 SCRUM ： 开发流程框架
• 1.6.2 XP(极限编程）：更侧重于实践

2- CSM

2.1- CSM : certified scrum master 敏捷认证

2.2- 等级

• 2.2.1 基础级认证

​ ScrumMaster认证（CSM）,

​ ProductOwner认证(CSPO)

​ Scrum开发者认证(CSD)。

• 2.2.2 专家级认证

​ 认证Scrum专家（CSP）

• 2.2.3 导师级认证

​ 指导级认证包括认证Scurm培训师（CST）、

​ 认证Scrum企业教练（CEC）、

​ 认证Scrum团队教练（CTC）

3- PMI-ACP

区别：

认证产品	方法	应用	质量
PMI-ACP	包含多种敏捷实践方法：ScrumKanbanXP精益TDDCrystal更适用于当下软件开发	小团队敏捷开发企业大规模组织转型	三个月敏捷思想方法培训，理论+实践
Scrum Master	Scrum敏捷方法为主	在5-9人的小型团队中做敏捷开发	学习+考试 2天，时间短，知识浅

4- SCRUM

4.1- 角色

• 4.1.1 产品负责人（produce owner)

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

• 4.1.2

流程管理员（Scrum Master）

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

• 4.1.3

开发团队（Scrum Team）

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

4.2- 开发流程

• 4.2.1 开发模型

1、我们首先需要确定一个Product Backlog（产品需求列表），这个是由PO负责的（如图（一））；

2、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

3、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）（如图（二）和如图（三））；

5、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。

6、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

7、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；