获取OKR模板 介绍 研究表明对目标做出承诺有助于提高员工绩效。更具体地说，研究显示设置具有挑战性的、具体的目标能进一步加强员工实现目标的参与度。谷歌常常使用“目标和关键结果”(OKRs)来制定令人鼓舞的目标并跟踪进展。 OKRs概述 目标是鼓舞人心的并且可能会让人感到有点不舒服 关键结果是可衡量的，易于用数字记分（谷歌使用0-1.0分的数值范围） OKRs是公开的，这样组织内的每个人都能看到别人在做什么 OKRs分值的 “最佳点”是60% - 70%；如果一个人一直都能完全实现目标，那么他的OKRs就不够鼓舞人心，他需要考虑一个更大的目标 较低的分数应该被视为有助于改进下一个OKRs的数据 OKRs不等于员工评估 OKRs不是一个共享的待办事项清单 实践过程中，应用OKRs和其它目标制定技术有所不同，因为OKRs旨在制定令人鼓舞的目标。使用这种方式时，OKRs可以让团队专注于大赌注，完成比团队认为可能的更多的任务，即使他们没有完全达到既定的目标。OKRs帮助团队和个人走出他们的舒适圈，对工作优先排序，从成功和失败中学习。 学习（删减的）OKRs历史 正如英特尔前首席执行官Andy Grove（安迪格鲁夫）在他的书《高产出管理》(High Output Management)中所解释的那样，要想成功建立像OKRs这样的共享目标体系，需要回答两个问题： 我想去哪？这个答案提供了目标。 如果我要到那里（目标）的话，我该如何调整自己的节奏？这个答案提供了里程碑，或关键结果。 谷歌早期的投资者，现在的董事会成员John Doerr在英特尔时从Andy Grove那里了解了OKRs。Doerr说他加入英特尔时，公司正在从一家存储器公司向一家微处理器公司转型，Grove和管理团队需要一个方法帮助员工专注于一系列优先（重要的）事项，以便顺利转型。OKRs帮助他们沟通优先事项，保持对齐，并实现转变。 几十年后的2000年初，Doerr向谷歌的领导层介绍了OKRs，后者（谷歌的领导层）看到了它（OKRs）的价值，并在接下来的几个季度里开始进行尝试。现在，谷歌制定年度和季度的OKRs，并且在每季度召开全公司会议来分享OKRs以及对OKRs打分。 OKRs的应用远不止于硅谷，而是各种各样的组织都在应用。《财富》100强企业西尔斯控股公司向2万名员工推行了OKRs，看到其对销售业绩和个人业绩产生了积极影响。 OKRs和拉伸目标 谷歌经常会制定一些看似不可能的目标，有时称为“拉伸目标”。制定无法实现的目标是很棘手的，因为这可能被视为组建一个失败的团队。然而，这些目标往往能吸引最优秀的人才，创造最令人兴奋的工作环境。此外，当目标高远时，即使失败了目标也能带来实质性的进步。 关键是清楚地传达拉伸目标的本质以及什么是成功的门槛。谷歌喜欢制定OKRs的成功是达到70%的目标，而完全达到这些目标则被认为是非凡的表现。 这样的拉伸目标是实现长期卓越成就的基石，也是“登月计划”。 将OKRs引入你的组织 OKRs的一个重要部分是透明度。把OKRs引入到一个组织中时，弄清楚它们是什么，为什么会有用，以及将如何使用才会有帮助。研究表明当人们对他们的目标做出承诺时，绩效会更高，因此让所有人都参与进来是很重要的。 介绍OKRs的小贴士： 什么是OKRs？覆盖什么是OKRs以及它们是如何工作的基本知识。 为什么使用OKRs？回顾组织现在制定目标的方式，以及这种方式的限制和问题。 OKRs如何工作？解释时间线，对每个人的期望，主要的里程碑，以及人们将如何负责。 仍对OKRs存疑？留出提问的时间，特别要强调要提出任何的疑问。 一致性。 一旦组织知道了它关注的是什么，如何衡量成功，个人就更容易将他的项目和组织目标关联在一起。 原则&优先级。 对公司里的任何一个人或团队来说，要对一个好的想法，一个有价值的项目或一个必要的改进说“不”是很难的。一旦所有人都对最重要的目标是什么达成一致，对不那么重要的目标说不就简单多了。说“不”不是一场政治或情感上的辩论，而是对整个组织已经做出的承诺的一种理性回应。 沟通。 OKRs应当在组织内部公开，这样每个员工都知道组织目标以及成功的度量标准。一次采访中，前谷歌人、前推特首席执行官Dick Constolo被问到“你从谷歌学到了什么并应用在推特上”时，他这么说： “我在谷歌看到的，确定也应用到推特上的是OKRs-目标和关键结果。OKRs是一种很好的方法，它可以帮助公司里的每个人了解什么是最重要的以及如何衡量什么是最重要的。从本质上讲，OKRs是一种很棒的沟通战略和衡量战略的好方法。这是我们使用OKRs的方法。公司成长的时候，最困难的事情就是沟通。沟通是非常困难的。OKRs是确保每个人都了解你将如何衡量成功和战略的好方法。” 制定目标和设定关键结果 制定目标时，谷歌经常从组织级OKRs开始，用3~5个目标和每个目标的三个关键结果来对齐优先级。成功的OKRs常常是由自上而下和自下而上的建议相结合，这让组织中的每个人都可以表达他们认为值得花时间去做的事情，以及怎样最好地安排他们的时间。 制定目标的小贴士： 只选3~5个目标–过多的目标会导致团队过度扩张（over-extended）和精力分散。 避免使用那些与追求新成就无关的表达，例如“继续招聘”，“保持市场地位”，“持续做X” 使用描绘终点和状态的表达，例如“攀登这座山”，“吃5个派”，“交付特性Y”。 使用有形的、客观的、明确的术语。对于观察者来说，目标是否已经实现应该是显而易见的。研究表明，更具体的目标可以带来更好的表现和更高的目标达成。 设定关键结果的小贴士： 每个目标确定三个关键结果。 关键结果表明可衡量的里程碑，如果实现，将直接推进目标的实现。 关键结果应该描述效果，而不是活动。如果关键结果包含“咨询”、“帮助”、“分析”、“参与”这样的词，那么是在描述活动。相反，要描述这些活动的效果，例如，“在3月7日发布客户服务满意度的水平”，而不是“评估客户服务满意度”。 可衡量的里程碑应该包括完成的依据，这些依据应该是可用的、可信的和易见的（discoverable）。 避免OKR书写错误 设定OKR，即制定明确的目标，和可衡量的、达成一致的结果，能推动团队取得好的成绩并且使组织专注于最重要的优先事项。写得不好的OKRs会产生混乱的策略，破坏内部指标，导致团队专注在维持现状。

