读《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？

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）、人们仍会实现我所说的架构吗？

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

5、不编码的架构师

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

6、职能经理

职能经理的领导角色：

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

7、人员管理职责

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

8、程序员

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

9、数据库管理员

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

10、测试员

Scrum团队的测试人员需要适应更频繁且有意义地与其合作者交流，并在很多时候面对的是来自团队外部的人员。

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个小的单位测试的列表，然后随机选择某个先实现。相反，他会选择单元测试并对它们进行排序，以便尽早解决该功能特性的不确定性。通过这种方式，测试的选择和实现，确实能驱动开发过程，这使得设计能从系统的需求中涌现出来。

 

3、重构

重构是指改变代码的结构，而不是代码的行为。重构不仅对TDD的成功至关重要，它也有助于防止代码腐烂（code rot）.产品发布后，代码腐烂是典型的综合症，如果允许代码腐烂，过不了几年，系统就需要全部重写，通过不断重构，并且在一些小问题变成大问题前不断地修复它们，我们能够保持我们的应用程序不会腐烂。RobertC.Martin称为童子军规则。

4、集体所有权（collective ownership）

集体所有权是指所有的开发人员共同负责开发过程中的所有产出内容，特别是代码合自动化测试。

团队中的每个成员共同承担下列职责：

1）、确保开发人员不会变得太专以至于只能在某一方面做出贡献。

2）、确保没有一个地方变得太错综复杂以至于只有一个开发人员可以明白和完成某工作。

5、持续集成

持续集成是指尽可能快地将新开发和修改过的代码集成到一个应用程序中，然后测试这个应用程序，确保没有任何东西被破坏，而不是可能过了几天甚至几周后才提交代码。

6、结对编程

结对编程是指两个开发人员一起编写代码。

7、设计： 有意的而又是涌现式的

Scrum项目的差异不是扔掉有意的设计，而是通过增量的方式来完成，像Scrum项目中的其他做法一样。

8、习惯于不做大型设计

这种转变带来如下新的状况：

1）、计划更困难

2）、在团队和个体之间分割任务更困难。

3）、没有完成设计会感觉不舒服。

4）、返工不可避免

9、引导设计

通过排列产品Backlog中的事项来影响系统的架构。

在新项目的早期，团队成员要鼓励产品负责人选择可以那些能最大化知识并排除技术不确定性或风险的事项。Scrum项目的设计包括有意的和涌现式的：涌现式设计是因为没有前期设计阶段；设计是有意的，是因为慎重地选择产品Backlog的事项，在不用的时期有一双眼睛在推动设计朝着不同的方向前进。

 

第iii部分 团队

第10章 团队结构

柯维定律：被制造出来的系统往往有一个结构，这个结构反映了制造它的团队结构。

1、给他们两个披萨

2、为什么两个披萨就够了

小团队有更多的优势：

1）、社会惰化现象程度更低。

2）、积极的互动更有可能发生在小团队。“一个团队如果超过10到12个人，将很难建立信任感、共同的责任感以及凝聚力。没有这些，积极的互动会很困难”。

3）、花在协调上的时间更少一些。

4）、没有人会消失在幕后。小团队会更满意他们的成员，过分专业化的不利因素不太可能发生。

3、小团队的效率

大团队带来了更多的投入和成本。这个趋势呈指数级变化，最高效的是小团队，但当团队小于9个人的时候，工作量的增长并不是线性的。大团队（29人）引入的缺陷几乎是小团队（3人）的6倍多，同事显然花费了更多的钱。然而，大团队做出相同数量的产出所花费的时间平均只少了12天的时间。

支持特性团队

4、一个多团队的项目中引入特性团队，有下面诸多优势：

1）、特性团队能够更好地评估涉及决策带来的影响。

2）、特性团队减少了交接带来的浪费。

3）、他确保了正确的人在讨论。

4）、组件团队会制造一些进度方面的风险。

5）、它保持着对交付热性的关注。

5、保守地使用组件团队

只有在特性团队要求的时候再构建组件：在组件团队中配备一个来自特性团队的人，是确保组件团队能听到有助于他们开发出游泳功能的反馈的最好方式。

决定什么时候需要组件团队：

1）、组件团队要开发供多个特性团队使用的功能。

2）、使用组件团队可以减少共享的专家。

3）、多种方法的风险大于单个组件团队的不足。

4）、可以促进讨论，否则会保持沉默。

 

6、谁来做这些决定？

理想情况下，应由团队自己决定他们的结构，但一开始时，可能需要部门经理、项目经理、ScrumMaster或者其他想推动Scrum转型的人决定团队的结构如何组织。

7、今天对，明天可能错：在选择适合的团队结构是，请记住，没有一个团队结构是永久的。

 

8、自组织不等于随意组合

