作者: Roman Pichler 原文: https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/?doing_wp_cron=1561070340.3916580677032470703125 给产品负责人的十条扩展建议 管理不断增长的产品是一件荣耀与挑战并存的事情：让更多人和团队参与并扩大规模并非易事。本文分享了10个实用技巧，以帮助您（产品负责人）进行有效地扩展。 1. 让合适的人参与进来 少数拥有合适的技能和主观能动性的个人要比那些不专业的当一天和尚撞一天钟的人更具生产力。根据我的经验，产品人员和开发团队成员都是如此。因此，努力让合适的人参与进来。这样可以让您的团队更长时间的保持灵活与高效，并且更具适应性。 虽然这可能听起来像常识，但我看到不止一个组织试图通过随意的增加人手到产品中来完成更多工作。例如，我与之合作的一家公司指派了使用古老编程语言开发企业信息系统的开发人员去开发采用最新技术的全新嵌入式产品。毫无疑问这些人在新岗位上非常挣扎，产品也蒙受了损失。 您的Scrum Master应该能够帮助您找到合适的人并清除相关障碍 - 例如，在没有考虑他们的技能和动机的情况下进行人员调动。 2. 不要过早扩张 我曾经参与过一项新产品开发工作，从项目开始就在三个地点分配了100多名开发人员。虽然最初没有足够的工作让这么多人忙碌，但是开发团队不想浪费时间，开始编写软件。这导致了一个膨胀的、过于复杂的代码库和一个难以适应且维护成本昂贵的产品的诞生。 与其过早地扩大规模，不如尽可能地保持小规模，直到接近产品产生市场价值的规模。这允许您快速响应市场反馈，试验新想法，并进行任何可能需要的架构和技术变动，以便进入增长阶段。 3. 建立最小可行性 另一种减少规模扩张需求的好方法是推出一款最小可行性的产品。与功能更丰富、更有抱负的产品相比，开发这样的产品通常需要更少的时间和更少的人员。更重要的是，它可以更容易地适应市场的变化，以实现产品与市场的契合。 你的产品能有多小取决于它的市场。例如，在最初的iPhone上，苹果创造了一个新的市场，因此可以提供一个相对简约的产品。与之形成对比的是，Apple Watch进入了一个现有市场，直接与三星(Samsung)、Garmin和Fitbit等公司的成熟产品竞争。 4. 帮助开发团队实现自给自足 随着产品的增长，工作负载通常也会增加: 处理越来越多的需要花费更多的精力来理解的不同的用户需求，并决定如何最佳地处理这些需求。如果您的开发团队在这个阶段仍然需要填鸭式地提供详细的需求，那么您的工作量可能会变得非常巨大。 为了减少这种风险，帮助开发团队尽早了解用户并了解他们的需求，例如，让团队成员参与用户调研(作为产品发现工作的一部分)，并让他们直接获得用户对早期产品增量的反馈。这将允许团队成员对解决方案拥有自主权，并做出正确的技术决策，提高参与积极性，为添加更多的团队打下基础，并使您不必创建细节丰富的用户故事并在sprint期间回答许多问题。 5. 有机增长 早在1968年，Melvin Conway就观察到“一个系统的结构和设计它的组织结构之间有着非常密切的关系。”这意味着，如果您从三个开发团队开始，那么您产品的软件体系结构可能由三个主要的子系统组成——不管这个体系结构是否支持所需的用户体验和特性。 为了避免这种风险，从一个产品负责人、一个开发团队和一个Scrum Master开始。一旦您验证了关键的用户体验和技术风险，就可以通过要求团队拆分来进行扩展。然后在新组建的团队中加入更多的人。这种方法也被称为有机生长，因为它模仿了生物的细胞分裂。 除了避免上面提到的Conway法则,有机增长还提供了两个额外的好处:它使增加人手的效果落到实处而不是让一个低效的团队处理所有的新特性,它允许您测量增加人手在生产力和基础设施上的影响。 后者可能看起来相当枯燥，但我曾经与一个组织合作过，为了加快开发速度，该组织一口气从3个开发团队提升到了8个。不幸的是，没有人预料到基础设施无法处理新团队造成的网络流量增加。因此，签入和签出代码突然需要花费几分钟而不是几秒钟，这意味着开发速度显著降低，直到升级工作完成后情况才有所好转。 6. 雇佣功能所有者和功能团队 随着您在开发工作中添加更多人员，请考虑使用功能团队 - 实现端到端功能的团队- 而不是像前端或持久层一样按架构分块构建组件的团队。与组件团队相比，功能团队具有更少的团队间依赖性，并降低了局部优化的风险，提高了整体产品性能。但是，它们确实需要统一标准以避免定义不良变量和代码重复：您通常不希望每个功能团队都重新开发自己的UI而放弃已有的可用代码。 当您将功能团队引入到开发工作中时 - 希望是通过有机增长的方式- 您还必须考虑对工作负载的影响。我的经验表明，单个产品人员通常无法与三个以上的敏捷开发团队合作。因此，您必须考虑让其他产品人员参负责该功能并指导功能团队，我称这些人为功能所有者。下图显示了如何应用该角色。有关更多信息，请参阅我的文章“扩展产品负责人角色”。 7. 从一个站点开始，以循序渐进的方式分发工作（如有必要） 虽然很难将合适的人员聚集在一起，但软件开发中有一些事情比分散团队 - 团队成员在不同地方工作 - 例如伦敦，波士顿和班加罗尔开展新产品开发工作更具反作用。 一般来说，存在越多的不确定性，变化和创新就会越多，参与开发工作的每个人都在同一地点办公（包括产品负责人）就越重要。这使您可以培养融洽的团队氛围，建立有效的协作并就共享标准达成一致，例如，如何协作优化产品待办事项以及进行有效的冲刺评审。 因此，在一个站点的一个团队开始新产品的开发工作。一旦解决了关键的用户体验问题和技术风险，如果需要，可以考虑以循序渐进的方式将工作分散到其他站点。这使您可以了解如何通过布局分布式团队来改进您的实践以取得成功，包括通过视频会议进行产品策略审核和产品待办事项优化的协作。 8. 考虑分拆功能和创建产品变体 成长是一件有趣的事情。虽然这是一个值得庆祝的理由 - 产品终于进入了成长阶段并取得了成功 -我们现在必须应对日益庞大且复杂的目标群体，更多样化的需求，更多的功能以及更多的开发团队。但它不一定非得这样。 还记得Facebook在2014年拆分Messenger并将其作为独立应用推出吗？分拆是一项很好的技术，可以避免成功的产品变得越来越大，越来越异构，并且需要越来越多的人来管理和开发它。取而代之的是，您可以使用自己的专业产品人员和开发团队创建新的专业产品。 产品变体执行类似的工作：但是，您可以创建针对一组特定的目标规划版本，而不是分离一个或多个功能。以微软的图表工具Visio为例，该公司提供VisioStandard和Visio Professional等变体。每个变体都可以由一个单独的团队开发，并拥有自己的产品人员来负责。 9. 利用平台优势 平台会捆绑一些共享资产，例如，共享的前端或后端组件或常见服务（如持久层，日志记录和安全防护），并标准化它们的使用方式。使用平台在扩展环境时有两个好处：首先，它鼓励重用并避免每个团队重复造轮子，比如日志服务。其次，它创建并实施跨不同功能和团队的标准，例如通用用户界面设计。 在创建平台时，您有两种选择：集体所有，要求不同的功能团队共同管理和改进平台。或者，您可以通过专门的平台所有者和团队管理平台。（请注意，平台所有者通常需要深厚的技术功底，因为他们通常需要功能团队讨论新接口和现有接口的更改。）

