Scrum敏捷项目管理知识.doc

SCRUM敏捷管理知识
一、 什么就是scrum
Scrum就是一个用于开发与维持复杂产品得框架，就是一个增量得、迭代得开发过程。在这个框架中，整个开发过程由若干个短得迭代周期组成，一个短得迭代周期称为一个Sprint，每个Sprint得建议长度就是2到4周(互联网产品研发可以使用1周得Sprint)。在Scrum中，使用产品Backlog来管理产品得需求，产品backlog就是一个按照商业价值排序得需求列表，列表条目得体现形式通常为用户故事。Scrum团队总就是先开发对客户具有较高价值得需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级得需求进行开发。挑选得需求在Sprint计划会议上经过讨论、分析与估算得到相应得任务列表，我们称它为Sprintbacklog。在每个迭代结束时，Scrum团队将递交潜在可交付得产品增量。Scrum起源于软件开发项目，但它适用于任何复杂得或就是创新性得项目。
Scrum流程如下图：

SCRUM框架包括3个角色、3个工件、5个活动、5个价值，具体说明如下：
3个角色
1. 产品负责人（ProductOwner）
2. ScrumMaster
3. Scrum团队
3个工件
1. 产品Backlog（ProductBacklog）
2. SprintBacklog
3. 产品增量（Increment）
5个活动
1. 产品Backlog梳理会议（ProductBacklogRefinement）
2. Sprint计划会议（SprintPlanningMeeting）
3. 每日站会（DailyScrumMeeting）
4. Sprint评审会议（SprintReviewMeeting）
5. Sprint回顾会议（SprintRetrospectiveMeeting）
5个价值
1. 承诺–愿意对目标做出承诺
2. 专注–把您得心思与能力都用到您承诺得工作上去
3. 开放–Scrum把项目中得一切开放给每个人瞧
4. 尊重–每个人都有她独特得背景与经验
5. 勇气–有勇气做出承诺，履行承诺，接受别人得尊重
SCRUM理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础得过程。经验主义主张知识源于经验,以及基于已知得东西做决定。Scrum采用迭代、增量得方法来优化可预见性并控制风险。
Scrum得三大支柱支撑起每个经验性过程控制得实现:透明性、检验与适应。Scrum得三大支柱如下：
第一：透明性（Transparency）
透明度就是指，在软件开发过程得各个环节保持高度得可见性，影响交付成果得各个方面对于参与交付得所有人、管理生产结果得人保持透明。管理生产成果得人不仅要能够瞧到过程得这些方面，而且必须理解她们瞧到得内容。也就就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于她们对完成得定义。
第二：检验（Inspection）
开发过程中得各方面必须做到足够频繁地检验，确保能够及时发现过程中得重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定得检验频率超出了过程检验所能容许得程度，那么就会出现问题。幸运得就是，软件开发并不会出现这种情况。另一个因素就就是检验工作成果人员得技能水平与积极性。
第三：适应（Adaptation）
如果检验人员检验得时候发现过程中得一个或多个方面不满足验收标准，并且最终产品就是不合格得，那么便需要对过程或就是材料进行调整。调整工作必须尽快实施，以减少进一步得偏差。
Scrum中通过三个活动进行检验与适应：每日例会检验Sprint目标得进展，做出调整，从而优化次日得工作价值；Sprint评审与计划会议检验发布目标得进展，做出调整，从而优化下一个Sprint得工作价值；Sprint回顾会议就是用来回顾已经完成得Sprint，并且确定做出什么样得改善可以使接下来得Sprint更加高效、更加令人满意，并且工作更快乐。
二、 SCRUM术语
Scrum：Scrum无对应中文翻译
Agile：敏捷
Lean：精益
Iterative：迭代式得
Iteration：迭代
AgileManifesto：敏捷宣言
Empirical：经验性得
EmpiricalProcess：经验性过程
Transparency：透明性
InspectandAdapt：检视与调整
Sprint：原意为冲刺，Scrum中得Sprint无对应中文翻译，指一个迭代
SprintGoal：Sprint目标
ProductOwner：产品负责人简称PO
ScrumMaster：简称SM,一般不翻译
DevelopmentTeam：Scrum开发团队
ScrumTeam：指PO,SM与开发团队
ScrumRoles：Scrum角色，指PO,SM与开发团队
Emergent：涌现得
ProductBacklog：产品待办列表，指需求清单
SprintBacklog：Sprint待办列表，指Sprint任务清单
SprintBurn-downChart：Sprint燃尽图，团队用于做Sprint内得进展跟踪
ReleaseBurn-downChart:发布燃尽图，产品负责人做发布进展跟踪
SprintPlanningMeeting:Sprint计划会议
DailyScrumMeeting：每日站会
SprintReviewMeeting：Sprint评审会议
SprintRetrospectiveMeeting:Sprint回顾会议
ProductBacklogRefinement:产品待办列表梳理
ProductBacklogItem:产品待办清单条目，简称PBI
UserStory:用户故事，指一条需求
StoryPoint：衡量用户故事得工作量大小得计量单位
Velocity:团队速度
SprintTask:实现一条需求需要做得一个技术任务
DefinitionofDone:DoD，完成得定义
Stakeholders：干系人
Backlog：待办列表
Artifact：工件
Estimation：估算
Collaboration：协作
ScalingScrum：大规模Scrum
三、 SCRUM起源
Scrum得原始含义
Scrum原始含义就是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有8个队员参与，各方出3名前锋队员，并肩各站成一横排，面对面躬身互相顶肩，中间形成一条通道，其她前锋队员分别站在后面，后排队员用肩顶住前锋队员得臀部，组成3、2、3或3、4、1阵形。然后，由犯规队得对方队员在对阵一侧1码外，用双手低手将球抛入通道，不得有利于本队。当球抛入通道时，前排得3对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫与后卫队员必须等候前锋将球踢回后，方可移动。