Scrum联盟了解你作为Certified ScrumMaster®所面对的障碍壁垒。获得认证是敏捷之旅中的第一步，我们在这里为你提供独家的好处，以帮助你持续进步。让我们与高质量培训、资源、工具以及全球最大的、活跃的Scrum认证社区一起前行。仅在你拥有ScrumAlliance认证后才能使用所有这些好处。 1）专用工具 更新你的认证将授予你 使用各种工具的专有权限。 诸如” Comparative Agility Personal Improvement（PI）”之类的工具仅提供给Scrum Alliance现有的Certified ScrumMaster。通过认证的ScrumMaster可以使用此工具评估其当前的技能水平，找到成长的机会，并通过社区与同行进行讨论。在社区委员会中，你会发现可以直接与认证的敏捷专家联系。你在PI工具中找到的资源将帮助你成长为ScrumMaster，为你提供在团队中取得成功所需的技能以及其他更多的职业机会。该 ScrumMaster的PI工具 -包括社区委员会- 仅适用于当前有效的认证ScrumMaster 。 有效的ScrumMaster认证中包括 赠送订阅”比较敏捷”，价值每年299美元。该工具专注于团队开发，并利用了全球最大的敏捷评估数据库。你将能够快速进行基准测试并收集信息，获取见解并为你的团队和组织采取行动。与其他敏捷组织相比，这将使你能够评估敏捷团队的绩效，从而为整个公司带来持续改进的思想。 2）认证和培训 学习可能是你敏捷旅途中最艰难的部分之一。通过认证，你可以获得行业领先的教练、资源和培训。Scrum联盟认证是敏捷社区中最受认可的一些认证。我们的课程会定期更新，以确保你了解最新的敏捷和Scrum最佳实践。由行业专家培训师主持的课程将使你受到教育和启发。NPS得分这个维度，我们为CSM培训师的平均得分为+81而感到自豪。你可以通过投资敏捷认证来开始成为认证的ScrumProfessional®（CSP）的途径。 通过证明你对敏捷之旅的奉献精神，脱颖而出成为申请人。我们的课程包括访问授权内容、培训、网络研讨会和志愿者机会，这将使你获得Scrum教育单位（SEU）。需要获得SEU来续费你的认证。这很容易帮助你在市场上保持竞争力。当你通过Scrum Alliance认证后，你将加入一个拥有超过一百万名认证会员的社区。你可以放心所学的内容是基于行业中最新的Scrum教育标准。 3）社区和支持 最后，我们了解 社区 是成功学习和分享你在此过程中获得的知识的关键。在32个国家/地区拥有 150多个用户组，你可以与世界各地的敏捷和Scrum从业人员连接。与敏捷社区同步将为你提供可以验证你所做的艰苦工作的经验。有了所获得的知识，你便可以自由地塑造Scrum的未来，改变你的工作世界！通过志愿服务机会，你将可以直接服务于敏捷社区。除了我们的面对面聚会和虚拟聚会外，Scrum Alliance社区还可以帮助你在事业中蒸蒸日上。 访问 中国敏捷社区小组 - 由Scrum 联盟支持 Scrum Alliance是501（C）（6）非营利组织，这意味着你的续费可以帮助推动世界各地的社区和用户群体，包括服务于欠缺的社区。我们的使命是帮助每个想要改善Scrum和敏捷之旅的人。我们正在改变工作世界。立即续费你的认证以支持全球新的Scrum和敏捷社区 。 原文 Scrum联盟英文链接

