读《Scrum敏捷软件开发》笔记

读《Scrum敏捷软件开发》笔记

目录

读《Scrum敏捷软件开发》笔记

第I部分 启动

第II部分 个体

第iii部分 团队

第四部分 组织

第四部门 下一站

---

第I部分 启动

第1章 为什么敏捷转型难（但值得）

1、为什么转型困难

没有面向对公司所有部门展开、高层担心影响组织架构、自己的权威，不推行、没有进行持续改进。

1）、成功的变革不是完全的自上而下或者自下而上：

自上而下要求、支持，自下而上承诺，执行。成功实践Scrum 的关键在于结合自上而下和自下而上的变革相关要素。

2）、结束状态是不可预知的：

有机会改变或制定一个过程，使其更适合其本身，是团队成功实施其过程的关键因素。没有一个方法模型是完全适合你的组织的，需要对其进行调整，而结束状态是无法预知，因为这是一个终点的过程，需要持续改进。

3）、Scrum是无处不在的

4）、Scrum是截然不同的

过渡到Scrum要求人们使用它们不熟悉的方式来工作，有悖于他们的培训和经验，所以如果不是彻底抗拒变革，人们往往会犹豫不决。

5）、变化来得比以往更快：

过渡到Scrum屡屡成为将人们推向未来冲击（future shock）的变革就不足为奇了。实施Scrum无处不在的天性和导致人们工作和交互方式根本性变化，更容易面临触发未来冲击效应的风险。

6）、最佳实践是危险的：

“有一些事情称之为标准工作，但是标准是在不断变化的。相反，如果你认为这些标准工作对你来说已经是最好的，那么一切都结束了” 。 “如果我们把一些事情作为最好的可能方法，那么对于精益【持续增量的改善】的动力就消失了”。

2、为什么值得投入

1）、更高的生产力及更低的成本

2）、员工的参与度和工作满意度增强

3）、更快的产品上市时间

4）、更高的质量

5）、项目干系人的满意度提升

6）、现在的做法不再有效

第2章 ADAPT模型

成功、持续实施Scrum必备的5个活动：

1、意识（Awareness）：当前的过程已不能实现可接受的结果。

2、渴望（Desire）：把实施Scrum作为一种方法来解决当前的问题。

3、能力（Ability）：有能力成功实施Scrum。

4、推广（Promotion）：通过分享经验来推广Scrum，从而让我们记住并能让其他人也能看到我们的成功。

5、传递（Transfer ）:把实施Scrum带来的影响扩大到整个公司。

意识：

变革始于不满足现状的意识。

意识开发工具：1)、通过沟通，说明问题的存在。2)、使用度量数据3)、接触新的人与经验4)、运行一个试点项目5)、关注最重要的变革理由。

渴望：

对一个人来说，时机不对，你就无法说服他们。好消息是，相同的消息、相同的传递方式，但在不同的时间，常常足以让一个人从有意识转变到渴望变革。

渴望提升工具：

1)、告诉人们有更好的方法2)、创造一种紧迫感3)、造势：把时间和精力集中于帮助热衷于Scrum 的人，而不是对Scrum意愿低下或持有异议的人。4)、让团队“试驾Scrum”5)、统一激励机制（或至少消除不利因素）6)、聚焦恐惧的消除7)、帮助人们学会放手8)、不诋毁过去。9)、努力让员工参与。

能力：

1)、学习新的技术、技能。2)、学会用团队的方式思考和工作：这是大家的工作，营造一个共同负责的思想倾向，这对许多团队成员来说也是新事物。3)、学会在一个短的时间箱内造出可以工作的软件：避免无谓的交接。

能力开发工具：

1)、提供辅导和培训。2)、赋予个体责任。3)、共享信息4）、设置合理的目标5）、立即行动

推广：

推广有三个目标。第一，为接下来的ADAPT周期传递好基础。通过宣传现在的成功，会对创造新一轮的改善意识有一个跳跃性的开始。第二，通过传播其他团队获得成功的一些好消息，加强现有团队的敏捷行为，第三，在直接参与Scrum实施的群体之外创造敏捷意识和兴趣。

不要为变革的过程命名。寻找一个无名转型过程的好处在于你很难去反对一个叫不上名字的东西。

Scrum推广工具：