“最好的架构、需求和设计出自组织的团队。”这里有两个关键点：1、不是所有的团队都选择同样的方式来组织，这并没有什么问题；2、相比仅仅依靠人员管理者的智慧，使用团队的集体智慧通常是组织工作的最好方式。

把正确的人放入团队

1）、包括所有需要的专业

2）、平衡技术水平的等级。1）平衡领域知识；2）寻求多样性。3）考虑持久性。

9、一个人一个项目

任务太多的时候，花在单一任务上的时间会减少

何时可以多任务

公司的多任务表

10、立刻停止：停止多任务的最好方法通常是立即停止。

1）、在做好充分准备之前不要启动项目。

2）、企业计划中要包括启动和收尾时间。

3）、制定简单规则。

4）、虽慢也要前进。

11、良好的团队结构指导原则：

1）、这个结构是否可以突出优势，弥补不足，并帮助团队成员提高积极性？

2）、这个结构是否可以尽量减少被安排两个项目的人数，并且可以避免任何一个人被安排三个项目。

3）、这个结构是否可以最大化团队成员的相处时间？1）组件团队的使用是否是受限制的，并且只有在简单适当的情况下使用？2）只有两个披萨，你的团队是否够吃？3）这个结构是否可以最小化团队之间的沟通路径？4）这个结构是否可以鼓励那些不主动沟通的团队之间的沟通？5）这个结构是否有助于清楚第理解责任制？6）团队成员是否对团队结构的设计提供一些输入。

 

第11章团队协作

1、拥抱团队责任制

2、培养团队承诺

3、依赖专家但须谨慎

4、所有工作总是逐渐完成:在Scrum团队总，如何喀什是需要在参与该功能开发的人员之间共同商讨的。

5、不要等到Sprint快结束时才完成所有任务

6、承诺完成不同粒度的产品Backlog事项：

不在一个Sprint中计划三个非常大、不能部分地完成的事项，而是只计划一个或两个大的事项，同时还有三两个小事项。

7、鼓励团队学习

8、确保学习环境的五大条件：

9、设计学习型团队

1）、个人必须有分享知识的具体方法

2）、领导者一定要强调学习的重要性：三种领导者应该展示的重视学习的行为方式：1）易于接近；2）询问别人的意见；3）做“易犯错的模范”。

3）、授予团队激励性的挑战：承认挑战的难度，但用积极的态度看待团队能力，和团队一起工作叨叨一个适合的初始版本。

4）、有一个互帮互助的学习环境：给Scrum团队创建学习环境则需要企业、社会关系和心理上的变革。有学习氛围的企业有如下特点：1）心理安全感；2）欣赏差异；3）对新想法迟开放态度；4）反思的时间。

10、消除知识浪费

精益开发专家Allen Ward吧知识浪费分为三类：分散、交接（hand-off）和一厢情愿

导致分散的连个主要原因是沟通不畅和不合理的工具。

Ward把交接定义为知识、责任、行为和反馈的隔离。

Ward的知识浪费的第三类一厢情愿：是指在缺少足够信息支持的情形下还是做出了决策。11、通过承诺鼓励合作

1）、广泛参与：鼓励所有开发人员参加为产品Backlog写用户故事的研讨会，团队成员越多看到项目与产品的前景，他们就越能够全心投入，并致力于完成它。

2）、寻找激励目标:“一些让人们感到兴奋和有趣并值得参与的事物”。

3）、深入了解固有的激励：如果一个项目可以让每个人不同的个人目标和项目目标保持一致，那么这个项目就可以产生期望的承诺。

4）、注意最没积极性的团队成员：一个积极性很高、技术娴熟的个人经常能使他的每个同事也变得更好一些。另一方面，一个懒散没有斗志的成员，也会拖垮整个团队。

5）、帮助每个人理解他们与目标的相关性：如果团队成员觉得自己的贡献无足轻重，将很难全身心投入项目目标。

6）、培养自信。

 

 

第12章 领导自组织团队

影响自组织团队

影响自组织团队的三个要素：“容器”、差异与交流。

容器：是自组织发生的边界条件。

扩大或减少差异

调整交流

影响演化

演化是变化、选择、保持这三个要素的结果。

领导力远不仅限于买披萨

第13章 产品Backlog

1、从文档到讨论的转变

文档易造成误解，说明口头交流胜于文档。

1）、书面文档会让你暂停做出判断。

2）、有了书面文档，我们就不能像谈话那样反复声明要表达的意思。

3）、书面文档不利于团队责任制。

2、切勿良莠不分：敏捷开发的目标是找到文档和讨论之间的合理的平衡。

3、在产品Backlog中使用用户故事

4、持续地提炼需求

5、涌现的需求：不能提前确认的功能被称为涌现的需求（特指没有预期到的需求）。

我们最好根据功能要被实现的时间，采用不同精确程度的方式来规定功能需求，而不是从一开始就为了它的完整性而苦苦挣扎。

6、产品Backlog冰山