假敏捷 Fake Agile 作者：Steve Denning (from Forbes) 译者：乔梁 （微信公众号：持续交付2.0） 我现在的微信签名是“别提概念，只解决问题”。而在2013年之前，我用的签名是“别提敏捷，只解决问题”。 为什么呢？因为在2012年的腾讯，敏捷开发方法似乎早已成为“过去时”。但是，还有一大堆问题要解决呀。 （上图与腾讯无关，来自我朋友圈的@王宇） 今天的文章是Martin Folwer在“推它”上一个引用，原文发表于福布斯网站，作者是Steve Denning。点击文末的”原文链接“，看英文版。 正文如下： 有个公司请我去讲讲“假敏捷（fake agile）”。他们想讲我解释一下，如何识别假敏捷，以及如何处理这种情况。这个要求是可以理解的。 就像穿着弗拉门戈服装和谈论弗拉门戈的人一样，没有掌握弗拉门戈舞步或展示弗拉门戈音乐的感觉或天赋，一些所谓敏捷管理的例子的确与真正的敏捷是相关的，但又似是而非。 随着人们越来越认识到“敏捷正在吞噬世界”。德勤和麦肯锡的调查显示，超过90％的高级管理人员高度重视敏捷，而不到10％的人认为他们的公司目前非常敏捷。 愿望与现实之间的差距导致大量的经理，顾问和教练声称自己敏捷并提供帮助公司变得敏捷。 不少公司也有首席执行官问：“我们为什么不敏捷？” 因此，“敏捷”一词经常被抛出，而并未对其含义达成任何共识。 它通常适用于对任何敏捷性没有实质性要求的公司或公司的一部分。 在某种程度上，事实上，实际上非常敏捷的公司往往回避标签，“敏捷”，并使用他们自己的本土词汇，感觉更真实。 1、定义“敏捷” 为了解决困惑，我们需要对真实事物进行定义。 正如这里所解释的，我对过去十年的研究表明，敏捷的主要成果是体现了具有三个主要组成部分的思维模式的公司。 为了强调所有这三个组成部分的重要性，我只是半开玩笑地称它们为“法律”。也就是说，除非你遵守所有这些“法律”，否则你无法真正称你的组织是“敏捷的” 。 我在这里谈论的是整个公司的敏捷性或业务敏捷性。因为，经验表明，只有整个公司使用相同的步调运行时，才会产生敏捷的主要成果。 2、敏捷三定律 客户法则 - 专注于为客户提供价值，作为组织的全部和最终目标。 小团队法则 - 假设所有工作都由小型自组织团队进行，工作周期短，专注于为客户提供价值 网络法则 - 持续努力消除官僚主义和自上而下的等级制度，使公司作为一个互动的团队网络来运作，所有这些都集中在共同努力，为客户提供越来越多的价值。 该定义包括运营敏捷性（operational agility，使现有业务更好）和战略敏捷性（strategic agility ，生成新产品和服务，从而引入新客户）。 该定义独立于那些术语、标签，或者是特定的专有流程或特定品牌。 3、没有标签的敏捷 该定义认识到，一些最成功的敏捷最终都在企业内部实现了本土术语。 换句话说，这些公司甚至没有称自己敏捷并且回避标准的敏捷词汇，其中一些（如Scrum）被故意设计为对管理层没有吸引力。 亚马逊，苹果，Facebook，谷歌，Netflix和微软等大多数规模最大，发展最快的公司在其所做的大部分工作中都具有敏捷性，即使他们通常不使用标准的敏捷词汇。 他们的业务敏捷性是他们成为世界上最有价值公司的重要原因。 3、敏捷的初级阶段 敏捷是一段旅程。 没有哪个公司能够在第一天实施敏捷的所有元素。 掌握敏捷的各个方面需要时间。 当一家公司处于敏捷旅程的初期阶段时，人们可能会称之为“早期敏捷”。这不是假的敏捷，而是“它是不完整的”。 如果旅程顺利进行，那么公司将逐步掌握所有三项敏捷法则以及战略敏捷性。 旅程永无止境：公司继续寻找变得更加敏捷的新方法。 公司敏捷旅程的路径顺序可能不同。 例如，微软大约十年前开始使用小型敏捷团队，如下图所示。 它继续在2008 - 2014年期间以稳步增长的规模进行试验。 只有在Satya Nadella成为微软首席执行官的这段时间之后，这种方法才开始传播到整个组织，人们可能会认为微软是一家开始体现业务敏捷性的公司。 人们可能会称，2014年之前的微软是一个”敏捷初级阶段“公司。 相比之下，亚马逊从1997年股票市场首次亮相开始就接受了对客户的痴迷，明确承诺致力于为客户创造价值并实现市场主导地位。 仅仅五年之后 （大约2002年），亚马逊就拥抱了“双披萨团队”，并开始将网络连接在一起，而不是自上而下的层级。 在此之前，将亚马逊称为早期敏捷实例是合适的，尽管其旅程中早期步骤的顺序与微软不同。