1）、讲述成功故事：成功的变革在于鼓励员工立足于成功，而不是让他们去解决问题。推广Scrum 转型的最佳方式是，口耳相传。2）、开一个“敏捷野生动物园”：“人们不会真正相信新的事物，除非他们亲身经历过”。3）、吸引注意力和兴趣

传递：

1）、人力资源2）、后勤3）、市场营销4）、财务

承前启后

 

                                第3章 Scrum实施模式

小团队试点，还是全面转型

1、选择小团队试点的原因

1）、小团队试点成本低：假如你不知道自己在做什么，请不要在大范围内进行。

2）、几乎可以确保早期的成功

3）、小团队试点规避了全面转型的巨大风险。

4）、小试点压力更小

5）、小团队试点能在不发生企业变革的情况下进行。

2、选择全面转型的原因

1）、全面转型可以减少阻力：破釜沉舟，这种针对变革的有形的承诺有助于改革成功进行。

2）、它避免了因Scrum和传统的团队一起工作而导致的问题。

3）、全面转型可以使转型更快结束：企业敏捷转型永远不会“完成”，要持续第进行改善是本书核心宗旨之一，但是总有一个时刻，员工可以回顾过去，然后说：转型过程最糟糕的日子已经成为历史。全面转型的公司能更快抵达这一时刻。

3、全面转型和小团队试点之间选择

选择小团队试点：1）、当公司的领导不愿意完全承诺实施Scrum时；2）、如果转型失败的代价太大时；3）、如果起亚迫切希望看到Scrum带来的好处时。

选择全面转型：1）、时间是关键时；2）、要向少数批判者和干系人明确表示会将Scrum坚持到底时。注意：如果没有足够经验丰富的ScrumMaster来指导每个团队，请不要使用全面转型。ScrumMaster来自企业外部还是内部，在短期内无关紧要，但最终，一定要让所有的ScrumMaster都是内部的员工。3）、团队规模比较小时（10人）；

4、公开敏捷，还是瞧瞧行动

5、选择公开展示敏捷的原因

1）、所有人都知道你在做敏捷，所以你更容易坚持下去。

2）、公开展示建立了工作的目标愿景

3）、公开操作是对承诺的鉴定声明

4）、公开展示可以争取企业的支持

5）、明确目标、然后实现，这样更具有说服力：说出你要做什么，然后做到，比达到目标后再宣传目标更具有说服力。

6、选择悄悄行动的原因

1）、有机会在别人反对之前取得进展

2）、悄悄转型避免了额外的压力

3）、没有人知道，知道你告诉他们

4）、如果没有人知道你在使用Scrum，就不会有人阻止你。

从公开展示和悄悄行动中做出选择

选择公开展开：1、对Scrum充满信心，并对转型做出承诺时/2、如果你预计会有一些阻碍，三世你想快速战胜它们时。选择悄悄行动：1、你只想对完成的Scrum或其中一部分做实验时；2、如果没有行政上有影响力声张“我们在实施Scrum”或者这样做会带来非常多的障碍时。

7、Scrum的推广模式

8、先拆分后播种

9、先成长后拆分

10、内部教练

11、优先选择先拆分后播种模式的原因

特点：快速传播

12、选择先成长后拆分模式的原因

1）、不破坏现有的任何团队，团队一直在一起，知道它足够强大，可以拆分成为两完整的团队，每个团队都有敏捷经验。2）、团队成员可以待在一起的时间更长，被分裂的感觉更小。

13、选择内部教练模式的原因

1）、不必拆分优秀团队

2）、为新的团队人工选择教练

3）、教练可以从一个团队转到另一个团队。

14选择自己的方式

选择内部教练模式：

1）、当队伍庞大，以至于不能依靠团队自身全面推广良好实践的时候；

2）、当拆分团队对项目来说不切实际的时候；

3）、当你有足够的内部教练或可以引入外界帮助的时候。

15、引入新的技术实践

16、马上开始的原因

1）、可能有非常快的改进。

2）、如果团队不尽早尝试新的技术实践，他们有可能永远不会尝试。

3）、它也许能解决项目最紧迫的问题。

17、推迟尝新的原因

1）、一些实践可能会遭到强烈的抵制

2）、团队成员也许已经忙得不可开交

 

第4章 渐进敏捷

1、改进Backlog

IBM开始实施Scrum时，它的改进Backlog包括下列事项：

1）、增加使用Scrum的团队的数量

2）、增加对自动化测试的使用