梳理产品Backlog   ：一个黄金法则是我们应该花每个Sprint中10%的精力梳理Backlog列表，以便为将来的Sprint做准备。

切记，Scrum要求你为变化做好计划，需要预留时间梳理产品Backlog。它在每个Sprint中并不一定都需要，但是需要经常做这件事以便能在产品Backlog顶部保持小型的、适合Sprint的事项，同时延迟对那些将来才会用于事项的投资。

7、为什么要持续地提炼需求？

1）、事情会发生变化

2）、不需要

3）、时间有限

7、对用户故事的持续提炼

一些大需求因为太多，所以它们要被拆分成稍小的大需求。

加入满意条件：故事被拆分到足够小的粒度，进一步拆分它们已不再有帮助，到这时，通过向用户故事中增加满意条件，我们还可以持续地提炼需求。一个满意条件是某个简单的概要验收测试，如果该用户故事已经完成，该条件就是真的。

8、学会在没有详细说明书的情况下开始

9、通过事例说明：通过事例来说明一个产品，在沟通系统想要的行为时，使用事例是一种非常好的方法，特别是加入交谈和少量解释性的书面文字。

10、跨职能的团队能降低对文档的需求

11、创建DEEP的产品Backlog

1）、详略得当

2）、做过估算的

3）、涌现的

4）、排列优先级

第14章Sprint

1、每个Sprint应递交可工作的软件

敏捷方法强调可工作的软件，因为下面3个主要原因：

1）、可工作软件鼓励反馈。

2）、可工作软件帮助团队衡量它们的进度。

3）、可工作软件允许产品在需要时尽早发布

2、“潜在可交付”的含义

零缺陷并不是意味着产品没有缺陷或者缺少功能，而是指产品达到某个里程碑设定的质量标准。

任何一个新团队需要做的一件事是讨论并同意“完成（done）”的定义。它定义了与所在环境相适应的某个潜在可交付的产品增量。Sprint里产品Backlog中的每一项只有在满足这个标准后，才可以认为是完成了。

3、识别“潜在可交付”的指导方针

1）、潜在可交付意味着测试过

2）、潜在可交付并不意味着系统功能的完成。

3）、潜在可交付意味着集成已做好。

4、每个Sprint提交一些有价值的东西：

在Sprint中工作的一个好处是可以在每个Sprint结束时获得用户和客户的反馈，所以在Sprint中完成那些可以让用户看到功能特性的任务，团队会得到更好的反馈。

5、在当前Sprint为下个Sprint做准备：在任何一个Sprint中应有10%的团队可用时间用于准备下一个Sprint。

6、只在一个Sprint中塞入能完成的东西

7、每个Sprint始终保持协作：公司是如何做到如此创新的伟大产品？“产品不会从一个团队传递给另一个，不存在分离的、顺序式的开发阶段，相反，它是同时进行并且是一体的。产品通过所有部门并行的方式一起完成，包括设计、硬件和软件，经过无穷论的多学科的设计评审”。

避免特定活动的Sprint：团队会决定第一个Sprint用于分析和设计，第二个Sprint用于编码，第三个用于测试。

特定活动的Sprint拥有的缺点：太多的交接工作和缺少作为整个团队的责任心。

1）、进度风险增加。

2）、花太长时间完成从想法到可运行、测试过的功能特性。

3）、这并没有真正解决交迭工作的问题

8、用完成-完成的关系取代完成-开始的关系

9、用户体验设计的交迭：除了通过每日站会保持与整个敏捷团队接触，我们在设计和开发中始终与开发人员紧密工作在一起……交互设计人员需每天与开发人员沟通，这不仅能确保设计正在被正确地实现，而且我们还能对影响设计决定的技术限制有一个全面的理解。

记住在Sprint中，团队只有两个目标：完成当前Sprint计划的工作以及准备下一个Sprint。

10、全盘思考，增量工作

全盘考量但迭代实现解决方案。

11、系统架构和数据库设计

12、保持时间箱定期性和严格性

固定Sprint长度的好处：

1）、团队收益于定期的节奏。

2）、Sprint计划变得更容易。

3）、发布计划变得容易。

4）、这正是Richard Feynman做的。在强调所有Sprint都应该一样长时，我不建议你们一定要如何，而是选择一周中在你的环境里比较合适的某天并在当天开始所有的Sprint。我喜欢在周五开始Sprint，这样我们可以让这天过得很充实，可以做Sprint评审、回顾和计划会议，将所有这些放在周一会导致我们比平时更恐惧周一。

13、绝不要延长Sprint

14、不要改变目标

15、放弃改变团队目标的习惯

稍后再缓和强硬立场

第15章 做计划

需要逐步完善计划，而不是一开始就做全面详细的计划。

1、逐步完善计划

早期计划要抓住要交付内容的要素，但是把细节放到以后考虑，在后续的计划中增加必要的细节，但我们只在自己又足够多的知识来支撑这些细节的时候才能添加它们。

