Scrum转型(二) Scrum的角色

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指南》当中。