3）、使团队如何确保每个团队都能有一名产品负责人（product owner）

4）、确定怎么样度量实施Scrum的影响

5）、增加对单元测试和测试驱动开发的使用

2、企业转型 区

发起、鼓励与支持企业引入和改进Scrum的小组被称为企业转型 区或ETC（Enterprise Transition Community）。ETC的成员通常不超过12人，他们来自参与Scrum转型的最高级别人员。

3、ETC的Sprint:

ETC Sprint的长度取决于ETC成员。最好是两周。

发起人和产品负责人：

1）、发起人是企业中负责成功转型的资深人士。

2）、转型发起人应该来自企业正在计划实施转型的部门级别。

3）、发起人是ETC的产品负责人

4）、有一点至关重要——发起人通过参与ETC来展现他对转型工作的承诺。“如果发起人只是支票簿式的参与，是Scrum实施失败的最可能的原因，敏捷实施需要一位激情四射的发起人热情投入，做出艰难的企业变革，从而服务于敏捷团队和成功结果”。

4、ETC的职责：

1）、清楚表达背景：为什么什么是现在什么用Scrum/p>

2）、鼓励对话

3）、提供资源：时间、精力和金钱

4）、设置合适的目标

5）、人人参与

6）、预料和处理人们的问题

7）、预计和消除障碍

8）、鼓励对实践和原则的同时关注

5、改进 区

改进 区 improvement community,IC由这样一群人组成——他们聚集在一起，协作工作，以便改进企业中Scrum的使用。ETC最大的目标是创造一个环境，让改进 区确认自己的目标，并自发地组织起来达成目标。

6、改进的催化剂：

区被融入实施和熟练应用Scrum时，便成为改进的催化剂。

最高效的 区的形成，通常不是为了响应管理层的指示，而是公司文化或者ETC创造出来的一种氛围，促使 区自发形成。当然不是所有 区都以这样自发的方式组建。特别在开始Scrum的前几周或几月，ETC需要鼓励改进 区的成立，具体做法是强调某个目标的重要性，然后表达围绕该目标成立 区的期望。

7、有效性的两个度量指标：

1）、非ETC直接要求组建的 区的数量；

2）、这类改进 区在整个改进 区中所占的比例。

8、改进 区Sprint:

改进 区的存在不是为了服务于ETC,它是为了服务于客户：创建产品或者系统的Scrum开发团队。

9、关注实际相关的目标：

改进 区要想具有最大的影响力，其成员必须关注于与已经使用Scrum或尝试开始使用Scrum的开发团队有着直接和实际相关的目标。

10、改进 区的成员：

 

 

 

 

第5章 试点项目

1、选择试点项目

2、理想试点项目的四个属性

1）、持续时间：3-4个月的周期项目，可以给项目团队足够时间在Sprint中开始很好地工作，看到Scrum给他们和项目带来的好处。

2）、规模：请尽量选择只有一个团队的项目作为开始，并保持团队成员都做在一起。这样可以节省沟通成本。

3）、重要性：选不要从边缘的、不重要的、所谓学习性的试点项目开始，而必须从对公司绝对关键的项目开始，否则很难实施Scrum比虚的所有那些难点。

4）、发起人的保证。实施Scrum不仅仅需要开发等式中技术一方发生变化，还需要商业上的变化。

3、选择适合的时机启动项目

4、濒临失败的项目：处于挣扎中的项目别无选择，必须改变，如能交付，那么就视为成功。通过在短小Sprint方式下工作而形成的关注度和强度，以及强调每个Sprint都至少需要一些进步，Scrum往往非常适合这种类型的项目，尤其是在团队在有经验的ScrumMaster或咨询师的帮助时。

5、选择试点项目团队

创建下列人员：

1）、Scrum说客。

2）、积极的乐观者。

3）、公正的怀疑论者。

6、试点项目不成功会怎样：

1）、多做几个试点。并牢记试点项目的意图是阐明Scrum项目遵循的方式。

2）、和约定的期望相悖。要和干系人沟通清楚，承担应负的责任，确保干系人明白，虽然试点项目无法达到所有的期望，但从事后看，项目已经做到或甚至超过实际应有的期望。

3）、不要与设想中运行非常完美的顺序式（瀑布式）项目进行比较。不要用实际项目和虚拟项目作对比。

7、设定和管理期望：

