能否开发出满足培训对象需求、具有一定深度、课堂教学效果良好的培训课程是衡量一个培训师水平的重要标志。
然而，对培训针对性与实用性的高要求，以及复杂的培训学员类别层次，让课程开发显得非常困难。
如何才能开发出一门优秀的培训课程呢？
以下内容整理自课程
《敏捷课程设计与开发十步法》
↓↓完整原版课程入口↓↓
为什么要敏捷？
之前有一句话很流行——ADDIE已死？敏捷时代到来。
1)什么是ADDIE？
A：analyse 分析
D：design 设计
D：develop 开发
I：implement 实施
E：evaluate 评估
ADDIE作为经典的课程开发模式，已在培训行业推行近60年时间。几年前，我也曾按ADDIE的模式开发课程，整个流程走完基本需要半年至一年时间，周期较长。
VUCA时代，事物快速变化迭代，学习内容也在发生变化。2个月前设计的课程，有可能已经无法匹配当前岗位的需求。企业必须快速沉淀知识，这就要求敏捷开发。
2)敏捷课程开发实施流程
① 团队组建
传统的课程开发更多依靠个人(讲师/业务专家)寻找资料、收集素材，开发并交付整个课程。
而敏捷课程开发模型会在前期组建一支课程开发团队(建议3-5人一组)，共同承担课题。在此过程中会涉及人员分配，如项目经理、讲师候选人、业务专家等。
② 需求调研
组建完团队之后，就要进入需求调研的阶段。通常会调研两部分人群——
学员本身
学员上司
培训的用户是学员，针对这一人群做调研可以了解学员学习偏好。
可学员的需求不一定就是真实需求，因此要对学员的上司进行调研，确认需求得到主管的认可。
③ 课程开发
可以采用三天两晚封闭、集中式的课程工作坊。工作坊当天，由讲师引导学员走完十步流程。这样产出的课程，准备度可以达到75%。
④ 材料优化 & ⑤ 精品课程
后期经过1~2周的材料优化，即可产出一门完整的精品课程。
敏捷课程开发可以将课程开发周期缩短到一个月，有效应对开发过程中业务发生变动的情况。
敏捷课程设计与开发
十步法
说完敏捷课程开发的整体流程，我们再聚焦其中“课程开发”的十个步骤里。
1)第一步：聚焦课程目标
课程目标 描述对课程产出成果的期望，也就是通过课程希望直接或间接带来的收益。
a.制定目标常犯的错误
目标宽泛、空洞，不够清晰具体
目标好高骛远，不切实际
不满足ABCD原则
目标过多
b.课程目标来源
需求调研+期望整合
可采用团队列名法，找出学员和上级期望的同类项，形成课程目标的优先项。个别只存在于学员或上司需求中的选项，单独罗列出来。 
2)第二步：聚焦学员
课程设计的目的，是搭建起学习和工作之间的桥梁，让学员做好两者之间的连接。如果学员无法将学到的内容渗透到工作中，最终的培训效果往往不太理想。
一般需要聚焦以下关键点——
年龄、学历、职位、工作经验、学习偏好、思维模式
3)第三步：聚焦课程名称
在这个“看脸”的时代，课程名称愈发重要起来。什么样的课程名可以吸引到我的学员？
准、雅、力、简
a.准：准内容、准对象
课程名称一定要精准，让听众一眼就能捕捉到课程内容以及参与课程的对象，如“总裁的私房课”。
b.雅：雅致、典雅
中文讲究优雅，特别是古语言文化非常唯美。课程名称若是能达到优雅，可以吸引更多学员。
c.力：冲击力
课程名称带给听众感觉上的冲击力一定要强，如“年薪百万HR修炼宝典”。
d.简：简洁
“7±2原则”，即标题在5-9个字之间是比较合理的范围，超过9个字不方便记忆。
课程命名可以参考以下方法——
模型量化法
以小见大法
真知灼见法
形象比喻法
问题悬念法
路径命名法
要案集合命名法
4)第四步：课程内容分析
课程内容分析通常有三种方法——
① 工作任务分析法
根据岗位梳理出工作职责和关键步骤，并匹配每一步所需的知识和技能。一般有以下步骤：
确定需要分析的职责
与业务专家访谈，罗列工作任务及子任务
评价工作任务及子任务的优先级(FID模型)
形成内容大纲草案
② 关键事件分析法
分析在某一具体场景下，或者某一关键事件中学员所需的知识和技能。
案例：
③ 主题分析法
一般概念式、知识类的课程通常运用这类方法。
案例：
这三种分析法都要做子任务FID排序，并根据FID的分数确定我们需要投入的资源和精力。
第五步    课程结构分析
第六步    开发PPT
第七步    九大教学方法设计
第八步    单个模块互动设计
第九步    多媒体选择与开发
第十步    PPT材料美化与完善
其余6步，戳下图解锁全部课程↓↓↓
课程概述
本次课程在ADDIE基础上，结合SAM敏捷课程开发模式与Agile敏捷课程开发模型，在企业实战基础上总结出来的课程开发10步法。能够大大缩短企业开发内部课程的周期，如果运用到线下工作坊中，通常3天2晚可产出5-6门准备度在75%以上的PPT授课材料。
适学人群
培训师/企业内训师/培训管理者
讲师介绍左明浩
TTT导师企业内训师建设与中高层培养顾问
曾任LG培训经理、LG商学院高级讲师
现任美资企业全球人才发展负责人
加拿大魁北克大学MBA
AACTP美国培训认证协会国际注册培训师
更多课程
你可能错过的干货
本文来源于培伴服务号(ID：trainingpartner2016)。文章仅代表作者个人观点，不代表“培训杂志”立场。
投稿请联系：editor@trainingmag.com.cn
	