黑暗敏捷 Dark Scrum 作者：Ron Jeffries 译者：陈旭 （微信公众号：敏捷变革中心） 我们来谈谈“黑暗Scrum”。至少在软件方面，Scrum似乎常常压迫人们。通常，Scrum不能像它本该的那样快速、可靠、稳定地交付。结果，每个人都在受苦。大多数情况下，开发人员比任何人都要承受更多的痛苦。 我最近很多想法背后的主题是： 我最初的“敏捷”导师Kent Beck曾经说过，他发明极限编程是为了让程序员的世界更加安全。事实证明，这个世界对程序员来说还并不安全。Scrum可能对程序员来说是非常不安全的。用Scrum的联合创始人之一Ken Schwaber的话来说:“这让我很难过”。 我很认真的说Scrum其实做得相当好，也是一个很好的框架。与决定需要做什么和需要推迟做什么的业务人员有紧密的联系是件好事。团队拥有构建产品所需的所有技能是件好事。每隔几周就构建一个经过测试的有形产品是件好事，向涉众（stakholders）展示它也是件好事，回顾工作的进展以及如何改进它们也是件好事。多年来，我一直在研究、实践和思考Scrum，关于它的一切都非常好。不是很完美，但真的很好。 不幸的是，这只是Scrum的理念，一个理想的按照预期的方式进行的Scrum。就像每一个好的理念一样，现实有时也不尽人意，有时它远远不及设想。我称之为“黑暗Scrum”。 黑暗Scrum: Scrum的一些典型滥用 让我们看看在黑暗Scrum中，事情是如何出错的，只需几个步骤。在本节中，我们将观察一个经历黑暗Scrum的团队，黑暗Scrum领导者的本意是好的，他们只是做错了。 自组织是缓慢发生的 显然，要精通Scrum需要一些时间。它有新的角色和活动。更困难的是，它要求我们接受新的价值观。我们应该让我们的开发人员自行组织工作。我们很容易组织Scrum会议，并通过Scrum角色来称呼自己。但真正做起来却并不容易。 Scrum开始时，接受过培训的人很少，理解它的人更少。很多人认为他们知道自己应该做什么，不过如果他们做错了也不奇怪，事实上他们经常做错。 当今的掌权者常常认为他们的工作是决定人们应该做什么，告诉他们去做，并监督他们做。Scrum则不然，Srum解释需要做什么，然后退后一步，让员工自行组织去完成它。 以Scrum模式运营并不容易。忘记旧的习惯需要时间，学习新习惯需要时间，学习信任团队也需要时间，团队也需要时间来学习如何被信任，在某种程度上，这就是本文想要传递的潜在信息。Scrum的培训为接受培训的人开启了这个学习过程。 黑暗Scrum始于那些熟悉自己的旧工作，但不熟悉新工作的人进行Scrum活动的时候。它是这样的: 太棒了，我们每天都可以帮助团队 每天，团队会聚在一起组织一天的工作。这种做法，即“每日Scrum”，典型的Scrum团队都会做。房间里可能有一个人，ScrumMaster，他被告知应该怎么做。程序员没有被告知，很多时候，甚至产品负责人也没有被告知。几乎可以肯定，其他掌权者也还没有被告知。 但掌权者已经知道他的工作。他的工作是高高在上的监督每个人都在做的事情，确保他们正在做正确的事情，否则就让他们改正。每天都有强制性的会议让他可以这么做，这是多么方便！ 结果是：团队无法围绕他们的任务群策群力，整理出一份适宜的当天的工作方案。取而代之的是掌权者将信息从他们身上抽离出来，在自己的头脑中处理，然后再告诉每个人该做什么。由于事情没有像昨天早上预期的那样被完成，这种不正当的活动往往气氛紧张并充满了互相责备。 黑暗Scrum每天都会压迫团队，自组织不可能产生。 我们也有快捷频繁的规划！ 每个Sprint，Scrum产品负责人都应该与团队会面，并描述需要什么。然后团队确定他们可以做些什么来满足需求，并开始构建它。嗯，理论上就该这样。可实际上，甚至可能没有业务方面的产品负责人。即使有，他们可能也没有接受如何成为产品负责人的培训。 好吧，掌权者有者可能是Scrum的新手，但他们对如何处理这个问题知之甚多。因此，每两周他们就会出现并告诉这些程序员他们必须构建什么。哦，那些程序员会反击。他们懒惰，顽固。但掌权者会继续施压，因为这就是他管理人的方式。所以他们告诉团队该做什么，他们最好这样做。 当然，掌权者很少或根本不知道如何编程，程序员通常至少有一些线索。他们不知道代码的状态是什么，程序员通常都知道。程序员应该决定某项任务在Scrum中的工作量，但在黑暗Scrum中，掌权者更懂这个。他们把任务堆积起来分配，他们认为这是他们的工作：驱使团队前进。 结果永远不会改变。团队认真地尝试做被要求做的事情。他们知道无法说不可能，尽管它就是不可能的。他们只是会因为懒惰，愚蠢和制造麻烦而受到谴责，所以他们尽力而为，但就是不够好。 在Sprint结束时，结果不符合要求。魔法再一次没有发生，开发人员再次失败了。幸运的是，我们有机会直接处理这些事：Sprint评审！ 我们需要批判性的评审已完成和未完成的事项 每个Sprint，利益相关者都会了解团队已达成的成果，并提供接下来相关工作的指导。伟大的理论，但在组织没有精通Scrum的情况下很少能在实践中完成。 黑暗Sprint回顾的第一步是提醒每个人团队“承诺”做什么。（也就是说，在团队说“我们会尝试”之前就提出要求。这是一个承诺，不是吗？）然后看看团队带来的可怜的失败。 你猜怎么着。组织要的比能完成的多，并且没得到满足。团队尝试了，并且在尝试时他们采取了他们能想到的所有捷径来完成所有那些不合理的请求。他们压缩测试工时，他们压缩设计工时，他们甚至在太累而无法思考时工作。 他们没有足量完成工作，已完成的工作做的也并不是很好。团队再一次失败了。 幸运的是，黑暗Scrum拥有掌权者，产品所有者和利益相关者，他们确保程序员可以完全了解他们做得多么糟糕。这肯定会激励每个人下次做得更好，在这一点上，我们有Sprint回顾！ 我们要告诉他们该如何改进 在Sprint回顾中，团队回顾上一次Sprint，以及之前的历史。他们观察哪些进展顺利，哪些进展不顺利，并弄清楚如何在下一次进行改善。 在实践中，黑暗Scrum掌权者会帮助他们，提醒团队尽管他们被紧紧的管理着，但仍存在不足之处。掌权者向这些开发人员明确说明他们的失败- 这种失败 - 肯定是由于他们的懒惰和无能导致的。 为了激励团队做得更好，掌权者会不停的摇头叹息并指出不改进的后果，这总是会引起团队的注意。 有时团队会提出建议。以下是他们可能会说的一些事情，以及掌权者如何回答这些事情： 开发者：我们需要更多的测试来减少bug的数量。 掌权者：不，开发进度已经落后了。你编程的时候动点脑子。你不写bug就不需要解决它们。我们需要新功能，不是测试！ 开发者：这个设计正变得混乱，我们需要重构并提升。 掌权者：不，你一开始想什么了做出这么蹩脚的设计？没人告诉你要设计的这么烂。马上收手把问题解决掉。快到周末了，就用这个周末把它解决掉。 开发者：需求不清晰，他们没有澄清需求，所以我们的工作在最后阶段被否决了。 掌权者：我们花钱雇你就是让你解决问题的。你需要自己想办法解决这些问题。别在这傻坐着了赶紧把我们想要的东西做出来。 现在你应该明白。把团队成员的鼻子放在磨刀石上磨，把脚放在火上烧，软件开发一直是这么干的。Scrum并没有改变这一点。 哎，这真是令人沮丧 嗯，当然，Scrum实际上正试图改变这一切。但是，除非组织的信念和思想真正的发生了变化，旧的管理方式依旧会频繁发生，它每隔几周，甚至每天都在发生。 作为开发人员我们能做什么？ 黑暗Scrum正在滥用Scrum，他们与Scrum试图教给我们的东西明确对立。没有真正的Scrum专家会推荐任何这些做法。正在做这些事的人并没有“做的正确”。每个人都同意这一点。尽管如此，黑暗Scrum真实存在，它还经常发生。在我看来，在人们真正学习Scrum的原则和价值之前，它被滥用几乎是不可避免的。 似乎开发团队除了接受压迫之外别无他法。幸运的是，事实并非如此。好消息是，我们可以做一些强有力的事情。坏消息是，这并不容易。另一个好消息是，它主要是关于编程，我们通常都很擅长这方面。 来自产品负责人和/或其他掌权人的大部分压力来自于他们无法清楚地看到我们正在做什么，我们实际上已经完成了什么。如果我们能清晰的展现出事情的进展，我们可以改变我们的境遇。 如果产品有很多已知的缺陷，我们的领导会认为还有更多，他们会害怕，会把他们的恐惧转化为压力施加给我们，因为恐惧经常表现为愤怒，他们会对我们生气，通常会非常生气。 如果我们在实现功能之前先处理设计或基础设施工作，开发新功能的进展似乎很慢。这使得我们的领导者担心我们会延迟发布或无法提供重要功能。我们将再次遭受他们的恐惧和愤怒的洗礼。 当领导层看不到可工作的软件时，他们会对未来感到害怕 - 这是对的。他们总是以对事情没有助益的方式展现恐惧，这通常是痛苦的。开发人员可以阻止这种情况发生。我知道的唯一方法是提供软件。真实存在，具有可见功能的已经上线的软件！