规模化敏捷大对决 The Scaling Agile Showdown 在底特律一个隐秘的地点，准备下去啦 规模化敏捷大对决。 Alarmin’ Craig (LeSS) vs. Don Leff (SAFe) 哟，是Don Leff，我会让匆忙的人变得脆弱。（猜一猜谁创建了最流行的规模化敏捷框架？） 摇起你的满头白发，就像假发一样。（Craig的技能好像是LeSS的组合水平，根本不存在） Man，你用无意义的愿景过度复杂化了事情。（而我采用清晰的产品定义简化了组织）我有个人魅力，甚至我的对手都知道（SAFe就像你，Leff：庞大、沉重并且缓慢） 我普及了大房间规划，那真的是发自内心的罪过吗？（你应该要感谢我，大公司都开始关心规模化敏捷了！）但是你仅仅把已有的最佳实践很好地打包进一个金字塔计划。（你这不是敏捷，你只是想卖课程赚钱！） 作者评论 非常感谢Dean Leffingwell，Craig Larmann和Jeff Sutherland等人建立了规模化敏捷的框架，因为这使许多大公司（许多非软件开发的公司）都接受了敏捷性原则和价值观。这些思想领袖使企业能够从软件部门开始敏捷实践，从而敏捷也覆盖了跨越多种开发类型的企业级别。 我们必须记住，“规模化敏捷”不是一维问题的解决方案； 在选择SAFe，LeSS，Scrum @ Scale，Nexus，DAD或其他之前，我们必须帮助组织真正地了解为什么要在选择框架之前进行规模化敏捷。理想情况下，本着学习的精神，我们应该启动几个扩展框架的试点，以便在做出选择之前确定最适合我们企业的框架。 并记住先钉下去，再扩展。 译者评论 每一种规模化敏捷框架都有其拥趸，每一种框架都有其用处。（一无是处早就被人放弃了）个人是非常推荐LeSS框架。因为LeSS框架： 足够的简单 完全是基于系统思考，甚至框架本身就是系统思考的因果回路图（CLD）推导出来的。 产品导向，技术实践为重 其他的规模化敏捷框架，有熟悉的朋友也可以来谈一谈。 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接

在家上学 Homeschooling 由于新冠疫情我们都在家，你妈妈和我都同意最好我们在家上学。 我想学习造小汽车。我想知道为什么太阳那么炎热。 很棒的建议，但我们先从一些更好的内容开始…… 今天，你们将学习验收标准（Acceptance Criteria）和完成的定义（Definition of Done）之间的区别。 作者评论 如果敏捷、快速试错、精益创业和PDCA循环等主题背后的思想观念（应该基于现代发展的概念）实际上是孩子们在学校学到的东西，那将会有多棒？ 因此，如果您因COVID-19疫情而被迫在家工作，并可以自由安排自己的时间，那么现在是时候让孩子们学习一些实用的知识了！ 除非他们整天都在远程学习，否则现在您就有机会向年轻人灌输您认为他们应该学习的课程。 因此，抓住机会，告诉他们验收标准（AC）是完成的定义（DoD）的一个子集，或者现场（Gemba）的重要性。 如果您需要，我们甚至可以考虑创建供儿童学习敏捷的材料。 译者评论 家庭教育如何应用敏捷，已经有越来越多的伙伴在进行尝试了。 你有尝试吗？ 这里有一个TED视频讲解敏捷家庭，或许对你有启发。 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接

