逃离传统项目管理百慕大三角

敏捷项目管理的关键点

敏捷提倡迭代递增交付，完全不同以往的开发方式

    什么是敏捷？相信大家一定对这个话题比较感兴趣，敏捷是相对于其他一种研发模式来讲的，比较典型的研发模式称之为瀑布开发。以大家最熟悉的电商购物来讲，在瀑布开发模式里，相当于要在三个月或半年之前跟电商网站说，要买什么东西，把你所要的东西全部列出来，一键下单，然后电商网站收到后，过了三个月或半年之后，你收到一个大集装箱，把你所要的东西全部拿到手里，开始你可能会比较开心，收到了自己期望已久的所有商品，但你很可能又会比较郁闷，因为很多东西已经过时了，现在不太想要了，这是传统的项目管理映射到在线购物的一种场景。

    而敏捷就像现在我们在网上买东西，今天下单明天就可以收到，再有什么需求可以再下单，很容易收到。在敏捷里提倡的是快速响应和快速交付的过程，通过快速交付和快速的验证需求，也是一个不断试错的过程。在现在的电商购物中，我们都喜欢第二种购物方式，今天下单，明天就拿到想要的商品，再有什么新的需求就重新再下一个新的订单好了。同样，客户也会更喜欢敏捷的交互方式，表面意义上，敏捷可能意味着快，但不仅仅是快，敏捷更重要的是在于响应客户的需求，它通过快，来响应用户的需求，这离不开一个非常重要的8020准则，也就是软件开发领域里经常提到的，20%的功能能够满足客户80%的需求。

    在这个调查报告的数据中，StandishGroup发现，有45%的功能是用户从来就没有用过的，用户总是在用和经常在用的分别是，7%和13%，这二者加起来是20%，如果说我们把用户最关注的和最重要的20%甚至30%找出来，就能够做的少、做的快并且做得更精，而且客户百分八九十的需求已经得到了满足，用户也会更早的实现他希望的结果，这是敏捷之所以能够快起来非常重要的出发点。

敏捷从不同角度考虑“铁三角”

    基于8020准则，才能够把传统的项目管理做一次颠覆，传统的项目管理实际上是左边这个三角，其中有一个确定不变的东西是功能，也就是需求，我们会假定所有要做的需求全都不变。基于这个假设情况下，调整两个参数，时间和资源，如果项目紧，就多放点资源，反之，就少放资源慢慢做，无非是制定一个计划，按部就班的去执行而已。

    在敏捷的项目管理把这个三角形倒过来了，倒三角形里确定不变的是时间和资源，这时候可变的是功能或需求，这意味着我们要在有限的时间和有限的资源的情况下，决定做哪些事情，这意味着我们不能把所有的需求一视同仁，需要进行一个排序，按照客户价值重要性的维度来进行排序，所以在敏捷经常讲客户价值驱动，也就是说先做对于客户价值最重要的事情，然后再慢慢地考虑其他事情。

敏捷迭代可及时调整中间过程，直至实现最终目标

    这是一个关于打靶的图，传统的项目管理相当于什么提前在瞄靶，而且假定这个靶是不变的，很多情况下，我们对需求的理解也就是瞄靶的过程，有可能会出现两种场景，第一种场景是我们对需求有偏差，相当于我们对用户的目标，理解错了也就是瞄靶瞄错了，还有一种可能是即使理解对了，瞄也瞄准了，但是现在这个靶是移动靶，移动靶意味着客户在三个月之前提的需求，现在已经在变化了，因为我们已经进入到一个新的时代，在移动互联网时代，三个月的迭代节奏，相当于过去的一年，实际上是非常快的。在敏捷里要承认，需求会不断变化，如果面对移动靶，更有效的做事方式应该是边开枪边瞄准，也就是说不断迭代递增式交付，不断地去跟客户去交付产品获得用户的反馈，调整做事的过程，一定能够最终命中目标，取得最大化的商业价值。

正确理解需求是逃离传统项目管理百慕大三角的出口

