一文搞懂Scrum Pattern︱敏捷软件开发

一文搞懂Scrum Pattern︱敏捷软件开发

　　软件启动器,刷cf点软件,思维脑图软件Scrum团队正在组织其开发工作，并正在选择团队成员，或正在评估如何使团队的技能获得成长。

　　Scrum团队如果不能自主工作，就是因为它不具备完成复杂任务网络所需的所有技能。如果依赖团队外部人员的技能，团队就不能真正“拥有”手头的工作。这样团队对工作的完成时间就没那么有掌控力了，并且最终工作的质量也会受到影响。一致性（Consistency）和减少返工（Reduced Rework）这两项核心精益原则依赖于短的反馈回路。大多数复杂的开发工作都需要有来自不同领域（如人类工程学、工程卓越和质量保证等）的众多人才。很少有人能在一个团队中找到所有这些人才，更不用说在任何一个人身上找到所有这些技能。团队通常围绕着能力领域进行组织，正所谓物以类聚，人以群分。这有时被称为职能型组织（Functional Organization）。然而，跨越团队边界协调这些职能的成本很高，因为只有在那些共享当前工作背景的人之间才能存在有效沟通 -- 这通常只有同一个团队的成员才能做到。

　　一个复杂的产品可能需要团队掌握许多技能才能“完成”（Scrum Pattern之一，将在单独的文章中介绍）各项功能。如果需要为每项所需的技能都分别增加一个人，那么团队就会变得过于庞大而无法有效工作。要解决这个问题，通常会有两种选择：你可能会倾向于不扩大团队的技能组合，而是引入外部依赖；你还可能会选择把工作交给团队，让他们去发展和学习所需的技能。但学习是需要时间的。

　　局部学习可以导致局部优化，也就是说专家会发展出优化他们工作的实践和流程。专业化（Specialization）、局部实践（Local Practices）和流程（Processes）都可以成为一个组织的效率来源，但也会在团队的边界处产生问题。为了解决这些问题，这个组织可以定义 合同，说明如何与对方合作（例如，服务请求）。这样的合同可以规定这个组织愿意做什么性质的工作，以及对请求的预期响应时间。任何需要该团队专业技能的人都必须使用这些合同与他们打交道。然而，这可能会减缓整个产品的开发，即使它提高了局部部门的效率。同时，可能需要在组织内设立额外的协调小组来管理这些边界合同、协商例外情况或确保所有各方了解所需的内容，并确保每个团队根据这些合同的义务，履行对其他团队以及对客户的义务。

　　新产品或现有产品的新版本，目的都是要为客户创造一个新世界。因为你无法事先知道这个新世界会是什么样子，所以你必须在产品开发过程中专注于学习和试验。团队必须从客户使用产品的经验中吸取教训，而不是单纯按预先安排的计划行事。而且，团队必须在整个产品开发过程中整合这些经验。每个人都认识到在流程的某一步骤或某一职能领域内作为个体工作所带来的局部流动、自主和控制的优势。然而，这样的工作结构使每个人（除了做最后一步的人）离最终用户更远，从而失去与最终用户进行互动才能获得的广泛洞察力。（从全局考虑问题）可能导致局部职能未必达到最优，但整个产品开发流程的优化程度会更高。

　　在团队创建初期，关注技能的覆盖度是很好的，但更重要的是，团队成员要对愿景有共同的热情，并愿意学习新鲜事物。因为事情会随着时间的推移而变化，团队不可能从一开始就预见到所有的长期技能需求。

　　与其因为需要新的技能就去更换团队成员，不如在内部培养人才，并努力建立小而稳定的团队。随着时间的推移，对团队成员进行交叉培训，使他们的技能组合不断增长，以适应越来越多的能力领域（详见后续推出的Moderate Truck Number模式）。这将提高团队作为一个自主团队工作的能力。有了跨职能的团队，就更容易均匀分配工作（Scrum Pattern之一，将在单独的文章中介绍）。

　　团队成员现在有太多的机会去学习次级技能。比如他们可以在产品待办事项（PBI）上使用蜂拥模式，这样就可以增加学习的机会，优化流动，有助于功能快速达到“完成”的状态。次级技能的发展使团队更加灵活，因此如果有人不在，其他任何人都可以顶上来。这样团队总是可以取得进展，并且是自主的。

　　Scrum对如何处理能力缺失的问题没有提及，它相信这些都是常识可以搞定的 ：例如，向其他团队寻求帮助，或把大的工作外包出去，不过外包出去的工作结果就不好说了，有可能会让团队大吃一惊。如果团队偶尔需要这样的帮助，还是可以理解的。但如果团队发现他们经常要依赖外部的帮助，那么他们就应该把这看作是一种阻碍，并采取措施（如培训、重组或招聘）来补救这种情况。

