学知识拿3000key红包｜｜DeFi里程碑，借款总量突破 10 亿美元,锁仓总量20亿美元

西站每天有秀一下区块链前沿话题的西站秀场，有让你充电的西站课堂，撒让你开心的大红包。

西站秀场，让你关心的区块链前沿话题和业内大咖在这里发光，秀出来！！！

西站课堂，区块链知识提炼，让你边学边拿key红包，多轮100个以上红包等你来拿！今日红包提示：找斜体的“项”字

红包大放送，讲一讲西站红包大放送的规则，每天文章收入的40%全部用来发红包，最大红包雨，只要你敢拿，我们就敢撒，快来接吧！！！

西站秀场

今天区块链秀主题:

DeFi借款总量突破 10 亿美元,锁仓总量20亿美元

DeFi是Decentralized Finance（去中心化金融）的缩写，也被称为“Open Finance”，其本质表达的是一种以去中心化技术为基础的金融生态的总称。在这一生态中包含了去中心化借贷、稳定币、支付、去中心化交易所、衍生品等数字货币分支行业。

去中心化金融DeFi的核心价值是一种零成本链接全球用户和机构的金融系统。作为全新的底层金融设施，DeFi业务需要由分布式账本、基础自由货币以及区块链资产来支撑，而代码是绝对的规则（Code is law）。

当前，DeFi领域的主要应用是，货币发行、全球支付、抵押贷款、代币融资、资产交易和储蓄理财。但是，在法律、用户认知、反洗钱等方面DeFi等发展将面临问题，同时，在技术上，系统容量和跨链交互等问题亟待解决。2020年，DeFi借贷市场高速发展，从百万级别的项目到亿万级别项目的跨度发展，仅仅用了半年时间就实现了。

根据 DeBank 数据显示，DeFi 借款总量突破 10 亿美元，目前为 10.5 亿美元。其中，Compound 平台以 8.27 亿美元，占总体份额 79.1% 排名第一，其后是 Maker 和 Aave。

传统的中心化金融的核心功能是借贷、延伸的话有支付、期货、期权、保证金、投资管理等方面。而DeFi作为开放式金融，作为一种无需许可的金融生态，其功能特性的发挥，首先必然是要围绕传统金融的核心功能的即借贷而进行的，所以在借贷方面， DeFi应用得到了蓬勃发展，如MakerDAO--以太坊上的央行、Compound--自动化商行、Dharma--点对点借贷。

另一个维度来看，根据 DeFi pulse数据显示，DeFi 锁仓总量达到 20 亿美元，其中，Compound 平台以 6.5亿美元，占总体份额 32% 排名第一，其后是 Maker 和 Synthetix。

最近DeFi项目Maker、Balancer、Aave、InstaDapp、WBTC发展迅猛，日增幅都在10%以上，反倒是Compound作为龙头项目，无论是锁仓量还是币价都有回落。

从DeFi项目代币市值排名来看Compound和Maker依然占据着两位。

7月 7 日 11 点 48 分，MakerDAO 通过执行投票，正式提高抵押 ETH 借 Dai 债务上限至 1.6 亿。

Compound目前总持仓14亿，总借贷达到了8.3亿。

传统金融已经运行行多年，DeFi想取代传统金融，并不容易，道路漫长，当前10亿借贷这个体量，在币圈可以说是一个里程碑，值得庆祝一下，但与传统金融体量相比，那真是乌鸦比凤凰,寒星比皓月,驽马比麒麟，DeFi想要金融领域有所建树，未来需要做的还有很多。

DeFi是否可以和传统金融平行存在，以满足不同群体的需求，各搞各的，最后以客户群体需求论成败。

以DAO形式的DeFi托管业务是否可以在这一块探索发展，成为传统金融的有益补充呢。

不需要担保、不需要各种资料的提供，而且在DeFi里的借贷抵押不会影响现实世界的你的信誉，不会因数字货币资产的抵押而影响到你的住房贷款、消费贷款的额度，这或许是DeFi可以独立存在于传统金融的根本。

想想，去中心化金融一大创新，就是根本不用做个人信用评估，仅仅凭数字货币就是可以实现贷款，是不是有点不可思意，虽然在币圈这已很平常，但是你到传统领域试试就知道，区块链改变世界，不会是个空口号！