需求直接决定一个项目的成功与否

    这是一个网上流传已久的需求漫画，客户最早是这样来描述需求的，他想要一个梯子，能够挂在树上，项目经理或者需求分析人员理解的需求还可能被树给挡住了，这时候架构师会觉得这个需求有些不合理，需要进行修正，架构师做了如下的修正，真正再把需求传递到开发人员后，开发人员写出的代码可能是这个样子，测试人员收到的东西并不一定就如开发人员所声称的那样，依然会有偏差，最终测出来的东西再交付给商务顾问去做描述的时候，一般来讲销售人员都比较厉害，能够把这个事情说的非常好。很多时候项目文档也不一定能够展示出来项目的真实场景，软件安装的过程再产生一些偏差，这样直接会导致客户对这个项目进展和做的产品不满意，用户的付款也经常是一波三折，用户付款之后必然离不开售后支持，我们的支持可能对产品和需求的理解不够准确，也会出现偏差，回到前面，客户真正的需求只是需要一个绳子，把轮胎挂树上就可以了，但是在整个过程中都产生了各种偏差，最终会导致做出的东西跟客户预期产生不一致。

    这是StandishGroup在2006年做过的一个调查，只有35%的项目可以称为成功，按照传统项目管理的三角来说，不超过预算、所有需求都完成而且质量没有任何问题，才算是成功，真正符合这些要求的项目，也就三分之一左右，将近46%的项目其实都有各方面的问题。在这些失败的项目里，经过分析发现，有八分之五的问题都是跟需求相关，只有八分之三的问题是跟管理相关，大多数问题跟技术没有任何关系。一个项目如果失败了，会带来各种各样的问题，不仅产品的上市周期会拉长，而且交付的产品不能够解决客户的问题，也会导致无人问津、资源产生浪费并且团队的士气也开始低落，也有可能会造成人员的流失，所以我们必须保证项目要做的成功。

    客户是慢慢地才能够知道他想要的是什么，开发人员也是慢慢地才能够知道，如何更好地进行开发，知道该用什么的技术，以什么样的方式来跟客户交流，而且更重要的是事情总会发生变化，这意味着在传统项目管理里必须采用不同的方式来应对需求。

写下需求，并不就能解决问题

    给大家分享一个小故事，这个故事是郭德纲老师跟于谦老师说过的一个相声，郭德纲老师说于谦他老爸，以前接过一个特别牛掰的活儿，这活儿完事能挣30万，在那个年代是一个非常好的活，于是，他老爸拿过图纸一看，太简单了，不就是盖一个40米的烟囱吗，把烟囱盖好了请人家来验收一下，结果发包方看了，非常不满意，不仅没给钱还把于谦他老爸给胖揍了一顿，其实人家原始的需求是打一个井，于谦他爸图纸看反了，理解成一个烟囱，跟原始的需求差的十万八千里，人家肯定会不开心了。

    很多时候我们觉得把需求写下来，就应该能够解决问题了，但现实并不会如此。再举两个例子，这是从国外的一个网站上找到的图片，是关于一个蛋糕的图片，一般大家都知道我们预订蛋糕的时候都会给蛋糕店打个电话说我要什么样的蛋糕，一般来讲，接线员会问我们上面要不要写字，有一天，接线员打了一个电话问要不要写字，客户说不写字，留空，留空的英文的意思就是leave blank，于是接线员就把那个蛋糕的需求，关于写字那一块就写了这么一行字，leave blank，蛋糕师傅看到这个需求，于是就把leave blank写上去了，这个就跟原始需求差了很多。

    接线员又接了一个电话，要做两个蛋糕，两个蛋糕写生日快乐，一中一英，所以他就把这两条需求也写了下来，蛋糕师傅看到这个，也会非常忠实地按照这个需求去实现，实际上依然做反了，人家原始的需求是生日快乐一个写中文的，一个要写英文的happy birthday，这些案例讲的是需求写下来，并不能解决问题，这都是生活中的一些案例。

    我们来看真实的科研案例，这是NASA发的关于火星的空气探测卫星，这个卫星发射出去之后马上就控制不住，脱轨了，后来大家就开始找卫星就控制不了的原因，原来它是个跨国界的合作项目，不同国家的人对于轨道计算公式的单位是理解不一致的，我们有公制米制英制，各种知识的区别，没有说清晰，理解错误，结果直接造成1.25亿被白白浪费了。