期望管理对任何项目全面成功的重要性，再实施Scrum这样的某个大转型开始时，设定和管理期望可能更重要，在启动项Scrum转型的过程中，我发现从4个方面来设定和管理期望很有帮助，分别是进度、可预测性、对Scrum的态度和参与程度。

8、关于进度的期望

团队是否具有更高的生产效率，很多程度上取决于该团队在实施Scrum之前进展如何。

两种情况几乎使用于所有刚刚开始的团队：

1）、大部分团队都会过高估计他们在第一个Sprint能取得的成绩：他们往往会低估其他占用他们时间的需求，造成他们完成的工作少于预期。

2）、大部分团队可以更有用：各个Sprint关注的是“在接下来的某某星期，我们能做什么。”Scrum团队更有可能去找一个足够好的解决方案，尝试它，学习并根据需要作出改变。

9、关于可预测性的期望：

喜欢用速率（velocity）来衡量项目进展。

10、关于对Scrum态度的期望：“让大家认识到变化正在进行并开始适应它相对容易一些，真正困难的是在变化行动举步维艰的时候让大家咬牙坚持”。

11、关于参与程度的期望

在Sprint或Sprint评审期间，务必于希望得到其输入和反馈的产品负责人和其他干系人讨论对他们的期望，务必让每个干系人都知道团队期望和需要他们做出任何程度的承诺。

 

第II部分 个体

第6章 客服抵触

会变革的确会导致抵触，但是所有的抵触只是来自于特定的个体。团队或者部门并不会抵触Scrum转型，但个体会抵触。

1、预见抵触：

下面的活动有助于实用主义者信服Scrum。

1）、运行一个试点项目，并在团队中包括实用主义者。

2）、确保没有在试点项目团队中的实用主义者能够看到它的结果。

3）、给实用主义者提供培训。

4）、让实用主义者接触其他公司的Scrum的成功故事，比如通过参加讨论会或区域间的敏捷兴趣小组等。

5）、公开说明Scrum的不足和面临的挑战，而不是吹嘘它是“银弹”。

6）、让实用主义者参与改进 区。

2、瀑布深信症（waterfallacy）和敏捷恐惧症：

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布深信症是指由于在瀑布模式项目中工作太长时间而产生对敏捷或者Scrum的错误看法或者观念。如：

1）、Scrum团队不做计划，因此我们无法对客户做出承诺。

2）、Scrum要求每个人都是通才。我们的团队遍布世界各地。自组织会与某些文化冲突，因而我们不能敏捷。

3）、我们的的团队遍布世界各地，而Scrum要求面对面的沟通。

4）、Scrum忽略系统架构，这对我们目前正在构建的这类系统是灾难性的。

5）、Scrum对于简单的 站是可行的，但是我们的系统过于复杂。

敏捷恐惧症是指对敏捷实践具有的强烈的恐惧或厌恶，通常由变革的不确定性引起。可能会有下面描述的敏捷恐惧症：

1）、我担心自己会无事可做。

2）、我担心如果我们做出的决定没有效果，我会被开除。

3）、我害怕冲突，害怕努力达成共识。

4）、我担心人们会看到我实际做的工作很少。

5）、如果有人明确告诉我该做什么，会更容易和更安全。

6）、如果我可以明确第告诉人们该做什么，会更容易和更安全。

3、关于变革的沟通

4、从领导那里听到：

员工更喜欢高层谈论为什么要变革。

在做传达转型时，一定要倾听。理解个体为何抵触是帮助他们克服抵触的第一步。

从同伴那里听到：

同班的影响力，如果同伴宣扬这种好处，人们更容易接受。一个有效的转型过程包括许同伴频繁的沟通和讨论。

5、个体抵触的方式和原因：

原因：1、他们安于现状。2、他们不喜欢Scrum。

6、怀疑论者（skeptic）

下面工具对克服怀疑论者的抵触比较有用

1）、顺其自然

2）、提供培训

3）、获得同伴的趣闻

4）、任命怀疑论拥护者

5）、促进问题的解决

6）、建立认识

7、破坏者（saboteur）：

下面工具对破坏者有用：

1）、成功

2）、持续的重申和强化承诺、

3）、把他们挪走

4）、解雇他们

5）、要确保正确的人在讨论

 

8、顽固分子

顽固分子最常用的技巧是通过控制资源来使Scrum转型“陷入泥潭”。