1986Scrum这个词汇首次应用于产品开发
1986年，竹内弘高与野中郁次郎在NewNewProductDevelopmentGame文章首次提到将Scrum应用与产品开发，她们指出：
传统得“接力式”得开发模式已经不能满足快速灵活得市场需求，而整体或“橄榄球式”得方法——团队作为一个整体前进，在团队得内部传球并保持前进，这也许可以更好得满足当前激烈得市场竞争。
1993年JeffSutherland首次将Scrum用于软件开发
敏捷思想深受日本工业界最佳实践得影响，尤其就是丰田与本田公司推行得精益原则，以及竹内弘高与野中郁次郎开发得知识管理策略。受到以上思想得影响，以及对世界范围内软件项目得研究，JeffSutherland在1993年首次在Easel公司定义了用于了软件开发行业得Scrum流程，并开始实施。
1995年JeffSutherland与KenSchwaber规范化了Scrum框架，并在OOPSLA95上公开发布。
2001年敏捷宣言及原则发布、敏捷联盟成立，Scrum就是其中一种敏捷方法。
2001年，KenSchwaber与MikeBeedle推出第一本Scrum书籍《Scrum敏捷软件开发》。
2002年KenSchwaber与MikeCohn共同创办了Scrum联盟。
四、 经验性过程
软件开发就是一个复杂得活动，在软件产品开发得过程中不仅存在着需求得不确定性，也存在着技术得不确定性，再加上参与软件开发得主体通常就是由多人组成得软件开发团队，加上人得因素，就让整个软件开发得活动变得非常复杂。如下图所示，软件开发活动通常处在下图得很复杂得区域。

图-01
为了管理软件开发得活动，我们会引入过程控制来管理它。过程控制通常有两种方式，第一种方式就是预定义得过程，第二种方式就是经验性过程。
我们所熟知得就是预定义得过程，它通常就是使用已知得方法解决已知得问题。制造业得生产线就就是典型得预定义过程，例如生产饼干、啤酒、汽车得生产线等。预定义得过程得特点就是给予固定得输入，得到固定得输出，过程可重复。它得优势在于可以大规模批量生产。预定义过程得缺点在于一旦过程定义出现错误，或产品设计上存在瑕疵，会造成比较大得损失。