我要提问 这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是： Scrum Master是否需要懂技术？ Bob的观点 Scrum Master需要懂技术，而且是一定要懂技术。不懂技术的Scrum Master很难成为一名优秀的Scrum Master。如果你想成为敏捷教练，或许不懂技术还行得通，但是Scrum Master不懂技术是不行的。具体还可以参考之前的博客文章，Scrum Master和敏捷教练之间的区别。 原因1： 不懂技术的Scrum Master很难融入团队。 原因2： 不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展。 原因3： 不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍。 不懂技术的Scrum Master很难融入团队 开发团队成员之间沟通的时候，多半会使用技术术语，如代码仓库、技术债、重构、vs code等等。如果听不懂团队说的是什么，就很难了解问题或背景，从而很难融入到团队中去。所以作为Scrum Master，至少需要了解： 常用技术术语 软件开发生命周期 常用的技术工具，等等 不需要Scrum Master成为代码管理的专家、重构专家，但一定要知道这是什么。 不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展 如果一名Scrum Master不懂技术，那么他也很难了解或掌握软件开发行业的最新工程实践（开发实践）。那么作为Scrum Master，如何帮助开发团队认识到当下行业有哪些最新的提高效率的开发工具、工作实践呢。 Scrum Master的关注度不仅仅是团队、产品负责人，还需要关注组织和开发实践。参考Scrum Master和敏捷教练之间的区别中Scrum Master关注度一节。 不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍 最后，如果Scrum Master不懂技术的话，他也很难有技术的感觉，从而很难敏感地发现团队内的潜在技术风险或障碍（不一定是真的风险，但有时候一句话就可以点醒团队）。 综上所述，作为一名Scrum Master一定需要懂技术，而且需要是懂大量的技术（不一定需要很深入）。 职场泥石流的分享 以下来自职场泥石流分享的总结，感谢小新同学（谢晓强）的努力。 之前在群里参与讨论过Scrum master与技术间关系的一些问题，从群友那里得到不少启发，其后有机会能在前两天连线Ethan黄老师，直接就这个问题展开了一些辩论，又聆听了黄老师对一些相关问题的分析与解答，让我对问题的认识又深了一些，这篇文字是对之前视频的回顾总结，加上一些我自己的思考。如果我对于黄老师的观点有引用错误的地方，或者大家认为我的观点有何不对之处，欢迎批评指正。 视频的最开始其实是关于SM懂技术是利大于弊还是弊大于利的一场小型辩论，不过我想先不记录这个，先记录黄老师后面回答的几个问题，然后再回到最开始的这场辩论，这样理解起来可能会更好。 问：没有技术背景的SM感觉无法融入团队怎么办？ 针对这个问题，黄老师首先指出这种情况非常普遍，感到fear也是正常的，他自己也有过这样的经历。面对这种情况： 第一个是要想到每个人的知识面都是有范畴的，要扬长避短，同时你现在不会技术不代表以后不会，这种fear也是你学习的动力； 第二个是要弄明白，这个fear是不是有可能是不必要的，因为在这个行业里或技术里你没有积累，并不妨碍你成为一名好的SM或教练，你可以通过学习掌握软技巧，如有效倾听与强力提问、还有学习的能力，来发挥自己价值，融入团队。 问：技术能力非常强的人，他来做SM会遇到哪些问题？ 针对这个问题，黄老师回答问题在于他可能忍不住涉入到技术问题中去，反而可能忽视了本来的职责。解决的办法就是要管住手管住嘴。但现实中当你越界时你自己往往是没有知觉的，所以就还有一些实践小技巧，比如你们团队间可以协商出某种方式来提醒你越界的事，如订做一顶大牛帽子，只有当你带上这顶帽子时才能扮演技术专家的角色，如果你不自觉的扮演了技术专家的角色的话，就要予以一些处罚，比如请喝咖啡等等。 总结一下，就是你作为一名SM，如果你很懂技术，你不是不能涉入到技术中去，只是你要有一种边界感，知道什么时候你是在扮演技术专家的角色，什么时候又该回到SM的角色。 记录完这两个问题黄老师的回答后，我想可以回到最开始的小辩论上来了。 “Scrum Master懂技术是利大于弊还是弊大于利” 虽然黄老师是站的正方，但我觉得黄老师其实心里还是向着反方的，哈哈。言归正传，如果做个比喻，我认为这个辩题，其实是类似于贝壳的东西，贝壳本身并不珍贵，珍贵的是贝壳辛苦酝酿出的珍珠，而辩题酝酿出的珍珠，其实就是它延伸出的一系列问题。