用来克服破坏者抵触的许多有效方法同样适用于顽固者。此外，还有以下方法：

1）、同步激励机制。如果你发现许多来自顽固分子的抵触，考虑企业中所有现有的激励措施，确保每个都与敏捷一致。

2）、制造对现状的不满。顽固者喜欢现状。尝试制造对与当前状态的不满，并不是说要制造危机，但如果它初露端倪，就要将它指出来。

3）、承认和面对恐惧。顽固分子抵触的一部分原因是因为随着Scrum的进展，他们的工作看起来将不确定。如果你知道答案并有能力给他们，就把答案告诉他们。如果答案是未知的，也说出来但承诺（如果你能以及你认可顽固者的工作）你会和他一起寻找答案。

追随者：追随者的抵触通常不是很积极，他们会进行轻微而消极的抵触，主要是希望变革能消失。

1）、改变团队的人员组成。

2）、表扬正确的行为。赞扬一些不管是在批评还是在支持者那里看到的适当行为。追随者会注意到这些，从而会在一定程度上减弱其抵触情绪。

3）、让他们参与。

4）、使用正确的行为模范。追随者需要有人可以追随。把正确的敏捷行为展示给他们看，为他们的行为树立模范，增加他们可以模仿的可能性。

5）、找出真正的障碍。判断一个跟随者是否因为缺乏意识、愿望或者使用Scrum的能力而抵触变革。然后提供适当的支持以突破这一障碍。

 

9、把抵触视为一个有用的危险信

注意：不要将处理抵触的需要变成“我们”战胜“他们”的对立氛围。真正的目标是创造一种氛围，让大家感觉到想Scrum转型势在必行。培养这种氛围的需要并不意味你有绝对的权威可以完全忽略员工的感情和反应，或把Scrum强势推给企业。当员工抵触时，好的领导不会把员工视为需要解决的问题，而是把他们视为需要理解的人。

 

第7章 新角色

1、ScrumMaster的角色：ScrumMaster对团队成员没有管辖权但对流程有控制权。一方面是团队的领导（servant-leader），另一方面是毫无行政权力的普通人。ScrumMaster的存在就是为了帮助团队使用Scrum。其权力只局限于团队遵循流程。

2、顶尖ScrumMaster共有的六种品质：

1）、负责：ScrumMaster要对最大化团队的产出和支持团队成员实施以及使用Scrum负责。优秀的ScrumMaster以一种独一无二的方式成功地履行其责任——没有权力、特殊的责任。

2）、谦逊：谦逊的ScrumMaster不会把自己的需求排在第一位，而是愿意去做任何能帮助团队实现目标的事情。谦逊的ScrumMaster理解全体团队成员的价值，并以身作则促成他人达成共识。

3）、协作：

4）、投入：ScrumMaster必须与团队成员一样，对项目及其目标具有高度的奉献精神，作为这种投入的一部分，优秀的ScrumMaster不会任由问题遗留多日不予解决。

注意：ScrumMaster展示其积极投入的一种方法是在项目整个周期内保持角色不变。项目中途更换ScrumMaster对团队来说是有破坏性的。

5）、有影响力：成功的ScrumMaster会影响团队内和团队外的人。所有的ScrumMaster要懂得如何运用自己的个人影响力，但理想的方式还是具备一定程度的公司政治技巧。一个ScrumMaster了解谁能在组织内做决定，这些决定如何做出以及有哪些派系等，这是团队的宝贵财产。

6）、知识渊博：“对某事如何工作有清楚而细致的了解，领导将有机会帮助团队弄清楚隐藏更深但又必须解决的技术问题。”

3、技术带头人担任ScrumMaster:

风险之一，技术领导习惯于给团队同事提供指导，而团队成员习惯于找技术领导做决定，而好的ScrumMaster不替团队做出决定，所以前任技术领导作为决策人的历史时不利于Scum转型。

风险二，把技术领导转变为ScrumMaster的风险通常是没有那些必需的与人员相关的技能。因为ScrumMaster必须在没有人事权的情况下，成为指引和领导自组织团队的推动者。评估一名技术领导能否成为ScrumMaster候选人的最好方法是，看这个人是否会运用其作为技术领导的权威。

4、内部或外部的ScrumMaster

选用技能娴熟的ScrumMaster是关键，并且他们应该留在组织里，不应该在长期项目上使用合同制的ScrumMaster。

