本文从超越预算来分析OKR（目标与关键成果），主要从三个角度来分析和质疑OKR（但并不是否定OKR）。相比国内一味的追捧OKR，这是一篇不可多得的文章。

写在前面 非常感谢 ETH123.org 的启发，在以太坊资源大全网站上线的时候，给我提供了灵感。尤其他们的网站是开源的，我可以直接 fork 下来进行改造即可。真心感谢ETH123.org，尤其还是感谢以太坊爱好者的曾汨和开发小伙伴。（帮我解决了一个技术问题） 还有哪些需要优化 目前还有几个地方有待进一步优化： 收集更多的敏捷相关学习资源 制作 Agile123.net logo 每个资源（网站）的logo收集 对于资源分类的建议 任何想法和建议，都欢迎在 github 上面提交issue。 目前有哪些资源 敏捷学习资源分类 当前的分类如下： 热门推荐、社区、敏捷框架、Scrum专区、大规模敏捷、产品设计、DevOps、敏捷度量、意见领袖、工具、资讯、博客、咨询公司、敏捷图书、敏捷实践等 收集的敏捷学习资源网站 这里就不一一列举了，如果你的博客，网站也想收录进来 欢迎在 github 上面提交issue。 最后，如果你认为这个站点对你有帮助，欢迎分享给更多的伙伴。 谢谢你的分享。

CSM培训总结 为期4天的CSM培训结束，自己对敏捷有了更深的认识，scrum是一种轻量级的框架，但却有着功能强大的价值观，原则和实践，主要体现在团队能在短期内能够尽快地响应变化，交付产品，快速反馈，适应变化，连续提升，相比较使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就会降低。 在scrum 三个角色当中，我觉得SM相对来说比其他两个角色重要，SM作为team leader和PO紧密地工作在一起，可以及时地为团队成员提供帮助。他的职责在于以下五点： 保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review 和Sprite Retrospective。 SM除了主持Daily Scrum之外，还有三个主要职责： SM需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。 SM需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的条目。 SM还必须仔细考虑进展中的任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。 SM需要找出阻碍 Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。 现在的工作模式基本是按scrum来运作的，在迭代开始前，会有需求清单(Product Backlog)，PO会把Product Backlog排出优先级，识别出更有价值的需求排在靠前，团队从需求清单中选择迭代中要完成的US(Sprint Backlog)，由SM给每个成员做任务划分，然后成员根据开发的周期输出自己计划，将US拆分成每天要完成的Task，每天上班先进行Daily scrum，反馈前一天完成了哪些任务，今天要完成的内容，其中遇到的一些问题，SM通过沟通，协调资源等多种途径解决在Daily scrum中反馈的问题，Sprint Backlog完成形成Increment，由PO和用户验收，之后团队进行Sprite Retrospective，总结出急需改进的Top问题以及继续保持的点。 不过还是有些差异，比如Scrum角色中的PO，只能定位作为一个决策者，团队在迭代过程中遇到解决不了的问题以及与其他团队协作问题等，才由PO来沟通，解决；而需求条目的澄清则由团队中专门负责需求整理输出的同事来承担，这可能是由于商业合作产生的这种模式。再比如迭代的周期都比较长，一个迭代至少3周甚至更长才能完结，迭代的交付时间中固定的，团队只能通过施压的形式，来要求团队成员按照交付时间点来完成产品Increment。 – CSM学员 宋

