Scrum转型(二) Scrum的角色

ScrumMaster对Scrum团队而言，是一位服务型领导。ScrumMaster帮助Scrum团队之外的人了解他如何与Scrum团队交互是有益的，通过改变他们与Scrum团队的协作的互动方式来最大化Scrum团队所创造的价值。
--服务于产品负责人 --服务于开发团队 --服务于组织

作为ScrumMaster,最开始一般都是从服务于一个团队开始。在经历过一段时间的磨合以后，团队的成熟度越来越高，越来越稳定。ScrumMaster就可以去寻找更多的挑战了

有些ScrumMaster在经历过一段时间的工作以后，他们发现自己热衷于激发团队进行创造的过程，并且无所谓产品本身。在经历了一段时间的经验积累以后，他们非常希望可以把这些经验分享给其他新手ScrumMaster，对于这种人来说，转型成为Agile Coach就是一个非常不错的选择。

还有一些人，也许做了一段时间ScrumMaster以后，发现自己对构建产品的过程很感兴趣，那么成为一个产品负责人就是他们的最佳选择。当然，我并不是说产品负责人在组织中高于ScrumMaster这个角色。在理论上，这两个角色是平级的关系。

对于像你这种从传统的项目经理转型成为ScrumMaster的人来说，也许做了一段时间的ScrumMaster以后，你仍旧更希望转回到传统的管理角色上来。如果这时候，组织里有机会，那么也是可以成为管理者的。

1.更新和检查目前冲刺的燃尽图报表。
2.如果团队落后于时间表，ScrumMaster需要帮助团队想办法追上进度。同时，ScrumMaster需要确保所有完成的任务都已经被标记成了完成，这样燃尽图的数据才准确。
3.检查Sprint待办列表里的条目和相应的任务情况。
　　3.1 检查是否有任何遗漏信息
　　　　- 遗漏条目的工作量估算信息。
　　　　- 遗漏具体任务的估算信息。
　　　　- 正在进行和已经完成的任务遗漏任务人信息。
　　3.2 检查是否有任何不一致的信息
　　　　- 是否有已经决定了不做了的条目仍旧可以被选中。
　　　　- 已经完成了的任务却没有标记成完成。
　　　　- 没有完成的任务却标记成完成。

1.找出所有影响进度的工作
2.如果需要的话，协助团队解决这些问题。
　　- 保护团队成员不被团队外的其他人打扰。
　　- 教育团队成员：他们应该先尝试自己解决问题，如果解决不了的话他们需要找ScrumMaster来解决问题。
3.协调Scrum每日战会
　　- 展示燃尽图
　　- 听取团队成员关于每日站会的三个问题的回答。
　　- 明确下一步行动计划和责任人。
　　- 和团队分享有用的信息。
4.评审新加入产品列表的用户故事，技术故事和问题，确保新加入的条目可以被正确地指派到相应Scrum团队。

和每天开始时一样： 评审状态，查看是否有任何遗漏，错误的信息，跟踪记录团队待解决问题的状态。

1.协调产品列表梳理会议。
2.统计下一个的迭代的生产能力。
    - 统计团队成员下一个Sprint的休假计划，公共假期和其他影响生产力的信息。
    - 估算团队下个迭代的生产力。
3.在各种电子和物理工具上更新相应的信息。 

1.从头到尾产看产品列表里的条目，并且将条目一个一个地从优先级最高的开始顺序念给团队。
2.协调估算过程。
3.记录团队讨论的内容（例如，估算的工作量，条目的详情）。
4.将相应的条目拖拽到下一个Sprint的代办列表。
5.建议团队在工作量范围以外多评估一部分用户故事以备不时之需。

ScrumMaster需要组织会议确保相应成员到场。

1.ScrumMaster组织团队成员一起回顾自上一个回顾会议以后团队的工作状态。
2.ScrumMaster组织，收集和记录团队成员讨论的信息。
3.ScrumMaster协调确认下一个迭代团队需要做的改进措施以及负责人。

1.清晰的表达产品待办列表项。
2.对产品待办列表进行排序，使其最好地实现目标和使命。
3.优化开发团队所执行工作的价值。
4.确保产品待办列表对所有人是可见，透明和清晰的，同时显示Scrum团队下一步要做的工作。
5.确保开发团队对产品待办列表项有足够深的了解。