1）、它可以最大限度地减少时间上的投资。

2）、它允许在最佳时机做决策。

3）、它允许我们改变路径。

4）、它可以帮助我们避免落入相信计划的陷阱。

2、不要用加班来赶计划

你不能无限制地推动团队去越过某一个点。

可持续的步伐对Scrum团队来说有同样的意义：团队大部分时间按照良好的、均速的速度运行，但是偶尔，团队需要“加档”，比如在临近项目结束的时候，或者可能遇到一个用户报告的严重缺陷的时候，偶尔加班不违反按照持续步调工作的目标。

3、历经挫折后才会明白

4、达到目标

使用可持续的速度工作以便于收集数据也并非易事，为了应对这种情况，我找到了下面这些有用的论据：

1）、以可持续步调工作可以使你保留一些能量供真正需要的时候使用。

2）、它给我们留出更多保持创造性的空间。

3）、不要再说我们的大脑每天六个小时后就枯竭了。

4）、它值得一试。

5、如果不加班，怎么办？

增加能源的最好方法之一就是增加热情。产品负责是关键，产品负责人需要传达一个引人注目的产品愿景，让开发这个产品的团队满腔热情地工作。

6、如果可能，支持改变范围

7、区别对待估算和承诺

8、用正确的数据来做：优秀的企业知道把估算和承诺分开，我们首先做估算，然后，根据我们对这个估算的信心，我们把它转化成一个承诺。

9、历史估算是承诺的基础

团队从来没有一起工作过：任何情况下，你都有机会在做出承诺之前运行一个Sprint。

团队规模频繁变动：团队规模频繁变动或预计会频繁变动，会引发不同类型的问题。

一个团队如何在做Sprint基本任务和发布计划之外进一步获得更大的好处：

1）、持续完善地计划。

2）、按照可持续的步伐工作。

3）、如果不能按时交付全部内容，首先看是否可以变更项目范围。

4）、区分估算和承诺。

第16章 质量

1、把测试集成到流程中

实际上测试完全不是事后的纠正活动，而是为了验证在之前的开发过程中没有引入错误。不是等产品构建好了之后才尽力测试产品的质量，我们在流程中、产品制造过程中构建质量。

2、为什么最后才测试没有效果：

1）、很难改进现有产品的质量。

2）、错误一直未被发现。

3）、项目状态难以测量。

4）、措施反馈时机

5）、测试很可能被削减。

3、什么是构建质量

构件质量的团队具有以下明显特征：

1）、最明显的是使用工程技术实践：测试驱动开发、结对编程、重构以及持续集成.

2）、程序员和测试人员之间的交接微不足道（如果它们还存在的话）。所有时候都在一起做几乎所有的工作有利于团队协作。

3）、在Sprint的第一天和最后一天应该有同样多的测试活动。

4、不同层次的自动化

 

单元测试是自动化测试策略稳固的根基，因此在金字塔中用最大的部分来表示。好处：1）一个自动化单元测试可以缩小它的错误范围；2）单元测试使用的语言通常和开发系统使用的语言相同，程序员写起啦得心应手。

UI用户界面常常有下面负面属性：

1）、脆弱

2）、成本高

3）、耗时

服务层：一个服务是指应用程序对于一些输入或输入集的响应。

5、保留用户界面测试的角色

6、手工测试角色

手动测试主要作为探索式测试。这类测试包括一个快速的循环过程，含有测试计划、测试设计和测试执行这些步骤，探索式测试应该以短为特色，它产生反馈的周期类似于测试驱动开发具有的测试——写代码——重构的短周期风格。

7、在Sprint内做自动化

自动化测试提供了一个便宜的保险，能确保原来正确工作的东西仍然是好的，此外，一个持续增长的自动化测试套件，可以不断检查产品状态以及过程：如果自动化测试套件两个星期都没有运行成功，那将是一个重大的警报信号；另一方面，如果自动化测试套件每天都在增加，每天晚上都没有运行错误，这可能说明团队状况良好。

8、验收性测试驱动开发（ATTD）

9、恰到好处的细节

COS仅仅是在Sprint最后阶段完成用户故事时要满足的内容的概要说明，它们用来判断在一个Sprint结束的时候，用户故事是否被正确完成了。其目标是讨论概要的验收性测试，让开发人员能初步了解产品负责人的期望，而不是确定最终需要的非常细的测试用例。

10、偿还技术债务

技术债：做一个设计很差、代码写得很差、包括未完成代码或任何其他缺陷的系统所涉及的成本。

“只要快速地归还，小的债务可以加速开发”

通过三个步骤3降低测试债务

1）、止血：防止事态越来越糟糕。找到自动化现有的某些手工测试。

2）、维持现状：在Sprint期间为新增功能开发自动化测试。

3）、还债

质量需要团队的共同努力

第四部分 组织