共享的一致理解一定是团队协作成果

    很多时候，对于同样一份需求，每个人可能都觉得我看了一遍，理解了，但其实每个人理解的东西都不一样，而且人类有一个天然的共性是你愿意去趋同，所谓趋同也就是说，我看了一份文档，理解之后，我会天然的认为我理解的跟他们的理解是完全一样的，但实际情况却完全不一样，这张图中，三个人理解的是完全不一样，有人方框，有人是圆，有人是个三角。在敏捷里，我们采用一些手段，最重要的就是沟通和协作，如果说我们每个人对同样一份需求理解不一致，那么我们就需要相互沟通互相分享各自的认知到底是什么，通过分享可视化之后会发现每个人理解的需求都不一样，那我们就讨论一下，我们为什么会这样理解，经过思想碰撞之后，才会发现原来真实的需求是一个多边多角的圆形。

用户故事三要素背后的背后

    在敏捷里，对需求的一致理解是团队协作的成果，我们会有一个特殊的技术叫用户故事，既然说它是个故事，那么就是希望大家从用户的角度，用自然语言的形式，来描述一个需求。

用户故事三要素

    用户故事有三个要素，分别是用户角色role，也就是说，谁要用这个功能，第二个要素是活动activity，用户需要什么样的功能，第三个要素非常重要，我们称之为商业价值也就是why，这个功能对于用户来讲，到底带来什么价值。对于这三个要素里，功能不是最重要的，更重要的是价值，也就是why，前面在敏捷项目管理三角形里提到过，按倒三角形是按照商业价值来排序的，用户故事跟前面是完全正好呼应的。

用户故事例子

    举个例子，做为一个球员，我想查看赛程安排，以便知道下场比赛的时间和地点，作为一个球迷，我想查看赛程安排，以便知道去哪里看比赛，所以同样一个需求，从不同的用户角度，背后的商业价值是完全不一样的，希望大家通过写故事的形式，把用户真实的需求，背后的背后描述出来，这一点是非常重要的，用户故事写起来很简单，就是三个要素。

    真正写好用户故事需要不断地问用户，为什么这个商业价值很重要吗？假如说，客户提了一个非常明确的需求，客户说请帮我做一座木桥，我需要在很短的时间内实现这个需求，这个需求很明确，所以就开始设计方案，然后快速的去实施，帮客户搭一个木桥，但是你把项目做完了，木桥的质量也不错，你也尽量控制成本，但客户可能依然不开心，因为我没有追问客户，为什么去搭这个木桥，没准客户要搭木桥的原因只是简单的想快速过河，关于过河，我们其实还有很多种方式来实现这个目标，所以我们不知道用户为什么要去搭桥的背后原因的话，就很难提出更有效的解决方案。

    很多时候，用户也不知道他想要什么样的解决方案，他只知道木桥这么一个方案，所以他只会提这样的需求，如果我们简单地按用户所说的去做，依然会偏离很多，一定要问用户需求背后的背后，要找到用户需求背后的这个商业价值why。

    华为的DevCloud平台，为了更好的支持敏捷，也设定了很多工作模式，其中关于需求这一块，有专门预置的用户故事模板，进入这个模板里面就可以看到，每次添加一个需求的时候用户故事的三个要素，已经缺省展示在那里，提示大家按照这三个要素来写需求。

Ron Jeffries的3C准则

    用户故事最早的提出人是Ron Jeffries，是非常著名的敏捷大师，关于用户故事提出一个3C的概念，虽然现在已经把3C扩充到了5C，3C最早的是第一个C叫Card卡片，用户故事通常是写在一张张小卡片上的，内容很简洁，只用三个要素就好，我们需要激发大家的沟通，对需求的一致理解靠的是相互协作和沟通，第二个C就是Conversation，沟通故事背后的细节和原因，一旦我们对于需求达成一致理解之后，需要达成一个确认，就是第三个C，confirmation确认我们这个故事，未来将会做成什么样子，如何去验收。

    DevCloud还支持树状视图，其中我们可以由epic、feature到yourstory的一个列表可能更容易能看到，多个需求之间是一种什么组合关系，而且还可以通过这种收缩关系，看到更多的需求。

用户故事的另一种形式

    用户故事5c里面那个最后的C称之为Consequence结果，就是帮用户实现预期的目标，在用户故事构建出来的那个程序或者是可运行的软件，只能称之为outcome结果，产出称之为output，output不一定产生outcome，如果说构建出来的东西不能跟客户需求去做积极有效的验证，我们就不知道是做对了还是做错了，所以为了更有效的把用户故事落地，我们会把用户故事做一层延伸，用户故事转化成另外一种形式，也就是一种假设，为了验证它，我们将提出一个假设检验，要有目的地去收集相应的数据来证明，这个用户故事代表的需求，真正让用户用它解决问题，而且用户喜欢用，我们把这称之为outcome。

