敏捷公开课 如果下面的课程计划中没有找到合适的时间和地点，还可以填写表格（表达课程兴趣，足够的人数即可单独联络开课）
CSM 课程计划 成都 2020年10月31日 - 11月01日 | 我要报名 线上 2020年11月07日 - 11月08日 线上 2020年11月14日 - 11月15日 | 我要报名 深圳 2020年12月05日 - 12月06日 | 我要报名 CSPO 课程计划 敏捷教练训练营 上海 2020年12月17日 - 12月20日 课程介绍 CSM课程 敏捷教练训练营
为什么要办敏捷教练训练营 自从2016年我开始讲CSM课程以来，总会有学员问拿到CSM证书以后可以做什么，后面如何晋级？
其实证书本身有什么用呢，这个是值得打个问号的。
虽然证书不代表任何内容，证书也不一定有用。但是获得证书的过程，以及共同学习的同学这是一笔很好的回报。
在获得证书的过程中，可以了解到自己的知识有哪些欠缺的地方，可以梳理出知识结构，还可以学习到正宗的Scrum知识。
不论你是否持有CSM证书、PMI-ACP证书或者其他敏捷证书，是否有想过下一步该往哪里去呢？
敏捷教练训练营就是为了给这样的实践者，提供一个晋级的可能性，晋级的可能方向。
在今年（2020）早些时候，我找到Lucy和Lance两位大神，协商我们是否可以一起开发一个课程。目的是为了提高敏捷教练的能力，从而可以让他们能更好的服务于组织和公司。（最初的目的是为了现有的CSP服务，实际上我们不想限制于这个群体，只要是有经验的敏捷教练，都欢迎来参加。）
欢迎各位CSM,CSPO,CSP,PMI-ACP,DOP等等证书持有者，也欢迎各位实践者参与到我们的训练营中来。
敏捷教练训练营包含什么 这个训练营中包含什么内容？
以自我认知和自我成长为基础，重点提升讲授（Teaching）、辅导（Mentoring）、教练（Coaching）、引导（Facilitating）能力。
我要报名 想要了解更多信息
作者：辛光烁
在艾威的课程班报名了scrum master的培训课程后，我花了一段时间认真的重新将老师的网络课程以及scrum指南回顾学习了一次，以下是我对scrum master的一些感受。
我个人是从事传统汽车行业的，对于传统的汽车开发/甚至是传统的汽车软件开发模式，一般遵循的是瀑布模型，从分析，设计，开发，测试，所有阶段是分开的，当我们结束分析后再去进行设计，设计做好后在做开发，等等。这种模式属于传统和经典模式，在汽车行业中至今仍然在使用。一些车载软件的娱乐系统更新换代的周期在几年以上，在长周期背景下，将每一步做好也可以节省成本。
但是在软件开发中我意识到，如果开发软件的同时也有大量的需求的更改，那么存在两周情况，意识退回去重做，造成延误，二是不能响应市场的需求，这两者在基于互联网开发的背景下是致命缺陷。版本迭代周期过长，没有办法满足用户需求上的变化。于是我想学习一下敏捷开发是如何解决问题的。
通过学习，我自己的认识是，在敏捷中为了解决需求的变化，可以将分析，设计，开发和测试通过不同用户故事的条件下组成不同的开发周期，组成不同的条目，如果要增加需求，那么只需要增加相应的用户条目，由PO进行确认并排序优先级，或者相反的删除需求，对于整体项目的损耗就降低了很多。同时在开发的同时，也有机会对趋势重新进行分析，这样开发的产品永远都可以跟上市场的节奏，可以实现敏捷开发。
在多种敏捷开发的模式中，Scrum是一种敏捷开发的方式，它的特点是：灵活性、适应需求变化、更适合团队比较小的情况、每一个迭代均有产出、容易学习。 对于scrum的使用流程，在每一个Scrum开始的时候，需要进行sprint计划会，确定这个Sprint要做的事产品待办列表，随后大家开始执行。在每天开始时，进行每日站会。在这一个周期结束的时候，一般是2-4周后，开sprint审查会议，审查会议之后要开一个回顾会议.以上步骤完成后，再开始下一次的Sprint。
对于scrum中的角色分类，核心团队包括产品负责人、Scrum教练和开发团队。猪队中，最重要的角色就是产品负责人，因为这个项目失败的话，他和开发团队是需要承担责任的。Scrum教练不对项目里面的任何细节负责，他只对这个团队是否合理的使用Scrum负责。
对于scrum的框架，包括产品待办列表，要不断的把已知的所有需求记录到这里面来，sprint计划会是对这个Sprint进行规划的会议。它的主要的目标就是从产品待办列表里面选择一些任务，放到Sprint待办列表中。Daily Scrum是一个用于同步进度的会议。会议形式是每日站会来进行昨天做事情，今天做的事情以及遇到挑战的总结。Sprint审查会是一个用于Sprint总结的会议。会议形式会演示产品增量，目的是把之前做的Sprint新功能给大家进行演示。Sprint 回顾会是一个用于Sprint回顾的会议。会议目的是回顾组内成员在项目开发过程中做的怎么样。
但同时，在使用scrum的过程中也需要一些注意的方面，包括Scrum绝对不能代替传统软件开发方法，Scrum适合十人左右的团队，Scrum的一个Sprint时间为2周–4周，Scrum需要一个强有力的团队等等。虽然scrum可以实现敏捷开发，但针对传统汽车行业的项目也要确定是否团队适合Scrum应用，外界的需求变化是否会很多多，这是决定使用Scrum的出发点。如果决定了使用scrum，在确定团队，相应的scrum master，找到合适的工具，比如每日看板。
欢迎报名我的线上课程 - Scrum敏捷精髓
超越指责（Beyond Blaming） ©1996年 Jean McLendon 和 Gerald M.Weinberg ，www.satir.org和www.geraldmweinberg.com
英格兰虽然目前处于非常繁荣的状态，但仍表现出民族衰败的一些症状。向英国人提出任何原则或任何手段，无论多么令人钦佩，您都会发现，英国人的全部努力都是针对于发现困难，缺陷或不可能的地方。如果您对他说剥土豆的机器，他会说这是不可能的。如果在他眼前将马铃薯剥皮，他会宣布马铃薯无用，因为它不会切成菠萝。将相同的原理或同一台机器展示给美国人或我们的一个殖民者，您会发现他的脑海全是在寻找该原理的一些新应用，以及对该仪器的一些新用途。” – 查尔斯-巴贝奇（Charles Babbage），1852年
早在1852年，查尔斯-巴贝奇（Charles Babbage）就能看到衰败的症状，并从中推断出未来的表现。通过这样做，他完美地描述了指责的沟通风格，这种风格出现在”衰败”的组织中，无论是国家还是软件工程组织。什么是”指责的沟通方式”？为什么在系统开发中如此重要？【指责的沟通方式，也严重影响着家庭关系】
什么是一致性？ 一致性是一个概念，它描述了内部和外部之间协调一致的人类体验 – 思想和感觉（内部），所说的话及如何说（外部）。
为了在世界上实现一致性的运作，您需要考虑三个普遍因素：自我（内部世界），他人（直接外部世界）和上下文（事物、结构、过程、法律和文化，更大的外部世界）。
自我：您必须考虑自己的需求和能力。假设您是一位不信任任何人的判断的经理，因此您尝试参加每次技术会议。这样做可能会使您的所有可用时间都超负荷，从而无法执行管理工作，或者在任何情况下都无法做出真正的技术贡献。（或者如果你是一位不信任儿子的父母，每次和儿子沟通的时候都是持有怀疑否定的心态，那么沟通就会非常吃力。） 他人：您必须考虑其他人的需求和能力。例如，如果您是一位程序员，编写可读代码的时候拒绝打扰，那么对代码的测试和维护将是一个巨大的负担，因为这是不可能。 上下文： 您必须考虑操作环境的实际情况。 例如，如果您是一位经理，坚持使用不再具有处理任务能力的旧设计，那么不管每个人的工作多么辛苦，您的项目都可能注定要失败。 或者，如果您是一家初创公司的经理，并且花了很多钱，好像该公司拥有10亿美元的现金余额，那么您的组织可能在软件产品投入市场之前就已经倒闭了。 一致性是最基本的诚信，因此对项目及其中的每个人都具有巨大的价值。没有诚信，我们就无法建立信任。没有信任，我们不会感到安全；没有安全，我们很难做到一致性。因此，一致性可以在一个强大的增强回路中强化一致性，从而提高按时、在预算范围内构建高质量产品的机会。
相反地，同一循环会导致不一致，从而加剧不一致。如果一个项目被允许走下坡路，信息的完整性（integrity）就会被破坏。很快，人们都不可能知道真正发生了什么。这样的项目总是失败的，而当它们失败时，总是发现它们保存着两套”书”（这里的“书”指的是信息）。他们的外部形象与他们的内部形象不一致，所以项目死了。更糟糕的是，可能永远活着 – 活死人（the living dead）。
如果一致性对于项目成功是如此重要，那么为什么不是所有项目都一致呢？原因之一是一致性是有代价的。另一个是，一致性通常会带来风险。风险的水平在某种程度上取决于所显示的一致性程度（心理或情感）。
精神上的一致 在美国，相对容易地表达我们的思想而无需过多地承担责任 – 言论自由是该国赖以建立的基础。即使这样，”大声说出来”也可能要付出代价。例如，与同事或当权者在错误的时间发生分歧，可以使我们迅速走上隔离、谴责、减少机会和微妙的关门之路。因此，我们都知道了对在哪里和对谁说的话要小心的重要性。说错话会引起激烈的辩论，然后是关于谁对谁错以及谁好谁坏的声明。到那时，我们已经基本失去了增进理解和有效沟通的可能性。
情感上的一致性 在我们的文化中，情感主要用于体育赛事、庆祝活动、葬礼、临近死亡的经历，深刻感受的精神体验主要体现于战斗以及与亲密的他人之间的交流（可能是小孩或老人）。我们甚至对自己的感觉也会有很多感觉（感觉的感觉），其中最强烈的感觉与羞辱和尴尬有关。感觉是个人的，并且贴近我们的内心，在那里我们温柔而脆弱。难怪我们所有人都变得如此娴熟地否认自己的感情，这必然使我们不一致。
假设您是一个开发人员，害怕您无法兑现承诺，从而无法交付产品。您试图告诉您的经理您的恐惧，但是他毫不犹豫地告诉您，如果您不表现出更多的信心会怎样。”你为什么这么消极？你不是团队的一员吗？” 保护自己免受此类负面反应的一种方法是生活在自己的头脑中。也许您会说：”这只是一个估算；我不同意它，”这意味着您不会受到伤害，因为您已经与自己保持足够的距离，可以抵御可能暗示拒绝的任何事物。但是，尽管您否认对经理的恐惧感，但还是感觉到了，被压扁了。您可以背弃自己的想法，但始终保持自己的立场。而且，当然您一直是不一致的。
当您分享自己的感受时，您的内心被暴露在外在世界中 – 暴露在其他元素中。当您害怕并表达恐惧，同时又要考虑他人（您的经理）和上下文（项目）时，您就变得与众不同。您在这里遇到的关键问题是：”我可以分享自己的想法并且仍然可以控制吗？” 如果您的项目环境受到指责，那么如果您说实话，就有可能取消您的控制权 – 因此，对您的想法撒谎的诱惑会增加。这就是为什么责怪文化会导致”双重后果”，也就是导致失败的原因。
什么是指责？ 在一致性的组织中，您的经理问：”您的项目进展怎么样？” 您会回答：”恐怕我不会按时完成了。” 这开始了一个解决问题的讨论，你们两个都在其中制定了新的计划，以使项目重回正轨。但是，在指责的组织中，您的经理可能会告诉您，只有劣等人缺乏信心。在这种情况下，解决问题将被避免指责所取代。
从作者的角度来看，一致性的交互作用不是很大。人们只是明智地采取行动，互相体贴，完成工作并享受所做的事情。这种行为可能不如肥皂剧一般的场面，您的经理发脾气而你在角落里哭泣，但这绝对是一个好的项目。
并不是说指责文化会以一种戏剧性的，指责的方式进行每一次互动。在通常情况下，应遵循一致性的应对方法，但如果情况总是很普遍，我们就不需要管理人员。当自尊心低落时，它们会以更加明显的、不协调的典型应对方式表现出来：指责，安抚，过分合理的爱或恨，无所作为。我们不能在简短的文章中解决所有这些问题，因此让我们讨论指责，也许是应对方式中最常见、最直接的破坏方式。
在压力下，人们往往会失去平衡，这三个基本要素可能会被忽略，从而导致一种典型的不一致的应对方式。例如，当人们不考虑他人时，他们就会陷入指责状态。这是您在软件组织中可能会看到的典型的指责行为（斜体字会以这种说话方式强调 – 因为句子中的多个强调字是指责的语言符号）：
经理，因为程序员迟到了一次会议：”您*总是*迟到。您*永远不会*对*他人*表示*任何*考虑。”
为什么这不一致呢？如果经理真的感觉到并认为程序员总是迟到并且不考虑周到，那么她是否就这么同意呢？是的，但这不是这位经理所说的。她没有说：”给我的印象是你总是迟到我的会议。” 取而代之的是，她把迟到的感觉说成是科学事实，从不提供程序员可能会有不同印象的可能性。她在会议中总结了经验，就好像这些经验必定适用于所有会议一样，从来没有考虑过她的经验可能不是唯一重要的经验。
如果经理真的感觉到并认为程序员总是迟到并且考虑不周全，她可能会说：”我认为您总是迟到，而且我觉得您没有考虑过我和其他人。这也是你的看法吗？” （并省略强调的单词。）甚至更好的管理风格是使程序员有机会在进行解释之前提供不同的看法。至少，这可以防止在以下情况下的尴尬：
经理，因为程序员迟到了一次会议：”在我看来，您总是很晚。这也是你的看法吗？”
程序员：”是的，我对此感到难过。我总是迟到的原因是，我必须为死于白血病的9岁儿子献血，而他们唯一的一次捐赠就是在这次会议之前。”
经理：”对你儿子感到抱歉。我不知道 让我们找出一个新的会议时间表，这样您就不必迟到了。”
更笼统地说，它考虑到除了该经理之外，还有其他考虑因素。例如，程序员可能有来自与客户的会议，即与经理会议重叠的定期安排的会议。
但是，如果程序员真的总是迟到而又没有合理的解释怎么办？经理不是有权指责程序员吗？并非如此，因为这种情况与权利无关，而与完成项目有关。为此，使用非指责的对抗与不可接受行为有关的事实，可以最有效地解决该问题。通过前述的指责，管理者使沟通保持清晰和开放，从而最大程度地提高了程序员接收预期消息的机会。而且，收到预期的消息会最大程度地解决问题（尽管不能保证）。
团队的问题 团队进展得怎么样？ 实际上并不太好；团队遇到了不少问题。比如…… 比如冲刺计划（sprint planning）之前梳理工作；冲刺评审（sprint review）的时候获得有用的客户反馈；团队都同意一个有意义的DoD（完成的定义）【这些问题的原因是什么呢？】 因为现在是新冠疫情，我们都是在远程工作…… 作者评论 不要认为你的团队目前像世界上大多数人一样远程办公为借口，认为保持团队合作是平淡无奇的。在这种没人能见面的时代，保持并进一步发展敏捷团队的团队精神比以往任何时候都更为重要。有了合适的在线工具，例如Miro，Zoom，Slack，Teams，Skype或其他工具，这变得可能了。但是，拥有正确的在线工具仅是答案的一半。练习“远程的团结”是另一半。
实现此目的的方法包括：在工作时间内不断开放所有团队成员的交流渠道，以模拟他们坐在一起；安排频繁的虚拟游戏会议以增强团队合作精神并一起玩乐；以及与特定同事计划在线聊天，以保持这些宝贵的临时讨论和交流机会。因此，如果您是Scrum Master或敏捷教练，现在是时候真正踏上第一步，因此即使在这些困难时期，您也可以帮助您的团队成长。
译者评论 疫情大前提下，团队合作变得更难。原来是远程团队还好，原来在办公室的团队，大家都不得不进行远程协作。这对于传统行业更为挑战。所以选择一个（套）好的工具是大前提，其次需要更多的设计团队沟通环节。因为原来团队合作，很多是发生在办公室，潜移默化（悄悄）的。而现在的团队合作，需要提前设计好固定的沟通时间、固定的沟通方式、固定的沟通渠道等等。
最后问一句，你的团队还好吗？
读者评论 对于今天的漫画，你有什么想说的呢？
原文链接
获取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）推导出来的。 产品导向，技术实践为重 其他的规模化敏捷框架，有熟悉的朋友也可以来谈一谈。
读者评论 对于今天的漫画，你有什么想说的呢？
参与讨论，请扫码加入”敏捷家”微信群 原文链接