1.每天开始都要检查Sprint待办列表里的条目和相应的任务情况，如果有任何关于进度的疑问都需要追踪。
2.协助团队成员解决问题，澄清需求。
3.尽早评审已经开发完成的功能，确认功能是否是期望的。如果不是则需要决定是否要在本个迭代做出更改，或者放到下一个迭代继续完成，或者需要创建新的用户故事。
4.编写新的用户故事来完成更多的功能，并且向团队澄清新的用户故事。
5.编写史诗级用户故事（如果功能太大，单个用户故事无法承载的话）。
6.报告任何你发现的软件问题。
7.参加每日站会（如果你和你的团队认为这样有助于完成迭代目标）。
8.听取并回答每日站会的三个标准问题。
9.发现需要你进一步跟进的任务。
10.和团队分享有用的信息。

收集足够数量的待办列表以便团队在计划会议上评审，并且按优先级排好顺序。
    - 要以商业价值做作为排序的依据，同时考虑到风险，潜在失败的可能性和其他相关的因素。
    - 列表项的信息里要包含它与其他列表项之间的依赖关系。

1.和研发团队，ScrumMaster一起使计划会议变得更有效。
2.产品负责人必须参加会议。
3.回到问题以澄清和解决有可能影响实施和估算的问题。
4.如果需要的话，需要更新用户故事的主题和描述以避免歧义和误解。
5.如果需要的话，重新更改用户故事的排序以便Sprint可以更有效。

评审团队在过去的一个迭代中提交的功能是符合期望，确定是否接受团队提交的潜在可发布增量。

ScrumMaster主持会议，团队共同决定产品负责人参与该会议是否对团队实现目标更有帮助。

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的协调确认下，团队成员一起确认下一个迭代团队需要做的改进措施以及负责人。

1.在冲刺执行期间，开发团队完成创造性的工作，包括设计，构建，集成，测试，最终提供潜在可发布的功能发布。
2.每日检视和调整（每日站会）——作为一个自组织的团队，团队通过每日站会来实现自我的检视和调整实现冲刺目标。
3.梳理产品列表——帮助产品负责人梳理产品列表，细化产品列表条目，估算和排列优先级。
4.冲刺规划——在每个冲刺之初，开发团队参与冲刺计划会议。在会议上，根据产品负责人提供的信息，对产品列表条目的工作量进行估算，并在ScrumMaster的指导下，与产品负责人共同制定冲刺目标。
　　注意，开发团队对工作量的估算是有绝对话语权，作为一个自组织的团队，他们不受其他角色的影响，对工作量进行估算并且按照自己的承诺去履行冲刺目标。
5.检视和调整产品与过程——在每个冲刺结束的时候，开发团队都需要参加冲刺评审会议和冲刺回顾会议。在会议上，Scrum团队检视和调整自己的过程和技术进一步改善团队使用Scrum来交付业务价值的能力。

1.自组织
没有项目经理或者其他经理告诉团队怎样开展工作；团队在没有外部力量干预的情况下，为了共同的冲刺目标而工作，逐渐达成默契，相互理解，不断改进。
2.跨职能
为了提交潜在可交付的增量，团队需要具备所有相应知识和技能的成员。
3.规模适中
5～9人的规模。

绝对不能！产品负责人和ScrumMaster这俩个角色在Scrum团队里是两个非常重要的角色。产品负责人负责产品要做成什么样，但不负责指导团队。
ScurmMaster则负责另外一个维度的工作，即专注于帮助团队以正确的方式和流程来执行Scrum项目。在团队中，产品负责人代表组织对经济利益的追求，
而ScrumMaster则代表团队的利益。如果要求一个人来同时完成这两个角色是很困难的，更重要的是经常会遇到这两个角色出发点不同导致的冲突而无从选择，‘
最终一个角色会凌驾于另一个角色之上，而是整个团队利益受损。

团队成员们一起识别，评估每一个用户故事的工作量。一旦冲刺开始，每一个团队成根据优先选择他们认为合适的工作。
因此，我们说团队成员自己给自己分配任务。具体的分配方法由每个团队的成员一起讨论而决定。

一个Scrum开发团队可以有多少工程师？对于这个问题来说，并没有标准的答案。2003年，Jeff Sutherland说一个Scrum开发团队的人数不能超过7个。
现在，根据最新的《Scrum指南》，一个Scrum开发团队的人数应该为3~9.如果团队里的人太少，团队会面临能力缺乏的困境。
虽然人越多，团队能完成的工作就越多，但如果人太多了又会对团队计划，沟通和协调带来巨大的挑战。正如我们所知，
在IT项目中，越多的工程师并不能意味着可以带来越多的产品功能发布。而且经常会带来相反的结果。如果你的项目有超过9个工程师的资源，
那么请把他们分解成两个Scrum团队。而且，请不要忘记，Scrum强调的实验！你的组织和项目团队合适的团队规模需要你自己去寻找。