　　例如，一个由软件程序员组成的团队可能会发现自己正在构建一个不属于自己专业领域的产品，如制药或航空航天。我们很想在团队中为每个弱势能力指定一个负责人，也许可以咨询外部领域专家。然而，团队代表可能不知道他们有多少不知道的东西，甚至可能不知道该向领域专家提出什么问题；反过来，大多数领域专家把领域专业知识当做隐性知识（译者注：已经成为专家潜意识的一部分），所以他们可能也没有办法意识到软件人员真正想要的洞见是什么（译者注：因为专家不会注意到他们觉得理所当然的事情，即隐性知识）。至关重要的是，团队成员要理解领域因素对实施的影响，并对业务和解决方案的空间都有全面的了解。在最近的一篇文章中，亚马逊的Jesse Watson指出，这两个因素在一个头骨内并存是至关重要的。[1] 最好是将专家带入团队，并通过交叉培训扩大知识面。但要记住保持小团队：向团队中增加专家可能会使团队合作减弱到几乎没有的地步。

　　这些团队自然会像 特性团队（Feature Team）（详见后续推出的康威定律模式）那样工作，因为大多数PBI都是以特性的形式存在的（Feature-Shaped）：产生收入的功能性产品增量中的可销售元素（marketable elements of revenue-generating functional product increment）。如果由跨职能团队来开发产品，那么交接动作自然会从价值流中消失：团队本身就可以开发任何特性，无需外部支持或干预。让多个团队参与进来，会造成反馈回路的延迟，增加返工的浪费（Muda），并在价值流的不同开发阶段之间产生不一致（Mura）。

　　《哈佛商业评论》（Harvard Business Review）发表了一项关于两家公司的研究，其中一家是按职能组织的，另一家是按产品组织的。研究表明，相比之下，跨职能团队交付特性的效果是最好的（见《组织选择：产品v.s.职能》[2] ）。

　　基于集合的设计（Set-Based Design，Scrum Pattern之一，将在单独的文章中介绍）是一种技术，它可以让开发人员参与到许多可能与业务相关的学科和领域中，即使这些学科和领域最终可能没有用在当前产品中。这种实践拓宽了团队和企业的专业知识基础，并且也让团队不会惊讶于需要掌握某些新学科。

　　随着团队整合新的经验，他们会对产品有新的想法。变化将会非常迅速（而且必须允许它迅速）。变化将是常态，而不是例外。这需要小规模的组织，因为在小规模的组织中，每个人都知道正在发生什么：这些组织能够拥抱变化、跨专业工作、定期交付价值，用一个词来形容就是：敏捷。

　　组建几个小团队，在游戏中竞争制作和飞行纸飞机。每个团队成员一次只能做一个折叠动作，然后必须换到另一个飞机上。任何飞机都不得有超过15个折痕。它必须至少有15厘米长，8厘米宽。它必须有一个至少2厘米宽的钝头。要成为优质产品，测试员测试时，飞机必须水平飞行3米。测试员对每架飞机只能测试一次。

　　试试这个游戏，并应用Scrum Pattern（提示：蜂拥模式）来优化在一分钟长的Sprint中生产的优质飞机的数量。

　　你已经为Sprint做好了准备，现在你正在开Sprint计划会，进行迭代计划。

　　Sprint的目标是为利益相关者交付价值。然而，简单地按照一个SBI（Sprint Backlog Item，Sprint待办事项；例如：任务）清单来做，不一定就能创造出最大的价值。如果团队按照单个任务或交付物来制定工作计划，就很容易在生产阶段（Production Episode，Scrum Pattern之一，将在单独的文章中介绍）选择单个待办事项，孤立地进行工作。如果这样的话，创新就被稀释了，因为创新是由对工作持有不同视角的个体进行互动而产生的。当工作孤立进行时，就像无形的办公隔间，可能会阻碍大家持续交流各种见解（这些见解不仅对一个开发人员，而且对许多开发人员甚至对整个团队来说都很重要）。没有充分的互动和沟通，团队合作就会受到影响。

　　团队可能需要部分重新规划正在进行的Sprint，以确保团队在Sprint结束时可以向利益相关者交付价值。随着时间的推移，团队会对工作有新的见解，可能会识别出新的工作，这时团队应该对计划做出相应调整。如果团队还是按照原来的计划行事，可能就无法创造出最大的价值。还有一种常见的情况是，在Sprint中途，团队感觉明显无法完成Sprint Backlog中的每个SBI，这通常是由于完成SBI所需的工作比预想的要多。此时团队仍然希望尽一切所能交付价值，这可能就需要通过重新规划来实现。重新规划Sprint的工作需要深思熟虑，并且需要时间。

　　另一种情况是，团队需要关于“如何实现一个PBI（Product Backlog Item，产品待办事项）”的重要技术知识，以便之后能够更有信心地开发它。比如开发人员（甚至是产品负责人）可能需要一个技术原型来验证一个建议的架构，或者了解一些技术的性能特点。这样的工作我们也把它做成一个PBI，不过这一类PBI的目标是帮助团队获取更多的知识，而不是完成一项功能。这样的技术原型是一种探索性的工作，耗时存在不确定性，因此它往往会处于Sprint成功的关键路径上，即它的完成与否关系到Sprint目标是否能够达成。（译者注：这样的PBI，我们称之为Spike，即探针。）

　　在某些情况下，最大的价值可能不是简单地实现一个PBI。例如，对团队来说，最大的价值是增加每个Sprint所能带来的经济收入，而团队只是用一个PBI来实现这个价值。另一方面，有时Sprint的大部分价值主要来自于很多PBI中的一个关键PBI。

　　因此：Scrum团队为Sprint期间所要创造的价值书写了