本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。

一、Scrum的定义和目的

Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。

二、敏捷宣言

其实，在发表《敏捷宣言》之前，很多的敏捷实践都已经存在且使用了，比如：Scrum、XP、KanBan等。之所以发表《敏捷宣言》，是因为这些实践都是在单打独斗地推进敏捷开发，而不是以一个联合体的形式，且没有一个统一的指导方针。所以17位敏捷联合创始人决定发表《敏捷宣言》，共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话：

 



 

 

三、Scrum中的人员角色

3个角色

Scrum中的人员分为3个角色：产品所有者（Product Owner）, Scrum Master，开发团队(Team)。

产品所有者：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序，认同或者拒绝迭代的交付。
	
ScrumMaster ：ScrumMaster不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他指导项目组的成员按照Scrum的原则、方法做事情，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。
	
开发团队：经典团队拥有 5-9 人，团队成员包含程序员、测试员、用户体验设计等等，团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整，团队自我组织和管理（自组织，自驱动），团队成员都全职工作。
四、Scrum的开发流程

 



（图片源自网络）

 

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周，最常见的为2周。Scrum并非以一段时间集中完成一个过程，而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代必须产生一个可以工作的软件。

4.1 五个会议

Scrum 整个开发过程分为五个会议:

1）待办事项整理会议（Backlog Grooming Meeting）

迭代计划会议开始之前3天召开，Product Owner与Scrum Master必须参加，关键开发者或架构师需要参加；时间控制在30分钟到1小时。

由Product Owner将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方，Product Owner现场记录，会后补全，Scrum Master与架构师，还有在场成员分析用户故事需要包含哪些技术任务，Scrum Master先把子任务建立，方便迭代计划会议的时候团队可以更准确地预估任务故事点。

会议结束时，Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决，会议重点如果团队发现需要加强或是完善的地方，Product Owner还有两到三天的时间可以补强，而不是浪费迭代计划会议的时间去做这件事情。

2）迭代计划会议（Sprint Planning Meeting）