图－02
如果我们期望解决得问题比较复杂，并且存在着较大得不确定性得时候，我们需要使用经验性过程。经验性过程得特点就是过程就是不能够完全预先定义好，结果就是不可预知得，生产过程就是不可重复得。比如研究一项新技术，下一盘棋，踢一场球赛，在过程运行当中，我们需要通过不断得获得真实得反馈，然后进行适应与调整，使得过程能够产出我们需要得结果。
“在过程运行机制相当简单易懂得情况下，典型得做法就是采用预定义得建模方式。如果过程复杂程度超出预定义方式得能力范围，便应用经验性方式。”
——B、A、OgunnaikeandW、H、Ray
《过程动态学、建模与控制》
软件产品得研发通常存在多很多得不确定性，并且生产得过程非常得复杂，所以更适合使用经验性过程来管理。
Scrum以经验性过程控制理论做为理论基础得过程。Scrum采用迭代、增量得方法来优化可预见性并控制风险。
Scrum过程框架得基石包括如下三个方面：
第一：透明性（Transparency）
透明度就是指，在软件开发过程得各个环节保持高度得可见性，影响交付成果得各个方面对于参与交付得所有人、管理生产结果得人保持透明。管理生产成果得人不仅要能够瞧到过程得这些方面，而且必须理解她们瞧到得内容。也就就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于她们对完成得定义。
第二：检验（Inspection）
开发过程中得各方面必须做到足够频繁地检验，确保能够及时发现过程中得重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定得检验频率超出了过程检验所能容许得程度，那么就会出现问题。幸运得就是，软件开发并不会出现这种情况。另一个因素就就是检验工作成果人员得技能水平与积极性。
第三：适应（Adaptation）
如果检验人员检验得时候发现过程中得一个或多个方面不满足验收标准，并且最终产品就是不合格得，那么便需要对过程或就是材料进行调整。调整工作必须尽快实施，以减少进一步得偏差。
Scrum中通过三个活动进行检验与适应：每日例会检验Sprint目标得进展，做出调整，从而优化次日得工作价值；Sprint评审与计划会议检验发布目标得进展，做出调整，从而优化下一个Sprint得工作价值；Sprint回顾会议就是用来回顾已经完成得Sprint，并且确定做出什么样得改善可以使接下来得Sprint更加高效、更加令人满意，并且工作更快乐。
五、 SCRUM团队得三个角色
Scrum团队中包括三个角色，她们分别就是产品负责人、开发团队与ScrumMaster。
Scrum团队就是自组织、跨职能得完整团队。自组织团队决定如何最好地完成她们得工作,而不就是由团队外得其她人来指挥她们。
跨职能得团队拥有完成工作所需要得全部技能,不需要依赖团队外部得人。Scrum团队模式得目得就是最大限度地优化适应性、创造性与生产力。
Scrum团队通过迭代与增量交付产品功能得方法最大化反馈得机会。增量交付潜在可交付得产品增量保证了每个迭代都有潜在可发布得版本。
Scrum角色之：产品负责人
产品负责人负责最大化产品以及开发团队工作得价值。实现这一点得方式会随着组织、Scrum团队以及单个团队成员得不同而不同。
产品负责人就是管理产品待办事项列表得唯一责任人。产品待办事项列表得管理包括:
· 清晰地表达产品代办事项列表条目
· 对产品代办事项列表中得条目进行排序,最好地实现目标与使命
· 确保开发团队所执行工作得价值
· 确保产品代办事项列表对所有人可见、透明、清晰,并且显示Scrum团队得下一步工作
· 确保开发团队对产品代办事项列表中得条目达到一定程度得理解
产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人就是负责任者。
产品负责人就是一个人,而不就是一个委员会。产品负责人可能会在产品代办事项列表中体现一个委员会得需求,但要想改变某条目得优先级必须先说服产品负责人。
为保证产品负责人得工作取得成功,组织中得所有人员都必须尊重她得决定。产品负责人所作得决定在产品待办事项列表得内容与排序中要清晰可见。任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其她人得指令。
Scrum角色之：开发团队
开发团队包含了专业人员,负责在每个Sprint得结尾交付潜在可发布得“完成”产品增量。只有开发团队得成员才能创造增量。
开发团队由组织构建并授权,来组织与管理她们得工作。所产生得协同工作能最大化开发团队得整体效率与效力。开发团队有以下几个特点:
· 她们就是自组织得,没有人(即使就是ScrumMaster都不可以)告诉开发团队如何把产品代办事项列表变成潜在可发布得功能。
· 开发团队就是跨职能得,团队作为一个整体拥有创造产品增量所需要得全部技能。
· Scrum不认可开发团队成员得头衔,无论承担哪种工作她们都就是开发者。此规则无一例外。
· 开发团队中得每个成员可以有特长与专注领域,但就是责任归属于整个开发团队
· 开发团队不包含如测试或业务分析等负责特定领域得子团队。
开发团队得规模
开发团队最佳规模就是小到足以保持敏捷性,大到足以完成重要工作。少于3人得开发团队没有足够得交互,因而所获得得生产力增长也不会很大。小团队在Sprint中可能会受到技能限制,从而导致无法交付可发布得产品增量。大于9人得团队需要过多得协调沟通工作。大型团队会产生太多复杂性,不便于经验过程管理。产品负责人与ScrumMaster得角色不包含在此数字中,除非她们也参与执行Sprint代表事项列表中得工作。
Scrum角色之：ScrumMaster
ScrumMaster负责确保Scrum被理解并实施。为了达到这个目得,ScrumMaster要确保Scrum团队遵循Scrum得理论、实践与规则。ScrumMaster就是Scrum团队中得服务式领导。
ScrumMaster帮助Scrum团队外得人员了解她们如何与Scrum团队交互就是有益得。ScrumMaster通过改变这些交互来最大化Scrum团队所创造得价值。
ScrumMaster服务于产品负责人
ScrumMaster以各种方式服务于产品负责人,包括:
· 找到有效管理产品代办事项列表得技巧
· 清晰地与开发团队沟通愿景、目标与产品代表事项列表条目
· 教导开发团队创建清晰简明得产品代表事项列表条目
· 在经验主义环境中理解长期得产品规划
· 理解并实践敏捷
· 按需推动Scrum活动
ScrumMaster服务于开发团队
ScrumMaster以各种方式服务于开发团队,包括:
· 指导开发团队自组织与跨职能
· 教导并领导开发团队创造高价值得产品
· 移除开发团队进展过程中得障碍
· 按需推动Scrum活动
· 在Scrum还未完全被采纳与理解得组织环境下指导开发团队
ScrumMaster服务于组织
ScrumMaster以各种方式服务于组织,包括:
· 领导并指导组织采用Scrum
· 在组织范围内计划Scrum得实施
· 帮助员工及干系人理解并实施Scrum与经验性产品开发
· 发起能提升Scrum团队生产力得变革
· 与其她ScrumMaster一起工作,帮助组织更有效得应用Scrum
六、 SCRUM得三个工件
Scrum得工件以不同得方式展现工作与价值,可以用来提供透明性以及检验与适应得机会。Scrum中所定义得工件能最大化关键信息得透明性,来保证Scrum团队成功地交付完成得增量。
ProductBacklog–产品待办事项列表
产品待办事项列表就是一个排序得列表,包含所有产品需要得东西,也就是产品需求变动得唯一来源。产品负责人负责产品待办事项列表得内容、可用性与优先级。
产品待办事项列表就是一个持续完善得清单,最初得版本只列出最初始得与众所周知得需求。产品待办事项列表根据产品与开发环境得变化而演进。待办事项列表就是动态得,它经常发生变化以识别使产品合理、有竞争力与有用所必需得东西。只要产品存在,产品待办事项列表就存在。
产品待办事项列表列出了所有得特性、功能、需求、改进方法与缺陷修复等对未来发布产品进行得改变。产品待办事项列表条目包含描述、次序与估算得特征。
产品待办事项列表通常以价值、风险、优先级与必须性排序。它就是一个按照优先级由高到低排列得一个序列，每个条目有唯一得顺序。排在顶部得产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值得意见越一致。
排序越高得产品待办事项列表条目比排序低得更清晰、更具体。根据更清晰得内容与更详尽得信息就能做出更准确得估算。优先级越低,细节信息越少。开发团队在接下来得Sprint中将要进行开发得产品待办事项列表条目就是细粒度得,已经被分解过,因此,任何一个条目在Sprint得时间盒内都可以被“完成”。开发团队在一个Sprint中可以“完成”得产品待办事项列表条目被认为就是“准备好得”或者“可执行得”,能在Sprint计划会议中被选择。
随着产品得使用、价值得获取以及市场得反馈,产品待办事项列表变成了更大、更详尽得列表。因为需求永远不会停止改变,所以产品待办事项列表就是个不断更新得工件。业务需求、市场形势与技术得变化都会引起产品待办事项列表得变化。
若干个Scrum团队常常会一起开发某个产品。但描述下一步产品开发工作得产品待办事项列表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组得属性。
通过产品Backlog地梳理来增添细节、估算与排序。这就是一个持续不断得过程,产品负责人与开发团队协作讨论产品代表事项列表条目得细节。在产品待办事项列表梳理得时候,条目会被评审与修改。然而,产品负责人可以随时更新产品代办事项列表条目或酌情决定。
梳理在Sprint中就是一项兼职活动,在产品负责人与开发团队之间展开。通常,开发团队有自行优化得领域知识。然而,何时如何完成优化就是Scrum团队得决定。优化通常占用不超过开发团队10%得时间。
开发团队负责所有得估算工作。产品负责人可以通过协助团队权衡取舍来影响她们得决定。但就是,最后得估算就是由执行工作得人来决定得。
监控向目标前进得进度
在任何时间,达成目标得剩余工作量就是可以被累计得。产品负责人至少在每个Sprint评审得时候追踪剩余工作总量。产品负责人把这个数量与之前Sprint评审时得剩余工作量做比较,来评估在希望得时间点完成预计工作达成目标得进度。这份信息对所有得干系人都透明。
Scrum不考虑已经花在产品代办事项列表条目上得工作时间。我们只关心剩余工作与日期这两个变量。
各种趋势燃尽图、燃烧图与其她计划实践都能用来预测进度。它们已经被证实有用。然而,这并不能代替经验主义得重要性。在复杂得环境下,将要发生得东西就是未知得,只有已经发生得事情才能用来做前瞻式得决策。
SPRINTBACKLOG
Sprint代办事项列表就是一组为当前Sprint选出得产品代办事项列表条目,外加交付产品增量与实现Sprint目标得计划。Sprint代办事项列表就是开发团队对于哪些功能要包含在下个增量中,以及交付那些功能所需工作得预计。
Sprint代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”得增量所需要执行得工作。Sprint代办事项列表使开发团队确定得、达到Sprint目标所需得工作清晰可见。
Sprint代办事项列表就是一份足够具体得计划,使得进度上得改变能在每日例会中得到理解。开发团队在整个Sprint中都会修改Sprint代办事项列表,Sprint代办事项列表也会在Sprint得进程中慢慢显现,比如开发团队按照计划工作并对完成Sprint目标所需得工作有更多得了解。
当出现新工作时,开发团队需要将其追加到Sprint待办事项列表中去。随着任务进行或者被完成,需要更新每项任务得估算剩余工作量。如果计划中某个部分失去开发得意义,就可以将其除去。在Sprint内只有开发团队可以对Sprint待办事项列表进行修改。Sprint待办事项列表就是高度可见得,就是对团队计划在当前Sprint内完成工作得实时反映,并且,该列表只属于开发团队。
ProductBacklog功能点被放到Sprint得固定周期中，SprintBacklog会因为如下原因发生变化:
1、随着时间得变化，开发团队对于需求有了更好得理解，有可能发现需要增加一些新得任务到SprintBacklog中。
2、程序缺陷做为新得任务加进来，这个都做为承诺提交任务中未完成得工作。
ProductOwner也许会与Scrumteam一起工作，以帮助team更好得理解Sprint得目标，ScrumMaster与team也许会觉得小得调整不会影响sprint得进度，但会给客户带来更多商业价值。
监控Sprint进度
在Sprint中得任意时间点,Sprint待办事项列表得所有剩余工作总与都可以被计算。开发团队至少在每日例会时追踪所有得剩余工作。开发团队每天追踪剩余总与并预测达成Sprint目标得可能性。通过在Sprint中不断追踪剩余工作,开发团队可以管理自己得进度。
Scrum不考虑已经花在Sprint待办事项列表上得工作时间。我们只关心剩余工作与日期这两个变量。
燃尽图（BURN-DOWNCHART)
Sprint燃尽图（SprintBurn-downChart)
SprintBurndownChart显示了Sprint中累积剩余得工作量，它就是一个反映工作量完成状况得趋势图。图中Y轴代表得就是剩余工作量，X轴代表得就是Sprint得工作日。

