1.1 ScurmMaster
作为Scrum流程的捍卫者和布道者，ScrumMaster在Scrum团队中起到至关重要的作用，他们确保团队使用正确的流程，确保团队正确地召开各种会议，他们训练团队的敏捷思维，他们和团队外的相关干系人沟通。根据最新的Scrum研究报告，ScrumMaster自组织中倾向于服务于多个Scrum团队。另一个倾向就是在组织中ScrumMaster同项目经理分担职责。
ScrumMaster对Scrum团队而言，是一位服务型领导。ScrumMaster帮助Scrum团队之外的人了解他如何与Scrum团队交互是有益的，通过改变他们与Scrum团队的协作的互动方式来最大化Scrum团队所创造的价值。
--服务于产品负责人 --服务于开发团队 --服务于组织ScrumMaster的职业发展路线通常有如下4个方向
(1) 服务于更多个团队或者更具挑战性的问题
作为ScrumMaster,最开始一般都是从服务于一个团队开始。在经历过一段时间的磨合以后，团队的成熟度越来越高，越来越稳定。ScrumMaster就可以去寻找更多的挑战了
(2)成为Agile Coach
有些ScrumMaster在经历过一段时间的工作以后，他们发现自己热衷于激发团队进行创造的过程，并且无所谓产品本身。在经历了一段时间的经验积累以后，他们非常希望可以把这些经验分享给其他新手ScrumMaster，对于这种人来说，转型成为Agile Coach就是一个非常不错的选择。
如果我们把Agile Coach的成长之路分成三个逐步跃升的层级。那么第一个需要达到的入门层级就是作为敏捷团队的协调者（在团队中角色叫做ScrumMaster），在这个级别需要实践者具备敏捷实践和协调的能力。接下来第二层就是Agile Coach了，与之前的一个级别的区别是，Agile Coach具有更多的实践知识足以支撑他们解决更复杂的问题的同时，还具备引导，教导和专业指导的技能。在这条职业发展的路径的顶峰是企业级Agile Coach，根据每个人背景 的不同他们可能会有各自非常擅长的领域，分别是技术领域（开发出身），商务领域（产品负责人出身）和变革领域（ScrumMaster）出身。但是，坦白的来讲，在目前的形势下能够做到企业级Agile Coach的人还是很少的。因为这些人的级别和能力和公司的CEO是在同一水平的，大部分具有这样能力的人都直接会选择做CEO.
(3)成为产品负责人
还有一些人，也许做了一段时间ScrumMaster以后，发现自己对构建产品的过程很感兴趣，那么成为一个产品负责人就是他们的最佳选择。当然，我并不是说产品负责人在组织中高于ScrumMaster这个角色。在理论上，这两个角色是平级的关系。
(4)成为管理者
对于像你这种从传统的项目经理转型成为ScrumMaster的人来说，也许做了一段时间的ScrumMaster以后，你仍旧更希望转回到传统的管理角色上来。如果这时候，组织里有机会，那么也是可以成为管理者的。
ScrumMaster每日工作列表
一天的开始
1.更新和检查目前冲刺的燃尽图报表。 2.如果团队落后于时间表，ScrumMaster需要帮助团队想办法追上进度。同时，ScrumMaster需要确保所有完成的任务都已经被标记成了完成，这样燃尽图的数据才准确。 3.检查Sprint待办列表里的条目和相应的任务情况。
3.1 检查是否有任何遗漏信息
- 遗漏条目的工作量估算信息。
- 遗漏具体任务的估算信息。
- 正在进行和已经完成的任务遗漏任务人信息。
3.2 检查是否有任何不一致的信息
- 是否有已经决定了不做了的条目仍旧可以被选中。
- 已经完成了的任务却没有标记成完成。
- 没有完成的任务却标记成完成。
ScrumMaster需要追踪这些问题，并提醒相应的团队成员作出更正。
工作期间
1.找出所有影响进度的工作 2.如果需要的话，协助团队解决这些问题。 - 保护团队成员不被团队外的其他人打扰。 - 教育团队成员：他们应该先尝试自己解决问题，如果解决不了的话他们需要找ScrumMaster来解决问题。 3.协调Scrum每日战会 - 展示燃尽图 - 听取团队成员关于每日站会的三个问题的回答。 - 明确下一步行动计划和责任人。 - 和团队分享有用的信息。 4.评审新加入产品列表的用户故事，技术故事和问题，确保新加入的条目可以被正确地指派到相应Scrum团队。
每日工作结束
和每天开始时一样： 评审状态，查看是否有任何遗漏，错误的信息，跟踪记录团队待解决问题的状态。
准备计划会议
1.协调产品列表梳理会议。 2.统计下一个的迭代的生产能力。 - 统计团队成员下一个Sprint的休假计划，公共假期和其他影响生产力的信息。 - 估算团队下个迭代的生产力。 3.在各种电子和物理工具上更新相应的信息。
计划会议时
1.从头到尾产看产品列表里的条目，并且将条目一个一个地从优先级最高的开始顺序念给团队。 2.协调估算过程。 3.记录团队讨论的内容（例如，估算的工作量，条目的详情）。 4.将相应的条目拖拽到下一个Sprint的代办列表。 5.建议团队在工作量范围以外多评估一部分用户故事以备不时之需。
在评审会议上
ScrumMaster需要组织会议确保相应成员到场。
在回顾会议上
1.ScrumMaster组织团队成员一起回顾自上一个回顾会议以后团队的工作状态。 2.ScrumMaster组织，收集和记录团队成员讨论的信息。 3.ScrumMaster协调确认下一个迭代团队需要做的改进措施以及负责人。
ScrumMaster小结：
对于传统的项目经理来说，他对项目负最终的责任，因此他也就同时被赋予了领导项目成员的权利。在项目当中，无论是开发，测试还是产品经理，他们都是项目经理的下级，项目经理给他们分配任务，他们有义务按照项目经理的命令来完成任务。但是在敏捷当中，ScrumMaster和团队成员都是平级的，不存在任何上下级关系。他虽然会承担一部分传统项目经理的职责，但是他并不具有命令项目成员的权利，也不像项目经理那样对项目的成败负全权的责任。当然他们更不会过问团队成员的绩效考核，薪资等这些问题。他们是一个服务者，他们的服务要确保能够满足团队最高优先级的需要。据个例子，项目经理会问：“那么，今天你要准备为我做什么？” 相反，服务型领导的ScrumMaster会问：“那么，为了帮助你和团队更加有效，今天我能做什么？”
ScrumMaster相关书籍：《Scrum指南》《Scrum精髓》《Scrum捷径》《Coaching Agile Team》《Agile Retrosectives》《看板方法》《精义思想》《SAFe白皮书》
1.2 产品负责人
作为确保团队作出正确产品以便帮助公司得到最高投资回报的产品负责人，在Scrum团队中负责“做什么”的问题。不同公司，不同部门，不同团队的产品负责人的具体职责不尽相同。但是，从总体上来说，产品负责人的工作包括：愿景和边界。产品负责人的工作包括两个方向：提出正确的解决方案和确保解决方案被正确“制造”。
产品负责人的职责是将开发团队开发的产品价值最大化。产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：
1.清晰的表达产品待办列表项。 2.对产品待办列表进行排序，使其最好地实现目标和使命。 3.优化开发团队所执行工作的价值。 4.确保产品待办列表对所有人是可见，透明和清晰的，同时显示Scrum团队下一步要做的工作。 5.确保开发团队对产品待办列表项有足够深的了解。
产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。
Scrum组织中项目管理职责的映射，不过下面的表格是理想的状态，实际情况可以根据项目情况适当的调整。
在项目开始的阶段，产品负责人会参与组合规划和产品规划。组为组合规划的一部分，产品负责人有可能要和组合经理和其他产品负责人一起讨论可能影响新产品计划的相关问题。在产品规划过程中，产品负责人和项目相关干系人，用户和客户一起共同讨论，一起构思新产品。做完这些以后，组织会从经济的角度进行筛选，以确定开发工作是否可以得到资金，工作何时开始（批准资金）。接下来，当项目得到组织认可后，产品负责人需要参与制订计划的草案。这个活动一般包含一个故事写作研讨会，目的是产生一个可供版本规划期间使用的概要产品列表。接下来，会再召开一个估算研讨会，产品负责人也要参与，在这个研讨会上，开发团队成员会对高价值的故事进行评估。再接下来，会再召开一个会议，综合考虑故事优先级，范围，估算，项目相关干系人共同讨论，制定足够的版本计划，得到一个足够清晰的整体版本，并对交付什么，何时交付之类的业务问题给出初步解答。在确定版本计划后，Scrum团队就可以执行第一个冲刺了。接下来，我们说在每个冲刺中产品负责人的工作。在冲刺开始的时候，产品负责人负责提供带有优先级排序的产品列表（有完整的接受标准）并且回答团队问题，以便制订冲刺计划。在执行冲刺时，产品负责人要随时回答团队对于故事的问题并且当特性完成时对特性进行测试。另外一方面，产品负责人还要与项目内外部干系人沟通会面，确保为下一轮冲刺设置正确的优先级顺序，并获得对今后冲刺所选特性有影响的重要信息。同时，产品负责人还需要对产品列表进行梳理，包括书写新的条目，细化现有条目等。
产品负责人每日工作列表
产品负责人每天都要做以下这些工作。
1.每天开始都要检查Sprint待办列表里的条目和相应的任务情况，如果有任何关于进度的疑问都需要追踪。 2.协助团队成员解决问题，澄清需求。 3.尽早评审已经开发完成的功能，确认功能是否是期望的。如果不是则需要决定是否要在本个迭代做出更改，或者放到下一个迭代继续完成，或者需要创建新的用户故事。 4.编写新的用户故事来完成更多的功能，并且向团队澄清新的用户故事。 5.编写史诗级用户故事（如果功能太大，单个用户故事无法承载的话）。 6.报告任何你发现的软件问题。 7.参加每日站会（如果你和你的团队认为这样有助于完成迭代目标）。 8.听取并回答每日站会的三个标准问题。 9.发现需要你进一步跟进的任务。 10.和团队分享有用的信息。
准备计划会议
收集足够数量的待办列表以便团队在计划会议上评审，并且按优先级排好顺序。 - 要以商业价值做作为排序的依据，同时考虑到风险，潜在失败的可能性和其他相关的因素。 - 列表项的信息里要包含它与其他列表项之间的依赖关系。
计划会议中
1.和研发团队，ScrumMaster一起使计划会议变得更有效。 2.产品负责人必须参加会议。 3.回到问题以澄清和解决有可能影响实施和估算的问题。 4.如果需要的话，需要更新用户故事的主题和描述以避免歧义和误解。 5.如果需要的话，重新更改用户故事的排序以便Sprint可以更有效。
评审会议中
评审团队在过去的一个迭代中提交的功能是符合期望，确定是否接受团队提交的潜在可发布增量。
回顾会议中
ScrumMaster主持会议，团队共同决定产品负责人参与该会议是否对团队实现目标更有帮助。
产品负责人小结：
产品负责人相关书籍：《Scrum指南》《Scrum精髓》《人人都是产品经理2》《用户故事》《Scrum产品经理》
1.3 开发团队
Scurm的开发团队应该由T型技能的成员组成。所谓的T型的意思就是团队的成员在广度（知识结构和能力）和深度（专业知识）两个维度都有发展。
在传统的软件开发方法里，定义了不同的工作类型：软件主任工程师，程序员，测试工程师，UI工程师，数据库工程师。但是，在Scrum里面定义了“开发团队”的角色，这个角色是所有这些工作类型的集合。在Scrum里面，所有这些人都被称为“工程师”。一些Scrum成熟度很高的公司和团队，甚至在和员工签订合同的时候也只是写了这个员工是工程师，而弱化传统软件开发方法里面的工作类型区别。
在Scrum的每个冲刺当中，开发团队为了实现计划里的功能，他们必须完成所有的相关工作，包括产品的设计，开发，集成和测试。为此，他们必须具备完成这些工作的所有技能。区别于传统开发方法里的“只负责自己那部分工作”，作为一个整体，团队对功能的实现负责。通过模糊title的方式我们希望能够弱化传统项目职能分工的“撇清责任”，促进团队的内部集体协作的积极互动，当目标实现出现问题的时候，所有人都可以起到积极的作用。举个例子，冲刺的最后难免测试的压力会大一些，这时候有空于的时间的工程师都应该帮助做测试，无论你的专长是研发，架构，UI。只要有时间，有能力，就都要帮忙。最终我们是要组织这样一个团队：团队成员拥有合适的技能，覆盖各个领域，并且总体上技能有一些重叠，以便团队有一定的灵活性。经理们有责任和义务去为团队创造一个促进学习的增加技能组合的环境，不论是领域知识，专业知识，思考技能或者其他能力。经理要支持团队成员花时间学习。
在自组织的团队里面，团队成员通过讨论达成共识并且最终制定规则和流程。由于每个团队成员都可以对所有议题发表自己的意见而成为规则和流程的制定者，因此当最后达成一致意见后，团队成员就会更加主动的去履行他们的承诺。在执行期间，通过每日站会和日常的充分沟通，如果有团队成员在履行承诺的时候出现问题，其他成员也有充分的机会提醒和帮助他。在传统的控制管理中，团队成员是被动接受者，但是在自组织的环境里大家是规则制定者，监督者和履行者，这样的身份变化，导致所有团队的成员都是团队的“领导者”。
团队需要具备的能力：产品，Scrum，架构，研发，手工测试，自动化测试，XP实践，自动化集成和自动化部署，UI，数据库。
需要外部支持能力包括：Scrum, 自动化测试，XP实践，自动化集成和自动化部署，数据库。
Scrum开发团队每日工作列表
一天的开始
1.查看目前冲刺的燃尽图报表。 2.如果团队落后于时间表，你需要确认自己是否可以帮助团队追上进度（尤其是当你的手中的任务落后于进度的时候）。你需要确认所有你已经完成的任务在相关的系统和任务板上都标记为完成。 3.检查今天你要做的工作。 4.如果你今天没有可以做的工作，你需要和团队成员一起找到你可以帮忙的工作。
一天当中
1.当你完成一个任务的时候，要立即更新任务状态。 2.更新所有相关项的信息。 3.如果你开始了一个新的任务，请把任务状态更新成“进行中”并且填写任务人。 4.如果你的任务完成了，请将任务标状态记成完成。 5.更新完成任务需要的剩余时间信息。 6.完成你领取的任务，如果需要帮助，请不要忧虑，立即让大家知道。 7.和大家一起写作完成任务。和大家讨论你的工作以便可诶完成任务。 8.参加Scrum每日站会。 9.汇报你的工作信息。 10.从上次站会之后你都做了些什么 11.你计划在下次次会议之前都做些什么 12.你遇到了什么阻挠你工作的进度的需要他人帮助的问题。 13.确认是否可以帮助他人 14.帮助产品负责人完成需求的更新 15.回答产品负责人的问题并提供你的理解 16.编写技术故事 17.报告产品缺陷（例如，你在完成任务进行的时候进行的验收测试中发现的缺陷） 18.和产品负责人澄清Sprint待办列表中的用户故事的细节（越早越好）。如果用户故事没有按照产品负责人的期望完成的话，产品负责人会作出决定是否在当前迭代中立即修改或者以后在改。
一天结束时
1.更新你的工作状态
2.查看燃尽图确认团队工作进展准备计划会议
1.梳理产品列表（和产品负责人讨论以澄清对条目的理解）
2.创建技术用户故事计划会议中
讨论并且估算每个列表条目
计划会议结束后
在计划会议结束后需要立即将用户故事分解为任务。这对正确完成工作非常重要。 - 和团队成员一起分解任务（所有的用户故事和缺陷）并且提供任务工作量的估算。 - 对于新的团队来说，这通常需要整组人员一起开会讨论决定。 - 对于有经验的团队，做法相对灵活；可以一个人负责进行所有的估算，然后其他组员进行检查以确保一致。
在评审会议上
团队成员负责向产品负责人演示功能
在回顾会议上
1.在ScrumMaster的组织下，团队成员一起回顾自上一个回顾会议以后的工作状态。
2.在ScrumMaster的协调确认下，团队成员一起确认下一个迭代团队需要做的改进措施以及负责人。Scrum开发团队小结：
Scrum开发团队的主要职责：
1.在冲刺执行期间，开发团队完成创造性的工作，包括设计，构建，集成，测试，最终提供潜在可发布的功能发布。 2.每日检视和调整（每日站会）——作为一个自组织的团队，团队通过每日站会来实现自我的检视和调整实现冲刺目标。 3.梳理产品列表——帮助产品负责人梳理产品列表，细化产品列表条目，估算和排列优先级。 4.冲刺规划——在每个冲刺之初，开发团队参与冲刺计划会议。在会议上，根据产品负责人提供的信息，对产品列表条目的工作量进行估算，并在ScrumMaster的指导下，与产品负责人共同制定冲刺目标。 注意，开发团队对工作量的估算是有绝对话语权，作为一个自组织的团队，他们不受其他角色的影响，对工作量进行估算并且按照自己的承诺去履行冲刺目标。
5.检视和调整产品与过程——在每个冲刺结束的时候，开发团队都需要参加冲刺评审会议和冲刺回顾会议。在会议上，Scrum团队检视和调整自己的过程和技术进一步改善团队使用Scrum来交付业务价值的能力。
Scrum开发团队的特征：
1.自组织 没有项目经理或者其他经理告诉团队怎样开展工作；团队在没有外部力量干预的情况下，为了共同的冲刺目标而工作，逐渐达成默契，相互理解，不断改进。 2.跨职能 为了提交潜在可交付的增量，团队需要具备所有相应知识和技能的成员。 3.规模适中 5～9人的规模。
1.4 实践类问题
1.4.1 一个人能同时即做产品负责人又做ScrumMaster吗？
绝对不能！产品负责人和ScrumMaster这俩个角色在Scrum团队里是两个非常重要的角色。产品负责人负责产品要做成什么样，但不负责指导团队。
ScurmMaster则负责另外一个维度的工作，即专注于帮助团队以正确的方式和流程来执行Scrum项目。在团队中，产品负责人代表组织对经济利益的追求，
而ScrumMaster则代表团队的利益。如果要求一个人来同时完成这两个角色是很困难的，更重要的是经常会遇到这两个角色出发点不同导致的冲突而无从选择，‘
最终一个角色会凌驾于另一个角色之上，而是整个团队利益受损。
1.4.2 Scrum里任务是如何分配给团队成员的？
团队成员们一起识别，评估每一个用户故事的工作量。一旦冲刺开始，每一个团队成根据优先选择他们认为合适的工作。
因此，我们说团队成员自己给自己分配任务。具体的分配方法由每个团队的成员一起讨论而决定。
1.4.3 开发团队可以有多少个人，为什么要限制团队人数
一个Scrum开发团队可以有多少工程师？对于这个问题来说，并没有标准的答案。2003年，Jeff Sutherland说一个Scrum开发团队的人数不能超过7个。
现在，根据最新的《Scrum指南》，一个Scrum开发团队的人数应该为3~9.如果团队里的人太少，团队会面临能力缺乏的困境。 虽然人越多，团队能完成的工作就越多，但如果人太多了又会对团队计划，沟通和协调带来巨大的挑战。正如我们所知，
在IT项目中，越多的工程师并不能意味着可以带来越多的产品功能发布。而且经常会带来相反的结果。如果你的项目有超过9个工程师的资源，
那么请把他们分解成两个Scrum团队。而且，请不要忘记，Scrum强调的实验！你的组织和项目团队合适的团队规模需要你自己去寻找。
1.4.4 如果项目工作太多，一个Scrum团队做不完怎么办
正如我刚才所说，如果你有足够的工作和足够的资源，那么就请你通过组建新Scrum团队的方法来加速你的速度。如果你的工作太多但是资源不足，
那么就请你通过给特性排列优先级的方式，保证团队只开发最重要的功能。
1.4.5 迭代和冲刺的区别是什么
迭代的英文为Iteration。迭代是一个通用的敏捷术语，指的是单个开发迭代。冲刺的英文是Sprint。作为敏捷的一种方法的Scrum，冲刺是指Scrum的一个迭代。
1.4.6 为什么在开发团队只有工程师而不是开发，测试呢？
在Scrum里，责任和成果属于整个团队。为了强调团队的整体性，Scrum开发团队里只有一种角色，就是工程师。
但这并不意味着每个人都拥有相同的技能，或者是说做相同的工作。这也许对每个人未必完全公平。例如，一个初级工程师和高级工程师能力就不相同。
但是，还是那句话，Scrum强调团队作为一个整体承担责任。
1.4.7 产品负责人和ScrumMaster都是全职的吗
为了保证Scrum团队的工作，ScrumMaster和产品负责人需要有足够的时间来完成他们的工作。一个比较常见的陷阱是，除了日常工作以外，
组织会给某个人分配产品负责人的新角色，让他同时兼顾日常工作和产品负责人的角色。这样做的结果通常都并不好。
我们比较推荐的做法是让产品负责人和ScrumMaster成为全职的工作。
1.4.8 质量控制在Scrum怎么体现
在Scrum里，质量控制不是一个在产品发布以后才执行的工作。相反，在Scrum当中，质量控制应该是包括在所有的从开始到结束的冲刺过程中。
在项目的每个冲刺开始的时候，团队就应该注意如何检查各个工作的进行。因此，我们说质量控制从用户故事的定义就应该已经开始了。所有的功能和非功能的测试都应该被覆盖到。
因此有人说，在Scrum团队里不需要一个叫做QA的角色。当然如果大家都认为有帮助的话，公司级别有专门的QA角色也是可以的。
但是我们要强调，在Scrum团队里面整个团队对质量负责，而不应该将质量的责任只记在QA的名下。1.4.9 新任ScrumMaster应该怎么办
美国第28任总统威尔逊说过：“如果你想树敌，就尝试改革吧”。对于大多数人来说，变化总是令人生畏。因为变化会把人从熟悉的环境拉出到一个充满“惊吓”的新世界。
因此，作为一个新任的ScrumMaster，你需要注意的是，在一开始请千万不要急于求成，一股脑儿地改变所有东西。要有耐心，好好准备。
当准备好以后，慢慢开始，而且以开始的时候先引入一两个实践（例如Scrum的每日站会和修整产品列表），当取得了一两个虽然小但有决定性意义的胜利后，再公开宣传并且继续改进。
1.4.10 Scrum的核心价值观
怎样才能通过挑战团队成员来确保团队不会因为各自强烈的自我意识和持续不断被的争吵而分崩离析呢？最好的办法就是所有的团队成员都要有用户Scrum的核心价值观，
并且以此形成他们的职业特质。
Scrum的核心价值观：活力，共情，好奇，友善，尊重。1.4.11 开发团队的人员配备
没有一个放之四海而皆准的规则可以定义开发团队的人员组成，因为项目和项目的都是各不相同的。如果你对团队组建毫无头绪，我向你推荐一个比例（当然需要你根据实际情况进行检查和调整）： 2个研发，1个测试，0.5个专家（如果你的项目已经实现了高度的自动化，那么研发的比例可以更高）。 项目之初，项目中的高级工程师和初级工程师的比例为2:1 (随着项目进行这个比例可以降低)。 有Scrum经验的成员与没有Scrum经验的成员比例为1:1.
1.4.12 一个ScrumMaster可以同时和多个团队一起工作吗
一个ScrumMaster可以同时在几个团队中工作这个问题有很多的讨论。虽然，我们一直强调ScrumMaster这个角色很重要，全职的ScrumMaster对于Scrum团队的重要性。
但是，我们必须灵活起来，根据2018年年年初公布的最新的Scrum报告，一个ScrumMaster同时在多个团队工作的目前已经成为一种普偏现象。
当然，如果资源允许，尤其是在团队刚刚组建的时候，一个全职的ScrumMaster是最好的。随着团队的成熟，
同时担任两个团队的ScrumMaster也是可以的（一个ScrumMaster服务于两个团队，是比较推荐的解决方案）。
如果Scrum团队已经是自组织的，成熟的精英团队，一个ScrumMaster可以为三个这样的团队服务。1.4.13 Scrum有没有一套流程，有没有标准
对不起，Scrum不提供流程或者最佳实践。Scrum的游戏规则就是它的标准，这些都包含在《Scrum指南》当中。