Scrum敏捷管理学习心得 敏捷开发是一种能应对快速变化需求的软件开发能力，包含Scrum、极限编程（XP）、晶体、特征驱动开发等多种方法。其中Scrum是最被广泛使用的一种方法，旨在指导团队进行产品的快速迭代和增量交付。 敏捷软件开发宣言： 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：个体的互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。 敏捷宣言遵循的原则： 1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 2、欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。 3、经常的交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。 5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 6、不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。 7、可工作的软件是进度的首要度量标准。 8、敏捷过程倡导可持续开发。责任人、开发人员和用户能够共同维持其步调稳定延续。 9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 10、以简洁为本，它是极力减少不必要工作量的艺术。 11、最好的架构、需求和设计涌现于自组织团队。 12、团队定期地反思如何提高成效，并依此调整自身的举止表现。 敏捷的五个核心价值观：专注、公开、承诺、勇气、尊重。 Scrum的三个核心角色：Product Owner（PO）、Scrum Master（SM）、Scrum Term（团队）。 其中 PO的核心工作为：对团队对外交付的价值负责，定义需求、定义需求的优先级和验收标准、定义产品发布内容与日期。 SM的核心工作为：帮助团队遵循Scrum框架，持续改进，促进团队工作，帮助团队排除影响生产力的障碍、保护团队不受干扰。 Scrum Team则对交付结果负责，敏捷团队是自组织的团队、小而美，一般团队成员定义为5-9个人。 Scrum的3个工件：Product Backlog（产品待办列表）、Sprint Backlog（Sprint待办列表）和Increment（可交付产品增量）。 Product Backlog即产品视角的需求清单，由PO负责维护，并根据优先级进行排序，优先级高的颗粒度更细，优先级低的对应颗粒度粗。用户故事是其中一种最佳实践，每项需求都应该描述其外部价值。 Sprint Backlog即冲刺周期内规划要完成内容，来源于Product Backlog，由团队评估和选择Product Backlog中哪些放入Sprint Backlog，同时团队需要一起定义完成的标准。 Increment即冲刺结束后可对外发布的产品功能增量部分。 Scrum的5个事件：Product Backlog梳理会议、迭代计划会议、每日站会、迭代评审会、迭代回顾会： Product Backlog梳理会议贯穿整个Scrum项目的始终，主要保持产品待办列表有序、凸显价值。 迭代计划会议作为Sprint的开始，决定在迭代中完成哪些待办列表，明确任务和战前鼓舞。会议时长对应Sprint周期每周2小时。 每日站会，会议时长建议为15分钟，检视上一个工作日做了什么，当天的工作计划和存在的问题，阐述最好是可视可量化的，问题不发散，做好时间管理。 迭代评审会议：会议时长一般每周对应1小时，在sprint结束时团队和相关干系人一起评审sprint的产出、完成工作是否符合需求预期，并展示当前产品增量情况。 迭代回顾会议：会议时长一般每周对应45分钟，在sprint结束后，scrum团队开会反省和检讨，对迭代周期内做的好的进行表扬和鼓励，不好的，提出改善方案和完成计划。 Scrum敏捷开发的优势：拥有快速反应的能力，精确要求，精准结果，更大的灵活性和稳定性、提高团队绩效，降低成本，失败的代价降低。劣势：敏捷注重人员的沟通，文档维护难度增加，在新员工较多未形成战斗力时，老员工较累。 结合当前项目实际情况的分析： 1）团队人员数量超出了Scrum的最优定义，站会易超时； 2）PO是新人，没有明确的职责定义，对产品认识度不够。 3）验收标准有时候没有很明确的定义，在长期不上线使用的情况下，拉通联调的支持周期过长，容易“带病”到后面的迭代。 4）新人较多，效能提升，共同价值目标磨合需要时间沉淀。 5）对于迭代评审会议，目前做的不够，没有很好的展示迭代输出成果。 6）奖惩制度不合理，在不断的高压冲刺中，难以长期的保持团队成员的斗志和凝聚力。 相信每个SM在Scrum交付过程中，总会遇到由内到外、由外到内等各种问题，需要不断地反思、学习、总结，所有的管理问题，最终都是人的问题，唯有持之以恒的学习反省，才能走的更远。 限于时间精力和篇幅，先写这么多吧，望谅解！ CSM考试学员：徐某 2020-12-23