5、轮流担任ScrumMaster：

如果你想Scrum团队发挥其最大潜力，我不推荐你形成轮流担任ScrumMaster的习惯。轮换不应该是一个长久的方法，有如下问题：

1）、被轮换到的人，经常有一些非ScrumMaster的任务要在当前Sprint完成，而且这些任务通常具有很高的优先级。

2）、很难通过培训使足够多的人能很好地胜任这个角色。

3）、有些人会在担任ScrumMaster的器件推行流程变更。

4）、指定某人作为一两个Sprint的ScrumMaster，并不会自动地让ScrumMaster的工作变得有价值，这可能会导致一些人认为Scrum是错误。

6、克服共同的问题

有人不适合承担这个角色

ScrumMaster也是团队程序员/测试人员/其他角色时：

倾向于选择一个ScrumMaster的时间被分配给两个团队，因为让一个团队的个体贡献者同时来担任ScrumMaster有许多风险：

1）、这个人没有足够的时间投入到两个角色中。

2）、该承担多角色的人可能需要远离项目关键路径上的活动，因为他可能随时可能受到ScrumMaster责任的干扰。

3）、其他团队的人无法轻易知道：他们是在和ScrumMaster谈话，还是和另外一个个体贡献者谈话。

4）、在防止团队受到外部干扰时，这种情况下ScrumMaster的可信度会比较低。

ScrumMaster为团队做决定：“ScrumMaster的职责是提供指导而非答案”。

 

7、产品负责人（product owner）:保证团队瞄准正确目标的人。

“产品负责人不只是一个项目经理，现在也要撰写需求和排列优先级”。

8、产品负责人的职责：产品负责人给团队提供的两样东西，愿景和边界。

提供愿景：拥有一个共同的愿景对激励团队和在开发人员与用户之间建立一个长期的联系通道是非常重要的。

 

提供边界：愿景展示了产品会变成什么样；而边界则描述愿景被实现时的现实情况。边界有产品负责人提供并经常表示为限制条件，如：

1）、我六月份需要它；

2）、我们要减少一半的每单位开销；

3）、它的速度要加倍；

4）、跟现在版本比，它只要用一半的内存。

注意：产品Backlog是一组已安排好优先级别并将加入产品的特征清单。

产品负责人的工作是建造新箱子——边界——团队可以在里面思考。这个新箱子能防止团队迷失在无限的可能性中，给他们提供一个比较和做出选择的基础。新箱子的边界取决于业务上最重要的约束，可包含类似最小保证的功能、高性能、资源消耗更小，当然还有日期。

9、每个团队只需要一个产品负责人：

一个有经验的ScrumMaster与两三个团队一个工作是可以接受的，但是建议每个团队最好只有一名全职的产品负责人。产品负责人的工作很具有挑战性，对外，与客户联系，了解和顺应市场趋势；对内，与团队一起建造产品。当内与外的职责需要同时兼顾是，对外的、面对客户的职责总要优先级最高。每个负责新开发和客户支持的开发人员都能证实与客户相关的问题总是要优先处理。

 

产品负责人团队

一个通用的解决方案是采用一个产品负责人小组。把产品负责人这一角色的职责分散到一个产品负责人团队里，并在该团队中挑选出某个人，由他最终负责和拍板。

10、优秀产品负责人的品质：

1）、始终都在（available）。

2）、懂业务（Business-savvy）：产品负责人懂得产品开发的业务背景是非常有必要的。产品负责人是决策人，决定产品有哪些功能，没有哪些功能，所以他必须非常熟悉产品开发的业务背景、市场状况、客户和用户。这种了解来自多年的行业工作的积累，但也可以从使用过类似产品的经验得来，这就是为什么许多成功的产品负责人来自产品经理、市场或者业务分析员等角色。

3）、善于沟通（communication）

4）、果断（Decision）

5）、得到授权的（Empowered）

11、ScrumMaster担任产品负责人：

当这两个角色合并到某一个人身上时，这是很难保持平衡的。如果一个人能对市场非常了解，又有着能担任ScrumMaster的技术能力与合作技巧，而且同时能够有效地平衡这两点，让他来兼任的确好处多多。

12、克服普遍问题：

1）、产品负责人授权他人决策，但他们往往凌驾于决策者之上。

2）、产品负责人对团队强迫过甚。

3）、产品负责人总想降低质量。