INVEST准则

    INVEST准则这个图中，画了很多硬币，写好用户故事，做好的需求就像投资一样，在前端做好了整个项目就有了起点，所以需求是我们的起点，INVEST的I代表的是Independent独立，需求经常需要调整优先级，不会一成不变，如果需求之间依赖太多的话，那就不容易调整优先级，第二个N，跟3C里面的第二个C，Conversation是相关联的，称之为Negotiable可协商的，协商用户需求的一些细节和背后的商业价值why，细节就是Confirmation验收标准的东西，V是valuable有价值的，就是要找到用户需求背后的商业价值why，E叫Estimable可估算的，S称为Side appropriate大小适当的，在冰山模型里大家会理解大小适当是什么概念，最后一个T是Testable可测试的。

敏捷需求管理的冰山模型及DEEP准则

产品需求列表/Product Backlog

    要管理好用户故事，就离不开冰山模型，在敏捷中会把所有的需求列成一个大表，这个列表从上到下是优先级的，这个列表的名字叫产品需求列表，英文叫Product Backlog，在这个冰山分为浮出水面的部分和沉在水面之下的部分，水面之上的部分，意味着这个需求马上进入迭代开发，它的力度要非常细，这里有一个特殊的定义，DOR，defination of ready和ready for development，要细化到让开发人员拿到一个需求，就知道如何进行开发，所以DOR通常会帮我们涉及到前面提到的验收标准，还有外部依赖，如果做一些web、app项目的话，对应的界面原型也应该准备好了。再往下，中间部分，这个力度稍微粗一点，这个是针对一个大的版本，一个发布release应该准备工作内容。再往下面一部分，我们称之为Future未来，可做可不做的还没想好，只是放在这里边，就是Backlog的含义。

    整个冰山图符合这个DEEP准则，第一个D称之为Detailed Appropriately详略得当，跟前边讲的INVEST的S是一个道理，第二个E是Estimated，就是估算的，第三个叫Emergent涌现，所有的需求它是动态调整的，可能今天在水面之下，明天就把他调整到水面之上，因为他的优先级提升了，马上要进入开发，需求不是一成不变的，未来会根据客户的反馈不断有新的需求加入进来，所以这个冰山的也会不断的变大，但有可能某一天我会发现某个需求，真的已经过时了，没有什么用途，并还没有做，那就可能直接把他抛弃了，那么最后一个P是Prioritized，划分优先级，这个一直都在强调，在敏捷里头所有的需求一定不是一视同仁的，应该是按照用户价值来划分优先级。

用户故事地图

    为了更好地组织用户故事以及进行拆解，还有另外一种工作形式叫用户故事地图，故事地图的出现也是跟前面讲的产品需求列表有关系，如果列表内容特别多，而且内容很繁杂的时候，你会发现我们只见树木不见森林，我有很多需求，但是具体要做什么样子，这个需求之间的脉络关系到底是什么，就不一定很清晰了。用户故事地图也是应运而生，按照用户或者多个用户角色，相互交互的业务逻辑按照时间序列进行依次组合的用户故事，地图的制作也体现了共创，专门有一本书就叫《用户故事地图》，右下角是用户故事地图的发明人叫Jeff Patton，也是在业界内非常有名的一个敏捷教练。

如何做发布规划和迭代计划

    关于如何做发布规划，我们有很多需求，需要作出不同版本，决定什么版本包含什么内容，每个版本大概在什么时间去发布，如果能把用户故事地图跟发布规划结合起来，会得到非常好的一个效果。