作者：曹天宇 Scrum指南读后感 本人从事传统汽车行业，敏捷经验或scrum经验为0，甚至没有软件开发经验，参加本次培训目的是对敏捷开发有个入门的了解，并结合传统汽车行业的开发流程做一定的思考，因为现在汽车上也会涉及到越来越多的软件。 以下是看完Scrum指南后自己归纳的重点（理解还是更多基于理论层面）： Scrum是一个框架 ，用于开发 交付 持续支持复杂产品的，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。 Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成 Scrum的应用：最初是为了管理和开发产品而开发的 Scrum 的精髓在于小团队 Scrum 基于经验过程控制理论 Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险 三大支柱：透明，检视，适应 4个正式事件： Sprint计划会议 每日Scrum站会 Sprint评审会议(review) Sprint回顾会议(retrospective) Scrum价值观：承诺commitment，勇气courage，专注focus，开放openness，尊重respect Scrum团队：产品负责人 + Scrum master + 开发团队， 跨职能的自组织团队 产品负责人：将开发团队开发的产品价值最大化，产品负责人是负责管理产品待办列表的唯一负责人 产品待办列表的管理包括： 清晰地表述产品待办列表项 对产品待办列表项进行排序，使其最好地实现目标和使命 优化开发团队所执行工作的价值 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作 确保开发团队对产品待办列表项有足够深的了解。 为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定 开发团队：负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。开发团队由组织组建并得到授权，团队自己组织和管理他们的工作， 规模3-9人 特点： 自组织的 跨职能的 不认可开发团队成员的任何头衔，他们都叫开发人员 不认可开发团队中所谓的“子团队“ 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队 Scrum Master: 负责根据 Scrum 指南中的定义来促进和支持 Scrum， 服务型领导 服务于产品负责人： 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域； 找到有效管理产品待办列表的技巧； 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项； 理解在经验主义的环境中的产品规划； 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值； 理解并实践敏捷性 按要求或需要引导 Scrum 事件。 服务于开发团队：

我要提问 这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是： 什么是Scrum Master，什么是敏捷教练，他们之间有什么差别？ 如何转型成为敏捷教练？ 本文将重点描述敏捷教练和 Scrum Master 这两个角色，以及他们之间的关系和对比。 Scrum Master Scrum Master 是一个全新的角色，是在《Scrum指南》中定义的。这个角色（Scrum Master）不是团队领导者，也不是项目经理，更不是经理。请不要把 Scrum Master 与现有的团队（或组织中）的角色进行映射。因为你找不到这种映射。 Scrum Master 在组织中教 Scrum，并可以帮助团队进行 Scrum 落地实践。Scrum Master，顾名思义，精通 Scrum， 对于 Scrum 有深刻理解，能够指导团队成员更好地产出更高价值的产品。 Scrum Master 是反馈环中重要的角色（另外一个反馈环是 Scrum 中的事件），他是一个支持角色，更像是团队的一面镜子，帮助团队识别出现在的问题，从而能够走向“完美”的目标。 想要对 Scrum Master 这个角色有更加深入的学习，可以看一下我讲的 Certified Scrum Master (CSM) 课程，这个课程是 Scrum 联盟的认证课程，可以为你的职业带来突破。 Scrum Master 角色的描述 – 以下摘自《Scrum指南》 什么是Scrum Master Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。 Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