Beyond Blockchain Hackathon 我们非常高兴地宣布Beyond Blockchain，这是Gitcoin和ConsenSys Labs联合举办的黑客马拉松。 在过去十年中，区块链社区为新的去中心化的世界建立、资助并扩展了核心基础设施。尽管如此，大多数企业、社区和个人还没有在日常生活中用上这种力量。 现在是时候去参加超越区块链了。超越区块链是一个为期三周的虚拟黑客马拉松，从6月24日到7月10日。来自全球的开发人员、企业家和建设者共同合作将区块链应用推向业务、技术和社会变革的新领域。在此注册！ 超越Blockchain跟随我们之前Ethereal Virtual Hackathon的成功。4月15日至4月30日期间，来自世界各地的500多名开发人员、设计师和企业家加入我们，共同打造基于区块链的项目。总奖金超过67,000美元，由14个区块链公司和企业软件公司赞助。 超越区块链将是一个更有针对性的活动，特别是围绕将区块链工具和技术带给更广泛的受众的主题。出于这个原因，我们将接受赞助商，他们对项目的想法有所建议，这些项目可以建立在影响世界的协议之上。伸出手赞助我们，如果你认为这是你的项目！ 在这个黑客马拉松中，您将有机会与开源维护者一起工作，并以建立区块链的未来而闻名。这包括ConsenSys Labs，您将获得媒体、医疗保健和去中心化的财务方面的奖项。 黑客马拉松细节 您可能想知道，这个黑客马拉松和其他许多黑客马拉松之间的区别是什么？简而言之，我们认为开源社区的开发人员在很大程度上会脱颖而出。Gitcoin生态系统中有20,000名开发人员完成了4000个项目。就在上个月，600多名黑客在短短两周内参与了80次提交。如果您正在寻找一个团队来开展以太坊未来的项目，那么现在是时候放手一搏了。 如上所述，Beyond Blockchain Hackathon将于6月24日至7月10日举行。除了许多发布的奖金之外，黑客马拉松参与者还将争夺超过10,000美元的奖金奖励，这些奖金分布在几个领域，包括媒体、游戏和医疗保健。 我们期待在下周分享更多关于这些奖品和奖金的信息。 立即注册 无论你是否听说过Gitcoin，注册黑客马拉松是一个3分钟的过程。填写此表单，点击右上角的“使用Github登录”创建一个Gitcoin个人资料，您将参加比赛。随着黑客马拉松的临近，我们会通过电子邮件向您通报！当你和你的队友在6月24日开始黑客工作时，我们预计将获得25,000美元的奖金，赏金等等。 点击此处注册为黑客，请访问Gitcoin的网站了解更多详情。 我们很高兴与您一起开发开源项目。 🌳 原文链接

