Scrum中文交流社区-最专业的敏捷开发社区
Scrum术语字典
本文由
提供，免费下载链
接：/down/class/译者：Ryan
目录
•燃尽图（BurndownCharts）•每日站会（DailyScrumMeeting）•障碍（Impediments）•产品Backlog(ProductBacklog)•产品Backlog项（ProductBacklogItem）•产品Backlog项的工作量（ProductBacklogItemEffort）•产品的燃尽图（ProductBurndownChart）•产品负责人（ProductOwnerRole）•发布（Release）•发布燃尽图（ReleaseBurndownChart）•Scrum角色（ScrumRoles）•ScrumMaster角色（ScrumMasterRole）•Sprint•SprintBacklog•Sprint燃尽图（SprintBurndownChart）•Sprint目标（SprintGoals）•Sprint计划会议（SprintPlanningMeeting）•Sprint评审会议（SprintReviewMeeting）•Sprint任务（SprintTask）•团队（Team）
Scrum中文交流社区-最专业的敏捷开发社区
•速率（Velocity）•团队成员（TeamMember）
燃尽图
燃尽图显示了随着时间的推移还剩下的工作量。
Y坐标表示工作量，X坐标表示时间.剩下的工作量应该有节奏的增加或减少，并最终显现下降的趋势。
Sprint燃尽图显示的日常的进展状况，产品的燃尽图则显示了每个Sprint的进展情况。
每日站会在15分钟的站会中，每个Scrum团队成员需要回答如下三个问题：
1."我昨天做了些什么？"
2."我今天准备做什么？"
3."是什么妨碍了我尽可能有效的进行我的工作？"ScrumMaster需要确保所有与会者讨论任何和以上三个议题不相关的任何话题。
每日站会建议做为早上所有成员到齐后的第一件事情来做。
障碍 任何阻碍团队成员尽可能有效工作的事情都认为是障碍。
任何成员都可以在每日站会上提出自己遇到的障碍。
ScrumMaster负责确认这些障碍并解决它们。
当一些障碍在每日站会上无法解决是，ScrumMaster需要召集另外的会议来解决。
产品Backlog 产品Backlog是系统需求,它的表现形式是一个排列好有先级的产品Backlog项目列表。
这些需求包含客户提出的功能性需求和非功能性需求，以及技术团队内部产生的一些需求。
产品Backlog有这么多的来源，产品负责人的唯一任务就是要把这些需求排列好优先级。
在Sprint的计划会上，会根据产品负责人排好的优先级将Backlog项目从产品backlog移动到SprintBacklog。
Scrum中文交流社区-最专业的敏捷开发社区 产品Backlog项 在Scrum中，一个产品Backlog项（PBI）是一个可以在一个Sprint中完成的任务单元.产品Backlog项会被分解成为一个或多个任务.它也是Backlog工作量估计的单元. 产品backlog项的工作量 一些Scrum的实践者采用理想的工程天（人/天）的方式来估计工作量，但是很多人不太赞成这种给具体时间的方式。
我们还可以使用故事点，功能点作为衡量的单元，或者类似定义T恤衫大小的方式（1代表小号，2代表中号等）。
采用模糊单元估计的优势在于他们很明确的指出产品backlog的工作量估计不是对开发周期的估计。
这些估计也只是粗略的估计，不能和时间的工作时间混为一团。
产品燃尽图 在Scrum中，产品燃尽图从一个全局的视角展现了项目当前的进展情况。
他显示在每个Sprint开始时还要多少工作要做。
这张图的范围跨越了多个发布周期。
尽管如此，一次发布的燃尽图仅限于显示当前release的状况。
下图是一个产品燃尽图的示例： Scrum中文交流社区-最专业的敏捷开发社区 产品负责人的角色 在Scrum中，必须有一个人可以在backlog的优先级和需求问题上能够代表客户的意愿。
这个人必须在任何时候都可以被Scrum团队找到，特别是在开Sprint计划会议和评审会议的时候。
产品负责人所面临的挑战：
1.抵制去管理团队的诱惑。
团队也许不会像你期望的那样自我管理起来。
如果有些团队成员的要求你进行干预一些他们自己应该理清楚地问题是最有挑战性的。
2.抵制在Sprint过程中增加许多重要工作的诱惑。
3.有意愿在Sprint的计划会议上做出艰难的抉择。
4.平衡相互抵触的利益相关者的利益。
发布 一个增量的可交付的产品到可以例行使用的产品的转换。
发布一般会在我们经历了一个或多个sprint，产品具有的价值超出了发布成本的时候去发布。
发布燃尽图 在Scrum中，发布的燃尽图是一个发布过程进展情况的全局视图。
它显示了在一次发布内部每个sprint开始时还有多少任务没有完成。
它的范围仅被限定在一次发布内。
但是，产品的燃尽图则显示的是所有发布所包含的内容。
Scrum角色 任何Scrum项目中都必须有如下三个角色:•产品负责人•ScrumMaster•Scrum团队 ScrumMaster角色 ScrumMaster作为teamleader和Productowner紧密地工作在一起，他可以及时地为团队成员提供帮助。
他必须: Scrum中文交流社区-最专业的敏捷开发社区 •保证团队资源完全可被利用并且全部是高产出的。
•保证各个角色及职责的良好协作。
•解决团队开发中的障碍。
•做为团队和外部的接口，屏蔽外界对团队成员的干扰。
•保证开发过程按计划进行，组织DailyScrum,SprintReview andSprintPlanningmeetings。
Sprint 一个固定周期的迭代，周期为1个月，迭代中增量的完成产品的一些功能实现。
这个周期要长于其他的敏捷方法，原因是我们在每个Sprint中都要产出一个具有增量功能的产品。
一个Sprint通过一天Sprint计划会议作为开始。
Sprint中每天都会有每日站会。
在Sprint结束时我们会有Sprint评审会议，紧接着是Sprint的回顾会议。
在每个Sprint中，团队必须不能被增加的需求打断。
保证团队不被打扰，使得我们可以真的实现我们按时交付的承诺。
出于实际情况的需要，一些团队选择扭曲了这条规则，采用一些成员留出20%的时间用来响应bug和紧急状况。
但这是一个滑坡，无论什么时候都要尽可能的避免。
SprintBacklog 定义了一个Sprint当中需要完成的工作，表现形式为一个为了实现Sprint目标必须完成的任务的列表，它们是从产品Backlog项中根据优先级挑选出来的。
SprintBurndownChart 一个Sprint的燃尽图描述了没有还剩下的所有任务的小时数。
它通过分析完成要达到Sprint的目标对应的产品backlog所分解出来的任务量，来看团队目前所处的位置。
X轴显示了Sprint中的天数，Y轴显示了还剩下的工作量（一般是用理想的工程天来表示）。
为了激励团队，燃尽图要突出显示。
燃尽图同时也扮演了一个有效信息散发器的角色。
对于这个的人工的替代品时一个物理的任务板。
理想的燃尽图在Sprint结束时会烧到
0。
如果团队成员如实地汇报剩下的工作量，这条线的凸点会没有规律的向上或向下.下图是一个典型的示例，从这里你可以很明确 Scrum中文交流社区-最专业的敏捷开发社区 的看到传统的百分比的管理方法失灵的原因，假如26号的时候完成了30%，28号的百分比该如何计算？ Sprint目标Sprint的目标是开发团队和产品负责人协商的结果。
有意义的Sprint目标是详细的，并且是可测量的。
比如和“提高系统的可扩展性”相比“处理版本0.8五倍的用户数”这个目标就要好的多。
Scrum关注的目标结果是一个可以演示的产品。
产品的负责人有权期望开发团队交付一个可以演示的产品，尽管它在第一个Sprint中有可能是只包含少量的功能，并且是相当简陋的。
但是，随着Sprint的发展，在后续的迭代中会递交更健壮，包含更多功能的产品。
有了这些对Sprint目标的承诺，在Sprint结束的时候，任何人都可以看出最终的交付是不是符合要求。
当然，在Sprint结束的时候可能存在一些产品的backlog没有完成，但这应该是相当少见的。
Scrum要求开发团队一旦意识到有些任务无法完成时，要及时的提醒产品负责人。
Sprint计划会议Sprint的计划会议是产品负责人和开发团队协商那些开发任务需要放在下个Sprint中开发的活动。
产品的负责人会和团队成员在Sprint的目标上达成一致，这些目标决定了那些产品backlog项从未承诺的backlog中放入Sprint。
在Sprint计划会议上，经常会有新的项加进来。
这一部分的会议时间为固定的4个小时。
在这之后的4个小时，Scrum团队会分解这些backlog项到具体的任务，这个时候产品负责人不需要在场，但如果团队需要重新协商 Scrum中文交流社区-最专业的敏捷开发社区 或遇到时间估计的问题时，产品负责人要随时可以找到。
有时候对于一些在Sprint最后的时候才会做的任务，团队可以采用插入占位符任务的方式（只做粗略的时间估计）。
Sprint评审会议 在Sprint结束的时候召开Sprint评审会.这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给ProductOwner.ProductOwner会组织这阶段的会议并且邀请相关的利益相关者参加。
业务，市场，技术都要做相关的评审。
有ProductOwner来决定ProductBacklog中的哪些功能已经开发完成，还要和ScrumTeam及相关的利益相关者讨论下个Sprint中ProductBacklog的优先级。
下个Sprint的目标在这个时候被确定下来。
会议的下半部分，是由ScrumMaster和ScrumTeam一起回顾当前的Sprint。
团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。
Sprint评审会结束后，新一轮的迭代又继续开始，迭代会一直继续，直到开发了足够多的功能去交付一个产品。
Sprint任务 在Scrum中，一个Sprint的任务，是一个工作量在4个小时到16个小时的单元。
估计出来的剩余的工作量每天都会更新，并体现在Sprint燃尽图上。
这些任务都是由Sprint挑选出来的产品backlog分解出来的。
Scrum鼓励将任务分解的更小，如果一个任务需要12个人/小时的时候。
团队 一个Scrum团队，最好是由7人左右组成，上下不超过两个。
在一个软件开发团队中，团队成员一般是由软件工程师，架构师，程序员，软件分析师，质量控制专家，测试人员，UI设计师等混合组成。
这经常称作“跨职能的项目团队”。
敏捷实践中也鼓励跨职能的团队成员。
在Sprint中，团队可以自组织的达到Sprint目标。
团队可以自主的选择如何去更好的满足目标，同时为结果负责。
Scrum也主张将一个团队安排在一个房间中做开发。
Scrum中文交流社区-最专业的敏捷开发社区 团队成员 在Scrum用语中,一个团队成员被定义为任何为了Sprint的目标在完成Sprint任务的人。
速率 在Scrum中，速率是指在一个Sprint中能够完成多少产品Backlog的工作量。
这个可以通过之前经历的Sprint的情况来估计，假设团队组成和团队周期是固定的。
通过一段时间的统计，速率可以作为后续项目工作量估计，产品开发周期估计的参考数据。
Y坐标表示工作量，X坐标表示时间.剩下的工作量应该有节奏的增加或减少，并最终显现下降的趋势。
Sprint燃尽图显示的日常的进展状况，产品的燃尽图则显示了每个Sprint的进展情况。
每日站会在15分钟的站会中，每个Scrum团队成员需要回答如下三个问题：
1."我昨天做了些什么？"
2."我今天准备做什么？"
3."是什么妨碍了我尽可能有效的进行我的工作？"ScrumMaster需要确保所有与会者讨论任何和以上三个议题不相关的任何话题。
每日站会建议做为早上所有成员到齐后的第一件事情来做。
障碍 任何阻碍团队成员尽可能有效工作的事情都认为是障碍。
任何成员都可以在每日站会上提出自己遇到的障碍。
ScrumMaster负责确认这些障碍并解决它们。
当一些障碍在每日站会上无法解决是，ScrumMaster需要召集另外的会议来解决。
产品Backlog 产品Backlog是系统需求,它的表现形式是一个排列好有先级的产品Backlog项目列表。
这些需求包含客户提出的功能性需求和非功能性需求，以及技术团队内部产生的一些需求。
产品Backlog有这么多的来源，产品负责人的唯一任务就是要把这些需求排列好优先级。
在Sprint的计划会上，会根据产品负责人排好的优先级将Backlog项目从产品backlog移动到SprintBacklog。
Scrum中文交流社区-最专业的敏捷开发社区 产品Backlog项 在Scrum中，一个产品Backlog项（PBI）是一个可以在一个Sprint中完成的任务单元.产品Backlog项会被分解成为一个或多个任务.它也是Backlog工作量估计的单元. 产品backlog项的工作量 一些Scrum的实践者采用理想的工程天（人/天）的方式来估计工作量，但是很多人不太赞成这种给具体时间的方式。
我们还可以使用故事点，功能点作为衡量的单元，或者类似定义T恤衫大小的方式（1代表小号，2代表中号等）。
采用模糊单元估计的优势在于他们很明确的指出产品backlog的工作量估计不是对开发周期的估计。
这些估计也只是粗略的估计，不能和时间的工作时间混为一团。
产品燃尽图 在Scrum中，产品燃尽图从一个全局的视角展现了项目当前的进展情况。
他显示在每个Sprint开始时还要多少工作要做。
这张图的范围跨越了多个发布周期。
尽管如此，一次发布的燃尽图仅限于显示当前release的状况。
下图是一个产品燃尽图的示例： Scrum中文交流社区-最专业的敏捷开发社区 产品负责人的角色 在Scrum中，必须有一个人可以在backlog的优先级和需求问题上能够代表客户的意愿。
这个人必须在任何时候都可以被Scrum团队找到，特别是在开Sprint计划会议和评审会议的时候。
产品负责人所面临的挑战：
1.抵制去管理团队的诱惑。
团队也许不会像你期望的那样自我管理起来。
如果有些团队成员的要求你进行干预一些他们自己应该理清楚地问题是最有挑战性的。
2.抵制在Sprint过程中增加许多重要工作的诱惑。
3.有意愿在Sprint的计划会议上做出艰难的抉择。
4.平衡相互抵触的利益相关者的利益。
发布 一个增量的可交付的产品到可以例行使用的产品的转换。
发布一般会在我们经历了一个或多个sprint，产品具有的价值超出了发布成本的时候去发布。
发布燃尽图 在Scrum中，发布的燃尽图是一个发布过程进展情况的全局视图。
它显示了在一次发布内部每个sprint开始时还有多少任务没有完成。
它的范围仅被限定在一次发布内。
但是，产品的燃尽图则显示的是所有发布所包含的内容。
Scrum角色 任何Scrum项目中都必须有如下三个角色:•产品负责人•ScrumMaster•Scrum团队 ScrumMaster角色 ScrumMaster作为teamleader和Productowner紧密地工作在一起，他可以及时地为团队成员提供帮助。
他必须: Scrum中文交流社区-最专业的敏捷开发社区 •保证团队资源完全可被利用并且全部是高产出的。
•保证各个角色及职责的良好协作。
•解决团队开发中的障碍。
•做为团队和外部的接口，屏蔽外界对团队成员的干扰。
•保证开发过程按计划进行，组织DailyScrum,SprintReview andSprintPlanningmeetings。
Sprint 一个固定周期的迭代，周期为1个月，迭代中增量的完成产品的一些功能实现。
这个周期要长于其他的敏捷方法，原因是我们在每个Sprint中都要产出一个具有增量功能的产品。
一个Sprint通过一天Sprint计划会议作为开始。
Sprint中每天都会有每日站会。
在Sprint结束时我们会有Sprint评审会议，紧接着是Sprint的回顾会议。
在每个Sprint中，团队必须不能被增加的需求打断。
保证团队不被打扰，使得我们可以真的实现我们按时交付的承诺。
出于实际情况的需要，一些团队选择扭曲了这条规则，采用一些成员留出20%的时间用来响应bug和紧急状况。
但这是一个滑坡，无论什么时候都要尽可能的避免。
SprintBacklog 定义了一个Sprint当中需要完成的工作，表现形式为一个为了实现Sprint目标必须完成的任务的列表，它们是从产品Backlog项中根据优先级挑选出来的。
SprintBurndownChart 一个Sprint的燃尽图描述了没有还剩下的所有任务的小时数。
它通过分析完成要达到Sprint的目标对应的产品backlog所分解出来的任务量，来看团队目前所处的位置。
X轴显示了Sprint中的天数，Y轴显示了还剩下的工作量（一般是用理想的工程天来表示）。
为了激励团队，燃尽图要突出显示。
燃尽图同时也扮演了一个有效信息散发器的角色。
对于这个的人工的替代品时一个物理的任务板。
理想的燃尽图在Sprint结束时会烧到
0。
如果团队成员如实地汇报剩下的工作量，这条线的凸点会没有规律的向上或向下.下图是一个典型的示例，从这里你可以很明确 Scrum中文交流社区-最专业的敏捷开发社区 的看到传统的百分比的管理方法失灵的原因，假如26号的时候完成了30%，28号的百分比该如何计算？ Sprint目标Sprint的目标是开发团队和产品负责人协商的结果。
有意义的Sprint目标是详细的，并且是可测量的。
比如和“提高系统的可扩展性”相比“处理版本0.8五倍的用户数”这个目标就要好的多。
Scrum关注的目标结果是一个可以演示的产品。
产品的负责人有权期望开发团队交付一个可以演示的产品，尽管它在第一个Sprint中有可能是只包含少量的功能，并且是相当简陋的。
但是，随着Sprint的发展，在后续的迭代中会递交更健壮，包含更多功能的产品。
有了这些对Sprint目标的承诺，在Sprint结束的时候，任何人都可以看出最终的交付是不是符合要求。
当然，在Sprint结束的时候可能存在一些产品的backlog没有完成，但这应该是相当少见的。
Scrum要求开发团队一旦意识到有些任务无法完成时，要及时的提醒产品负责人。
Sprint计划会议Sprint的计划会议是产品负责人和开发团队协商那些开发任务需要放在下个Sprint中开发的活动。
产品的负责人会和团队成员在Sprint的目标上达成一致，这些目标决定了那些产品backlog项从未承诺的backlog中放入Sprint。
在Sprint计划会议上，经常会有新的项加进来。
这一部分的会议时间为固定的4个小时。
在这之后的4个小时，Scrum团队会分解这些backlog项到具体的任务，这个时候产品负责人不需要在场，但如果团队需要重新协商 Scrum中文交流社区-最专业的敏捷开发社区 或遇到时间估计的问题时，产品负责人要随时可以找到。
有时候对于一些在Sprint最后的时候才会做的任务，团队可以采用插入占位符任务的方式（只做粗略的时间估计）。
Sprint评审会议 在Sprint结束的时候召开Sprint评审会.这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给ProductOwner.ProductOwner会组织这阶段的会议并且邀请相关的利益相关者参加。
业务，市场，技术都要做相关的评审。
有ProductOwner来决定ProductBacklog中的哪些功能已经开发完成，还要和ScrumTeam及相关的利益相关者讨论下个Sprint中ProductBacklog的优先级。
下个Sprint的目标在这个时候被确定下来。
会议的下半部分，是由ScrumMaster和ScrumTeam一起回顾当前的Sprint。
团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。
Sprint评审会结束后，新一轮的迭代又继续开始，迭代会一直继续，直到开发了足够多的功能去交付一个产品。
Sprint任务 在Scrum中，一个Sprint的任务，是一个工作量在4个小时到16个小时的单元。
估计出来的剩余的工作量每天都会更新，并体现在Sprint燃尽图上。
这些任务都是由Sprint挑选出来的产品backlog分解出来的。
Scrum鼓励将任务分解的更小，如果一个任务需要12个人/小时的时候。
团队 一个Scrum团队，最好是由7人左右组成，上下不超过两个。
在一个软件开发团队中，团队成员一般是由软件工程师，架构师，程序员，软件分析师，质量控制专家，测试人员，UI设计师等混合组成。
这经常称作“跨职能的项目团队”。
敏捷实践中也鼓励跨职能的团队成员。
在Sprint中，团队可以自组织的达到Sprint目标。
团队可以自主的选择如何去更好的满足目标，同时为结果负责。
Scrum也主张将一个团队安排在一个房间中做开发。
Scrum中文交流社区-最专业的敏捷开发社区 团队成员 在Scrum用语中,一个团队成员被定义为任何为了Sprint的目标在完成Sprint任务的人。
速率 在Scrum中，速率是指在一个Sprint中能够完成多少产品Backlog的工作量。
这个可以通过之前经历的Sprint的情况来估计，假设团队组成和团队周期是固定的。
通过一段时间的统计，速率可以作为后续项目工作量估计，产品开发周期估计的参考数据。
声明：
该资讯来自于互联网网友发布，如有侵犯您的权益请联系我们。