从想法到落地计划

    假设我们已经有一个用户故事地图，按照时间顺序从左到右，把多个用户使用产品的交互顺序，以业务逻辑的形式展示出来之后，进行分层细化，比如说先做广度优先，再做深度有限的细化之后，形成一个大的地图，在这个大的地图里边，理论上来讲，缺省的应该是从上到下有优先级的，高一级的在上面，我们画几道折线，就可以把最高优先级的挑出来，组成第一个版本，再画几个折线挑一部分，组成第二个版本，最后，其他的再画几道折线会组成多个版本。

    第一个版本称之为MVP，这个MVP是指最小可行产品，也称之为minimal variable product，它首先是非常小的，同样的又是可行，既为客户带来价值同时是一个完整的功能，能够把它做出来代表Product。很多时候大家对于MVP的划分不得要领，如果你的第一个版本，不能让你觉得不好意思，那就不够MVP。如果说发布一个版本，这个版本太好了，其实有可能就做多了。MVP一定要做最必要的精简内容，因为第一个，我们希望能够更快速地交付一个产品给用户，另外一方面，很多时候我们也不知道，用户想要的需求和真正关心的是什么，用户很多时候他也说不清楚自己想要什么，只有他看到一个原形的时候，他会才豁然开朗，知道自己想要的跟这个差不多，再在某个方向上，去做一些修正优化，就差不多了。MVP有两层含义，快速地验证需求同时避免过度的开发。

    这是在实际过程中的用户故事地图和真实发布计划相结合的实例，在一面墙上，做地图同时做一些规划，形成了一些发布计划。

发布计划与迭代计划的关系

    发布计划包含内容如果比较多，可能会拆分成若干个迭代来实现，现在的迭代周期通常是一到三周，典型的玩法是两周，我一个发布可能两周做不完，大概需要三到四周，一到两个迭代才能够把事情做完，一个迭代可能会包含若干故事，故事又会包含若干个任务，只有把这两个迭代的工作内容全部做完之后，才有可能做一次发布。

    前面规划MVP，内容很简，正好能够在一个迭代完成，一个迭代内完成可能又分两种场景，一种是正好在迭代的边界也是迭代结束的时候完成了，这种你做一次性发布没有问题，但还有可能是很多云的产品，比如DevCloud，已经提前帮你开发了很多套件，部署在云上，有很多基础的服务已经具备了，可能很快就把一个基础版本MVP搭建出来，可能根本用不了两周，这时候就可以根据自己的需要直接做发布，有一句话是说按节奏开发，按需要发布，我们做软件开发做项目本身是一场马拉松，在这场马拉松的过程中的形成一个节奏感，这样才能真正跑完全程，而且效率会更高，所以迭代就是为节奏而产生的。

    当然，发布不要跟迭代进行深度绑定，不能只在迭代的结束才做发布，我们希望大家能够把需求拆解，尽量独立，这样两三个需求做完之后，就可以满足发布，这样叫按需发布，持续交付DevCloud很多理念也是在强调这一点。

DevCloud做计划

    在DevCloud中，做计划是非常容易的，假设我们把所有的需求都以用户故事、树状图或脑图的形式，进行不断的拆解细化之后，接下来做计划的时候就会进入另外一个计划视图，这有项是列出所有未计划的工作项，未计划的工作项就像冰山里面那个大的概念，叫Product Backlog产品需求列表，所有没做的事情列在这里，接下来就可以从高优先级里面挑一部分来，先进行开发。

    在挑选的过程中非常简单，只需要先建一个迭代，迭代里面比如说约定，从7月1号到7月14号，是两周的时间，是一个迭代，建好迭代之后，直接把对应需求拖过去，就把一个排好序的内容拖到迭代的计划中去，这样一个迭代计划就做出来。

    做完迭代计划之后，用户故事需求要拆成任务，在做计划里，DevCloud也非常灵活，可以快速创建小的工作项，这些小的工作项实际上就是一些任务，任务分为前端任务和后端任务，很多时候产品是前后端分离的，后端按模块的划分，还可能涉及到一些架构设计文档的编写任务，这都可以列出来，跟这个需求相关，自动地就会关联起来。

    在整个迭代计划做完之后，DevCloud还会有另外一个视图叫成员模式视图，其中可以看到每一个成员的工作任务安排情况，可以在整体执行一个小计划的时候来判断一下，计划是否合理，大家的工作是不是有冲突，任务的依赖有没有问题，可以提前做一些传统项目管理的风险依赖分析，同时也能从每个人的角度知道每个人到底应该做什么，或者在什么时间内，要完成什么，这样大家也会有更好的自己的管理职能。

    在传统的项目管理，有个角色叫项目经理，他会统控全局，会做任务的拆解分配，制定计划去跟踪。在敏捷中，管理人员会稍微不太一样，现在流行scrum团队会有新的三个角色，三个角色分别承担了不同的管理任务，Product owner主要负责需求，优先级设定，价值的验证和验收。Scrum Master  主要是为大家消除障碍，带领大家去执行项目的流程，还有就是team，更多的是完成产品功能的交互，三个角色把传统管理职能进行了承担，在实际过程中有些组织依然保留了传统的项目管理角色，这是跟当前的业务和业务特性直接挂钩的，在敏捷里，只是希望不要依赖一个人去做管理职责，而是一个所有人自我管理和自我组织的形态。