Reputation vs Tokens 声誉和代币 不熟悉DAOstack声誉的读者应该考虑阅读这篇 介绍文章 。 权力下放治理的主题越来越受欢迎，随之而来的是去中心化投票系统的主题。 目前，DAOstack的去中心化治理基础设施主要侧重于支持基于信誉的投票。 在这篇文章中，我们解释了声誉和代币之间的主要区别。 然后，我们讨论了可替代性及其对投票购买的可防御性影响。 最后，我们将审查可以使用信誉或基于代币的投票探索的不同治理模型。 将差异形式化 当我们讨论声誉与基于代币的投票时遇到的最常见的事情是对代币的误解，这导致两者之间可以理解的混淆。 在一些会谈中，我们甚至听到了一个不熟悉的术语“声誉代币”。我们认为，一些混淆与Augur项目命名他们的代币“REP”以及区块链空间中使用的其他单词声誉相关。 。让我们澄清代币的含义以及DAOstack中的声誉。 我们认为区块链上的代币应该包含以下两个属性： 代币不能从其所有者手中夺走。 所有者可以将代币转移给其他任何人，而无需请求许可。 注意：并非所有“代币”都包含这两个属性。 例如，Bancor团队可以禁用 BNT代币的 所有传输 。 他们还可以选择性地销毁（刻录）他们 选择 的任何用户的代币 。 其他人可能不同意，但由于BNT不具备上述两个属性，我们不认为它是一个代币。 既然我们已经理解了代币的这两个属性，那么我们可以更好地理解声誉。 在DAOstack中，Reputation声誉具有以下属性： - 可销毁的：即名义上，它不是真正的属于“你”。只要声誉系统的所有者不选择将其带走，它就属于你。 对于DAOstack，有一个隐藏的假设，即声誉系统所有者不是一个人，而是一个DAO，其行为由DAO的声誉持有者控制。 - 不可转让：即分配了一些声誉的账户既不能转让也不能转账。 这些属性创建了一个非常有趣的结构， 持有声誉的账户在组织中拥有一定的权利 - 在我们的情况下，是投票权。 但是，这种权利远非绝对：在任何时候，组织都可以通过削减账户的声誉来反驳它。 您可以想象，如果利益相关者违反组织的规则，代码强制执行的硬性规则或社会强制执行的软性规则，都可能发生这种情况。 此外，声誉的不可转移性使其实际上不可替代 ，因此该帐户的削减威胁没有到期日期。 因此，没有法定时效：由于五年前犯下的罪行，DAO可以削减账户的声誉。 贿选 在基于代币的投票中，投票购买被视为一种特性（功能）。 基于声誉的系统试图阻止或限制投票购买。虽然确定这些措施的有效性并非易事，但我们在尝试这样做。 首先，区分值得信赖和无信任的投票购买非常重要。 如果卖方和买方可以相互依赖是诚实的，那么交易就是可信的，这种信任通常来自某种社会关系。 如果买方和卖方无法确定对方是否诚实行事，我们称该交易无信任。 在投票购买（我们的系统中的声誉交易）的情况下，我们的声誉版本提供了对信任无信誉交易的强有力的防御。 最天真的例子是出售他的私钥的人。 虽然没有机械方法来阻止私钥的销售，但由于声誉无法转移，买方将始终相信卖方不使用密钥并对其进行投票。 这种投票购买显然需要信任。 此外，DAO可以实施从发现销售其私钥的任何地址剥离信誉的策略。 如果一个密钥的卖方是不诚实的并且保留了一些销售证据，那么他就可以揭示这个证据，并且DAO将剥去该地址的声誉，实际上没收买方的购买。 DAO还可以采取政策来奖励卖家披露这些记录，进一步阻止这种类型的交易。 因此，寻求在声誉系统中购买选票的人有充分的理由不进行无信任的交易。 区块链通常被提出作为解决这个问题的方法 - 使无信任的交易值得信赖 - 但他们并没有绕过这种信誉剥离机制。 例如，有人可能认为使用密钥托管可以在区块链上实现安全，无信任的投票购买。 如果一个人拥有一份持有声誉的合同（与钱包地址相对），他确实可以使用这样一个托管来永久地或在有限的时间内安全地出售该合同的所有权。 这个区块链托管没有做任何事情来防止卖方秘密保存他以前对合同的所有权证明，这意味着这种类型的销售可以被DAO轻易地惩罚。