第17章 扩展Scrum

1、扩展产品负责人

产品负责人这个角色时Scrum项目中最具有天战性的角色之一。在所有项目上，他身兼二职：彼此竞争的对内和对外的需求。其对内的任务是参加Sprint计划会议、Sprint评审会议、Sprint回顾会议和每日站会，管理产品Backlog，回答来自团队的问题，在Sprint期间能被团队找到。对外的任务包括和用户谈论他们的需求，发起并解释用户调查，前往客户现场，参加行业贸易展览会，管理项目干系人的期望，给出产品Backlog的优先级，决定产品价格，指定中长期产品战略，观察产品和市场趋势，进行竞争分析等等。

项目开始变大，成长为多个团队后，最好是给每个团队找到一个新的产品负责人。如果不能达到团队和产品责任人一对一对应的目标，也要试着让每个产品负责人负责的团队不要超过两个。这通常是产品负责人能够有效工作的最大范围。

2、共享责任，分割职能

3、完成大型产品Backlog的工作

不管选择哪种Backlog管理工具，仍有两个值得指出的始终有效的指导原则：

4、如果只有一个产品，那么应该也只有一个产品Backlog

5、产品Backlog的大小必须合理

我们大多数人在大脑中只能直接记住100到150个产品Backlog

使Backlog项目处于可管理状态的两种方法：

1）、利用史诗故事（Epic）和主题故事。

2）、给产品Backlog提供多个视图

6、主动管理依赖

7、进行滚动的前瞻性计划会议：最恰当的时机是Sprint计划会议末尾，因为团队和产品负责人已经共同对计划的事情形成了形象。

滚动前瞻性计划应被看作一个可以思考下一步可能做什么的机会，而不是已经锁定的计划，产品负责人依然能够修正他的基于这些当初有效信息的观点。

8、举行发布启动会议：这件事的理想时间是新项目或发布周期的开始阶段，启动会议能够降低大型项目最大的风险之一：不同的团队或个人会被引到错误或不同的方向。

9、共享团队成员：当依赖很难被提前找到或需要尽快解决这些依赖时，这是一个有效的方法。当依赖发生在许多团队间并且许多方面都有依赖时，它就无效了。不过，当依赖存在于特性团队和组件团队时，这是一种好的策略。

10、使用集成团队：集成团队完成开发团队之间所存在的差异的工作，大多数这些差异发生在团队间的接口。接口问题可以分为两类：1）未经确认的接口：指已存在，但没人发现的接口；2）无人管理的接口：指接口已存在，至少有一个团队知道但没有一个团队为它做任何事情的接口。

集成团队直接关注无人管理的接口，同时也会搜寻未经确认的接口，集成团队发现无人管理的接口或未经确认的接口后，首要任务应该是鼓励某个开发团队为它承担责任。当这不可行时，集成团队才接过它的所有权。

11、在团队协调工作

团队间不存在敌意或是竞争，仅仅是每个团队只关注自己的目标，而忽略了整体的目标。

12、Scrum of Scrums 会议：让多个团队可以讨论它们的工作，尤其是关注交叉和集成的领域。

13、同步Sprint

让Sprint重叠最大的缺点是绝没有一个时间点是所有团队都完成任务的。

同步Sprint的基本好处时所有的团队能够在一两天内开始和结束Sprint，但不意味着所有团队工作的Sprint长度必须一样。多个团队的项目可以通过使用嵌套Sprint来调节不同的Sprint长度。

14、拓展Sprint计划会议

在多个团队工作于同一项目的情况下，Sprint计划会议会出现很多问题，如下所述：

1）、有些人需要参加多个Sprint计划会议。由于所有的Sprint使用共同的起始日期，所以有的人需要同时出现在两个地方。

2）、如果一个团队发现对另一个团队有依赖，那么他们不能指望另外那个团队承诺完成依赖，如果后者已经完成Sprint计划的话。

3）、如果多个团队从同一产品Backlog中挑选条目，那么这些条目要在Sprint计划会议开始前就预先分配好。

对于大规模Sprint计划会议有很多途径可以减少或消除这些及其他类似的问题。

15、错开一天

16、大房间：大房间方法对关键的共享资源尤其适用。

17、培养实践社区

由一群具有相同思想、相同技能的个人因为对某种技术、方法或愿景的热情和投入而自愿形成的。在大型项目中，这些实践社区极有助于划破边界把个人多个跨职能团队拉到一起。

18、正式的或者非正式的

19、创造有利于社区形成和繁荣的环境

关于创造支持这种进化的环境，他们提供了七条准则：

1）、为进化而设计。

2）、在内部和外部的参与者间进行对话

3）、邀请不同级别的参与者。

4）、举办公开的和私有的活动

5）、专注于价值

6）、把亲近和兴奋结合起来

7）、维持社区的节奏

20、参与