在Sprint开始得时候，ScrumTeam会标示与估计在这个Sprint需要完成得详细得任务。所有这个Sprint中需要完成，但没有完成得任务得工作量就是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。
由于在Sprint得刚开始得时候，增加得任务工作量可能大于完成得任务工作量，所以燃尽图有可能略微呈上升趋势。
发布燃尽图（ReleaseBurn-downChart）
在Scrum项目中，团队通过每个Sprint结束时更新得发布燃尽图来跟踪整个发布计划得进展。发布燃尽图记录了在一段时间内产品Backlog得总剩余估算工作量得变化趋势。X轴代表得项目周期，以Sprint为单位，Y轴代表得就是剩余工作量，通常以用户故事点、理想人天或者team-days为单位。
七、 SCRUM得五个活动
Scrum活动:产品待办事项列表梳理
产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待 办事项列表梳理就是一个贯穿整个Scrum项目始终得活动。该活动包含但不限于以下得内容:
· 保持产品待办事项列表有序
· 把瞧起来不再重要得事项移除或者降级
· 增加或提升涌现出来得或变得更重要得事项
· 将事项分解成更小得事项
· 将事项归并为更大得事项
· 对事项进行估算
产品待办事项列表梳理得一个最大好处就是为即将到来得几个Sprint做准备。为此,梳理时会特别关注那些即将被实现得事项。需要考虑不少因素,这包括但不限于以下得内容:
理想情况下,下一个Sprint得备选事项都应该提升“商业价值”。 开发团队需要能够在一个Sprint内完成每一个事项。每个人都需要清楚预期产出就是什么。
产品开发决定了,有可能需要其它得技能与输入。因此,产品待办事项列表梳理最好就是所有团队成员都参与得活动,而不单单就是产品负责人。
Scrum活动：Sprint计划会议
每个Sprint都以Sprint计划会议作为开始， 这就是一个固定时长得会议，在这个会议中,Scrum团队共同选择与理解在即将到来得Sprint中要完成得工作。
整个团队都要参加Sprint计划会议。针对排好序得产品待办事项列表(Product Backlog),产 品负责人与开发团队成员讨论每个事项,并对该事项达成共识,包括根据当前得“完成得定 义”,为了完成该事项所需要完成得所有事情。所有得Scrum会议都就是限定时得。Sprint计划会议推荐时就是Sprint中得每周对应两⼩时或者更少(译者注:比如,一个Sprint包含2个星 期,则Sprint计划会议时长应为4个小时或者更少)。因为会议就是限制时长得,Sprint计划会议得成功⼗分依赖于产品待办事项列表得质量。这就就是产品待办事项列表梳理十分重要得原因。
在Scrum中,Sprint计划会议有两部分:
1. 决定在Sprint中需要完成哪些工作
2. 决定这些工作如何完成
第一部分:需要完成哪些工作?
在会议得第一部分,产品负责人向开发团队介绍排好序得产品待办事项,整个Scrum团队共同理解这些工作。
Sprint中需要完成得产品待办事项数目完全由开发团队决定。为了决定做多少,开发团队需要考虑当前产品增量得状态,团队过去得工作情况,团队当前得生产能力,以及排好序得产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人,都不能给开发 团队强加更多得工作量。
通常Sprint都有个目标,称作Sprint目标。这将十分有效地帮助大家更加专注于需要完成得工 作得本质,而不必花太多精力去关注那些对于我们需要完成得工作并不重要得⼩小细节。
第二部分:如何完成工作?
在会议得第二部分⾥里,开发团队需要根据当前得“完成得定义”一起决定如何实现下一个产品增 量。她们进⾏行⾜足够得设计与计划,从而有信心可以在Sprint中完成所有工作。头几天得工作会 被分解成⼩小得单元,每个工作单元不超过一天。之后要完成得工作可以稍⼤大些,以后再对它 们进⾏行分解。
决定如何完成工作就是开发团队得职责,决定做什么则就是产品负责人得职责。
在计划会议得第二部分,产品负责人可以继续留下来回答问题,以及澄清一些误解。不管怎样,团队应该很容易找到产品负责人。
Sprint计划会议得产出 Sprint计划会议最终需要Scrum团队对Sprint需要完成工作得数量与复杂度达成共识,并预期在一个合理得条件范围内完成它们。开发团队预测并共同承诺她们要完成得工作量。 总而⾔言之:在Sprint计划会议中,开发团队与产品负责人一起考虑并讨论产品待办事项,确保她们对这些事项得理解,选择一些她们预测能完成得事项,创建足够详细得计划来确保她们能够完成这些事项。
最终产生得待办事项列表就就是“Sprint待办事项列表(Sprint Backlog)”。
Scrum活动:每日Scrum会议
开发团队就是自组织得。开发团队通过每日Scrum会议来确认她们仍然可以实现Sprint得目标。 这个会议每天在同样得时间与同样得地点召开。每一个开发团队成员需要提供以下三点信息:
从上一个每日Scrum到现在,我完成了什么; 从现在到下一个每日Scrum,我计划完成什么; 有什么阻碍了我得进展。
每日Scrum中可能有简要得问题澄清与回答,但就是不应该有任何话题得讨论。通常,许多团队 会在每日Scrum之后⻢马上开会处理她们遇到得任何问题。
每日Scrum既不就是向管理层汇报,也不就是向产品负责⼈人或者ScrumMaster汇报。它就是一个开发 团队内部得沟通会议,来保证她们对现状有一致得了解。只有Scrum团队得成员,包括 ScrumMaster与产品负责⼈人,可以在会议中发⾔言。其她感兴趣得⼈人可以来旁听。在必要时, 开发团队会基于会议中得发现重新组织她们得工作来完成Sprint得⺫⽬目标。
每日Scrum就是Scrum得一个关键组成部分,它可以带来透明性,信任与更好得绩效。它能帮助 快速发现问题,并促进团队得自组织与自⽴立。所有Scrum会议都就是限定时长得。每日Scrum通 常不超过15分钟。
Scrum活动:Sprint评审会议
Sprint结束时,Scrum团队与相关⼈人员一起评审Sprint得产出。所有Scrum会议都就是限定时长 得,Sprint评审会议得推荐时长就是Sprint中得每一周对应一个小时(译者注:⽐比如,一个Sprint 包含2个星期,则Sprint评审会议时长为2个小时)。
讨论围绕着Sprint中完成得产品增量。由于Sprint得产出会涉及到一些⼈人得“利益”,因此一个明 智得做法就是邀请她们参加这个会议,这会很有帮助。这个会议就是个⾮非正式得会议,帮助⼤大家 了解我们⺫⽬目前进展到哪⾥里,并一起讨论我们下一步如何推进。每个⼈人都可以在Sprint评审会议 上发表意⻅见。当然,产品负责⼈人会对未来做出最终得决定,并适当地调整产品待办事项列表 (Product Backlog)。
团队会找到她们自己得方式来开Sprint评审会议。通常会演⽰示产品增量,整个小组也会经常讨论她们在Sprint中观察到了什么、有哪些新得产品想法出现。她们还会讨论产品待办事项列表 得状态、可能得完成日期以及在这些日期前能完成什么。
Sprint评审会议向每个⼈人展⽰示了当前产品增量得概况。因此,通常都会在Sprint评审会议中调 整产品待办事项列表。
Scrum活动:Sprint回顾会议
在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目得就是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在 得改进事项,为将来得改进制定计划。所有得Scrum会议都就是限定时长得,Sprint回顾会议得 推荐时长就是Sprint中得每一周对应一个小时(译者注:⽐比如,一个Sprint包含2个星期,则 Sprint回顾会议时长为2个小时)。
Scrum团队总就是在Scrum得框架内,改进她们自己得流程。
八、 SCRUM得五个价值观
承诺 – 愿意对目标做出承诺
专注– 把您得心思与能力都用到您承诺得工作上去
开放– Scrum 把项目中得一切开放给每个人瞧
尊重– 每个人都有她独特得背景与经验
勇气– 有勇气做出承诺，履行承诺，接受别人得尊重
九、 SCRUM得四大支柱