如何使用DAOstack 各位网友大家好，如果你到达互联网的这个角落，就意味着你正在考虑参加一个去中心化的自治组织，或者酷孩子有时称之为DAO。 自2016年著名的The Dao hack以来，很少有人相信我们有可能看到一个功能正常的DAO，但我的朋友Matan Field和 DAOstack团队是这个领域真正的先驱，因此他们一直忙于打造难以想象的工作！ 在这篇文章中，我不会详细介绍DAO以及DAO可以实现的内容，我相信 DAOstack 团队以及其他团队提供的内容比我更好。 我也不会关注使用去中心化技术的安全方面，使用本指南需要您自担风险⚠️⚠️⚠️ 我将关注的是把自己加入到目前正在运行DAOstack的 Alchemy 平台的实验性DAO中。 如果你想问任何关于本教程中提到的步骤和产品，欢迎加入bitfwd community (bitfwd.com) Telegram channel at: t.me/bitfwd 译者注：中文可以访问HiBlock官方网站（https://www.hiblock.net） 👩🏼‍🎤👨🏾‍💻👧🏻👩🏼‍🏫🧕🏻🧔🏻🐨🌈⏩ 开始之前，你需要准备的内容如下： 准备清单 科学上网技术：这里有一些工具都需要你会这个技能，如metamask, google docs, twitter, telegram等 浏览器：Firefox是我推荐的浏览器，但你也可以使用Brave或Chrome Metamask: 🦊浏览器插件，可以让浏览器兼容Web3以及轻钱包 ETH: 你需要一点点以太币，来支付提议的手续费 Google Doc或者Github账号: 你需要草拟一份对外的提议，并允许其他人方便的查看该提议且提建议 Twitter账号：可选项，强烈建议用一种工具来证明你的社交关系。LinkedIn以及其他工具都需要人们强制登录。 Telegram 或 Discord: 可选项，因为有需要的加密社区讨论在这2个平台上进行，所以很有用。 准备提议 我们一步一步来看，如果卡住了，欢迎到bitfwd社区提问。 1. 用google docs（或github），撰写声望（reputation）请求提议，可以采用如下参考样例：BoB Jiang’s reputation request proposal.如果你在用google docs，生成文档共享链接时，确保打开“建议”而不是编辑模式，否则其他人可能会搞乱你的提议。 2. 把google doc（或github）链接发布到twiiter上，例如 https://twitter.com/bobjiang123/status/1134387962571923456 3. twitter链接复制到google doc里面，交叉引用 4. 在浏览器里打开Genesis DAO （Alchemy是DAOstack的门户）。会有很多DAO组织加入，Genesis DAO是这个点上的最相关的实验。 5. 假设你已经安装好了Metamask（译者注：需要科学上网），并且你的账号里有以太币，那么久可以开始在Alchemy上提交你的提议 6.

