模式六十一 没人在意的交付物
没有人愿意为团队开发的一些项目产物掏腰包。每一项产物都需要对应有愿意付钱的资助人。在这种场景中，付钱意味着不仅仅有权利要求开发某产物，而且也有能力把必要的开发资源拨派给团队。没人在意的交付物并没有清晰一致、经过验证的需求，换句话说，没有资助人。考虑一下每一个没人在意的交付物的价值。如果你发现没有人愿意为之付钱，而且项目也不需要它，那么就不要去开发，否则，找到一个资助人。
模式六十二 隐藏的美
项目的某些产品不是满足于尚可甚至优雅的标准…而是追求至善至美。所有的设计都存在美学元素，问题是，这种美学元素对你是敌是友？任何设计都不可能通过堆叠附加特性或者外在装饰得到改善，恰恰相反，只有减少特性才能改善设计的美学品质。最好的设计都是简洁的、功能明确的、易于测试的，而且即使对其修改，也不会带来新的麻烦，此外，它们让你觉得没有比这更好的方式来实现产品的功能了。
模式六十三 我不知道
组织能营造出能讲真话的氛围，即使讲真话意味着无法立即给予答复。在有些组织里面，“我不知道”被理解成：我现在没有答案，但我最终会给出答案。“我不知道”也能激起团队的协作氛围，鼓励每一个对问题有一定了解的人提供有帮助的信息。我们谈论的不是持续的无知状态，而是公开宣布的待填补的知识缺口。
模式六十四 乌比冈湖儿童
经理给出的绩效排名不能有效区分出执行力的强弱。在绩效管理的早期阶段，经理处于教练的模式：解释，演示，协助，回答问题，尤其是鼓励雇员。等到了评估绩效和提供评定结果的时候，经理必须更多的扮演法官的角色。只有基于实际的平均水平，你才讲出了真正的事实。
模式六十五 互相教学
项目的利害相干人明白每个人都能从其他人那里学到很多东西。在消费者和构建者之间必须互相教学，每一方都必须教导对方，并且向对方学习。如果要让开发项目产生正确的产品和服务，就必须深刻地理解消费者的需求和支撑那些需求的特性。这种理解只有当消费者和开发者各自向对方学习需求的时候才会出现。最难做到的就是意识到同心协力互相教学的必要性。
模式六十六 意气相投
组织允许特殊的团队来简化它们开发流程中的规则，甚至是那些最基本的规则。
模式六十七 十字槽螺丝帽
显而易见的好想法不会很快被接受。更新，更好并不足以保证立刻能被接受，那得一段时间。组织抗拒变化，或者在决策的延长期里面推迟变化。
模式六十八 可预测的创新
创新意味着你的团队将会做一些从来没人做过的事情，而且该投入是否成功依赖于人们是否使用全新的、不同的方法来解决问题。与此同时，老板几乎总是要求你就“什么时候完成”这样的问题，提供比较精准的预测。这等于是让你去预测好的想法何时出现——那可不容易。项目因为创新而不断前进，但它们同样需要可预测性。两者中哪个太多或太少，都可能把团队推向深渊。
模式六十九 玛丽莲·明斯特
在有些组织中，开发人员就是君王，而在有些组织中，他们只是无名小卒。
模式七十 布朗运动
在项目愿景尚不明朗的情况下，团队成员就被添加到项目里面。在愿景变得清晰之前就往项目加人，只会适得其反。当太多的人试图给项目制定计划，结果就会混乱不堪，逻辑不清。无论最后形成的团队规模多大，清晰的愿景只来源于一个人或者一个很小的团体。
模式七十一 大声地、清楚地
大声地、再三地清晰表达项目的目标。项目的目标就是最高级别的需求和约束。这些目标需要在项目早期就声明出来，并且项目中的每个人都需要不断地去审视。目标需要清晰表达、审视和优化，这样才能保证不同的资助人与利害干系人对于项目的期望真正地汇聚在一起。设定目标时每个人都在场，并且在项目的全过程中，每个人始终都能看见这个目标。
模式七十二 安全阀
为了化解工作中的紧张气氛，团队发明了纾解压力的活动，并演化成为团队生活的一部分。最有效且最受欢迎的安全阀来自于团队内部。
模式七十三 巴别塔
项目未能开发出一种开发团队和利害相干人都能理解的通用语言。项目所需要的语言是一种不断演化的语言，真实地反映了所有的团队成员对问题域的理解。
模式七十四 惊喜
提供奖赏和奖励的经理听到了意料之外的回应。死死抓住奖励和奖金模式的组织从来得不到奖励。
模式七十五 冰箱门
团队成员定期把各自的工作成果展现给团队所有的人。虽然没有必要让每个人都知道所有的事情，但团队仍然以高度可视化的形式把重要的信息展现出来。健康的团队在不同的项目角色之间共享以下产物：版本计划，本周或者当前版本的工作安排，燃尽图（剩余时间表），系统的上下文关系图，用例列表，用例和领域类型的交叉结构图。项目产物的公开展示反映出团队成员之间的信任。它传达了一种信号—没有什么会仅仅因为主管原因而隐藏起来。没有人会因为让其他人看到了未完成的事物或者进度延迟而担心。
模式七十六 明天会是晴空万里
经理相信未来的平均进度会超过过去的平均进度。当由于坏运气导致迭代周期的紧凑性甚至可能延期时，请相应的对项目的未来制定计划。
模式七十七 堆积
利害相干人宣称支持项目，然而却一直百般阻挠直到项目失败。项目工作的堆积通常表现为给产品增加无关痛痒的特性，而这些特性的成本收益比尚未可知。虽然看上去富于建设性，但这种行为的隐秘目标是增加死亡的可能性。采用大量迭代的项目团队对于“堆积”并不具有免疫力，但是他们确实拥有天然的和强大的防御工事：在计划每个迭代的排列顺序时，他们强制按照从关键到“堆积”的级别来评估特性，并相应的指定优先级。
模式七十八 变更时节
在项目的整个过程中，范围变更的时机只出现在特定的时刻—通常是开发迭代开始或者结束阶段。你需要尽早地得到准确的范围值，但随后你几乎总是要做出调整。最终，由于想要完成工作，你对于范围变更的容忍耐心消磨殆尽。
模式七十九 造纸厂
项目就是一次旅程，在这个旅程中，人们去理解问题，直至足以得出满足既定约束集的解决方案。而且随着理解越来越深入，方方面面都需要与不同的利害干系人进行沟通，针对这些理解的沟通常常既要使用纸质文档，还要使用电子文档。在造纸厂中，每项活动都是以文档的产出作为标识的。项目的进度也是以产出文档的数量——而不是文档所包含的内容——来衡量的。造纸厂是有害的，因为一旦人们去关注产出文档的质量，他们就会停止思考更为重要的事情：我们是否在从事有助于实现项目目标的工作？
模式八十 离岸荒唐事
领导们被低廉的工人薪资所吸引，启动了离岸开发计划，使得在各个开发地点之间沟通的难度剧增。为了充分发挥离岸开发的潜力，可以尝试这么做：只要可能，就把需要快速迭代的工作的各阶段任务分派给单一地点的团队，无论是近地还是离岸。要认识到最初几次利用离岸开发会比近地开发花费更长的时间，意识到离岸团队与近地团队在大多数方面没有区别，树立各个地点的目标。这些步骤，尤其是最后一个，同样能帮助你避免近地的荒唐事。
模式八十一 作战室
使用专用的作战室，把项目列为重点。作战室表明了一种态度—大量面对面的交流对于项目的成功至关重要。此外，它还强调了积极地展示工作的产物对团队的凝聚与工作的引导尤为重要。最后，它也清楚地展示了利害相干人为了项目成功而大力投资的决心。仅仅声称项目拥有作战室，并且为之留出空间并不能奏效，关键在于如何把作战室变成项目不可或缺的有机组成成分。作战室必须是项目自身选择的一种管理举措。
模式八十二 什么味道
组织中的人们无法察觉隐藏于表面之下的究竟是活力还是衰败。无论你在组织内处于何种位置，你都无法依靠自己判定组织的气味。如果你在多个项目上待过一段时间，你或许就完全有能力为其他的组织作同样的工作（闻项目的气味）。
模式八十三 不从教训中学习
团队认识到自己的错误，却又一次接一次地重蹈覆辙。对于每个人都承认的失败，如果不想办法去改进，去汲取教训，那么，同样的失败会一再发生。
模式八十四 不成熟的想法神圣不可侵犯
团队愿意鼓励、呵护即使看起来不成熟的想法。不成熟的想法是项目生命周期的一部分，团队应该视之为需要保护和培育的东西。即使是最不成熟的想法，只要受到团队的尊重并允许其存在，有时也会转变成有价值的商业产品。
模式八十五 渗漏
时间和金钱往往会从衡量密切的范畴”逃离“到衡量不那么密切的范畴。管理层紧紧地盯着那些差不多到期的任务，因为当分配的时间耗尽的时候，工作就应该完成，没有人会注意其他任务，因为它还远在”明日“之后，这种无恶意把接下来的时间从一项任务转移到另一项任务就叫做渗漏。渗漏可能导致部分（甚至是整体）失去控制。
模式八十六 模板僵尸
项目团队使用模板—而不是对于产品交付所必须的、经过深思熟虑的流程—来驱动自己的工作。
完结~