对多数得到正式认可的实践社区来说，如果委任一名社区协调人将会有很多好处。社区协调人不是小组的领导，而是确实通过两种重要方式为团队服务：

1）、围绕组建的社区开发实践

2）、发展社区本身

社区协调人的任务是安排会议和其他活动，确保成员们参加，联络有共同兴趣的个人，自己参加社区活动等。

第18章 分布式团队

1、决定如何分布多个团队

协作式的本地团队以强化一个概念，即每个本地团队和其他的远程团队一起工作以交付产品。

有意的分布式团队则是在项目本能够使用协作的本地团第但还是决定分散团队于不同地方的情况下形成的。

分布式项目中可能出现的沟通问题：

1）、不与产品负责人一起工作的开发人员不能充分理解领域业务。

2）、不同城市的开发人员不自觉地不认同已开发的东西。

3）、不同城市的开发人员作出互不兼容的决定。

4）、在不同地点的个人之见形成一种敌对的“我们和他们”的关系。

5）、一个城市的开发人员不知道另外一个城市的开发人员在做什么，或者他们为什么作出那样的决定。

2、形成凝聚力

3、承认显著的文化差异：1）权威距离指数（PDI）;2)个人主义（IND）;3)不确定性规避指数（UAI）;4)长期导向（LTO）.

4、承认微小的文化差异：

5、加强职能和团队的亚文化：1）交流和建立共同愿景；2）达成共识；

6、通过强调早期进展来建立信任

7、现场见面会

8、播种访问:让团队短期待在同一个地方，是朝着彼此了解与信任迈出了一大步。

比如面对面的启动会，让我们有机会认识每一个人，建立关系，并一起理解项目。

9、联络访问：“请记住访问的基本目标不是做任务，而是建立工作关系。”

10、旅行大使：走动式管理（Management By Walking Around，MBWA）常规实践在分布式项目中被替换为飞行式管理（Management By Flying Around，MBFA），从许多方面来说，从一个城市飞到另一个城市的人们都可以被认为是大使。大使的工作中，一个重要的职责是传达各式各样的、看上去重要性不够，以致于不能放到正式交流渠道的小道消息。（小道消息是指有助于我们熟悉同事的消息）。

“我们发现在分部之间交换大使是改善夸团队沟通最有效的一个手段，它使得我们可以建立一种个人关系，并提供一种构建互信和传递知识的手段，大使能够传递学到的经验教训，也能够为项目设立未来的方向”。

11、改变沟通方式

12、添加一些文档。

13、给产品Backlog添加细节：“距离越远，你就需要在沟通需求上投入越多的精力”，“给概要用户故事补充更多详细的规范有助于授权给远程团队，更详细的需求使团队在不能直接联系到产品负责人的情况下获得对功能和终端用户目标的深刻理解”。

14、鼓励横向沟通：一个城市的任何人都能和另一个城市的任何人对话。横向沟通的一个重要优点是它抵消了“沉默效应”沉默效应只指项目参与人不和其他人分享坏消息。通过封锁坏消息，这个人将项目置于风险之中，因为没有问题相关的消息，所以无法解决。

不愿意分享坏消息的三个原因：

1)、害怕受到惩罚，包括被解雇。2）、想要维护团队团结。3）、没有通畅的渠道沟通问题。

15、会议

对于分布式团队而言，难的不是距离而是时差。

16、一般性建议：1）留一些闲聊的时间；2）分担痛苦：存在时差的会议，不能总是对一方有利；3）告诉大家谁在发言：用在电话会议时。

17、Sprint计划会议：1）长时间的电话:多数团队默认采用的方法是让每个人都拨进电话，除此之外则正常地进行Sprint计划会议，电话试图模仿现场Sprint计划会议的形式和互动。定期Sprint计划会议的所有工作都在一次电话中完成。电话结束时，就像团队在同一个地方峰做一样，Sprint已经被安排得满满的。

2）两次电话：对于一些团队，在一次电话里完成Sprint计划是很不现实的——时区差异太大，以至没有充足的重叠工作时间段。那么安排两次电话的Sprint计划会议方法，通过连续两天的两次电话会议来完成。第一次电话会议主要讨论产品负责人那边最高优先级的功能和期望。第一次会议结束后，各处的子团队接着开会计划接下来Sprint中需要完成的工作。第二次会议目的是同步各个子团队的任务。

18、每日站会：每日站会时间限制在15分钟之内。三个基本策略：单次电话、记录会议和地区会议。

1）单次电话：

2）写会议记录

3）地区会议

19、Scrum of Scrums

Scrum of Scrums 供大团队用于协调工作，它要求每个团队派出一名代表参加会议，通常一周两三次。降低这个会议的频率，以减少分布式团队带来的麻烦，这个会议一般是一个小时或者更短。因此，在工作时间有重叠的任何分布式团队都很容易安排一次Scrum of Scrum会议。