准备 反思 找一个当地的合作伙伴，这样会少去很多的麻烦。 如定场地，酒店，午餐，茶歇等等 对于海外的CSM培训，能早一点确定对于机票会有很大的优惠。 一般提前一个月的机票有很大折扣（但要注意寒假暑假）。 预留出宣传时间，一般最少提前2个月订好课程时间。 收获 这次共同培训的是一名CSP，他正在申请CST。 从培训的课程中，具体收获： 课程主线一定要清晰 课程大纲，授权给学员来创建 对于讲师，守住学习目标的底线 每半天进行一次回顾。回顾学习目标，回顾学习过程 每个学习单元，与学员进行确认是否可以 课程中加入辩论环节（有意思） 加入表演环节（有意思，亮点） 行动 每日问题 你的课程用过哪些有意思的设计环节？方便的话可以共同讨论。 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！

我的第一次加州之旅 美国来过多次，但加州一直没来过。这次借参加ScrumGathering Austin的机会，来见2个朋友，顺便拜访了一下大名鼎鼎的斯坦福大学。 下面是斯坦福大学的3张照片（主楼区）： 还有一些工程区（Engineering），艺术区的照片，如果感兴趣的可以私聊我分享。 这次加州之旅，先来到旧金山，接下来去洛杉矶（长滩）。 在旧金山经历了几个人生第一次： 第一次飞机早落地30分钟，又原地等待了40分钟（欲哭无泪） 第一次来加州 第一次来旧金山 第一次在美国租车 第一次去斯坦福大学 第一次加油体验 …… 还有很多的第一次 这是我第一次在美国租车，之前一直有担忧，实际开车后发现，大家都很守规矩，比国内好开车。记住规矩： - stop标识符 - yield标识符 - 按标线的车道行驶 - 不随意并线 加油，是一次糟糕的体验。（同一个加油站的加拿大同胞也不会操作） 加油机无法识别信用卡，所以只能预付费。 以下记录旧金山加油站预付费使用过程： 1. 拔下加油枪 2. 放进汽车的油箱口中 3. 别上加油枪的卡子 4. 选择加油的油品（大部分 regular即可，需要根据车型） 5. 1-4准备好之后，就不要动。记住油枪号码 6. 到店内，报油枪号码，预付费一个金额。（需要预估一个数字，半箱油大概20美元） 7. 回加油枪可以看到开始工作了，等加完了。挂枪走人即可。 最后 - 旧金山的气候，真的是一级棒。阳光明媚，气温适宜。 @2019.05 于旧金山机场 行动 每日问题 你最喜欢的城市是哪里？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人