敏捷交付 对于敏捷交付培训与实际运用中，我理解为我们需要持续不断的及早交付满足客户有价值的的软件，在交付过程中不断通过变化，通过及时沟通，标准的流程，统一化的工具，进行可持续，高效的交付。 在软件开发中，领导阶层的指挥控制方式（经理创建详细的工作细分结构、向团队分配任务，并告诉他们每项任务要花多长时间完成的方式）存在问题。敏捷方法从业者认识到，实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务，他们执行自己的评估，他们自愿挑选任务，他们自行分担工作量。在本质上，他们就像一个高效运转、自行组建的团队，没有明确定义项目经理职位。相反，该团队指派某个人作为团队领导，帮助推进整个流程，让团队成长，让团队在缺少SM这个角色后，还能依然运转。 我从如下几点详细描述我了解的敏捷交付: 产品路线图， 项目目标与里程碑， 团队成员责任划分， 团队流程与工具管理， 项目风险管理， 团队反思。 第一，产品路线图。 在产品路线定下来以后，根据产品的背景、前景和价值，让团队意识到该项目的重要性，了解产品的主要交付路线，产品主要需求的优先级，以及大致上线时间点。 第二，项目目标与里程碑。 主要是对产品路线的补充，对交付功能模块的细化，项目完结交付的所有功能点，SM基于产品路线和需求进行模块拆解，澄清所有功能点，对总目标功能点的里程碑设定，以及每个里程碑各个职能组完成的主要任务； 第三，团队成员责任划分。 主要是基于项目功能，明确团队成员和职责，让团队对每个人所负责有概念认识，基于功能和流程，明确团队成员和职责，对项目开展的相关环节的必要说明，大家共同遵守的团队规则章程，明确团队共识的协作方式。 第四，团队流程与工具管理。 为了确保共识计划得到落地执行，团队保持高效交付，那么就需要借助一些研发管理工具，辅助我们进行项目开展实施，同时在项目交付的过程中不断优化交付流程，代码管理，需求管理，人员管理，交付件的管理，将产品需求、项目任务、测试Bug以及其他事项都及时录入到项目管理工具，持续跟进、督促、检查，争取将所有事务录入项目管理工具，包括未被考虑的事情，让团队自己给自己建任务。 第五，项目风险管理。 主要是向团队成员告知个人任务进度和安排，以及需要支持的相关事项，及时暴露风险和问题；同时交付过程中存在需求理解，表达不清晰的地方，人员理解不一样的地方，要及早暴露出来这些风险，通过与客户沟通及视补救，沟通过程流程与工具能够尽早把风险扑灭。 第六，团队反思。 团队定期的反思如何提高效率，并以此调整自己的能力，让团队没个人都能够成长，同时淘汰不符合团队的人，让团队人员更加稳定延续，人员稳定才能保证项目的稳定，让团队成员执行力强，凝聚力强，没有旁观者、推诿者，共担解决；能力强，独挡一面，人人都是神枪手。 通过这6点，我们能够提醒、督促、辅助我们落地美好计划，让团队管理更加透明，让项目实施更加具体、让项目风险更加可预期，同时也可以加速交付节奏，做到极限编程，有着稳定的工具，流程，人员，并以即时的方式来让项目投资获得最高回报。 – CSM 学员陈某

一共有三个关键步骤： 生成新的私钥 上传公钥到github 修改本地ssh配置 Mac pro迁移后，本地的 github 私钥忘记是哪个，重新生成一个新的私钥放在一个新目录。（怕覆盖了原来的私钥，其他应用受影响） 1. 生成新的私钥 ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/<default>/.ssh/id_rsa): <your new path>/id_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in <your new path>/id_rsa. Your public key has been saved in <your new path>/id_rsa.pub. The key fingerprint is: ... ... 注意指定一个新的目录 <your new path>