20、Sprint评审和回顾：Sprint评审和回顾具有每日站会和Sprint计划会议的属性。必须参加。偶尔举行同城回顾会议

第19章 与其他方法共存

1、混合Scrum和顺序式开发

2、三种交互场景：1）瀑布在前模式：Scrum和顺序开发在项目的开始就交汇，通常发生在组织有项目批准障碍时。为了清除这些障碍，通常要求Scrum团队将他们对文档的厌恶放置一旁，创建某个规格说明书、项目计划、或其他批准要求的物品。在一个瀑布式在前的项目获得批准后，该项目就可以开始作为一个正常的Scrum项目来运作了。

2）瀑布在后模式：当Scrum和顺序式开发在项目的结束时交汇，这通常是在测试阶段。原因1）企业知识暂时拥抱Scrum，让测试人员或质量保障人员作为单独的在最后参与项目来校验和验证产品。2）有一个外部小组可能要求最后进行测试时，也会用到瀑布在后的方式。

3）瀑布两头模式：常见例子是两个或多个团队必须一起工作来创建单个产品，其中一个团队使用Scrum而另一个使用顺序方法。

3、冲突的3个领域

避免在Scrum和顺序过程共存时可能发生的3种冲突1）开发过程2）业务过程3）人。

针对这些问题的解决方法，Boehm和Turner提供了如下建议：

1）所做的分析超过Scrum通常所需要的。

2）创建一个刚好足够的流程，而不是分拆一个大的流程。

3）定义一个划分了Scrum和顺序方法的系统架构：具有稳定和清楚明白的需求的地方有顺序式团队构建，具有不确定需求或存在多个正确设计方法的部分应由Scrum团队来构建。

4）教育项目干系人。

4、Scrum和顺序式能永远共存吗？

能。但是“敏捷不是目标”很重要，敏捷意味着持续改进。当某个企业尝试变得越来越敏捷时，Scrum和顺序开发之间的冲突将变得更痛苦。如果这些冲突的来源不被移除，企业的重力会将企业拉回采用Scrum前的软件开发过程。

监管

对了解项目总体情况的需要，通常叫监管，它用来确保项目进展没有偏离。

中心思想是在开发过程的每个阶段，要强制项目通过一个门槛，每个门槛承担对项目的一个正式的评审检查点，项目可能被批准向前，或发回去在之前阶段重做，或被取消。

用非敏捷的监管来运行Scrum项目：1）预先协商和设定预期2）报告要提前满足当前的期望。3）邀请他们参加你的过程。4）参考成功的例子。

5、兼容

6、ISO 9001

国际标准化组织（The  International Organization for Standardization,ISO）维护着9001标准，通常被指定为ISO9001:2000或ISO9001:2008。这两个名字表明该标准具体版本的年份。认证不意味着能保证组织的产品达到一个具体的质量级别。更确切地说，ISO 9001认证意味着组织遵循了一套正规的实践来开发它的产品。遵循ISO 9001中最大的工作量是创建质量管理系统，通常为一份冗长的文档或一套网页，其中描述了组织要遵守的质量实践。

7、能力成熟度模型集成（CMMI）

能力成熟度模型集成（Capability Maturity Model Integration，CMMI）:在某种程度作为对一个企业有多少流程的度量（或至少有多少已被定义），CMMI与其前身（Software Capability Maturity  Model,SWCMM）常被看作是重量级软件开发方法和敏捷开发的对立面。

8、实现兼容

在企业里成功地结合Scrum和ISO 9001 与CMMI

1)在的产品Backlog上投入足够的精力。2）将监管相关的工作放入产品Backlog。3）考虑使用检查列表。4）自动化。5）使用敏捷项目管理工具：慢慢而稳定地前进、跟审计员一起工作、引入外部的帮助。

第20章 人力资源、后勤和PMO

开发团队之外的群体中敏捷转型所带来的影响：1）人力资源2）后勤3）PMO

1、人力资源

大部门企业本质上喜欢个人的责任胜过小组（团队）的责任。岗位说明、赔偿方案、职业发展路线和绩效考评都在关注个人……我们的文化强调个人成就，并让我们相信：如果我们的职业发展需要依赖别人的绩效，那让人不舒服……甚至从个人责任转变团队责任的想法也会让我们不安。

2、管理层次结构

企业结构应该尽量扁平。在团队成员和公司高层之间的层级越多，就越有可能慢慢失去控制。

1)向ScrumMaster汇报2）向产品负责人汇报

2、定期的绩效评估：1）评估要尽量消除那些倾向个人的因素 2）要包含团队写作的因素 3）更频繁地评估绩效，每年超过一次4）广泛收集反馈意见 5）培训人力资源部门并让他们参与

3、开除团队成员

1）、职业发展

2）、只要有人参与，就总是存在与人相关的问题。

4、后勤

团队所处的物理环境对团队能够做到何等程度的敏捷有非常大的影响。

5、空间

