今天我跟吴老师分享的主题是基于Spotify敏捷转型的实践，主要会分几块内容来介绍：
-
首先跟大家介绍我们组织经历过的三次敏捷转型,从Scrum到SAFe到Spotify,包括现在一直在用的Spotify的敏捷转型后的形式；
-
-
Spotify这一块我觉得大家最感兴趣的Squad、Tribe、Chapter、Guild是怎么run的？
-
-
-
最后会跟大家分享一些度量、可视化、成熟度等等我们目前正在做的实践。
这是我跟吴老师的个人介绍，吴老师应该是一个非常资深的敏捷玩家，同时也经常在一些大会如TiD、敏捷之旅、 RSG上面做一些宣讲，同时也担任一些出品人、工作坊等等。目前他是一个技术团队的负责人，同时也是一个类似Scrum Master角色，他们部门叫做IM（Iteration Master），一个DevOps 团队的IM。我就没有吴老师那么专注了，有点不务正业，连头像都是一个开飞机的头像，目前是一个团队的敏捷项目经理，之前也担任过项目及交付经理、PO、SM等职位。
Scrum -> SAFe -> Spotify 三次敏捷转型
我们组织最早的敏捷转型是从Scrum开始的，之所以选择Scrum也有一定的背景，最大的原因是当时的组织，在六、七年前，有一个非常沉痛的痛点，他们的应用集每年的 revenue或者说每年营业额大概有几百亿美元，然而上线的频率只能做到一年四次或者说每季度一次，现在的需求变更来得非常的快，这一年四次的上线已经远远满足不了变更需求的发展，所以必须得开始做敏捷转型。
敏捷转型这一块，我相信很多团队也会有同样的情况，就是对Scrum可能相对比较熟悉，尤其是团队级别的，所以一开始在众多的敏捷框架当中，首先选了Scrum敏捷框架，所以我们的敏捷转型从Scrum开始， Scrum这一块我觉得大家应该都挺熟悉，不熟悉的话可以找Bob老师去拿个CSM的认证，打个软广告。这个是大家应该比较熟悉的一个Scrum框架。
组织在运行Scrum的时候，像大家比较熟悉的一样，做了一些物理的看板，比如说最常见的画了一些燃尽图曲线，把团队的效率或者速率给标出来，做了一些看板等等，这都是Scrum当中相对来说比较常见的一些敏捷实践。
Scrum对于百亿美金的一个大项目来说，可能不能解决全部问题，当然它带来的好处是显而易见的，比如每个人都开始接受，至少是接触敏捷这个概念，让团队要按照Scrum的方式进行运作，3355(的概念），也尝试了一些看板等等其他的一些敏捷的可视化，并且团队级别的迭代和交付变得有效和频繁了。当然它最终还是没有解决一年四次的组织级别的交付问题，在我们来看它没解决的问题还是有挺多的，
（如）几百人多团队合作中的需求的优先级排序，敏捷主要运用在那些开发测试人员当中，也就是我们说的开发团队；最关键的一个问题，Scrum没有帮我们解决跨团队的交付依赖。当然后面还会提到这个问题其实过了挺久才被解决。
关于Scrum我们相当于做了一个回顾，我们有这些做的好的，做的不好的，接着我们就又开始转型，既然根据刚才的痛点，之前的Scrum只能运用在团队级别，并且跨团队的优先级解耦，这些都没有解决。
我们又开始敏捷转型，这次我们选了一个SAFe的框架， SAFe我这个图截的比较小，因为受制于版面的关系，可能上面还有 Portfolio level，上面还有好几层，这里只截了一个SAFe Essential那一个。SAFe里面的角色、各种各样的实践看起来就相对规范，所以当初我们认为SAFe可能能更多的解决刚才的那些痛点，我们就尝试着去运行 SAFe，去玩发布列车等等。
SAFe我们运行的时间不久，甚至还没有第一阶段Scrum run得久，因为SAFe run了一段时间以后，发现了它的好处，也马上发现了它的不足。相当于我们做回顾一样，又发现了它的不足。
先说它的好处，每个人开始接触或者说接受企业级敏捷的概念，并且团队按照发布火车做规划和交付，并且有之前Scrum的基础，我们团队或者说组织级别在做估算、做回顾等等这些敏捷实践方面已经上升到另一个层次，相对来说更精确更有效，但SAFe也给我们带来一些不足，或者说SAFe它本身这个框架没有解决我们团队的问题。
首先几百人多团队中同时开启的发布列车太多，大大占用团队的时间和影响团队的士气。最关键的一个问题就是跨团队的交付依赖。
所以SAFe我们运用的时间其实真的很短，就一年不到的时间，正因为SAFe和Scrum还是没有能解决我们全部的痛点，我们同样的先下来回顾一下，看看我们接下来要选择怎样的一个框架。
SAFe和Scrum，几年run下来，我们发现做得好的地方有很多，每个人包括Team都开始接触敏捷、企业级敏捷这些概念，Scrum也用得很成熟，能用一些比较多的可视化的工具，回顾、估算这些敏捷的一些实践也做得更加的有效，同时也开始有频繁的有效的迭代和交付。一开始我们说的一年4次那种非常低频率的交付，在Scrum和SAFe两阶段run下来以后，相对变的没有那么的低频率，但还是没有办法做到每周一次或几次，甚至是每天一次那种交付频率。
做的不好的刚才也提了，目前我们run Scrum和run SAFe ，团队中大家都run的比较累，几百人当中开始的团队train太多，优先级排序的问题同样存在，最关键的是交付依赖还是没有办法解决。
我们开始看一下我们需要提高什么，有了需要提高的点，我们就可以选择下一次我们需要选择的敏捷框架。
需要提高的点，首先是需要更大范围的参与敏捷。之前只是技术团队，现在业务团队也得参与进来，业务团队进来以后就能够做到更有效的理解需求和优先级排序。这个问题其实一开始就有问题包括SAFe的时候也一样，跨团队交付依赖，从Scrum开始就已经有问题，可视化，这个应该是玩敏捷团队基本上都会涉及的一个问题。可视化永远都不嫌它做的多，因此我们就进入了我们的敏捷转型的3.0模式。
Spotify可能大家在国内因为某些原因用的不是特别多，它是起源一个瑞典的音乐平台，它背后是有一个运维团队，这个运维团队最重要的是建立了自主运营小组Squad。这Squad尽量小组独立，减少组件依赖，尽量避免共有的大型项目。如果做得好的话，很大程度上它能够解决刚才一直在提的一个问题：跨团队的交付依赖。因为我们一直没有解决跨团队的交付依赖，所以我们这次尝试选用了Spotify这个框架。
使用Spotify之前，我们还做了一件非常惊天动地的事情，那就是扁平化的组织变革。之所以要这么做，原先的组织可能层次层级太多，大家知道敏捷宣言里面也说了个体交互高于文档，那么我们文档被淡化了以后，个体交互也就是说沟通成本会很高，如果组织级别还是很多，你的沟通往上汇报的沟通的效率就会比较低下。所以老大们也做了一个非常大的变革，也就是扁平化的组织变革。
我可以给大家先看一下左边的这张图，左边这张图看起来挺扁平了，最上面的是一个领域，一个领域负责一个业务，一个领域有可能（当然也不是一定）分成若干个子领域，负责若干个子业务或者子业务集，每个子领域下面就有了若干个 tribe，也就是我们说的部落，放大了看右下角这张图，每个子领域里面可能有若干个部落，每个部落里面也有小分队，但从这个角度来看，大家可能觉得好像也没多少扁平，只是我画的比较扁平。
我们来看下一张图，同样的我们把其中的一个子领域拿出来，给大家做一下介绍。
这个子领域，就是我跟吴老师之前在的那个子领域，这个子领域目前有大概300个人，先给大家一个概念，300个人通常情况下可能是一家比较具有规模的公司，这种公司通常情况下可能会有普通的下面的小组长、上面的中层领导、再上面的高管、最上面董事长等等，可能层级会相对比较多，至少也有三四层。
在我们组织当中是经历了扁平化的组织变革以后，这300个人的组织，假如说我们是一个非常普通的底下员工，比如是一个开发，或者是个测试，或者是个产品经理，在我们头上只有两层的老板，也就是说我们头上有一层老板，再往上就是子领域的大老板，试想一下，如果一家300个人的公司只有两层，或者说只经过一层就能汇报到总经理或董事长那个级别，其实它还是相当扁平的。我们怎么来看这个组织，左边红红和黑黑的文字分成两种，红的代表他是个老板角色，黑的代表他是非老板角色，就普通员工，比如说Product owner、产品经理、Iteration manager（就是Scrum master）、下面BA测试、开发等等。
在上面的三个角色是老板。事实上这老板只有两个角色，并不是三个角色，最上面顶层Sub-domain Leader子领域的老板，他是真正的老板，下面的Tribe leader和 Squad FLL Co-located leader其实都是属于一线经理，也就是说tribe leader（部落的leader）是由一线经理担任的，这是每个Squad的leader，小分队的 leader也是由一线经理担任的，他们之间没有那种汇报的关系。比如说我这个子领域中有5个部落。每个部落有3个分队一共15个小分队，这15个小分队就会有十几个一线经理，这十几个一线经理，其中个别也同时兼任部落的Tribe leader。
这中间看起来有几层的Leader，但是他真正的Manager只有两层，最顶上的Sub-domain Leader和下面的 Tribe leader或者Squad leader，这就是一个扁平化的组织变革，变完以后，从开发测试、产品经理product owner，到最顶层的Sub-domain Leader，只要跨一层一线经理，那么沟通效率就会大大提高。目前是3层，原先这里是5层，也就是少了两层，沟通效率应该就会提高很多，大家可以设想一下。
Squad, Tribe, Chapter, Guild
讲完了扁平化的组织以后，我们就着重来看一下我们 Spotify模式下面我们的Squad-Tribe-Chapter-Guild这些。
我们从小分队这边再从头讲起，小分队有一个最大的特点，它有原子性，也就是说它能够负责端到端的交付用户价值，每个小分队里面所谓的原子性，或者说当端到端交付用户价值，它是怎么体现的呢？
每个小分队里面都有前端开发、后台开发、测试、产品经理等等，我们敏捷团队的所有角色，每个小分队里面都是有的。我觉得很多公司在没有玩敏捷之前可能都有一个现象，各个部门不是按照（业务）功能来划分的，而是按照前端、后台或者说测试开发来划分的，这样划分的结果每个部门都是没有办法端到端的交互用户价值。比如说我们是个开发部门，但它不经过测试是没有办法端到端交互用户价值，所以Spotify Squad或者小分队，或者我们玩的Scrum团队也一样，有了端到端的用户价值，它就能够最大程度上为用户及早的交付价值。也就是说我们刚才说的跨团队的交付依赖，可能从Spotify上面能够得到解决。
接着往下看是不是真的解决呢？这就是小分队Squad。
那么在小分队中间有一些比较有趣的实践，比如说各个小分队的组队，还有一些合作的契约，比如说像这边提到的按时参加会议、开会时站在看板前、每个人都对质量负责等等。
小分队以后，往上面一层就是部落Tribe。部落这一层，就是刚才我们之前那几张PPT上面讲的，它是由几个小分队组成的一个应用集，这么一个大的团队，每个小分队部落就负责好多个应用集，或者说一个大一点的应用集。部落这一块的实践，我们这边等下一起讲。
先讲后面的分会，分会是在部落里边干同样的事情的人的一个集合，比如说部落里边有干同样的事情的，有BA有干同样事情的测试等等，或者说有干同样的事情前端开发，这些人集合成一个分会。
还有一个是协会，协会通常是跨部落的，它是兴趣小组，比如说我们组织当中有一个比较重要的协会，就是敏捷教练的协会，它跟分会其实是有区别，分会是在一个部落当中干同样事情的人的集合，而协会不管他们同样的事情，它主要是由于兴趣而产生。
比如说敏捷教练他可能是个前端开发比较拿手的人，他还可能是一个测试等等。所以协会之间的人干的事情可能不尽相同，这边就有一个实践，我觉得比较好可以分享给大家。
这边我们有一个敏捷教练协会，在每个部落中间，甚至每个小分队中间去播撒一些敏捷的积极分子的种子，让这些敏捷积极分子孵化如何成为敏捷教练。目前的敏捷积极分子是一个分会，我们这边叫Champion chapter，敏捷教练是Coach协会。Coach guild。
首先每个小分队都会有一位敏捷的积极分子。在每个部落当中就形成了Agile champion的chapter，敏捷积极分子的 chapter。怎样的人是敏捷积极分子，首先他应该是工作在团队当中，然后他是去支持和指导周围人 Being Agile。通常我们都在“做”敏捷实践Doing。积极分子它的作用是让大家从Doing往Being去转变，怎么转变呢？通过实践向大家展示如何敏捷，它并不是教科书式的灌输，这个需要这样做那个需要那样做，而是通过一个实践，比如说我们开个回顾会、我们有这样一个比较好的开回顾会的方式，我们来尝试一下，用这种方式来开回顾会。就通过实践来向大家展示如何敏捷，怎样的人算是积极分子呢？
首先他对敏捷富有激情，还有一定的基础知识，比较重要的一点，他不能是个Squad leader或者 Tribe leader，也就是说刚才提到他不能是个一线经理，如果是经理的话，可能人家就会因为他是经理，这样自组织可能就会受到一定的影响，如果他不是经理，大家之间相对来说都是比较平等的关系，自组织就比较容易形成。
最后一条，积极分子需要与敏捷教练结对，也就是我们刚才所说敏捷教练协会当中的跟敏捷教练协会当中某个敏捷教练去进行结对。
这些积极分子成为了一个积极分子chapter，这么一个分会，它的目的是什么呢？很简单，在整个组织当中扩展敏捷，将敏捷成为一种工作方式。它有几个目标，首先通过这么一个敏捷积极分子的网络，提供一些现场的培训教练支持，将敏捷作为一种工作方式，在各级传播，并且使这些积极分子成长为敏捷专家，或者刚才说的敏捷教练，这样整个公司各个层面、所有业务领域都有广泛而深入的敏捷专业知识。所以Agile champion chapter和刚才的Agile Coach guild的要做的事情，就主要focus在这一块上面。
这里几条都是关于Champion chapter，既有他们的一些实践，积极分子分会Agile Champion chapter有一些实践，首先有一个定期的会面，我们会去讨论一些话题，我们比如说接下来一段时间，我们需要做一些什么实践，带到Team 当中去，同时我们也会把它分成几个迭代往各个team里面去做，相当于用敏捷的方式来run一些敏捷的实践。像这几张图片上面，就是积极分子会定期的做了一些回顾，Which is expected。同时积极分子的分会也会做一些敏捷知识的竞赛，这一块可能大家就看得比较欢乐，在做一些敏捷知识的竞赛。
敏捷教练的协会要做的事情主要是分为几条：一个是工作坊的Facilitation；成熟度的assessment，就是成熟度的一些测评；教练引导 。并且敏捷教练协会也会提供一些课程，这些课程如果都通过，基本上就属于敏捷领域在组织层面的专家，并且敏捷教练协会也会搜集一些比较好的Best Practice，收集上来，放到内部站点上面给大家分享。
下面还有一个话题，就是跨团队的解耦协作以及过程改进。跨团队解耦协作这一个之前我应该一直都在提，我们组织每年的营业额非常的大，然而一年只能交付4次，最大的问题，使用Scrum与SAFe还是没能解决的，最大的问题就是跨团队的解耦。
使用Spotify以后我们发现这个问题几乎被解决了，我这边还是说几乎，因为可能他还有会有一点问题，我们接下来还会提到，基本上是被解决了，因为我们看到 Spotify这个模式里面的小分队 Squad，它已经能够做到端到端的交付用户价值。
所谓的原子性，把原先的大系统给解耦到每个小分队当中，让每个小分队来承担其中一个或者几个应用，每个部落来承担一群应用形成的应用集，跨团队的解耦就这样基本上完成了。解耦以后的协作，我们采用一些实践，像左边图上面有Scrum of Scrums形式，这个可能是Scrum@Scale里边比较常用的，我们这边也借鉴起来，然后也用了一些右边列的工具，如JIRA、Trello。
-
JIRA可能是相对重量级的工具，能够把一些流程给运用上去，一些Workflow给运用上去。
-
Trello是个比较轻量级的工具，主要适用在Program level比较高层次的应用需求管理。
-
Box folders里面是丢一些常见的文档，虽然敏捷淡化文档，但是我们还是有一些必要的文档。
-
-
每天都有PO和Scrum master的meeting，包括刚才提到的Chapter meeting、Guild meeting、协会和分会的一些meeting。
-
同时也用了DevOps和Github repositories。
然后是过程改进，过程改进这一块，因为刚才也提了我们运用了Spotify这个框架以后，我们能把解耦这个问题最大的一个痛点给解除了，我们也发现做了比较好的一些东西，比如多角色组成的小分队，每个分队都配备了 Product Owner跨团队的解耦，更好的可视化扁平化管理，但还有一个痛点没有办法解决，那就是团队的MVP有点大，交付周期还是很长。虽然从之前的一年交付4次有所提高，可能每两周能交付一次。但是如果需求还是很频繁，每周交付甚至每天交付这种还是没有办法做到。这是因为我们这边从需求角度还需要做一些过程改进，也就这边最右边这一列需要提高，团队需要更多了解这个项目的商业背景，以及度量上面需要更多的考虑投入产出比和商业交付的价值。
于是就又有了一个从需求层面的过程改进，因为刚才我们一直在提 Spotify也好，Scrum也好SAFe也好，可能更多的都是从组织从团队级别的一些改变，需求层面这一块，可能改变相对还是做的比较少。于是对需求层面进行了一个更大层面的一个过程改进。正因为团队级别、组织级别的能力成熟度相对提高，需求层面的改进就变得迫在眉睫。我们是怎么改的？简单来说，每来一个需求，在进入领域之前进行评审，也就是个G1的Review，完了以后发现对我们这个领域有价值的放进来，觉得没有价值的把它剔除，这样需求就进入了这个领域。
接着会有一个 G2 Review，这个时候就会同样的方式，把那些需求对我们有价值的需求放到对应的 Tribe部落当中，把没有价值的需求或者价值不够高的需求暂时的剔除，这样完了以后就到了g3，g3就把所有的需求放到各个Scrum当中，同时也是把那些糟粕给剔除掉。这样看起来可能我们的需求层面，所有的需求至少进到领域、进到Tribe、进到Squad都是相对有价值的需求。但还存在一个问题，有可能有些Squad负责几个应用，那些应用非常的关键，它每次都需要承担比较多的需求或者变更，而有些Squad可能没有那么的关键，承担的需求不是很多，就存在有些小分队吃不饱，有些小分队会撑着这种现象，怎么来解决呢？
这里还涉及另一个过程改进，我们这边叫引进了一个叫做Flexible Squad，自由小分队的这么一个概念，每个小分队可能对自己一直以来负责的应用相对比较专业，但是它也会去学习一些其他隔壁邻居小分队的那些专业知识，这样的话万一隔壁邻居小分队相对来说比较忙不过来的时候，他也能承担一些需求。
这样做的目的很简单，就是为了每个小分队承担的需求相对比较均衡，不存在有的吃不饱，有的吃饱了撑的这种状态，完了以后就能发现类似于这张漏斗图的这么一个方式，所有的需求进来，通过漏斗能够相对的比较平衡的分配到每个小分队当中去。
每个小分队也能够拿到相对工作量比较均衡的工作，这是在需求层面做的另一个过程改进。
我们可以看一下，在经过三次敏捷转型以及一些过程改进以后，现在我们办公区域的样子，没有了部门墙，也没有人与人之间的物理隔离。
纯粹的那些 open office或者open space的工作区间、休息区，因为休息区通常能够碰出一些思维的火花，所以休息区的重要性并不比工作区来的低，讨论区，相比传统的那种封闭的会议室，开放式的讨论区，相对来说就能够更加自由一点。
自由有些时候对大家来说是非常必要的，如果长期关在压抑的会议室当中，大家就不容易碰撞出一些火花，而这种比较open的地方相对大家讨论氛围比较轻松，能够碰出一些火花，更有利于团队和组织的提升。
下面是度量、可视化与成熟度。度量可视化与成熟度这一块，我们可能更多的跟大家分享一些我们这边的实践。
像度量这一块，因为我们每个小分队，每个部落，都有了一些比较成熟的数据以后，我们就度量，相对来说做起来就比较容易。比如这边我们经常在用的，或者说对我们组织来说价值比较大的度量就是一个趋势，主要衡量哪两方面？
-
一个是我们的 story point是不是平稳的在递交，并且跟我们的估算是不是相对比较准确。
-
右上角那张 story个数是不是也相对比较平稳？其实大家可以看到基本上我们这边还相对都平稳，不会存在比较大的估算误差，比如估100个点，只交50个点，这种误差不会有，因为这个是整个tribe的趋势，所以多多少少都会有一点误差。
之所以主要来衡量正反这两方面 story point，其实相对大家比较清楚，我们估了多少，交付了多少工作，右边 的story个数其实也很重要，story个数，有时候我们估的过多，意味着我们的story就太小，太小的话相对还好说一点，如果太大的话就会存在问题，story太大、story个数过于少，就有可能出现某个story的WIP过大，到时候交不了差的现象。
度量和可视化，还有成熟度这一块，我可以给大家补充一些东西。比如说我们系内部有几个系统就自己做了一个系统，再加上一些团队需要的度量指标，比如说右边所列出来的你的我的Velocity是多少，你的 Throughout是多少，以前是手工去添的，大家每一个迭代在JIRA里得到结果后添进去，后来重新做了个系统，直接从JIRA里面去拉数据，所以所有的这些数据都不用再去手工填，都是真实的，因为之前你手工添，可以去改变一些数据是吧？就比较好看一点。
后来这个系统直接从JIRA里去拿了之后，所有数据都是真实的，不用你去改，都是最真实的数据。所以就能根据这个进行度量，每个Squad和每个program都会有一些对比，包括Domain和Sub-Domain都会有一些数据和图形展示出来，随时都能看到这些数据，
现在这些是在JIRA里面，我们使用JIRA的图都会去展示我们每一个迭代的情况，比如说第一个图里面就显示了我们有多少个迭代，最近几个迭代交付了多少，做了多少，又有多少bug这样一些情况，包括Burn down chart都会在系统里面看到的。左下角这个就是你的问题和你现在新开的这种story的一个情况，还有一些健康状况，这些都是我们在每个小队里面，我们在每天开会的时候都会去review一下，观察这个状况怎么样，包括我们的Burn down chart，在迭代结束的时候也会去回顾这些东西，这是我们通过可视化的方式来让大家都能看到目前我们团队的状况、风险等情况。
在图上也会在我们周围的物理墙上也会显示各种各样的一些状况，包括我们现在的一些组织的图，包括组织的人员、还有一些进展的情况，大家这个图有点模糊，因为有些信息可能不方便给大家看，通过这种方式让大家能够包括物理的和电子的两种方式都能可以看到我们整个团队整个Domain、下面的一些Program层面的东西，具体的状况，这是在墙上，现在我们办公区的周围，基本上所有墙上都是贴满了各种各样的一些东西，你到办公区走走一走看一看的时候就会基本上发现团队现在的大概的一些状况都能看到。
另外一个可视化的方式就是Trello，我们现在基本上所有的团队都在用Trello board去展示我们的状况，包括有时候做plan，包括做回顾，比如说retrospective会议，我们也会用这个来做，还有我们一些跨各个Squad的情况，还有一些团队管理的任务，全部都是通过Trello的方式来跟踪。
这一块是度量，从团队成熟度层面分成了15个维度，对15个维度进行了一个成熟度的度量。在度量之前大家经历了一定的实践，并且对自己下了一些目标，通过敏捷的方式对每个成熟度达到哪个程度下了一些目标，在这些目标达成了以后，进行成熟度的度量，当然这都是定期的，目前他们可能是每几周进行一次成熟度的评定。
像这边它分几个程度，从1~5：初始级、实践级、转型级、扩展级到卓越级，brilliant at basics就是做得最卓越的或者最基础的。
可以看到右边上面那张是电子版的，下面那张是实体版的，电子版的那张图，它根据你打分的不同，分了不同的颜色，下面那张右下角那张实体版，实体版可能就有不同的维度来展示，虽然也是不同的颜色来显示它的评分，它有了一些箭头，箭头就表示相对上一次的评价，这一次我们又提高了多少或者降低了多少，当然最不希望看到是降低，降低了多少也会有。
内容来源：敏捷+社区线上直播012期，《基于Spotify的敏捷转型实践》分享实录
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）