产品负责人建立产品功能列表（Product Backlog）。产品功能列表是一组条目化需求，它必须从客户价值角度描述，并按优先级排序。

Scrum Master召集相关人员召开迭代计划会，迭代计划会在每个迭代第一天召开，目的是选择本次迭代的Backlog和估算本次迭代的工作量。

产品负责人逐条讲解最重要的产品功能，开发团队共同估算Backlog所需工作量，直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。队员认领任务（或由组长协商分发），独立或与别人一起完成任务；会议时间控制在1-2小时内。

3）每日站会（Standup Meeting）

团队内部利用每日立会来沟通进度，15分钟结束，开发团队利用燃尽图来展示整体进度；如无特殊原因，迭代期内无变更，在每日站会上团队成员需要回答以下3个问题：

昨天你做了什么?
	
今天你将要做什么?
	
你有需要帮助的地方吗?
这些都是团队成员的彼此承诺。

4）评审会（Retrospective Meeting）

小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加，ScrumMaster、产品所有者、团队，可能还有客户，时间控制在1-2小时内。

5）反思会（Retrospective Meeting）

在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好。做得好的保留，不好的摒弃。会议得出这样的结论：开始做什么、继续做什么、停止做什么，一般控制在15-30分钟。

Scrum是一套开发流程，是敏捷的一种，实施主要还是看人，强调是自组织、自驱动的，只有不断的在实际应用中仔细体会，才能理解Scrum的真谛，把Scrum用好。

4.2 12原则

下面给出敏捷开发的12原则，这12原则作为敏捷开发对于软件开发流程的指导性纲领，也是对敏捷宣言进行了具有实际操作意义的解释，希望大家在实际应用中仔细体会。

我们遵循以下准则：

我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
	
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
	
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
	
项目过程中，业务人员与开发人员必须在一起工作。
	
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
	
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
	
可用的软件是衡量进度的主要指标。
	
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
	
对技术的精益求精以及对设计的不断完善将提升敏捷性。
	
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
	
最佳的架构、需求和设计出自于自组织的团队。
	
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

作者：史文帅

来源：宜信技术学院

本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。

一、Scrum的定义和目的

Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。

二、敏捷宣言

其实，在发表《敏捷宣言》之前，很多的敏捷实践都已经存在且使用了，比如：Scrum、XP、KanBan等。之所以发表《敏捷宣言》，是因为这些实践都是在单打独斗地推进敏捷开发，而不是以一个联合体的形式，且没有一个统一的指导方针。所以17位敏捷联合创始人决定发表《敏捷宣言》，共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话：

 



 
 


三、Scrum中的人员角色

3个角色

Scrum中的人员分为3个角色：产品所有者（Product Owner）, Scrum Master，开发团队(Team)。

产品所有者：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序，认同或者拒绝迭代的交付。
	
ScrumMaster ：ScrumMaster不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他指导项目组的成员按照Scrum的原则、方法做事情，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。
	
开发团队：经典团队拥有 5-9 人，团队成员包含程序员、测试员、用户体验设计等等，团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整，团队自我组织和管理（自组织，自驱动），团队成员都全职工作。
四、Scrum的开发流程

 



 
 


（图片源自网络）

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周，最常见的为2周。Scrum并非以一段时间集中完成一个过程，而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代必须产生一个可以工作的软件。

4.1 五个会议

Scrum 整个开发过程分为五个会议:

1）待办事项整理会议（Backlog Grooming Meeting）

迭代计划会议开始之前3天召开，Product Owner与Scrum Master必须参加，关键开发者或架构师需要参加；时间控制在30分钟到1小时。

由Product Owner将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方，Product Owner现场记录，会后补全，Scrum Master与架构师，还有在场成员分析用户故事需要包含哪些技术任务，Scrum Master先把子任务建立，方便迭代计划会议的时候团队可以更准确地预估任务故事点。