“设计一个强调协作的团队空间对实现Scrum的工作环境大有好处，并且可以提高团队的

6、凝聚力。”

7、将作战指挥室变到整个空间：对于Scrum团队，一个专门的“作战指挥室”是没有必要的，因为它的整个开放的工作空间就变成了“作战指挥室”。每日站会和其他会议经常在团队空间中的公共部门举行，而不是在某个会议室里。2）公司管理层的支持是有帮助的

8、家具

可移动的桌子、桌面的形状和宽度。让小东西也动起来：电话。每个人坐哪儿：隔墙减少后，每个人都有更好的视野。频繁结对让大家避免整天坐在相同的地方，能从开放空间的某个地方移动到另一个地方（甚至没有可移动的桌子）减少了永久性的感觉。作为团队的保护者，ScrumMaster经常紧挨着团队区域的主要入口处就坐。

9、在工作空间里应该可见的东西：大的、可见的图表，额外的反馈设备，团队里的每个人：都能相互看到，SprintBacklog

产品Backlog,至少一个大白板，一些安静和私有的空间，事物和饮料，一个窗户。

10、项目管理办公室

在三方面的贡献和工作：人员、项目和过程。

11、人员：开发培训课程，提供指导，选择和培训教练员，挑战现有行为。

12、项目：协作报告，协助完成符合性需求，管理新项目的流入。

13、过程：提供和维护工具，协助建立和收集度量，减少浪费，保持团队间适当的一致性，协调团队，使用Scrum的典范，和其他部门协作。

第四部门 下一站

如果你已经完成了95%的旅程，那么你只完成了一半。——日本谚语

第21章 看看进展如何

1、测量的目的

测量的真正目的是为了减少不确定性。成功实施Scrum需要回答以下问题：

1）我们实施Scrum进行的投资值得吗？2）我们下一步应提高什么？3）我们是否应该继续Scrum？4）我们的软件开发是否比一年前做好更好？5）我们是否正在生产更好的产品？6）我们产品中的缺陷是否更少了？7）我们比过去更快了吗？

2、一般性的敏捷评估

我们使用三个一般性方法来研究如何衡量一个团队的敏捷度。

3、撒丹遵守度调查

Bill Krebs 的“撒丹遵守度调查”的做法是15个自我管理的调查问卷，其中涵盖极限编程的各种实践。问卷的答案为从0（“不同意使用此实践”）到10（“对这种做法狂热”）之间的值，以反映15个实践的遵守程度。最后的得分来自综合多位受访者的答案并结合Krebs给定的每个实践做法的重要性的权重。

优缺点：优点：只有15个问题。缺点：它的结果不能直接采取行动，因为某个实践得分低，可能是对此方面问题中包含的某条声明的遵守度较低。

4、Agile:EF

敏捷评价框架（Agile Evaluation Framework）遵循敏捷精神中简化事情的建议，因此它更像是一个评估流程，而不像是一个执行框架。

Agile：EF不提供推荐的问题集，而是推荐使用正在使用的问题集，比如，在撒丹遵守度调查方法所使用的问题可被使用。

优缺点：优点：定期、快递、不唐突的评估可能比一个更长更详细的评估有更快的响应率。缺点：限定为一个框架。

5、比较式敏捷的评估

比较式敏捷评估（Comparative Agility，CA）CA评估需要靠个人问卷调查来执行。CA方法评估7个维度的敏捷程度：团队协作、需求、计划、技术实践、质量、文化和只是创造。

在图21.2所示的三个方面中每一个方面都包括3至6个特征，使用一组问题对团队的每个特征进行打分。例如，计划方面的特征包括：

1）什么时候需要计划2）哪些人参与制定计划3）是否有针对Release和Sprint的计划4）是否重要的可变量（如范围，进度和资源）都被锁定了5）如何跟踪进展。

针对“什么时候需要计划”特征的问题列于表21.2中，从表中可以看出，一个问题的答案包括：真实，比较真实，既不真也不假，比较假，假，不适用。

优缺点：优点：它的目的是为了得到便采取行动的结果。通过看到你的团队和其他团队的比较改善重点可以放在最有希望的重点区域。

缺点：调查的广度。包括近125个关于开发过程的问题。有两个同行的解决方法：1）每年只执行一次或两次全面评估。2）每个月只评估七个维度中的一个。

6、创建你自己的评估

7、Scrum团队平衡计分卡

多维度：1）卓越运作2）面向用户3）商业价值4）未来的方向

8、构建平衡记分卡

9、推崇简单度量

10、我们真的在意这些吗

我们真的应该关心如何收集数据来反应我们是否已经变得敏捷了吗？是的，我们应该做，这有三个主要优点：1）数据可以帮助对抗“企业重力”。2）指标可以帮助我们宣传Scrum的实施工作。3）指标有助于我们知道从哪里重点着手进一步改进工作。

第22章 没有终点