正如我刚才所说，如果你有足够的工作和足够的资源，那么就请你通过组建新Scrum团队的方法来加速你的速度。如果你的工作太多但是资源不足，
那么就请你通过给特性排列优先级的方式，保证团队只开发最重要的功能。

迭代的英文为Iteration。迭代是一个通用的敏捷术语，指的是单个开发迭代。冲刺的英文是Sprint。作为敏捷的一种方法的Scrum，冲刺是指Scrum的一个迭代。

在Scrum里，责任和成果属于整个团队。为了强调团队的整体性，Scrum开发团队里只有一种角色，就是工程师。
但这并不意味着每个人都拥有相同的技能，或者是说做相同的工作。这也许对每个人未必完全公平。例如，一个初级工程师和高级工程师能力就不相同。
但是，还是那句话，Scrum强调团队作为一个整体承担责任。

为了保证Scrum团队的工作，ScrumMaster和产品负责人需要有足够的时间来完成他们的工作。一个比较常见的陷阱是，除了日常工作以外，
组织会给某个人分配产品负责人的新角色，让他同时兼顾日常工作和产品负责人的角色。这样做的结果通常都并不好。
我们比较推荐的做法是让产品负责人和ScrumMaster成为全职的工作。

在Scrum里，质量控制不是一个在产品发布以后才执行的工作。相反，在Scrum当中，质量控制应该是包括在所有的从开始到结束的冲刺过程中。
在项目的每个冲刺开始的时候，团队就应该注意如何检查各个工作的进行。因此，我们说质量控制从用户故事的定义就应该已经开始了。所有的功能和非功能的测试都应该被覆盖到。
因此有人说，在Scrum团队里不需要一个叫做QA的角色。当然如果大家都认为有帮助的话，公司级别有专门的QA角色也是可以的。
但是我们要强调，在Scrum团队里面整个团队对质量负责，而不应该将质量的责任只记在QA的名下。

美国第28任总统威尔逊说过：“如果你想树敌，就尝试改革吧”。对于大多数人来说，变化总是令人生畏。因为变化会把人从熟悉的环境拉出到一个充满“惊吓”的新世界。
因此，作为一个新任的ScrumMaster，你需要注意的是，在一开始请千万不要急于求成，一股脑儿地改变所有东西。要有耐心，好好准备。
当准备好以后，慢慢开始，而且以开始的时候先引入一两个实践（例如Scrum的每日站会和修整产品列表），当取得了一两个虽然小但有决定性意义的胜利后，再公开宣传并且继续改进。

怎样才能通过挑战团队成员来确保团队不会因为各自强烈的自我意识和持续不断被的争吵而分崩离析呢？最好的办法就是所有的团队成员都要有用户Scrum的核心价值观，
并且以此形成他们的职业特质。
Scrum的核心价值观：活力，共情，好奇，友善，尊重。

没有一个放之四海而皆准的规则可以定义开发团队的人员组成，因为项目和项目的都是各不相同的。如果你对团队组建毫无头绪，我向你推荐一个比例（当然需要你根据实际情况进行检查和调整）：
2个研发，1个测试，0.5个专家（如果你的项目已经实现了高度的自动化，那么研发的比例可以更高）。
项目之初，项目中的高级工程师和初级工程师的比例为2:1 (随着项目进行这个比例可以降低)。
有Scrum经验的成员与没有Scrum经验的成员比例为1:1.

一个ScrumMaster可以同时在几个团队中工作这个问题有很多的讨论。虽然，我们一直强调ScrumMaster这个角色很重要，全职的ScrumMaster对于Scrum团队的重要性。
但是，我们必须灵活起来，根据2018年年年初公布的最新的Scrum报告，一个ScrumMaster同时在多个团队工作的目前已经成为一种普偏现象。
当然，如果资源允许，尤其是在团队刚刚组建的时候，一个全职的ScrumMaster是最好的。随着团队的成熟，
同时担任两个团队的ScrumMaster也是可以的（一个ScrumMaster服务于两个团队，是比较推荐的解决方案）。
如果Scrum团队已经是自组织的，成熟的精英团队，一个ScrumMaster可以为三个这样的团队服务。

对不起，Scrum不提供流程或者最佳实践。Scrum的游戏规则就是它的标准，这些都包含在《Scrum指南》当中。