敏捷中的模式与反模式 本文的内容来自于7月10日我在“艾威网校”的一次分享。 开始先简单自我介绍如下：（欢迎扫码获取ppt） 本文主要分为四个部分： 什么是模式语言及反模式语言 敏捷中的模式语言（Scrum Patterns） 敏捷中的反模式语言 回归本质 什么是模式语言和反模式语言 模式（英语：Pattern，源自法语：patron），在物体或事件上，产生的一种规律变化与自我重复的样式之过程。 在模式之中，某些固定的元素不断以可预测的方式周期性重现。最基本而常见的模式，称为密铺，具备重复性以及周期性两大特征。找寻出固定模式是人类基本的认知功能之一。 – 摘自维基百科 在1977年的《A Pattern Language》一书中，Christopher Alexander提出了模式语言的概念。在豆瓣中的图书介绍如下： 克里斯托弗·亚力山大是美国杰出的建筑理论家。由他领衔撰写的《建筑模式语言》一出版就受到建筑界的广泛重视和高度赞誉，并对建筑业产生了深远的影响。 《建筑模式语言》别出心裁且有根有据地描述了城镇、邻里、住宅、花园和房间等共253个模式，提供了一幅幅设计、规划、施工等方面的崭新蓝图，构思新奇，妙想迭出，不同流俗。 作者写道：“我们深信无疑，本语言要比一本手册、或一位教师、或另一种可能的模式语言略胜一筹。这里的许多模式看来在今天和以后的500年间将成为人性的一部分，成为富有人情味的行动的一部分。”诚如美国《建筑设计》一则评论所说：这也许是20世纪出版的关于建筑设计的最重要的一本书了。 这本书的生命力在于“以人为本”。它是此书的主题思想，像一条鲜艳的红线贯穿始终。各模式的字里行间洋溢着浓浓的人情味和对人的无微不至的关爱，如保护生态环境，如何绿化美化城镇和住宅，反对建筑风格的千篇一律，鼓励人际交往，强调人、社会和自然环境三者的和谐统一，等等。 所以不论是在敏捷转型中，还是软件开发中，亦或是建筑行业或我们身边，都会存在着许许多多的模式。而本文就是要和大家一起来探索一些敏捷转型中的模式（以及反模式）。其中的一些模式摘自于《A Scrum Book》一书，书中提供了94中Scrum的模式，下面我会结合实际工作经验介绍其中的4种。 反模式 反模式（anti-pattern）也是一种模式，最早是在软件工程中提出的，反模式指的是在实践中经常出现但又低效或是有待优化的设计模式，是用来解决问题的带有共同性的不良方法。按照《反模式》一书的作者的说法，可以用至少两个关键因素来把反模式和不良习惯、错误的实践或糟糕的想法区分开来： 行动、过程和结构中的一些重复出现的乍一看是有益的，但最终得不偿失的模式 在实践中证明且可重复的清晰记录的重构方案 – 演绎自维基百科 敏捷中的模式语言 下文主要描述四种敏捷中的模式语言：（分为两类 - 产品组织和价值流） 回顾会（产品组织） 小吃神社（产品组织） 障碍清单（价值流） Scrum板（价值流） 回顾会 回顾会是敏捷中至关重要的一个会议（也是敏捷的本质，在最后的总结中我会再次提出这个重点）。如下图，如果忙于交付而忽视了改进，则从长期来看一定是得不偿失。 对于团队而言，回顾会就是每个迭代结束前团队在一起反思团队中关于人、关系、过程和工具的情况，根据上述情况制定具体的改进计划。上图中采用的方法是： Start, Stop, Continue 开始尝试新的方法 停止无效或低效的方法（或工具） 继续使用良好的工具（或方法） 另外对于个人而言，也是需要不断的回顾总结与反思。这里是我个人的每周总结。 小吃神社 团队都很难独立存在的（尤其在大公司中），于是日常工作中团队（或团队成员）总是会受到不同人的干扰与打断。被打断后要再重新开始刚才的工作就需要思路能接上，这是一个很难的事情。所以对于团队需要有一个缓冲地带，就是下图中的“小吃神社”。（这个名字来自于日语） 注：小吃神社不是茶水间，这个区域离团队很近，但不至于影响到团队的其他人工作。 这个缓冲地带对于团队来讲非常重要，任何问题都不要直接去打断团队的节奏（除非是生产系统挂了）。而是大家可以在小吃神社这里进行讨论。这个模式的前提是，团队太容易也太频繁被打断了。 障碍清单 工作中每个人都会碰到不同的问题、障碍。敏捷中经常也会提倡在每日站会上提出遇到的问题障碍。然而仅仅提出并不是很好的做法，更好的做法是可以创建一个障碍清单，用于收集并排序团队中的障碍。 这个模式的好处是： 可视化团队所有的障碍问题 排序（根据风险评估）后，根据顺序来一次解决障碍 每个障碍可以注明跟进人 Scrum板 Scrum板如下图，是一个白板，用于可视化团队在迭代内的进度。团队每日站会就围在Scrum板的前面，每个人回答三个问题。