Gitcoin第八轮支持活动 原文链接 发表于 2020年11月26日SCOTT MOORE 以下内容为机器翻译，准确信息已上述的原文链接为主。本活动是Gitcoin组织，解释权归Gitcoin。 从12月2日至12月17日，获得50万美元的集合资金，立即创建您的赠款 今天，我们很高兴宣布最新一轮的Gitcoin Grants。在过去的七轮中，在您的支持下，我们已经为超过700个关键的以太坊生态系统项目分配了超过3百万美元的资金。它不仅取得了巨大的回报，看关键 成员 的 我们的 社区获得可持续的资金来源，它是惊人的测试二次资金作为一种机制来满足我们不断增长和维持3D人类是建立我们依靠开源软件的更广泛的使命（OG Internet创建者有很多方式）。 但是，与以太坊生态系统一起工作有一些独特之处。如果我们不得不尝试提炼它，那就是社区总是团结在一起。我们将彼此之间的关系视为连续的，无限的游戏，并将与其他创作者的所有工作视为正和。我们发现，这不仅在补助金中而且在与社区的许多其他互动中都是如此。以太坊擅长建立小队财富。 正是这种认识使我们决定在Gitcoin Grants第8轮中尝试一些独特的事情（毕竟这是一个幸运的数字）。使人们团结在一起，共同学习并维护公共物品。 因此，我们很高兴宣布Gitcoin Grants Round 8（GR8）Hackathon，以及我们最大的配对资金池，其中有超过50万美元来自我们的新资助者联盟资助的6个类别。我们希望随着牛市的回归，我们可以使开源创作者获得最高100万美元的资金，并吸引更多的二次自由职业者。 如果您有兴趣参加此活动，则需要以下所有链接： 创建一个Grant。您要在Web 3中进行构建吗？您的工作很有价值。资助+加入社区！  注册到Hack：使用1inch，Balancer，Ceramic，Gnosis，Keep，Panvala，Nexus Mutual和其他10个版本进行构建  加入我们（虚拟）庆祝Web 3。在2周内始终开放的GR8 Airmeet中进行20多次活动 如果您不确定要做什么，或者只是想与我们discord，请加入Gitcoin的全新Discord，在此回合中，受赠者，贡献者和黑客将在这里闲逛！  那么，Gitcoin Grants如何运作？ 它从”赠款”页面，资金池和贡献者社区开始 赠款从您的项目页面（或您自己！）开始，以及一组匹配的资金。借助二次资助的力量，捐助者将表明他们对受赠者的支持，并民主地决定匹配资金的去向。 如果您是受赠人，则需要注意的关键是，对项目的每笔捐款的*数量*和*金额*都会影响分配给您的总额。如果您是贡献者，那么即使是很小的贡献也会对受赠者获得的对等资助金额产生巨大影响。 换句话说，Gitcoin Grants实际上就是社区共同努力，以帮助为公共物品提供资金和表示支持。而且我们都受益于公共物品。 前往https://wtfisqf.com/?grant=1,1,1,1&grant=4&match=1000来体验QF的基本功能！ 第七轮回顾 第七回合的配对资金为45万美元（较上一轮增加150％），这主要要归功于DeFi的所有人（甚至是匿名人士）。主要资助者包括以太坊基金会（我们的第一个主要支持者<3），optimism（另一个长期支持者），yearn（在第七轮成功的许多方面的催化剂），balancer，Synthetix，Chainlink，threearrowscap等。 我们还看到了近200个新项目参与，使总数达到850个以上。在产品方面，我们将工作重点放在了更好的Sybil抗性，更快的（和更便宜的）第2层结帐交易以及集合上！ 在第7轮中，社区支持的新水平对我们而言是一个重要的里程碑，也是朝着实现二次自由职业的愿景迈出的非常谦卑而重要的一步。如果您想了解更多信息，请在此处查看Vitalik的Round 7回顾展。 第8轮–有什么新功能？ 除了修正总体贡献者和受让人的体验之外，我们还指导了以下几项工作： 多个CLR；多种资金  作为资助者，您可以捐赠到多个类别或收藏集。作为受赠者，您可以轻松参与多个匹配池！ 您的资助页面 我们希望获得一个赠款页面，该页面中的描述中要包含清晰的”要求”，因此，作为Gitcoin，我们可以在GR8黑客马拉松期间与我们的社区联系，以解决特定问题。在此处阅读更多一些技巧，以最大限度地提高您的匹配度。 赠款页面现在显示了更美的爱墙  现在可以选择将视频简介上传到您的资助说明中  向Sybil抵抗前进（一次整合！） 除了SMS，BrightID和Twitter，我们现在还集成了Idena，POAP和Gmail，以验证您是否是贡献者，以增加您为之贡献的赠款的匹配金额。 受赠者通过Twitter进行自我验证，而贡献者通过各种选择以增加其信任奖金的方式进行自我验证。 活动阵容！ GR8黑客马拉松 第一个旗舰Gitcoin授予Hackathon！此次联合活动不仅有机会召集社区，不仅围绕他们关心的资金项目，而且也有助于建立社区，请在此处阅读更多内容。

Scrum 官方权威指南 收听有声版 | 官网下载PDF 由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护 版本：2020中文版 | 查看旧版本（2017） Scrum 指南的目的 在 1990 年代初，我们开发了 Scrum。在 2010 年，我们撰写首版 Scrum 指南，以帮助全世界的人们理解 Scrum。自那时起，我们通过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。 Scrum 指南包含了 Scrum 的定义。框架的每个元素都有其特定的目的，这对于使用 Scrum 实现全部价值和成果是至关重要的。如果更改 Scrum 的核心设计或理念、遗漏元素或不遵循 Scrum 的规则，将掩盖问题并限制 Scrum 的好处，甚至可能变得毫无用途。 我们关注到 Scrum 在日益复杂的世界中应用越来越广泛。我们很荣幸地看到 Scrum 在许多本质上具有复杂性的工作领域中被采用，超越了 Scrum 的起源领域——软件产品开发。随着 Scrum 的应用范围不断扩大，developers、研究人员、分析师、科学家和其他专家都能在工作中应用。因此，我们在 Scrum 中使用 “developers” 一词并不是为了排除其他使用者，而是为了简化统称。如果您从 Scrum 中获得价值，那么您可以将自己视为其中一员。 在使用 Scrum 时，可能可以找到、应用和设计适合本文中所描述的 Scrum 框架的模式、过程和见解。它们的描述超出了 Scrum 指南的目的，因为它们因 Scrum 的使用具体情境不同而不同。这些使用 Scrum 框架的特定技巧有很大的差异，因此不在本文中描述。 Ken Schwaber & Jeff Sutherland 2020 年 11 月