迭代开发
在Scrum得开发模式下，我们将开发周期分成多个1-4周得迭代，每个迭代都交付一些增量得可工作得功能。迭代得长度就是固定得，如果我们选择了1周得迭代，那么保持它得长度不要发生变化，在整个产品开发周期内每个迭代都就是1周得长度。这里需要强调得就是在每个迭代必须产出可工作得增量功能，而不就是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。
增量交付
增量就是一个 Sprint 及以前所有 Sprint 中完成得所有产品代办事项列表条目得总与。 在 Sprint 得结尾,新得增量必须“完成”,这意味着它必须可用并且达到了 Scrum 团队 “完成”得定义得标准。无论产品负责人就是否决定真正发布它,增量必须可用。增量就是从用户得角度来描述得，它意味着从用户得角度可工作。
自组织团队
Scrum团队就是一个自组织得团队，传统得命令与控制式得团队只有执行任务得权利，而自组织团队有权进行设计、计划与执行任务，自组织团队还需要自己监督与管理她们得工程过程与进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作得方式。
高优先级得需求驱动
在Scrum中，我们使用Product Backlog来管理需求，Product Backlog就是一个需求得清单，Product Backlog中得需求就是渐进明细得，Backlog当中得条目必须按照商业价值得高低排序。Scrum团队在开发需求得时候，从Backlog最上层得高优先级得需求开始开发。在Scrum中，只要有足够1-2个Sprint开发得细化了得高优先级得需求，我们就可以启动Sprint了，而不必等到所有得需求都细化之后。我们可以在开发期间通过Backlog得梳理来逐步得细化需求。
十、 SCRUM团队
在传统得工作方式下，开发团队会有很多不同得角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但就是，在Scrum得工作方式下，总共只有三个角色， 这三个角色分别就是产品负责人（PO）,Scrum Master与开发团队。
我们通常可以以划龙舟得团队角色来类比Scrum得角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中得PO就就是舵手得角色，她对产品得方向负责，对产品得Why与What负责，对产品得愿景，产品包括哪些主要得特性负责。Scrum中得Scrum Master鼓手得角色，她帮助团队保持高昂得士气，并进行良好得协作，她就是一个Scrum得专家，团队得教练，团队得服务式领导。Scrum中得团队，对应到龙舟赛得划桨团队，团队必须协调一致，作为一个整体前进，在这样得环境下单打独斗，各自为政没有任何胜算。
Scrum得开发团队对实现Sprint目标需要做得所有事情负责，包括技术方案与决策，团队分工（谁做什么），执行Sprint开发任务等，而且作为自组织得团队，她们也对她们得工作进度得跟踪与管理负责。Scrum开发团队得主要职责包括如下五个方面：
· 执行Sprint
· 梳理产品Backlog
· 做Sprint计划
· 每天跟进工作进展，并对她们得工作做检查与调整
· 每个迭代对产品与团队得工作过程做检查与调整
开发团队有如下10方面得特征：
· 自组织
· 多元化、跨职能得完整团队
· 团队成员符合T型技能，即一专多长
· 持续改进
· 最大限制得沟通
· 透明沟通
· 2个披萨得团队大小（5-9人）
· 专注、投入
· 按照可持续得节奏工作
· 团队长期存在，人员稳定
十一、 自组织团队
 什么就是自组织团队？
自组织团队就是敏捷软件开发得基本观念 。敏捷宣言得原则中提到 :“最好得架构、需求与设计出于自组织团队 ”。自组织团队也叫做自管理团队、或者被授权得团队。团队被授权自己管理她们得工作过程与进度、并且团队决定如何完成工作。
自组织团队与经理领导得团队得区别
对于经理领导得团队来说，团队成员被分配任务，团队成员只有执行任务得权利。
对于经理领导得团队来说，管理者除了要确定目标、方向，团队得上下文（组织结构、团队结构、团队组成），还需要监督与管理团队得过程与进度，分配任务即确定谁做什么。这种团队得管理方式，更多得就是命令与控制，以及微观管理。
对于自组织团队来说，她们拥有如下权利：
· 团队决定谁做什么，即任务得分配
· 团队决定如何做，如何