今天评论秀主题，请大家上墙！！！

【1】：你用DeFi产品做过借贷吗？

西站课堂

今天的西站课堂教你学习区块链项目管理的知识，请你忍上3分钟，一会就下课。

项目范围管理

项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。

项目范围管理过程包括：

5.1 规划范围管理 — 为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。

5.2 收集需求 — 为实现项目目标而确定、记录并管理相关方的需要和需求的过程。

5.3 定义范围 — 制定项目和产品详细描述的过程。

5.4 创建 WBS — 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。

5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。

5.6 控制范围 — 监督项目和产品的范围状态，管理范围基准变更的过程。

图5-1概括了项目范围管理的各个过程。虽然各项目范围管理过程以界限分明、相互独立的形式出现，但在实践中它们会以《PMBOK? 指南》无法全面叙述的方式相互交叠、相互作用。

项目范围管理的核心概念

在项目环境中，“范围”这一术语有两种含义：

1、产品范围。某项产品、服务或成果所具有的特征和功能。

2、项目范围 。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时 也包括产品范围。

从预测型方法到适应型或敏捷型方法，项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中，在项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。

采用适应型生命周期，旨在应对大量变更，需要相关方持续参与项目；因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完项）。在一个迭代开始时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建WBS。相反，在预测型项目中，这些过程在项目开始时开展，并在必要时通过实施整体变更控制过程进行更新。

在适应型或敏捷型生命周期中，发起人和客户代表应该持续参与项目，随同可交付成果的创建提供反馈意见，并确保产品未完项反映他们的当前需求。在每次迭代中，都会重复开展两个过程：确认范围和控制范围。相反，在预测型项目中，确认范围在每个可交付成果生成时或者在阶段审查点开展，而控制范围则是一个持续性的过程。

在预测型项目中，经过批准的项目范围说明书、工作分解结构（WBS）和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础。而采用适应型生命周期的项目，则使用未完项（包括产品需求和用户故事）反映当前需求。

项目范围的完成情况是根据项目管理计划来衡量的，而产品范围的完成情况是根据产品需求来衡量的。在这里，“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。

确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授权的相关方正式签字批准。因此，相关方需要在规划阶段早期介入（有时需要在启动阶段就介入），对可交付成果的质量提出意见，以便控制质量过程能够据此评估绩效并提出必要的变更建议。

目范围管理的发展趋势和新兴实践

需求一直是项目管理中的重点，并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂，组织开始认识到如何运用商业分析，通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始。根据《需求管理：实践指南》[14]，需求管理过程始于需要评估，而需要评估又可能始于项目组合规划、项目集规划或单个项目。

在项目范围管理过程中，收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括（但不限于）注重与商业分析专业人士的合作，以便：

1、确定问题并识别商业需要；

2、识别并推荐能够满足这些需要的可行解决方案；

3、收集、记录并管理相关方需求，以满足商业和项目目标；

4、推动项目集或项目的产品、服务或最终成果的成功应用 [7]。

需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、 实现和维持效益。应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师，那么，与需求管理相关的活动便是该角色的职责。而项目经理则负责确保这些活动在项目管理计划有所安排，并且在预算内按时完成，同时能够创造价值。

项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责，项目成功的可能性就更大。

裁剪时需要考虑的因素

因为每个项目都是独特的，所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包 括（但不限于）：

1、知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系？为了在未来项目中重复 使用需求，项目经理应建立哪些指南？

2、确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南？

3、开发方法。组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测 型方法？混合型方法是否有效？

4、需求的稳定性。项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应型 技术来处理不稳定的需求，直至需求稳定且定义明确？

5、治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南？

在敏捷或适应型环境中需要考虑的因素

对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求。这样一来，范围会在在整个项目期间被定义和再定义。在敏捷方法中，把需求列入未完项。

同学们，下课！去拿红包吧！

红包大放送

西站社区会将每天文章收益的40%将用于红包发放，40%！是的你没听错!

3000key以上用于西站课堂埋点红包，连续多轮更新，上一篇收入越高，发放的红包越多。

快来抢吧！

—-

编译者/作者：EOS西站社区

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。