4）、我们的产品负责人和团队身处不同的城市。只要做到以下几点，工作就会非常成功：

1）、始终保持对项目的参与；

2）、同团队建立联系；

3）、执行所任角色的所有常规职责；

4）、产品负责人保证每天在某些时段能接听团队成员所有的来电，下班之后也要能有一段时间这样做。

5）、即便当时自己没空，也要写邮件回复或者打电话。

第8章 角色转换

1、分析员

在Scrum项目中，实时分析是他的目标。分析员将焦点从编写需求文档转变到讨论它们的目标。

2、项目经理

在Scrum项目中，我们认识到项目经理角色时没有必要的，并且会废除它。但是废除该角色并不意味着我们可以废除其对应的工作和责任，曾经的项目经理一般可以转换为承担过去一部分职责的角色，可成为ScrumMaster、产品负责人或者团队成员中任何一种角色。这主要取决于他们的经验、技能、知识和兴趣。

3、为什么头衔要发生变化

1997年发明了单词ScrumMaster，部分原因是这将提醒每个人，这不只是项目经理角色增加或减少某些附加的责任，“Scrum词汇表就是一个关于变化的词汇表，词汇经常有意第难看——燃尽（burndown）、Backlog、ScrumMaster——因为它们提醒我们变化正在发生。”

4、架构师

很多架构师在面临采用Scrum时提出的担忧归纳如下：

1）、人们仍会实现我所说的架构吗/p>

2）、我如何保证在没有提前设计架构阶段下能有一个架构不错的产品/p>

5、不编码的架构师

对于抵触在新角色中动手参与项目工作的架构师，要警惕他们。“作为一个架构师，敏捷给我们带来的最大变化是，之前架构师不需要具有指示具体解决方案的能力，而现在他必须能成为一个顾问和促进者。作为顾问，我最好仍然能做那些自己擅长的工作。”

6、职能经理

职能经理的领导角色：

职能经理还保留培养自己团队成员的责任。确保有预算或时间让们参加会议，通过参加恰当的项目让他们有挑战以及鼓励他们参与或成立实践 区是职能经理角色的全部内容。

7、人员管理职责

在大部分组织中，职能经理将保留为部门下属写定期评估的责任。

8、程序员

Scrum团队中，程序员很大的变化之一就是他们将不能再呆在自己的隔间里等待有人来告诉他们具体该写什么程序。他们需要积极主动第理解产品需求。程序员被期望能花更多时间与共事的人员沟通，程序员要呆在一个小组的空间里，参与讨论，帮助有问题的其他人，并参与结对编程。

9、数据库管理员

数据方面的专业人士将面临学习如何增量实现此前传统项目中被视为项目前期工作中一部分的任务。在数据库设计方面的标准建议是在做物理或逻辑数据库设计过程中，对系统需求进行完整分析，创建逻辑或物理数据库设计，并且将这些概念限定在实际数据库限制中。这一系列步骤的成功是以全面而准确的提前分析为基础的。数据库需要演变来支持建造基于它们的不停演变的应用。“应用是变化的，但数据是永恒的”。

10、测试员

11、用户体验设计师（User Experience Designer ,UED）

UED能感觉到自己是团队的一部分以及他们的首要任务是要提交当前Sprint所承诺的东西。他之后的工作是与每个人期望产品负责人提前计划公司要做什么以及用户需要什么等，提前计划未来Sprint的设计。

在进行角色的转换时，有三个最重要的主题需要重申：

1）、增量地工作：总是努力在当前Sprint产生一个潜在可发布的产品增量。

2）、迭代地工作：功能特性能在接下来的Sprint中被更新。

3）、超出专业之外的工作：为了创建在Sprint结束时潜在可交付的某些东西，个人需要愿意偶尔做一些超出其专业之外的工作。

第9章 技术实践

1、追求技术进步

Scrum团队用来改善工作质量的常用技术实践：测试驱动开发（test-driver development，TDD）、重构、集体所有权、持续集成以及结对编程。

2、测试驱动开发

对代码的清理称为重构（refactoring）

把TDD作为一个设计实践和作为一个编程实践同等对待是相当合理的。毕竟，程序员编写的测试代码以及它们在编写时的顺序，会指导某个功能特性的设计和开发。程序员不会创建一个包含50个小的单位测试的列表，然后随机选择某个先实现。相反，他会