会议结束时，Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决，会议重点如果团队发现需要加强或是完善的地方，Product Owner还有两到三天的时间可以补强，而不是浪费迭代计划会议的时间去做这件事情。

2）迭代计划会议（Sprint Planning Meeting）

产品负责人建立产品功能列表（Product Backlog）。产品功能列表是一组条目化需求，它必须从客户价值角度描述，并按优先级排序。

Scrum Master召集相关人员召开迭代计划会，迭代计划会在每个迭代第一天召开，目的是选择本次迭代的Backlog和估算本次迭代的工作量。

产品负责人逐条讲解最重要的产品功能，开发团队共同估算Backlog所需工作量，直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。队员认领任务（或由组长协商分发），独立或与别人一起完成任务；会议时间控制在1-2小时内。

3）每日站会（Standup Meeting）

团队内部利用每日立会来沟通进度，15分钟结束，开发团队利用燃尽图来展示整体进度；如无特殊原因，迭代期内无变更，在每日站会上团队成员需要回答以下3个问题：

昨天你做了什么?
	
今天你将要做什么?
	
你有需要帮助的地方吗?
这些都是团队成员的彼此承诺。

4）评审会（Retrospective Meeting）

小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加，ScrumMaster、产品所有者、团队，可能还有客户，时间控制在1-2小时内。

5）反思会（Retrospective Meeting）

在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好。做得好的保留，不好的摒弃。会议得出这样的结论：开始做什么、继续做什么、停止做什么，一般控制在15-30分钟。

Scrum是一套开发流程，是敏捷的一种，实施主要还是看人，强调是自组织、自驱动的，只有不断的在实际应用中仔细体会，才能理解Scrum的真谛，把Scrum用好。

4.2 12原则

下面给出敏捷开发的12原则，这12原则作为敏捷开发对于软件开发流程的指导性纲领，也是对敏捷宣言进行了具有实际操作意义的解释，希望大家在实际应用中仔细体会。

我们遵循以下准则：

我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
	
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
	
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
	
项目过程中，业务人员与开发人员必须在一起工作。
	
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
	
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
	
可用的软件是衡量进度的主要指标。
	
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
	
对技术的精益求精以及对设计的不断完善将提升敏捷性。
	
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
	
最佳的架构、需求和设计出自于自组织的团队。
	
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

 随着Agile敏捷开发的流行，越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法，一直实践到现在，并取得不错的成果，包括：产品功能更加符合市场和业务人员的需求，开发效率获得提高。本文从实践的角度介绍笔者所在团队的产品敏捷开发过程和作者的敏捷开发体会。