什么是相对估算？如何做相对估算

估算单位：故事点

    既然用用户故事来写需求，在敏捷里，指需求这个估算单位，我们称之为故事点，它是一个虚拟的单位，它不能映射成理想日或工时，它是基于你要完成工作的一个复杂度，大家做出了一个相对估算，没有任何直接映射成经常用的理想日、理想工时的映射关系。他只是代表相对的大小，一个故事是三点，另外一个故事是一点，我们只是认为，三点的故事是一点故事的三倍大就够了，采用这种方式更容易让我们达成一致。

    比如说，一个写Java程序的，对java程序很熟，但今天进入了新的项目要用Scala，虽然他不懂，但是组内另外的成员对Scala还熟悉，同样的Scala语言，一个需求，另一个成员可能只需要8小时，而他可能要12小时，这俩工作效率不一样，可以先假设一个基准点，都认为这个任务只需要一个故事点，那么对于另外一个故事，可能会要复杂一点，对于另一个成员来讲，可能需要20小时，这个故事是前面那个故事的三倍大，而不熟Scala的可能就要花40小时左右，本身因为语言不熟，所以效率比较低，但是不妨碍这个故事是前一个故事的三倍大，这样的话大家通过相对估算，都容易达成一致，如果用绝对估算，绝对会吵起来，这个就不合理。

    使用用户故事呢，会更容易让我们达成一致，用户故事估算中故事点不是理想工时，所以不能够映射成工期（Duration），用户故事很有效，就是因为人类特别善于估大小比大小，做估算是一个特殊的数列，这个数列是斐波那契数列，所以用户故事估值那个点，通常取值是一、二、三、五、八、十三、二十一、三十四，用户故事会经常进行拆解，斐波那契数列正好符合这种形态，之前一个大故事我们做过估算，重新进行拆解之后，用户整体需求的规模不会有太大的变化，对于需求，也就是用户故事，用的是相对估算，取值取一、二、三、五、八、十三、二十一这些值，不能做平均。

计划纸牌（Planning Poker）

    有一种道具叫Planning Poker估算纸牌，大家通过打牌的形式，实现用户故事的一个估算，用户的需求的理解是通过团队协作的一致理解来达成的，我们通过打牌，可视化每个人对需求的理解，我理解认为这个需求是三点，另外一个人可能认为这个需求是八点，我们因为不同，所以可以快速的沟通一下，为什么你理解成八点，我理解成三点，没准你考虑的场景更复杂，而我忽略了什么，我认为是三点有可能是我找到了更容易的实现方式，通过打牌可视化，把不一致的理解可视出来，然后通过沟通来解决，所以估算得到这个值，既重要也不重要，其实最重要的是沟通。

另一种估算方法T-Shirt Size

    除了估算纸牌，用户故事，故事点，这种估算形式之外，有时候还会用更简单的估算方式，T-Shirt SizeT恤的大小，只有三个值，大中小分别代表了321，如果太大可以拆一下，基本都符合这个规律就可以了，具体采用什么形式，每个团队都有自己的倾向，关键是在需求理解，一定是通过共享的一致沟通协作来达成的。

推荐书籍

    希望通过今天分享的内容，帮大家打开一个新窗口，在传统的项目管理里，经常会遇到很多问题，在敏捷里把三角形进行颠覆，更多地去树立，用户价值、排优先级、不断迭代交付的思路，帮助我们快速实现用户需求的确认和验证。我们希望这些总结和反思，能给正在实施敏捷或将要实施敏捷的朋友们，提供有价值的参考和指导，让大家少走一点弯路，早日实现敏捷项目开发。

 视频链接：https://huaweicloud.bugu.mudu.tv/watch/b7kdpeml

以上文字内容由【内容众创兴趣小组-SUNSKY】整理。