敏捷开发体会
    实施敏捷开发近两年来，我对在产品开发中应用敏捷方法有着深刻的体会。首先说下产品背景。我参与的产品是面向行业的产品，在全世界都有客户，有10年历史，和一百多个基于不同版本的客户，我们的团队完全负责产品的未来发展方向、发布计划、架构、设计、开发进度、测试、客户支持等。在这样一个面向全球的产品和自主的团队环境中进行敏捷开发体会尤其深刻。
    1) 注重概念和架构设计，而轻详细设计
    敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计，则是具体的设计和做法、API接口等。
    一个产品，特别是面向行业的产品，概念设计和架构设计非常重要，需要考虑行业未来的发展方向，产品在市场中横向和纵向的比较，技术的发展方向，和每个模块的投入和收益的比例等，这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎，因为一旦新增模块被客户使用，以后就很难在产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性，以及客户的升级迁移。所以，在开始正式开发之前，通过概念设计和架构设计，梳理思路是非常必要的。
    2) SWOT分析
    以前在做项目时，大多是从技术角度来考虑哪一些功能模块需要做，哪一些功能模块先做，而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源，却并不一定是客户最想要的。
    在敏捷开发中，更加注重客户需求。如果对产品进行SWOT分析，就能选出付出最小工作量，但能获得最大价值的模块。
    SWOT分析阶段会在概念设计和架构设计之后进行，输入是概念设计和架构设计，输出是模块的重要度和需要的时间。这样按照性价比可以进行排序，选出最能符合市场的模块。
    一款产品哪个模块重要，哪个先做，需要花多少资源和时间投入，花这么多时间和资源的模块是否在客户心中有相应的重要程度等，这些都是由这款产品的市场策略来决定。所有产品都是为了市场和赢利为目的，Agile方法更好地帮助企业实现了这一点。
    3) 业务和客户驱动，而非技术驱动
    这点说是体会，也可以说是教训。在我们的产品开发过程中，在某一新版本中重新设计了老版本的某一个重要模块，而引发了几个问题：一是，新版本的模块和老版本模块的兼容性问题，导致老版本客户无法平滑的迁移到新版本；二是，新版本的改进是纯技术方面的重新实现，不管对客户而言，还是对内部的架构而言，都没有明显好处；最后导致的结果是我们花了很多资源和人力去重新实现，但是在最后由于种种考虑还是废弃了重新实现的模块，依然沿用老模块。
    在产品的敏捷开发中，虽说拥抱变化，但不盲目变化。产品的改动需要经过概念设计、架构设计以及SWOT分析后，三思而后行。敏捷开发中也强调"在整个项目开发期间，业务人员和开发人员必须天天都在一起工作"，确保技术人员能够开发出客户需要的产品。
    4) 时刻考虑版本兼容性
    敏捷开发，废除了过多冗余的文档和繁杂的设计，强调拥抱变化。但作为产品，敏捷开发不意味着盲目地去变化。
    当设计变动、API接口重构、配置文件变更时，要时刻考虑产品的架构、规划路线图，老版本的兼容性，及迁移平滑性。否则，随着版本的增多，必将面对着大量的维护工作。
    5) 轻文档，但非无文档
    敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于整理思路，加快沟通和讨论。
    我们产品中的文档包括：概念设计文档、架构图、当前版本要实现的功能列表，以及SWOT分析。
    这些文档在每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。通过我们实践证明，这对产品的思路、沟通讨论都非常有帮助。
    而且这些文档，大多是几页PPT，书写和维护工作都很小。
敏捷开发过程
    敏捷开发改进了产品的开发流程，提高了整个团队的效率。下面分析敏捷开发前和敏捷开发后的产品开发的各个阶段。
    1) 敏捷开发"前"的产品开发过程

图1 敏捷前开发流程
    上图是敏捷开发前我们产品一个版本的开发流程，整个开发大概持续一年左右。从图中可以看出，流程中的大多数活动都是串行进行。这样的一种类似瀑布的开发流程，前提是需求在产品的初始阶段就完整的被捕获并正确的分析，这样才能保证最后交付的产品是客户所需要的产品，但通常这样的理想状况很难实现。
    类瀑布的开发流程缺乏灵活性，无法通过开发活动来发现不够确切的需求，导致产品无法随着业务人员和市场的反馈而随需应变，开发出符合业务人员需求的产品。
       2) 敏捷开发"后"的产品开发过程
 
图2 敏捷后开发流程
    上图是敏捷开发"后"我们产品一个版本的开发流程，整个开发大概也是持续一年左右，但每个迭代都是1个月时间。和敏捷开发前相比，有很多的区别和优点，下面是其中几点：
    市场和需求驱动，拥抱变化
    在我们产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示大会，把这个月的开发结果演示给组员、业务人员、售前，甚至客户，并收集反馈。此外，在开发的过程中，产品的业务人员和售前时刻保持与产品开发团队的沟通和工作，保证开发出来的产品是符合业务需求。
    充分利用资源和时间
    敏捷开发前，产品的需求设计阶段占用整个开发流程35%左右的时间，这段时间只需要几个核心的架构师和设计人员，无法充分地利用开发和测试人员。敏捷开发后，迭代开发、强调沟通、缩减文档，在每个迭代初期就可以充分地利用开发、测试人员的时间，达到效率最大化。
    每日交付
    产品开发过程中，每天都会做自动化Build，并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。
    充分自动化
    敏捷开发强调拥抱变化，这必然带来动荡的产品代码变更。每一个新的功能和修改的功能，都可以影响到其他功能，造成副作用。所以，需要自动化去支持变化，在变化的同时保证质量和开发速度，包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。
架构师和Scrum Master的重要性
    流程的变化必将带来岗位和职责的变化，架构师和Scrum Master是在敏捷开发中两个重要的人物角色：
    1) 产品架构师
    在产品的敏捷开发中，特别是我所参与的产品是面向行业的产品，架构师是个举足轻重的角色，需要有深厚的行业背景、创新能力，以及架构能力。
    产品是为了解决一类客户需求而存在。但是，客户的需求往往是会随着业务的发展而变化，而且竞争对手也会有类似产品的推出。所以一个产品推出市场后，所具有的功能模块慢慢地会越来越成熟，并拥有越来越多的竞争对手，慢慢地失去竞争力。一个好的产品，特别是面向行业的产品，要具有长期的生命力，需要具有下图所示的产品模型：

    成熟的模块：指的是推出市场有一段时间，这些功能模块因满足客户的需求而被广泛使用。随着市场趋于稳定，大量竞争对手的产品也推出类似的功能。这些成熟模块都是产品的基本模块，不代表产品的竞争力。产品中如果只具有这些功能模块，随着需求和竞争的激烈，慢慢会走向灭亡。如90年代的BP机一样，当手机一旦推出，这个产品也就走向灭亡。
    发展中的模块：指的是刚推出市场并且具有强劲的市场生命力、符合客户当前几年的业务发展需求，正在被大客户所接受的功能模块。这些功能模块是产品占领市场的动力，是继成熟的功能模块后，产品的新的增长动力。
    研究中的下一代产品方向：指的是还没有推出市场、正在研究中的、符合未来行业五到十年发展方向的模块。当然如果能创造出未来的发展方向，则是最高境界。如任天堂的Wii、苹果公司的iPhone。
    一个行业软件产品要保持长期的生命力，在整个产品的生命周期架构规划中，需要考虑到这三种模块和特性，只有这样才能保持产品的先进性和长久生命力。
    敏捷开发也强调拥抱市场变化，这对产品架构师提出了很高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。
    2) Scrum Master
    Scrum Master虽然是敏捷开发的新名词，但其工作内容和开发组长没什么太大的区别：安排任务、协调资源、控制进度和解决难题。
    架构师根据对行业的理解和创新，设计出产品的架构。Scrum Master则是进一步分解和实现这个架构中的每个组件。如果形容"奥运会开幕式"是一个产品，架构师则设计整个开幕式的主题、创意、架构和包含的主要环节，而Scrum Master就是整个庞大工程的详细设计者和协调者。
    在我们产品中有三个Scrum Master，各自负责架构中的不同模块，并和开发人员一起把模块分解成一个个单独的、可以衡量的用例，然后协调开发人员高质量的完成任务。
    此外，每天早上需要主持小组成员进行一个10分钟左右Scrum会议。每个组员汇报昨天完成的任务，是否完成任务以及碰到的问题，最后是今天打算完成的任务。Scrum Master会协调解决每天碰到的问题，确保产品进度和质量。
总结
    在笔者的理解中，敏捷开发是一种思维方式和软件过程方法论，以及一系列的最佳实践，它能帮助团队开发出更加符合市场需求的产品。我们的团队在产品两个版本的敏捷开发历程中，不断摸索，找到了一条适合自己的产品敏捷开发流程，我们还将继续用敏捷的思想改进我们的敏捷开发流程，希望能与大家讨论探索，持续改进。