李攀

一起长大 Kubernetes Serverless 实践

i@lipan.me (李攀) — Fri, 10 Jun 2022 00:00:00 +0000

背景

一起长大服务端技术架构一直跟随着云原生的发展方向，云原生让我们适应了业务高弹性的场景，满足了业务高峰的需求。

但如何让云原生资源利用率更高，用更少的计算节点承载更多的实例，降低资源开销，提高服务的可用性，是我们一直在探索的。最近两年持续升温的 Serverless 具备弹性伸缩、按量计费、无需运维等优势，是解决上述问题非常好的方案之一。

公有云厂商有很多 Serverless 解决方案和相关产品，包括函数计算， Serverless 应用引擎，Serverless 容器服务，弹性容器实例等等。调研和试用以后发现，很多产品屏蔽了底层的 Kubernete，更适合于没有 Kubernetes 基础设施的团队来使用。一起长大从 2018 年就已经开始通过运用 Infrastructure As Code (IAC) 的方式使用云厂商的 Kubernetes 基础设施，所以云厂商的上述 Serverless 解决方案产品对我们没有太多的帮助和价值。

选择

因为一起长大的业务有着明显的波峰和波谷，我们选择了 Kubernetes Serverless 虚拟节点的方案，阿里云 ECI 就是一种典型 Kubernetes 虚拟节点方案，对已经运行在 Kubernetes 上的服务其实没有实际差异，在高峰期弹性调度到 Serverless 虚拟节点会带来巨大的收益。

Kubernetes Serverless 虚拟节点

虚拟节点并不是真实的节点，而是一种调度能力，它将标准 Kubernetes 集群中的 pod 调度到集群服务器节点之外的资源中。部署在虚拟节点上的 pod 具备一致的安全隔离性、网络隔离性、网络连通性，又具有无需预留资源，按量计费的特性，架构如下图：

成本试算

一起长大所有服务都是容器化部署，业务有着典型的高峰期，且高峰期持续时间不长（6 个小时 / 每天），全部使用包年包月服务器，低峰期负载只有 30% 左右。所以一起长大的场景本身就非常适合 Serverless 的弹性伸缩落地。

做一个简单且粗略的计算：假如全部使用传统节点单位规格时间成本为 C，平均每天高峰期的时间为 6 小时，使用同规格 Serverless 的单位规格时间成本为 1.5C，那么：

全部使用传统节点的总成本为每天 24C
保留 60% 的传统服务器，高峰期增加 40% 的 Serverless 来应对，此时的总成本为：24C * 0.6 + 1.5C * 6 * 0.4 = 18C

理论上高峰期波峰部分使用 Serverless 可降低的成本为：(24C - 18C) / 24C = 25%，成本降低的效果是很明显的。

调度、扩容与缩容

使用 Kubernetes Serverless 虚拟节点，调度主要存在两个问题：一是扩容时创建 pod 基于何种调度策略调度到虚拟节点，二是缩容时应优先缩虚拟节点上的 pod。

阿里云支持添加 Annotations 来声明只使用普通节点的资源或者虚拟节点的 ECI 资源，或者在普通节点的资源不足时自动使用 ECI 资源，这已经可以满足大部分场景对弹性资源的需求了。

除了调度到虚拟节点的能力外，我们还配合了 Kubernetes 本身的 hpa 及 cronhpa 同时使用，来满足业务更灵活的需求。

缩容时应优先缩虚拟节点上的 pod，这个是需要修改调度器的调度算法才能实现的。

TODO

扩容：修改调度器，设置阀值，将超过阈值的 pod 调度到虚拟节点上，而不是资源不足的时候才到虚拟节点。这样既能满足集群节点的利用率，也能满足性能的要求。阈值太低可能会造成资源浪费，阈值太高可能造成资源利用率过高，甚至影响业务。

缩容：缩容时优先缩 serverless 虚拟节点上的 pod 很好理解，因为包年包月的节点单价更低，虚拟节点上的资源是按量计费的，单价较高，优先缩虚拟节点上的 pod 可以达到成本的最优。

附图，通过 k9s 工具看到的集群中的传统节点和虚拟节点状态。

云原生成本优化实践

i@lipan.me (李攀) — Wed, 09 Mar 2022 00:00:00 +0000

在全行业上云的进程中，最大的赢家可谓是公有云厂商，随着云原生越来越火，越来越多的企业也意识到使用云原生的优势：不再关注下沉的基础设施，更敏捷地实现组织转型、产品迭代、应用交付效率。虽然各行业也开始关注上云成本，但是鲜有具体的实践案例，主要有几个原因，对于大厂来说，资源不是问题，根本不用关注这个问题；对于小厂来说，研发支出和研发绩效不挂钩，业务压力那么大，为何要花时间去考虑云的成本，压缩云上资源甚至可能牺牲 SLA，而且还需要跟产品、市场跨部门沟通，很多时候还需要研发资源，财务或者老板也不懂技术，不知道这里面有多少浪费和可优化的空间，所以没有人去做这件吃力不讨好的事情。

我看了一些关于云上如何降本的文章，都是大方向，没有任何落地的实战，近期我们做了大量的优化，降低了 30%+ 左右的云计算成本，下面从我们的实战中，具体分享我们落地层面的一些行动。

在优化前，我们每月的云服务成本构成图大概是这样的：因为有特殊的运营需求，我们忽略掉 1 月份的短信服务。从这两个月的成本构成上可以看出，我们支出的大头在 OSS、CDN、ECS、ECI、PolarDB 这几块，所以，要优化云成本，我们从这几块入手，更容易看到成果。

OSS

因为业务特殊性，我们产品有大量的图片和视频上传，目前 OSS 的规模在近 300T 左右。OSS 费用主要是三部分：存储费用、CDN回源流量费用和图片处理费用。

降低存储费用的直接方式就是在可接受的范围内减少存储的容量，因为业务特殊性，销售付费转化和上传的媒体数量是有正相关性的，所以产品和运营侧会不断促使用户上传更多的内容，所以不可能限制用户上传的数量，那优化上传后的文件大小是一个容易想到的方向。因为近几年视频内容的流行，用户上传视频内容的比例在不断增加，虽然客户端在上传视频前做了一步压缩处理，但是这个压缩是有限和耗时的，所以上传上来的视频仍然会比较大。我们之前是没有对这一块做特殊处理的。

这次我们使用阿里云的媒体处理功能，通过设置工作流和管道，每一个上传到 OSS 的视频会自动触发转码，用阿里云的窄带高清转码出来的效果对用户来说在手机上感知到的差别非常小，但实际的文件大小约为原始大小的 1/5 - 1/10，这里通过增加一次性的媒体处理费用，来换长期需要付费的存储空间费用，是非常划算的。另外，根据业务场景，对已经不在使用产品的用户的媒体内容，进行定期的压缩，压缩后满足用户回归再查看时不受影响无感知即可。

CDN

CDN 主要的费用就是流量费，那优化的方向也很明确，那就是降低流量。从技术角度来说，能做的几个方向是：

客户端每次加载的图片资源根据展示容器大小按需加载对应尺寸的图片，通过 OSS 的图片处理参数，拼接对应的宽高，而非加载原图。这个是最基础的，不仅是节省流量的大头，也可以大大提升客户端图片的加载速度，提升用户体验。
在上述宽高的基础上，增加 OSS 图片处理支持的其他参数，比如格式使用 webp ，用户几乎无感知，图片大小可以减少 20% - 50% 左右。比如图片质量设置为 80%，用户也几乎无感知，图片大小可以再减少 50% 左右。这两个参数可以让整体的图片大小减少到之前的 30% 左右，换算为 CDN 成本就是 70% 实实在在的降低，而对于用户来说，体验不降反增。

ECS

ECS 在我们的场景主要是 kubernetes 集群的节点，节点数和 kubernetes 容器规模是相关的，所以优化 ECS 的根本是在优化每一个 deployment 的配置和弹性伸缩的配置。

kubernetes 看一个节点是否能调度更多的 pod ，统计的指标依据是 requests，我们每一个 deployment 的 resources 设置原则一般是 limits = request * 2，hpa 设置的扩容阈值是达到 requests 的 100% 的时候（当然也有特殊的情况），这样，当一个 deployment 的所有 pod requests 均值到 100% 的时候会自动触发扩容，这在我们实践下来是一个安全且资源利用率最高的规则，在 SLA 和成本之间找到了一个非常好的平衡点。

ECI

ECI 的使用我们踩了不少坑，花了不少冤枉钱，其中最大的坑在于阿里云默认对于不设置 resources 的 pod 会给一个默认的 2C4G 的规则，这个规格按量付费的价格是 0.44 元/小时，一天成本高达 10元左右，如果整个集群所有服务都不设置，这部分的开销可谓是非常高的，我们之前一直在优化 ECI 的费用，收获甚微，近期发现这个点以后，我们把所有 resources 都设置为 0.25C0.5G 且部分迁移到云原生服务以后，ECI 的成本降低了 70%！

PolarDB

我们从 2020 年开始将核心业务数据库从 RDS 迁移到 PolarDB，PolarDB 解决了之前 RDS 很多问题，比如只读节点扩容耗时非常长的问题，因为底层数据需要做一次完全的复制，PolarDB 因为底层数据是共享的，所以可以做到分钟级的节点扩容，这让我们在数据库计算层可以从容应对高并发高流量。但底层的支持是一部分，数据库扩容的触发条件一般是 CPU 阈值，CPU 高的主要原因一般来说是为命中索引导致的扫描行数多导致的慢查询，业务层如果优化到位的话，是可以减少底层节点扩缩容的频率的。这时合理运用阿里云 SQL 洞察功能去分析耗时占比高或者扫描行数多的 SQL，针对性地去优化一波业务查询是非常必要的。这期间我们对于索引优化、 json_contains、隐式转换等方面的优化大大降低了数据库层面的 CPU 负载，极大减少了数据库节点的扩缩容频率。

后续方向

Serveless 这两年开始逐渐升温，对于短时间的流量洪峰，Serveless 是非常合适的，不长时间占资源，可以充分享受云原生的弹性和按量，对于成本的节省是非常可观的，这将成为我们后续某些场景考虑的重点方向。

关于 To B 的一些落地打法思考

i@lipan.me (李攀) — Sun, 27 Dec 2020 00:00:00 +0000

近段时间思考 To B 的落地打法，总结和记录了一些观点，希望能给大家一些启发。

关于服务

产品力和服务力是 To B 企业的基础，其中服务力更为根本，强大的服务支持是 To B 企业对客户的核心价值所在。比起纯产品宣传和销售，创造更多贴近客户需求的价值和给客户全方位的解决方案，才能构建企业服务的护城河。

关于增长

To C 的增长主要是通过漏斗和非常多的转化率来实现，只要产品本身质量到位，有资金投广告，就一定有人用你的产品。To B 端购买者和使用者不是同一人，所以 To B 对销售团队的要求很高，销售团队要能和企业高管、决策层对话，需要根据不同客户的不同情况进行销售策略调整。
To G To B 在某些行业（如教育）是一个很好的路径，前提是产品足够好，在业务层面能足够打动 G。
To B 跟 To C 的另一个区别是 To B 需要稳而慢，To B 并不能简单通过产品和互联网运营就可以获取客户并实现业务增长，其对产品质量要求非常高。而客户一旦使用，对 To B 端产品依赖程度，替换和迁移成本都非常高。
当一个餐饮餐馆变成了 1000 家店的餐饮连锁，它的规模是变大了，但是企业的护城河其实并没有变得更深，企业并没有因为大而变得更强，企业的管理成本反而直线上升。同样，教育和其他行业也存在相同的问题。

关于产研

产品的标准化是产研的核心。
研发不能不知不觉沦为大客户的外包商。做不到产品的标准化，To B 创业公司会疲于应付大客户的各种琐碎需求，要么人员急剧增加，要么团队精疲力尽，资金链也会频频吃紧。
产品标准化不仅仅体现在产品上，还体现在销售上：一名真正好的销售，不仅仅要能把产品卖出去，还要能说服客户，在前期放弃或者推迟一些个性化需求。比如跟客户讲，您这个需求我觉得很有道理，但是研发有周期，产品上线可能半年之后了。咱们能不能先解决您最紧迫的问题？至于您提的这个需求，未来我们在 2.0 版本里给您做个免费升级。这样才是好销售。而不是客户什么需求，都去满足。客户是高兴了，但团队资源全被消耗进去了。团队都在项目里，便没有精力打磨标准化产品，这样企业就成为了项目制公司，一旦交付不了就陷入增长的死循环。
To B 产品需要非常高质量的代码，保证客户使用产品不需要担心安全和 Bug 问题，这也是 To B 端产品发布新的功能的节奏要缓慢很多的原因之一。
研发不宜在某些技术细节做过深的投入，以客户适用、快速迭代为原则。
研发要对收入负责，否则用户至上、以客户为导向、提升产品化能力等永远只是空话。公司如果过于产品导向，就难建立起来为客户服务的文化。

关于销售

服务的标准化是销售的核心。
公司经过的一段时间的发展有了直营客户，但必须形成标准化的打法。如何介绍公司、如何介绍产品、如何区分不同画像的客户、如何和决策关键人沟通、如何培训客户等等，都应该整理成标准化服务 SOP，这沉淀出来的是一套适合自己公司的打法。标准打法目的是减少销售人员个体因素影响。只有标准的打法，才可以降低对销售人员的销售经验和资源的要求，从3 - 5 年以上的销售经验降低到1 - 3 年，这都是成本！同时也可以快速缩减销售的成单周期和提高销售转化率，加快销售的淘汰。
高激励、高淘汰，在快速迭代中锻炼销售队伍、提升战斗力。高激励就是舍得给，提成给的高才能不断吸引人才。同时要舍得汰换，一旦没有业绩立即汰换，汰换慢，销售会疲软。要淘汰到销售必须很努力做到不在最后 10%。另外，需要不断有新鲜血液进来，标准打法才会更加完善，才能快速迭代，否则公司永远都是以几个大销售为主，队伍一直搭不起来。

关于客户成功

客户成功是 To B 企业中非常重要的岗位，产品售出后，客户成功要观察用户到底有没有使用产品，用的频率怎样。如果发现客户使用数据波动较大，客户成功应立刻去了解客户发生了什么，不管是通过提供咨询、服务还是培训，必须确保客户持续用好产品。

客户成功需要做好 3 件事:

发现，挖掘客户需要解决的问题；
将要解决的问题进行细化；
和客户一起制定接下来要提升的目标。

总体来说就是：不断地和客户沟通，看客户使用数据，深挖客户存在的问题，过程中及时引导和培训。

关于渠道建设

是否完成渠道体系的建设是 TO B 企业是否具备竞争力的重要标准。
以项目制和直营为主的企业并不是好的 To B 企业，原因在于项目制和直销两者都存在覆盖率低、客户关系维护成本高、应收帐款时间长等问题，每一问题都会拖垮整个公司。
没有渠道，面上看公司规模很壮观，几百人，规模反而可能是大坑。虽然我们已经进入数字时代，但金牌代理、行业代理、总代体系等仍是 TO B 企业的精髓。
但是，渠道建设的前提一定是，我们要有自营打个样，知道这里面的渠道成本、销售效率、标准化模式是怎么样的，然后才能去筛选、管理和培养渠道商。

关于公司投入产出和现金流

减少外部融资需求，实现经营现金流平衡，实现公司整体盈利对创业公司非常重要。
【研发费用】据统计，To B 上市企业研发投入与收入占比平均在 20% 左右，科创板要求不低于15%，实际上在创业初期，多数企业这个比例会超过35%，甚至50%以上，不能以研发投入高为豪。
【销售费用】据统计 To B的上市企业销售费用与收入占比平均也在20%左右，在创业初期，特别是还在搭建销售团队的早期，这个比例也会超过30%以上。
上述两者加起来都有70%左右。这种情况下创业公司要考虑产品的毛利需要做到多少才能有利润？现金回款达到多少，经营性现金流才能平衡？
评价一个 To B 企业还有一个数字，是全员人均销售收入，就是总销售收入除以员工总数，这个数字可以按 50 万元去评价，比如公司总共 30 人，那么年销售收入应该在 1500 万以上才健康。假设销售人员占全员比例三分之一，平摊到每位销售的人均销售额需要超过150万，这个数字对很多企业来说压力山大。
一旦以数字管理企业时，就会发现很多问题。这些数字不是让我们现阶段达到，是让我们思考何时、如何才能达到。有了这个基础，再去想收入增长多少，人员增加多少，架构和产品方向如何调整，增加现金多少，何时实现利润，企业估值到多少等等。没有这个基础逻辑，就会发现很多时候裁员发生在了最不应该的扩张期，倒闭都是因为自己的子弹先打光了，枪（公司产品）却还很好用。

上述一些内容，其实我们自身还没做到或还没做得很好，但我相信这些都是我们的方向和目标。

另外，关于 To B 线上运营的一些思路，还在艰难探索中，有进展后会再跟大家分享。

参考资料：

做To B，一定要避免9类错误！

投资视角看To B创业

万字长文梳理运营大神干嘉伟的to B心法

极限编程(XP)简介

i@lipan.me (李攀) — Sun, 28 Jun 2020 00:00:00 +0000

这篇文章是我最近在团队内做极限编程分享的内容整理。

极限编程(XP)的定义

极限编程中的「极限(Extreme)」是指将我们认同的有效软件开发原理和实践应用到极限，频繁地去实践，如：“如果单元测试很重要，那我们就做测试驱动开发。如果集成测试很重要，那就要在一天中进行多次集成，并且反复进行回归测试”。结对编程在提出时更多的是强调”如果代码评审很好，那么我们就一直进行代码评审”，所以我们要做结对编程。结对编程就是两人用同一台电脑完成同一个任务，其中一人负责编码，另一人负责审查代码，从而能够时时刻刻地进行代码评审。

XP 在敏捷中所处的位置

我们先抛开精益，这一块不是我们今天要讨论的。事实上，源自丰田汽车的精益生产方法对敏捷有着巨大的影响。

从图中的包含关系可以看到，Scrum 和 XP 都是敏捷方法的一种，二者有不少交集，但更多的是不同，二者都在敏捷方法中占据着非常重要的位置。

用 Scrum 就可以号称敏捷了吗？

是的，但还不够。

我们先来回顾一下什么是敏捷，我喜欢用这句话来解释敏捷：持续不断地交付对用户最有价值的产品。不管怎么定义敏捷，一定离不开「短周期地频繁交付」。大家思考一个关键问题：当产品的交付周期由以前的数月缩短至 1 - 2 周，甚至进一步缩短到数天时，配置管理和质量保障相关的实践应该如何升级以应对如此频繁的交付上线？这是个现实而又尖锐的问题，仅靠 Scrum 我们是做不到的。

只要召开了每两周一次的Planning, Review, Retro 三大会议和每天的 Daily Scrum，只要用户故事以卡片的形式被记录被追踪，只要迭代范围和进度以燃尽图的形式呈现出来，是否就可以声称我们已经“敏捷”了？答案当然是否定的。这仅仅是安抚我们的情绪，当然这确实为 Scrum 招来了红火的生意，因为 Scrum 的引入的成本实在是很低。在 Scrum 中，我们是不提配置管理（CI/CD）和质量保证（TDD）、自动化测试等。正因为此，Scrum 的门槛低，大家都能采纳，这迎合了很多团队的需求，能够让过程变得有规律可循，并达到一些效果。但如果真的想做好，技术环节的实践一定是逃不掉的。在整个敏捷的实施过程中，持续交付是最难的，需要一定的技术提升，而不仅仅是靠流程。

有越来越多的组织，尽管引入了某些（如 Scrum）敏捷的流程、方法和工具，号称已经“敏捷”，却发现自己仍然深陷代码质量差、软件缺陷多、测试跟不上、返工严重、进度缓慢的状况，大家甚至产生出对敏捷的怀疑情绪。

XP 和 Scrum 的核心区别

简单地说，XP 更关注技术和工程实践，而 Scrum 更关注团队协作和管理实践。这是我总结的二者核心区别，其实很好理解。

极限编程是第一批敏捷开发方法中最具实效的一种。在各种敏捷方法中，极限编程最为重视工程实践。

极限编程核心的测试驱动开发、持续集成、用户故事等具体落地的实践，给研发团队提供了明确有效的指导，使他们得以随时保持软件处于可工作、可交付的状态，使迭代交付高质量软件成为可能。所以我们可以说，没有 TDD，没有持续集成的敏捷只停留于形式，不是真正的敏捷。

极限编程的规则非常简单，采用极限编程很像在玩拼图游戏，你会看到很多小片的拼图，每一个小片单独看起来没有意义，组合起来就会看见一幅完整的图景。这些规则乍一看可能显得幼稚笨拙，但在它们背后有着坚实的价值观和原则支撑。

XP 规则

计划

编写用户故事。
根据发布计划制定发布时间表。
进行频繁的小规模发布。
将项目分解成迭代。
用迭代计划驱动每个迭代。

管理

为团队提供专注开放型办公空间。
可持续的节奏。
以站会开始每一天。
团队开发速度可度量。
让团队坐在一起。
调整有缺陷的规则。

设计

简单原则。
设定一个系统隐喻。
在设计交流中使用CRC卡。
使用Spike方法降低风险。
不要过度设计或过早添加不必要的功能。
尽可能地重构代码。

编程

客户紧密参与团队协作。
遵循编码规范。
优先编写测试。
通过结对编程构建生产代码。
一次仅限一对程序员集成代码。
持续集成。
选一台机器专用于代码集成。
代码集体所有。

测试

所有代码都必须有单元测试。
发布前必须跑通所有单元测试。
发现一个Bug要增加一个单元测试。
经常性进行验收测试并公布测试结果。

XP 规则间关系

下图是我整理的上述规则之间的关系，各规则之间有着强烈的联系，从关系中可以隐约看出极限编程出现了左右两部分的实践，左边偏项目流程，和 Scrum 重合的部分基本在左边，右边偏工程实践，是极限编程的核心实践。

获得一项技能的唯一方式，就是刻意练习，极限编程也一样，保持专注并大量重复的联系，才能将极限编程实践运用得游刃有余。

参考资料：http://www.extremeprogramming.cn/

一起长大敏捷实践 - 自组织篇

i@lipan.me (李攀) — Thu, 12 Mar 2020 00:00:00 +0000

如果不存在外部指令，系统按照相互默契的规则，各尽其责而又协调自动形成有序结构，就是自组织。

自组织是我们认为理想的组织形式，它能充分调动组织内各个个体的能动性，也能让组织更健康地运作和成长。一个系统自组织功能越强，其保持和产生新功能的能力也就越强。

在我们团队，我一直以团队达到自组织为我的管理目标，当然，要形成自组织团队，对团队每个个体的要求都非常高。在这里，信任是自组织形成的基础，包括团队和我之间的相互信任，团队成员之间的相互信任。

我们发现，我们使用的敏捷方法和 Scrum 框架，是实现自组织非常好的方式和工具。

自组织分为自组织个人和自组织团队，他们有着各自显著的特征。

自组织个人

自组织个人的核心是自驱力。个体能在没有外界指令的情况下，自我学习，自我提升，自我成长和超越，在团队内，能主动承担困难工作，能主动提出产品方案，能主动优化产品体验，主动偿还技术债等等，都可以归为具有自组织的个人，这类人群的价值和贡献是超乎想象的。

自组织团队

自组织团队会自发设定规则和约束，自组织团队通常目标一致，互助协力，互相督促。自组织团队的团队规则不是自上而下颁布的，而是团队为了能更高效协作和变得更有序，自发思考出来的规则。自组织团队内的任务不是分配的，而是成员各自认领的。团队会经常一起脑爆，对产品有深度地思考，想方设法让产品变得更优。团队会一起分享对技术和行业的理解。团队中 PO 和开发团队不是上下游的关系，而是利益一致的统一作战体。

在我们团队中，团队的规则和约束基本上都是团队自己制定，而规则的来源，最主要是回顾会议上提出的团队在过程中遇到的问题以及一起讨论的解决方案。当然，也包括敏捷转型初期，大家制定的团队公约，包括 DoD， DoR，团队日历、团队公约，checklist 等等，如下图，是我们一个团队公约内容：

一个自组织的团队，是可以在没有任何外力的情况下，非常良好地运转，整个团队在一次次 PDCA 循环中，践行着敏捷的乐趣，收获着交付的喜悦。

一起长大敏捷实践 - 激励篇

i@lipan.me (李攀) — Thu, 05 Mar 2020 00:00:00 +0000

关于团队激励，我们设计了一套适合敏捷团队，可操作性极强，实用且有趣的方案。

激励分两部分，一是团队激励，一是个人激励，其中团队部分是重点，因为敏捷团队是一个整体，团队为共同目标而努力。

我们分别叫这两类激励为 Sprint 团队之星和个人之星，每个 Sprint 评一次。为保证客观，团队之星我们完全用可量化的标准，而个人之星来自于团队互评。两者都产生于回顾会议。

话不多说，直接分享我们可操作的内容。

团队之星

记分规则

每个 Sprint 结束后，【评定条件】得分大于或等于总分的 80% 团队获得一颗 Scrum 团队之星。

评定条件

【001】完成所有的 Scrum 事件（按照团队约定时间按时进行）：（1 分）

Product Backlog Refinement
Sprint Planning
Daily Scrum
Sprint Demo/Review
Sprint Retrospective

【002】PO 在 Sprint Planning 给出 Sprint 需实现的价值目标（如：新功能用户留存时长超过 5 分钟占比 50%），发布评论到对应团队的 Sprint Wiki 文档（如 FT1 Sprint 5 文档）；（1 分）

【003】PO 在下一个 Sprint 结束前给出 Sprint 上线后价值目标达成情况反馈（如：第一周（10/14-10/20）新功能用户留存时长超过 5 分钟占比 80%；第二周（10/21-10/27）新功能用户留存时长超过 5 分钟占比 50%），发布评论到对应团队的 Sprint Wiki 文档（如 FT1 Sprint 5 文档）；（1 分）

【004】团队完成 Sprint 目标；（2 分）

【005】当前 Sprint 完成的故事点相较于上一个 Sprint 有增加（速率增加）；（2 分）

【006】Sprint Review/Demo 成功: Demo 后不需要修 BUG 就能发布上线；（2 分）

【007】Sprint 完成的 70% 以上故事点不能是之前 Sprint 未完成的遗留功能；（1 分）

说明：【002】中的价值目标特指 PO 计划由 Sprint 开发的功能为公司或团队带来的价值所达成的目标，与 Sprint 目标不同。Sprint 目标指该 Sprint 应该达成的目标，在 Sprint 结束就应该能查验 Sprint 目标是否达成。

奖励规则

每满 5 颗 Scrum 团队之星可以兑换团队奖励（兑换规则参照【奖励计算规则】）；
每颗 Scrum 团队之星只能使用一次；

奖励计算规则

计算方式：y = 200x²

其中：

y = 可兑换奖励额度（或积分）

x = 有效 Scrum 团队之星的数量

Scrum 团队之星(颗)	对应可兑换团队奖励
1（仅限首次）	1000
5	5000
10	20000
15	45000
20	80000
25	125000
30	180000
35	245000
40	320000
…	…

我们实践下来，两个团队分别跑了 10 个 Sprint 后，仅一个团队拿到过一次团队之星，可见这难度还不小。但是，因为有难度，当拿到团队之星时，团队的那种喜悦之情溢于言表。

奖励为什么要用二次函数呢？我们希望团队可以考虑把星攒起来，去冲击后面巨大奖励的刺激。

Sprint 之星

记分规则

参与评选的人员：FT 团队 PO 及开发团队全体成员（Scrum Master 不参与）；
每个 Sprint 的回顾会议上，团队匿名投出本次 Sprint 最给力队友为【Sprint Star】，得 5 颗 Sprint 星。
其他成员，如果完整参与了整个 Sprint 所有团队事件为【Sprint 最佳搭档】，得 1 颗 Sprint 星。
本规则可能会根据实际运行情况作调整；

说明：

• 【Sprint Star】与【Sprint 最佳搭档】不能同时获得，【Sprint Star】的评估不受【Sprint 最佳搭档】评选条件影响；

• 若出现多个人获得相同最高票数，则 Scrum Master 与其他人再次对获得最高票数的人重新投票，选出最高票数为【Sprint Star】；

• 完整参与了整个 Sprint 的定义：完整参与 Sprint 的所有 Scrum 事件；

• Scrum 事件：Product Backlog Refinement（PBR，产品待办列表梳理），Sprint Planning（计划会议），Daily Scrum（每日站会），Sprint Review/Demo（成果演示会议），Sprint Retrospective（回顾会议）；

• 所有事件无缺席；

• 所有事件无迟到，早退；

奖励规则

100 颗星以内（包含），满 10 可兑换奖励（兑换规则参照【奖励计算规则】）；
超过 100 颗星，每满 50 的倍数可以兑换；
每颗 Sprint 星只能使用一次；

特别地：超过 100 颗星时，仍可按照规则 2 兑换：如 110 颗星，可以选择兑换 100 颗，保留 10 颗。

奖励计算规则

奖励计算方式：y = 4x²

其中:

y = 可兑换奖励额度（或积分）

x = 有效 Sprint 之星的数量

Sprint 之星(颗)	对应可兑换奖励
10	400
20	1600
30	3600
40	6400
50	10000
60	14400
70	19600
80	25600
90	32400
100	40000
150	90000
200	160000
…	…

违规判定规则

贿选：不得私下利用权利或利益授意别人投选；
其他非正规手段；

Sprint 之星在被宣布时，同时获得团队所有成员的掌声。

我们发现，我们两个团队几乎每位成员都获得过 Sprint 之星，这说明团队每个成员在不同 Sprint 都有突出表现，团队成员的整体贡献和实力相当，团队运作默契且融洽，而这些都来源于下一篇将要讲到的 - 自组织。

一起长大敏捷实践 - 数据篇

i@lipan.me (李攀) — Thu, 27 Feb 2020 00:00:00 +0000

团队效率是否在逐渐提升，让数据来说话

在我们的 Scrum 中，最常涉及到的是以下几个数据：

时间盒

时间盒定义了 Sprint 的长度，有良好节奏的团队的时间盒应该是恒定不变的，Scrum 的建议是在 2 - 4 周里选一个时间固定下来，我们选择以 2 周为一个 Sprint，用简易的最小值，是为了可以更及时地去调整。我们实践下来发现，CI/CD 等基础设施不成熟的团队，时间盒适当长一些，Sprint 的产出会更高，毕竟回归测试、版本发布是每个 Sprint 中不可缺少的部分。

下图是我们一个团队的时间盒图，可以看到，团队在经历过初期 3 个凌乱的 Sprint 后，从第 4 个 Sprint 开始，非常好的控制了时间盒，整个团队后续的每个 Sprint 都很有规律，这样团队的节奏感非常强。

故事点

这个概念不用多说，大家都了解，我们借鉴了《硝烟中的 Scrum 和 XP》里「理想化人天」的方法，让故事点有一个「摸得着」的参考依据，也方便关联其他（实际可用人天等）数据，团队在 Planning 上出牌的时候，更容易给出故事点的数值。在 Planning 上，团队会确定本次 Sprint 计划完成的故事点数，回顾会上，会得到本次 Planning 实际完成的故事点数。下图是我们一个团队的计划故事点和实际完成故事点的柱状图，可以看出，团队的计划性越来越好，完成的故事点越来越接近于计划的故事点。

实际可用人天

这个数据很简单但必不可少，有了团队人数 P，时间盒 T，成员请假总人天数 O，便可计算出实际可用人天 D = P * T - O

投入度

有了上述几个数据，投入度自然就出来了，投入度 = 实际完成故事点点数/实际可用人天。投入度反应了整个团队的效率。下图是我们一个团队的投入度曲线，可以看出，整个团队效率整体是上升的。有了投入度这个数据，团队才可以比较合理地预测下一个 Sprint 预期能完成多少故事点，也方便 PO 准备 Planning 的内容。

Sprint 计划

我们在 Sprint 开始时，还会有一个数据模版被填充，这些数据告诉团队和整个公司，当前 Sprint 的节奏和重要时间点，以便所有人知晓，如下：

尾声：很多对敏捷转型犹豫的人会问，转为敏捷开发以后，如何来证明团队效率更高，交付了更多有价值的产品功能？上述这些数据可以说明一切，让数据说话，是最真实的答案。

强烈推荐《硝烟中的 Scrum 和 XP》一书，团队人人必看。

参考资料

《硝烟中的 Scrum 和 XP》https://www.infoq.cn/article/scrum-xp-from-the-trenches

一起长大敏捷实践 - 工具篇

i@lipan.me (李攀) — Thu, 20 Feb 2020 00:00:00 +0000

工欲善其事，必先利其器。

上一篇讲了我们的 Scrum 流程，本篇分享一下我们在各流程中用到的提升团队效率的工具。

Jira

市面上有很多新一代的团队协作和任务管理工具，国外的 Trello，国内的 Tower、Teambition 等我都使用过，但仍然选择 Jira 是因为它有两个优势：

和 Scrum 完美贴合。Jira 的 Scrum software development 项目太适合 Scrum 团队了，里面包括了所有的 Scrum 工件，和 Scrum 完美贴合。Backlog, Active sprints, 燃尽图，故事点等，这些你在 Scrum 里面非常熟悉的东西，在 Jira 里都可以找到。
灵活。可配置可定制性非常高，也可以配置非常多的自动化流，当然，灵活也意味着高阶用法的门槛很高。另外，Dashboards 里面很多 widgets 可以做出不少有意义的仪表盘。Jira 是整个 sprint 的 story, task 和 bug 汇总的地方，团队整个 sprint 都聚焦在 Jira 上。

实体白板

我们有两个 FT 小组，其中一个小组热衷于实体白板和手写故事卡，用得也非常好。

简单对比一下 Jira 看板和实体白板的优劣

	优势	劣势
Jira 看板	方便做数据统计，方便展示燃尽图等各种报表	展示成本较高，需要配备大屏
实体白板	任何人任何时候都知道进展，团队紧迫感和成就感更强	每次 Planning 后需要手写卡片，需要手绘燃尽图

适合团队的才是最好的。

大显示器

上面说到，Jira 的展示需要配备大屏，我们配备了幼儿园教学使用的一体机，屏幕大约 65 寸左右，用于团队的 Daily Scrum 和平时展示，展示出来 Jira 上的故事卡状态，让大家在 Daily Scrum 时可以更聚焦一致。

Confluence

Confluence 和 Jira 是一家公司的产品，是用来做知识管理和文档管理的神器。团队使用后，所有成员的文档能力都有显著提升，这也成为了团队的知识库，很多文档通过搜索都可以方便找到。我们不少会议也用 Confluence 来记录，采用提前创建会议纪要，参会人会前提前回复内容，会上沟通起来效率非常高。另外，Confluence 和 Jira 可以打通，直接在文档中展示 Jira 的内容，效果也非常棒。

伙伴云

为数不多的免费但功能齐全，且可以自定义工作流的数据表格类工具，主要还免费。我们主要用于业务部门反馈问题记录、产品需求池整理和产品计划。

Slack

最好用的团队 IM 工具，没有之一。但是在国内用起来真的很悲伤，即使公司可以翻墙，体验和速度也很让人抓狂，为了不折腾，团队没办法和公司一致换成了钉钉作为沟通工具。 

lanhuapp

替代 zeplin 的国内产品，可以很好地托管 Axure 和 UI 设计稿，极大方便了客户端和 UI 设计师之间的协作。

Scrum poker

PBR 和 planning 上用来评估故事点的工具，推荐微信小程序「Scrum 敏捷估算」。

一起长大敏捷实践 - 流程篇

i@lipan.me (李攀) — Thu, 13 Feb 2020 00:00:00 +0000

全面转型敏捷之前，我们的 Scrum 流程在 Scrum 框架基础上改造了非常多，现在看起来很多都是没必要的，Scrum 框架已经非常简单和成熟，可操作性也非常强，只需要根据团队实际情况做微调即可。

我们在每个 Sprint 中增加了 PBR，通过一个小时左右的会议，让团队对未评估过故事点的故事和后续的一些史实故事，使用 Planning Poker 工具进行故事点的评估，以便 PO 得到故事点后，结合故事的价值，对故事进行优先级综合排序，来重新调整 Backlog。这个环节的好处在于，所有故事都在 Planning 前有故事点，且故事点是团队一起评估出来的，PO 根据过往团队速率，可以对未来 Sprint 大致可以放入多少故事有一个准备，避免 Planning 准备不足或者故事过多。同时也可以让 PO 对未来要做的史诗故事大小有大致的了解。

Sprint Planning

我们的 Sprint Planning 没有太多特别，PO 详细讲解本次 Sprint 相关故事，团队一起提问和讨论，最后定下 Sprint 目标，大家会后一起将任务拆分到 JIRA，如下图：

在 JIRA 中我们以故事+子任务的方式来管理，子任务包括各端的任务和测试任务，所有子任务都完成后，整个故事算完成。新的 Sprint Planning 结束后，我们会在公司的一块大白板上，公示 Product Backlog 近期完成（上个 Sprint 已交付）、正在进行（当前 Sprint 计划交付）、即将进行（后续 Sprint 计划）的故事，让整个公司都知道开发团队的进展和规划，也是 Scrum 里面提倡「透明」的一个体现。

Daily Scrum

我们选择在每天下班前进行 Daily Scrum，这样有几个好处：

工作了一天大家都比较累了，Daily Scrum 让大家放松和站起来活动一下；
大家在同步信息和进度时，如果某人发现因为自己的原因，导致燃尽图偏离，会主动选择下班后加班去弥补和赶上进度，不至于让整个团队目标受到影响；
早上一到公司就可以开始工作，不用等待开会，早上的效率会更高。

另外，我们配备了一个超大的显示器，在 Daily Scrum 时所有人都可以注视着显示器，发言的同时去移动 JIRA 卡片，这让大家焦点一致。

Sprint Review

RC 环境走完以后，我们开启 Review 会议，当然，这个会议时间在 Planning 结束后就已经定下来并创建了日程。这个环节很重要，事实上，Review 应该是给客户展示我们即将交付的新特性，在我们公司，业务部门（销售、客户成功、运营、客服等）就代表着客户（和客户走得最近），所以，每次的 Review 会议，团队都会邀请业务部门来参与。会上团队指定一个演示人，按照故事列表，对本次 Sprint 完成的所有故事进行演示，这个环节也有很多好处：

让业务部门了解哪些功能是我们即将交付上线的，可以给用户/客户去传达；
业务部门会站在用户/客户的角度，给团队提出很多好的建议，PO 搜集以后可以作为下一次优化的参考；
增进开发团队和业务团队的交流机会，让业务团队不断地看到他们期望的新特性上线，通过业务团队的反馈和认可，也给开发团队更多的信心和成就感。

每次 Sprint Review 结束时，业务部门参与者都会给团队的产出以掌声，这个仪式感对团队来说是超棒的。

下面是一个典型的 Sprint Review 场景

Sprint Retro

回顾会议一般在正式上线生产后进行，回顾会议是我认为最重要的会议，自组织团队的自我认知、更新、迭代、流程优化等，全在这里。我们的回顾会议有几个特点：

封闭的会议室，让大家畅所欲言，更有安全感；
提前准备好水果，让回顾会议的氛围变得轻松；

我们的回顾会议大概是这样的流程：

所有人写出本次 Sprint 做得好和不好的，大家用工具投出优先级；
投票最多的 3 个不好的，大家在会上一起思考和讨论改进意见；
针对每个做得不好的点，分配一个成员，在下个 Sprint 中重点跟进；
回顾之前 Sprint 的不好项的跟进进展，是否有改善；
评选 Sprint 之星和看是否能获得团队之星（这两个在后续激励篇会专门介绍）

每个 Sprint 结束后，团队一般会组织一次聚餐，然后进入下一个 Sprint 迭代。

下面是一个典型的 Sprint Retro 场景

参考资料

Scrum要素 https://book.douban.com/subject/20507350/

一起长大敏捷实践 - 组织架构篇

i@lipan.me (李攀) — Thu, 06 Feb 2020 00:00:00 +0000

2018 年底我写了一篇文章，叫「Scrum 实践 - 我们是如何做敏捷开发的」，现在每次看到这篇文章，都觉得自己当时对敏捷的理解太浅，践行的是「中华田园敏捷」。2019 年开始系统地看了很多关于敏捷和极限编程的理论和实践资料，升级迭代了很多我对敏捷的认知，从 2019 下半年开始，决定让团队开始全面转向敏捷。

本次我通过一个系列的文章，从敏捷团队组织架构、工具、流程、数据、激励、自组织等各方面，去分享我们近半年的敏捷实践，以及我们是如何从敏捷中受益的，希望我们的最佳实践能给正在敏捷转型过程中并处于迷茫期的团队以帮助。

我们使用的是 Scrum 框架来做敏捷实践。

Scrum 中两个重要的角色

Scrum Master - 这个角色在转型 Scrum 刚开始甚至中期非常重要，一定要由全职的人来担任，前期的 Scrum 普及工作，非常多的 HOW-TO ，教练工作，协作流程，以及会议组织（特别是回顾会议）是 Scrum Master 的重点。这次转型前，我们的 Scrum Master 一直是团队成员兼职担任，这分散了团队成员开发的注意力，同时又没法将 Scrum Master 本职工作做好。根据不同团队情况，当整个团队走完 10 个至 20 个 Sprint 后，Scrum Master 这个角色可以慢慢淡出，变为兼职，因为这时团队对敏捷的理解已经很充实，而且团队默契已经形成，也有了相对固化的协作流程。

PO - 外包团队的 PO 是客户，在 ThoughtWorks 这类「外包」公司，团队有 BA 和业务方 PO 对接做业务分析。对于我们这类产品型公司，PO 由传统的产品经理担任，职责也基本一致，这里不过多说。

上述两个重要角色的关键一定是需要对敏捷有非常深入且一致的理解和非常高度的认可，所以在转型前，我们团队让 SM 和 PO 都提前去参与了 CSM 和 CSPO 的相关培训，也算是持证上岗。

Scrum of Scrum

转型初期，我们在内部建立了一个叫做 Scrum of Scrum 的组织，这个组织的参与者包括所有的 PO，SM，以及之前兼职担任过 SM 现在作为 DevTeam 的成员等，这个组织的目的是提供一个关于敏捷的学习交流平台，我们直接用 Scrum 的方式来推进这个组织的运作，提出所有我们不知道应该怎么做的事情，去找答案，讨论，让参与者将我们形成的结论和一致认知，带回到团队，将自己学习和理解到的敏捷，去影响其他人，从点到面让所有团队成员都对敏捷逐步有深刻的理解。这个组织每周一次固定一小时的交流，持续了三个月，我们一起解决了转型初期非常多的疑惑，达到了很好的效果。当然，在转型初期，我们要求所有团队成员都完整地看一遍《硝烟中的 Scrum 和 XP》这本实战性非常强的书，并一对一沟通每个人对于书中内容的理解，保证大家的认知一致性。

矩阵式组织架构

说新的组织架构前，简单讲一下我们之前的组织架构，我们之前采用了一种矩阵型的组织架构，如下图：

矩阵式组织架构是这样运作的

立项时，团队成员由职能主管从职能部门（服务端、客户端等）分配到项目组
在项目中，团队成员被分配任务
团队成员要例行向职能主管进行每周工作汇报
项目结束后，团队成员从项目释放，回到职能部门，待分配到下一个项目

这种矩阵架构存在一些问题

项目团队不固定，团队没有固定的流程和规范
每次项目团队重组后，成员之间协作都需要进行磨合
每次重组项目团队时，职能部门中谁可用就只能用谁
人力资源很难分配均衡
双线汇报

新的组织架构 - 引入小队的概念

组织定位

小队是一个相对固定、高度自治、迷你的「创业公司」，具备开发和发布产品需要的所有知识和技能，肩负一个长期的使命，长期从事某一类任务或者开发产品的某一个部分，例如：
- 功能团队（FT - Feature Team）：专注于某块功能特性，例如园本库、高质量陪伴等
- 基础设施小队（IT - Infrastructure Team）：提供如持续集成工具、云平台基础设施工具等，让其他小队更有效率，不进行业务特性开发
- IT 影响 FT 中相关成员按照 IT 制定的规范和原则进行业务功能开发

小队成员

不存在官方任命的团队领导
各功能小队有一位产品负责人 PO
- 各小队的 PO 之间需要紧密合作，共同维护一个宏观的产品路线图（Roadmap），指引整个公司的产品发展方向
- 每个小队的 PO 也分别维护一个自己所在小队的产品待办列表（Product Backlog）
有一位公用的敏捷教练（Scrum Master），帮助 FT 小队改进工作方式
工作方式
- 坐在一起工作
- 自组织管理
- 通过回顾会议等自定义和自改进小队工作流程

新架构与之前矩阵架构的区别

团队成员在小队中持续工作，与小队中其他成员共同打造优秀的产品
团队成员汇报对象是 FT 团队
小队具备开发和发布产品需要的所有知识和技能，能完成所有工作

这样的组织架构，对团队成员的自组织和自驱力要求很高，这也是我对团队成员的一贯要求，因为团队目标的一致，所以团队成员之间在协作时也会形成一个相互制衡，共同向上的拉力。

实际上，我们有两个 FT 团队，每个团队固定两周一个 Sprint，两个团队 Sprint 交替开，于是，对于用户来说，每周会有一个新版本发布上线，这样让整个产品迭代的节奏也非常健康。

通过上述组织架构，可以看出，我们淡化了产品部和研发部的概念，研发内部更没有服务端和客户端部门划分，全部都以纵向的方式组织，PO 和团队完全融合在一起，服务端和客户端完全融合在一组。这样的组织形式，让团队可以拥有长远的共同目标，持续磨合，持续改进流程，通过后面的数据篇可以看出来，团队的效率会稳步提升。

结构决定功能，组织架构变化是走好敏捷转型的第一步。

参考资料：

Spotify敏捷模式详解三部曲第一篇：研发团队 https://mp.weixin.qq.com/s/Srd6esYCy_babI_4Q3RrBQ

硝烟中的Scrum和XP https://www.infoq.cn/article/scrum-xp-from-the-trenches/

Scrum 实践 - 我们是如何做敏捷开发的

i@lipan.me (李攀) — Tue, 18 Dec 2018 00:00:00 +0000

互联网团队用 scrum 做敏捷开发的不少，介绍一下我们团队的 scrum 实践。

我们使用到的一些工具

JIRA - 和 scrum 的理念完美结合，scrum 里面所有的概念和工件，JIRA 都有非常棒的对应和支持
WIKI - 实际上是 Confluence, 和 JIRA 一样，都是 Atlassian 公司出品，文档神器，和 JIRA 可以完美打通
Slack - 团队沟通利器，产品研发整个团队都使用 Slack 进行沟通，充分利用 Slack 沉浸式，基于频道的分组方式，让团队沟通更聚焦，同时减少无效消息打扰，消息搜索和查找更方便(由于国内网络原因和公司协作，现换成了 DingTalk)
Gitlab - 代码托管
processon.com - 流程文档，在 WIKI 里面我们也集成了 Draw.io 来作图
lanhuapp - 替代 zeplin 的国内产品，可以很好地托管 Axure 和 UI 设计稿

标准的 scrum 是怎样的

标准的 scrum 在 Srcum.org 已经很清晰了，这篇文章认为大家对于 scrum 相关的概念已经很熟悉了，不在这里介绍。

在 scrum 中，Sprint Planning，Daily Scrum，Sprint Review，Sprint Retrospective 这四个事件一个都不能少，我们在这基础上，增加了一些我们认为很重要的环节。

我们的改进流程

角色定义：
Product Owner (PO)
Scrum Master (SM)
Dev Team（DT）

Sprint Planning

前提:
产品召集团队开过 PBR，产品 Backlog 按优先级排好序，本次迭代需求确定，功能优先级排定，并已生成 PRD 文档，UI 设计稿确定

PO 至少提前一天创建日程，并在日程里附上产品 PRD 文档链接，DT 提前阅读并理解接下来版本要达到的目标。
会上 PO 对照 PRD 和 UI 设计稿讲解 Sprint 的目标以及达成该目标所需完成的产品 Backlog，UI 设计师对本次 UI 稿规范做说明。
整个 Scrum 团队协同工作来理解当前 Sprint。

产出：
PRD - PO 使用 Axure 绘制产品流程和交互图
BDD - PO 撰写 BDD 场景概要

Sprint Backlog

前提：
DT 任务拆分和时间评估完成

会前前后端分别对开发内容进行拆分并录入 JIRA，形成 Sprint Backlog，并完成开发时间预估。
会上 DT 讨论需求的技术架构、接口以及前后端实现方案。

产出：
JIRA - 所有的任务拆分落实到 JIRA 的 sprint 中

Daily scrum

内容：
昨天你完成了什么工作？
今天你打算做什么？
完成你的目标是否存在什么障碍？

对照 JIRA 上的 Active Sprint 来进行
增进交流沟通，减少其他会议，发现开发过程中需要移除的障碍。
会后 DT 每人需要更新 JIRA 当前的任务状态。

工具：
slack - 我们创建了名为 #daily-scrum-report 的频道，通过使用付费工具 Standup Alice (https://app.standupalice.com/) 每天早上在固定时间组织团队所有人通过 slack 的方式来参与 daily scrum，对于较大的团队，这种方式大大节省了整个团队一起 face to face 开展 daily scrum 的时间，当然，小组内的 daily scrum 并没有被替代

测试用例评审

前提：
QA 完成测试用例或 BDD 文档撰写并和产品确认

QA 至少提前一天创建测试用例评审日程，并在日程里附上测试用例文档，DT 提前阅读并理解测试用例。
评审会上，QA 讲解测试用例重点，DT 和 PO 针对测试用例提出疑问。

Sprint review

前提：
当前 Sprint 即将结束，DT 已经按照测试用例做过冒烟测试

检视即将交付的产品，并按需调整产品待办列表，重新规划时间。
DT 在会议上对当前版本进行演示，QA 根据演示结果判断版本是否达到提测标准。

QA 演示和 PO 验收

前提：
功能在 QA 环境测试结束，上到 RC 环境

QA 在 RC 环境给 PO 做当前版本演示。
PO 在 RC 环境做产品体验验收。

上线（Integrated Increment）

前提：
PO 在 RC 环境对产品验收完成

Scrum Master 创建项目上线任务（另有规范）。
各端执行产品上线检查项 （另有 checklist 文档，大部分的上线事故都可以通过 checklist 的方式很好的避免）。
部署上线。

Sprint retrospective

前提：
当前 Sprint 结束并上线

在会议上所有团队成员都要反思这个过程中遇到的问题和困难，目的是为了进行过程改进。

我们的思考

回顾会议非常重要 - 产品上线并不代表 sprint 结束，我们在每一次的回顾会议中，都暴露出来大量的问题，会后重点跟进暴露出来问题的责任人和下一步行动方案，这是一个发现问题，思考下一步解决方案的绝佳时机，一定要重视回顾会议；
多使用提高效率的工具 - Slack，JIRA 等都是非常棒的提高生产力的工具。

Slack 集成

最后，介绍一下我们通过 slack 集成的工具：

gitlab，成员提交代码和文档以后其他人第一时间获得反馈
fabric，线上客户端出现崩溃时相关人员第一时间能收到通知
jenkins，客户端或者服务端 CI 完成以后收到通知，减少前后端沟通成本
jira，任务新建（new）或者任务状态发生变化时（To Do -> In Progress），第一时间收到通知
fir/testflight，客户端有新包第一时间收到通知
sentry，生产环境服务端出现错误时第一时间通知
zeplin，UI 设计稿有更新第一时间通知并能直接预览设计稿，提高前端和设计师沟通效率
standup alice，组织异步站立会的神器，上面 Daily scrum 中提到过
sms，非生产环境短信发送到 slack #sms，提高速度同时节约成本

「Netflix 文化」笔记

i@lipan.me (李攀) — Sat, 08 Dec 2018 00:00:00 +0000

最近读了 Netflix 文化, 启发很大，摘抄了一些作为读书笔记，如下。

1. 价值观来自于我们推崇和珍视的价值

公司真正的价值观和动听的价值观完全相反，是具体通过哪些人被奖励、被提升和被解雇来体现。

珍视以下 9 项同事们拥有的行为和技能：

判断力

你在对人，对技术、对商务和对创新上能够做出明智的决定，摒弃模棱两可
明辨事物根由，不为表象所惑
你能战略性思考，有自知之明，并努力做到
你能很聪明地分清楚哪些事现在必须完成，哪些事可以稍后跟进

沟通力

你善于聆听，而非快速反驳。如此你能够更好地理解
你在说和写的时候简洁清晰
你待人接物心存敬意，不在意对方的身份，也不在意对方持有异议
在重压之下，你也能镇定自若

影响力

你能完成众多重要工作
你的同事能仰仗你持续输出的强大工作能力
你注重结果而非过程
你偏好先发制人而非谋定后动

好奇心

快速学习且渴望学习
努力理解公司的战略、市场、用户和供应商
拥有对商业、技术和娱乐的广泛认知
在你专长之外也能有效提供贡献

创新

你能重构概念以找出难题的特别解决之道
你能挑战成见，给出更好的方法
你能想出的新点子且被证实有效
你能通过降低复杂度，找到简化时间的方法以保持公司的敏捷

勇气

你想说什么就说什么，哪怕有所争议
你能毫无痛苦地作出艰难决定
你能明智地冒险
你能质疑和我们价值观不一的行为

热情

以你对卓越的渴望激励他人
你对公司的成功深系于心
你热爱胜利
你坚忍不拔

诚实

众人认为你坦白直率
你不同意他人意见时并非出于公司政治的考量
你不背后议论他人
你能很快承认错误

无私

你寻求的是什么对公司最好，而不是什么对你自己和你的小团队最好
当大家一起找寻最佳方案时，你没有那么多自我要维护
你愿意花时间帮助同事
你能主动开放地分享资讯

2. 追求高绩效

对于程序型的工作，顶级员工的输出量是一般员工的 2 倍；
对于创新型/创意型的工作，顶级员工的输出量是一般员工的 10 倍。

最好的工作环境是拥有一群超级棒的同事

仅仅做到称职的员工，也要拿钱走人
我手下的员工里，如果有人要辞职去同业公司做类似工作，有哪些人是我会拼命挽留的？
我们的团队能力越大，我们所取得的成就也就越大，所以我们的人始终彼此帮助
我们彼此帮助，共同成就
忠诚就像稳定器一样有益

勤奋工作，并非切题

我们不会用花了多少小时工作，或者有多少人呆在办公室里作为衡量员工和团队的标准，我们只在意是否完成了伟大的工作成就
持续做出 B 级的工作输出，不想着做到A级的效能，只能请他拿钱走人，客客气气的
保持 A 级的工作输出，追求最大效用，将会被委以重任，酬以重金

不羁天才

有些公司容忍他们
对于我们而言，这种人会使得保持团队效率的代价太大
保持多样性的风格很好，但这个人得体现出前述 9 种价值观

3. 自由和责任

罕见的有责任感的人是

自励
自知
自律
自我提升
如同领导者一般行事
不会等着被叫去做事
主动捡起地上的垃圾

为什么大多数公司成长伴随着员工自由的缩减和公司的日益官僚化?

对于做大的渴望压缩了创造的增长
成长增加了公司的复杂度
成长同时稀释了人才密度
混乱和错误扰乱，在这个人才水平上，业务已经变得太过复杂而不可能以非范式的形态运行
流程开始出现以停止混乱
强调流程作业驱离更多人才
流程作业引出强有力的短期行为结果
接着市场变了
流程和员工无法适应变化
……

以超过复杂度提升的速度提升人才密度

提升人才密度

支付市场最高薪酬
用自由吸引高价值人才产生巨大影响
强化高效能的企业文化

将复杂度增长降至最小

用少数大产品取代数量众多的小产品
消除让人分散精力的复杂度
警惕效率优化所带来的复杂度和僵化度增长

自由不是绝对的

两类必要的规则

为了阻止不可挽回灾难
为了避免道德、伦理和法律问题

大多数情况下，快速修正都是正确的模式

尽快修复问题
我们处在一个创新的市场，而不是一个类似医药或者核能这样以安全性为第一的市场
你也许听说过预防错误比修复代价更低，是的，在制造业或者制药业的确如此，但在创新型行业里并非如此

好流程 VS. 坏流程

好流程帮助人才搞定更多事情

当你在升级代码时让其他人知道
在每个季度都按照预算花钱，这样就不用频繁通过部门会议调整每一笔支出
定期制定战略和搞清会议背景

坏流程试图阻止可以恢复的错误

得到预先批准的 5000 美金支出额度
要 3 个人签字才能终止的横幅广告创意
在墙上贴个海报需要的许可
项目所需的多层级许可流程
找 10 个人去面试每一个应聘者

案例：Netflix休假规定和考勤管理

我们并不追踪每天或者每周的工作时间，为什么我们要追踪每年休假了几天呢？
我们应该关注人们做了什么，而不是做了多少天
既然我们没有朝九晚五的工作时间规定，我们也就不需要假期规定
你不需要为每样事情都制定规则

自由与责任的其他一些例子

围绕员工如何花销，如何出差，可以接受何种馈赠等等，大多数公司都会制定复杂的政策
再加上一整个部门来核实员工是否遵循了这些政策
Netflix 关于花销、娱乐、馈赠和出差的政策是：最合乎公司利益

4. 情景管理而非控制

如果你想造一艘船，先不要雇人去收集木头，也不要给他们分配任何任务，而是去激发他们对浩瀚汪洋的渴望

最佳的管理通过设定合适的情景而非试图控制员工以达到最大成果
致管理者：当你的人才犯下了愚蠢的错误，不要指责他们。相反，你应该问问自己，在情景设定上犯了什么错？

5. 认同一致，松散耦合当

高度一致又松散耦合的团队效率取决于高绩效人才和优秀的情境管理

合作团队的 3 种模式

紧密耦合的巨无霸型
各自为政的国企型
认同一致 - 松散耦合型
- 除非是为了目标和战略而合作，否则尽量减少跨职能部门的会议
- 相信团队合作执行战术动作，无需进行预演或者审批，这样团队能快速行动
- 领导者在合适的时间积极出手做临时协调
- 偶尔的战术复盘对增进团队间合作是必要的

6. 支付市场最高工资

一个卓越的员工比两个胜任的员工做得更多，花得更少
我们致力于只雇佣卓越员工
持续地基于市场价格制定薪酬是最好模式

判断卓越员工的 3 个测试

这个人可以在别的地方得到吗？
为了取代他我们要付出多少？
为了留下他我们愿意付出多少？

没有固定的人力预算

每年没有公司高层决定的“加薪池”
每个管理者每年把自己下属的薪酬和市场最高价格调整到一致

薪酬并不取决于 Netflix 的成功

体育队伍哪怕失掉比赛也得按照市场水平支付薪酬
员工可以通过决定持有多少 Netflix 期权的方式，决定自己愿意多大程度上把自己的经济前景和 Netflix 绑定在一起

糟糕的薪酬实践

管理者根据头衔，按照百分比排列设定薪酬
管理者关心内部薪酬一致而无视外部人力市场价值
管理者给每个员工 4% 的增幅
传统模式是上年度业绩好则加薪，完全和市场价格脱离

高薪是最有效的薪酬形式

在任何给定的费用中，高薪最具激励性
没有奖金，没有免费的期权，没有慈善比赛
相反的，把所有费用尽可能的打入高薪酬包，给予员工按照自己的意图花费薪水的自由

不要用等级刺激员工

避免用“最好的 30% ”或者“最差的 10% ”这样的等级来刺激员工
我们不希望员工感觉到彼此之间是竞争关系
我们希望员工是所有应聘者中的“最好的 10% ”
我们希望员工彼此帮助，而他们也的确做到了

7. 晋升和成长

平凡的同事和无挑战的工作正是杀死员工工作技能的元凶
我们希望员工管理他们自己的职业发展，而不是依赖于公司“规划”他们的职业生涯

篮球类比：小联盟和大联盟

非常有才华的人经常得到晋升，但仅仅是对那些真有才华的人来说是这样
有些运气是依仗有什么位置空缺，或者面对某种竞争
有些人转岗到其他团队获得了他们所需要的机会
伟大的团队保留住他们最好的人才
有些小联盟的球员即便没有得到升迁也继续打球，原因是他们热爱这个游戏

不必在 Netflix 呆一辈子

在某些时候，某些团队，也许没有足够多的成长机会给每个人
在这种情况下，我们应该为某些人离开 Netflix 得到更好的工作而庆祝，因为我们并没有合适机会可以给他

两种升职的必要条件

工作必须足够重要
这个人必须在现有的岗位上是个超级明星

升职时机

如果一个管理者可以通过升职来阻止一个员工的离去，那么这个管理者应该现在就给这个员工升职而不是等待
达到上述两种升职必要条件

谈谈加班

i@lipan.me (李攀) — Thu, 24 May 2018 00:00:00 +0000

很无奈地跟团队宣布了接下来的加班原因和加班计划。

虽然自己的工作时间基本是 996，但是我很不希望团队长期处于加班的状态，工程师的成果不是能通过工作时长来衡量的，所以谈谈我对加班的看法。

为什么自己要 996

一定不能用战术的勤奋来掩盖战略的懒惰。

公司战略，产品方向，团队配置，技术选型，项目规划，如果上述东西哪一项没有理清楚的话，都一定不要要求团队加班，加班就是做无用功。作为团队和公司的负责人，一定是比团队其他花更多的时间去思考、规划和解决上面的问题。

看到有些团队负责人说，「刚开始实行 996 一个月，就有人提出离职了」，「团队全年离职率为零」，其实都是有问题的，都没有掌握好度。

什么情况下需要加班

先问自己几个问题：加班项目是否能够有效提高公司的销售业绩？是否能够有效降低公司的运营成本？是否能够改善研发流程和提高研发效率？是否符合公司未来战略布局？

无意义加班、重复劳动和返工对一线成员影响很大，这部分需要技术负责人来把控，保证技术团队接收到的需求是正确的。

所以，需要保证：

产出的工作是有效的
目标非常明确，比如上生产出了问题需要立即解决
能使公司业务快速增长，公司业务快速增长是最好的团建

另外，加班前一定要告知团队本次加班的目的和计划的周期，达到目标后会恢复正常的状态，这样才能让团队成员有所期望。

团队成员为什么愿意加班

支撑团队成员接受高强度的工作时长无外乎是对工作内容的高度认可，有温度的管理氛围，高度协同的工作同事和合理的物质回报。所以：

通过 OKR 等方式来设定目标，让全员都有很强的自驱力和目标感，认同公司的业务和发展方向，成为公司命运共同体的一部分，为自己的事业而奋斗
后勤要跟上，比如加班餐，加班水果，打车报销等福利，项目庆祝，非加班期间多一些活动，周五不加班等
全体动员，全公司步调一致进入作战状态，只有各部门步调统一，才能做到跨部门的高效协作，拧成一根绳
完善的绩效奖励机制，薪酬和职级体系，付出总有回报

加班干什么

写平时没时间写的单元测试代码
优化和重构代码，让 API 更快地返回、让服务更稳定
优化产品，思考产品怎样才能让用户获得更好的体验
探索和尝试提升研发效率的工具
完善待改进的工作流程
技术分享，打造学习型团队

如何平衡工作和生活

运动是必不可少的，在不加班期间，保持每周 2 次大运动量的运动，数次小运动量的运动，打好身体基础，身体真的是一切的根本。加班期间保证周末 1 次运动和 1 次娱乐放松，平日适量运动。

运动是自己一直坚持比较好的一件事情，坚持运动的人一般精力会更旺盛，能适应长时间工作，也会更少生病，好的体质是根本。

事实上时间都是挤出来的，自己并未感觉到时间不够或工作严重挤压生活时间，其实是可以很好地在工作和生活中做一个平衡。

如果团队成员也能平衡好身心、家庭的关系，必定能爆发出更大的工作热情和工作效率，从而提升团队产出。

不应该提倡什么

加班不应该上升为一种文化，更不能宣传这种奉献。

最近发现的几个优秀库

i@lipan.me (李攀) — Wed, 16 May 2018 00:00:00 +0000

最近几天发现几个有用的库，以后产品上一定能用得上，记录一下。

Lottie

真可谓大幅降低开发工作量的库，以前客户端用程序来实现动画是一件既耗时又很难达到设计师效果的事，加上项目开发周期一般都会比较紧，动画相关的功能优先级会放低，优先级放低，很多时候也就意味着被砍掉了，原本提升用户体验的效果，结果被无奈的大打折扣。

Airbnb 开源的这个库解决了开发的问题，只要设计师通过 AE，尽情实现想要的效果，然后通过 bodymovin 插件导出 json，开发只需要用 Lottie 即可完成动画效果。

而且，Lottie 同时提供了 iOS、Android 和 Web 三端的库，这样也可以保证同一个效果在各端显示的一致性，Android 小哥再也不用愁和 iOS 小哥实现出来的效果不一样了，同时也保证了多个产品线风格的统一。

Intro.js

看名字基本就知道是干嘛的，对，就是给 Web 产品用来做新功能一步步教程引导的库，这个相信有 Web 产品的同学们都能够用得上。

MPAndroidChart | Charts

基本上常用的图表都有了，还带缩放、拖拽、动画等，满足绝大多数场景。

Hero

iOS 上非常优雅的动画转场移动库。

ijkplayer

B 站开源的一款基于 FFmpeg 的视频播放器，支持 Android 和 iOS 两个平台，大多数的坑，特别是 Android 上的坑都被踩过了。

技术领导力的艺术

i@lipan.me (李攀) — Thu, 13 Jul 2017 00:00:00 +0000

本月初参加了极客帮组织的GTLC（全球技术领导力峰会），收货颇丰，20多场演讲基本都比较务实，干货有不少。

整体感觉是，作为科技创业公司的技术负责人，大家在愿景、思维方式、价值观、创新意识、以至于遇到的问题和困境上几乎都一样，大家交流起来极易产生思想共鸣。

实际上，CTO是比其他O更难的角色，除了懂技术以外，还要必须要懂业务，懂产品，懂设计，懂运营，懂市场……需要是团队里面最全面的成员。

下面是会议的收获和我的一些理解：

CTO必备技能

职责：建立技术团队文化，规划技术发展路线，落地产品研发成果。
素质：谦虚谨慎的工作态度，随机应变的处事风格，统领全局的战略思维。
硬技能：技术能力、业务能力、管理能力。
软技能：领导能力、学习能力、抗压能力。

CTO进阶

思维的转变：以支持各部门为中心到以用户为中心，站在用户的角度去思考问题。
技术领导力的进化：从研发能力到资源整合能力，资源协调和资源重组。
更高的视野：从仅聚焦某部门或职能到连接企业各部门。
角色的升级：从关注交付，实施和执行到商业战略导向，需要像CEO一样去思考。
义不容辞的责任：让公司重视技术、技术驱动甚至是技术引领。
反转的态度：从理解产品需求到跟产品甚至投资人说技术能做什么以及做到什么程度。
无可挑剔：以专业服人，以身作则，每一件小事都高标准要求自己和团队，并获得团队的认同。

人才

招聘
- 创始人需要足够重视人才的招聘，前期招人所花的时间是值的，一定要亲自做。
- 先通过一级人脉，翻遍电话本、微信联系人等，一次次约咖啡，一次次讲愿景，激情澎湃。
- 再通过开源社区资源去挖掘合适的人才。
- 每个顶级人才都希望和同样水平的人共事，每一个进入的人对以后招人都非常重要。
- 用心建设雇主形象，公众号，博客等，干货Only。
培养
- 创造学习机会，充分赋能。
- 提供有挑战的事情，让聪明的人在一起。
- 不惜赞扬和认可。
- 帮助技术团队成员达到个人职业目标。

团队建设

开放的理念。互联网企业一定要有开放的心态，这个理念应该贯穿在公司和团队的每一个细节，每一件事情上。
每月一对一面谈。这个也是我坚持了几年的习惯，收集反馈，解疑答惑，畅快谈心，目的是为了让大家把想说的说出来，想暴露的问题暴露出来，事后一定要去解决这些问题，让大家能更爽的工作。
每月全员工程师会议。保证每个人对公司目前阶段的方向和优先级是明确的，走在正确的路上。
技术团队文化。文化是团队的灵魂和核心，也是隔壁公司出高价也挖不动人的根基。
鼓励创新，鼓励使用最新技术与工具，鼓励开源，反馈社区。技术人员的追求，莫过于不断的保持对新技术的饥渴和学习姿势，鼓励创新，鼓励使用新技术是对团队极大的支持。

绩效考核

对孵化中的项目考核应该更宽容，不定指标。初创项目（10人以内）具有太多的不确定性，应该将更多的时间花在技术和产品上，而并不是花在考核和制度上。
技术绩效考核应该考核的三部分是：业务部分，系统稳定性，学习能力。团队大了以后，需要有目标和激励，绩效考核的目的不是考核，而是提高绩效，不管是KPI还是OKR都不重要，有没有做正确的事情才是关键。

融资

期权应该是所有股东一起稀释，第一期不需要太多，10%左右就够了，后面需要的话再一起稀释。
战略投资人：实现他的梦想而不是你的梦想，战略完全一致是竞争对手！
财务投资人：帮他赚钱即可，一定不要签对赌协议，自己坑自己，没有正确的认知。
坚持，不要脸，坚持不要脸。

其他

技术总是在短期内被高估，但是在长期又被低估。
放下自我，比团队认同自己更总要的是，让团队认同共同的目标。
居安思危，如履薄冰 - 最顺利的时候总是最危险的时候。
昨天最好的表现，是今天最低的要求。
不管是技术还是管理，前方是无人区，有待我们探索。
一个人走得快，一群人走得远。

最后，放几张现场的图片：

明年再去。

聚会玩错过了狼人杀吗？

i@lipan.me (李攀) — Fri, 03 Mar 2017 00:00:00 +0000

最近视频狼人杀很火，好多朋友问我聚会玩当初为什么没做狼人杀。

统一回复一下吧：

狼人杀作为一款生命周期超长的游戏，自2001年问世以来，一直在民间、桌游吧等存在，却一直不温不火。
2013年底为了提高活跃度，我们确实准备做在线版的狼人杀，但因为某些原因却并没做，现在回想起来，如果当初做了，效果也未必好，因为3。
15-16年全民直播让所有人接受了直播这种互动交互方式，同时JY等狼人杀神级别玩家的带动，以及Lying man等直播节目的火热，在16年底把狼人杀这款游戏推到了一个小高潮。

我觉得，趁热，接下来一定会有狼人杀为背景剧情的手游出来，反应迅速的游戏团队应该已经在做了。

所以，创业的时机非常重要，即使13年底我们做，其他条件不成熟，也未必能火起来（让我自我安慰一下吧）。赶上这一波环境，你就起来了，顺风顺水，如果没赶上，很难。

错过了就错过了，说这么多有啥用，哈哈。

卷土重来，我的第二次创业已经开始

i@lipan.me (李攀) — Fri, 02 Dec 2016 00:00:00 +0000

三年七个月后，我最终结束了聚会玩这段漫长的创业旅程。一句话总结，没有尽早商业化，遭遇资本寒冬。其实，现在聚会玩拥有的1600万用户通过广告收入和游戏联运是赚钱的，但是我们已经看到了后面我会说到的天花板。还是老一辈的教诲好啊，Too young, too simple, sometimes naive.

在聚会玩创业之初，就知道创业这事儿注定是九死一生的结局，即使知道自己当时的性格并不太适合创业，即使知道自己要承担非常高的时间成本的代价，但也没人能拦得住，就这么做了。

一路过来了，无怨无悔，之前也写了不少文章，在经济飞奔房价飞涨的这几年，比很多同时期的同学和朋友少赚了很多钱，我们还经常用“当初拿到投资人的钱如果去买房子的话都已经翻几倍了”等来调侃一下自己。但又总可以用获得了别人无法获得的经验这一点冠冕堂皇的理由，聊以慰藉。

这里再次提炼一些经验：

「互联网思维」提倡的免费是骗人的 「互联网思维」应该是2013年最火的词了，用户思维，体验为王，口碑，快速迭代，极致，免费，低价，创新等关键词都是其所提倡的，这些词在当年风靡整个行业，各大会议分享上面，演讲者都以这些关键词为主题，听众们如痴如醉的被洗脑。在当年，不管是创业者还是在投资界，如果你做的事情不是免费，不是以用户增长为基础，而是只赚钱的项目，是会被其他人鄙视的，是没有想象空间的。但是，当资本寒冬真正到来的时候，所有只做免费，只做用户的产品，都挂得差不多了。所以，又有了第二点。

不以赚钱为目的的公司都是耍流氓 公司生存的最基本点就是能够活下去，活下去，活下去，如果连活下去都成问题的公司本身就是有问题的，所以公司从成立之初就应该明确，公司的目的是赚钱，在能赚钱正常存活的基础上才能谈如何创造更多的社会价值，纯依赖资本的模式是不长久的，即使不被资本束缚，也很可能会因为资本环境的变化而出现极大的风险。

产品方向一定要尽早清晰 互联网产品虽然是迭代出来的，但主要的方向要尽早明确而且去验证，这个过程需要非常迅速果断，不能有半点含糊，试错的沉默成本是我们最容易忽略的，这些沉默掉的时间成本累积起来相当惊人，很可能就是最后结果的直接原因，很多产品都会因为早期方向问题或市场原因经历转型，然而能转型成功的寥寥无几。

决策要果断，忌优柔寡断 不管是产品方向，研发效率，团队人员能力，各方面都要及时调整，切记不要优柔寡断，这是我们犯的最大错误，决定了该做的就尽快去做，去试错，该提高的效率就尽早去提高，磨刀不误砍柴功，能力不足、能力提升跟不上公司发展、影响团队等该开的人就尽早开掉，开人一定不是公司的损失，而是收获，想想你为什么有想开掉他的念头就知道了。

做了三年多，从产品技术驱动的公司，最后无奈转型为平台渠道型公司，摸爬滚打这么久，也算是从移动互联网踏入半只脚到游戏行业，简单分析一下游戏行业上下游的情况吧：

游戏开发商（CP） 上游的游戏开发商要有团队，要养团队，要有IP，要有验证过的框架，要有验证过的完整的数值，这样游戏做得好才可能卖一笔可观版权给代理，然而在国内同质化的游戏市场，真正能走出来的还是那些踏踏实实创新的团队，换皮、逐利、追求快钱的团队也许能赚点钱，但是注定难做大成；

发行代理商 中游的发行代理商要有钱，才买得起CP的版权，还要看得懂市场，知道哪些游戏可能会爆发，市场需要什么样的游戏；

渠道下游的渠道要有流量，做的其实是流量变现的生意，然而大部分的流量其实都已经被几家大的公司垄断了，小的渠道活的很累很艰辛，人口红利期已过，流量的获取和转化成本越来越高；

从移动互联网之初我们就知道其商业模式就是广告+游戏，所以大家趋之若鹜的入坑游戏也是有道理的。

越说越远了，所以聚会玩作为下游渠道，就像上面说到的，有瓶颈和天花板。

于是，我们在这个时候选择了暂停，在事业的黄金期去寻找新的方向。

在画这个不算完整的句号的时候，我还是想比较俗的感谢一些人。

首先，谢谢我老婆，从创业一开始你就一直支持我。从广州到上海，你放弃的东西，我都记在心里，在这个时代，我认为已经很难找到像你这样知性的人了。

感谢我的合伙人李伟，我们俩认识12年，创业3年多的过程中，我们之间没有发生任何大的矛盾和冲突，配合非常默契，这样我们才能把更多的时间放到产品和公司运营上去。

感谢所有在聚会玩工作过的同学们，你们的实力是我们能坚持这么久的根源，我们一直想给大家打造一个最佳的工作环境，相信你们也能感受到我们的努力。

感谢所有帮助过我们的朋友们，我会继续努力，后面的路还得靠你们相助。

终于可以简单说说新的事情了。

首先我认为，针对C端市场的纯移动互联网产品的机会已经不多，移动互联网格局基本已定，接下来是时候在某个行业去深耕了。未来的方向，一定会和大数据、人工智能、云计算等紧密相关，2B和企业服务还有不少机会。

我的新公司由海致（国内领先的商业数据分析平台）和万得（国内最大的金融数据和分析工具服务商）合资，取二者之所长，新产品大方向是金融大数据，专注金融分析B端市场，是大数据落地和在金融行业实施大数据的最佳实践。前景就不用多说了，千万级天使轮融资已到位，我目前负责整个公司的技术研发，团队正在组建中，希望有志在金融行业和大数据领域深耕的同学们能一起加入来创造奇迹。

这次，卷土重来，继续从头开始，但不再屌丝。

简单几步在Mac上实现智能VPN

i@lipan.me (李攀) — Thu, 03 Nov 2016 00:00:00 +0000

VPN 是好用，挂上之后国外的网站是能访问了，但原来国内正常访问的网站立刻变得慢吞吞了，怎么破？这是个问题。如果连了 VPN 没做任何设置的话，会导致所有网络都是通过 VPN 访问，缺点有二：

1、VPN 的流量问题;

2、国内网站变慢吞吞的问题。

方法： 1、自行搭建 VPN 服务器或购买 VPN 提供商的服务(见上一篇)。

2、打开系统偏好设置—>网络，增加 VPN 设置，根据提示设置用户名密码等信息即可。

3、下载 chnroutes.py，https://github.com/jimmyxu/chnroutes/blob/master/chnroutes.py

4、打开终端进入下载文件的目录，执行：python chnroutes.py -p mac，该目录下会生成两个文件「ip-up」和「ip-down」。

5、把这两个文件复制到 /etc/ppp 下

搞定！

用AWS几分钟搭建自己的VPN服务

i@lipan.me (李攀) — Tue, 25 Oct 2016 00:00:00 +0000

使用VPN的好处很多，比如隐私，匿名，访问被封锁的网站，更安全，以及克服地理上的限制等。然而你总是很难信任你的VPN提供商，因为他们可能会记录或劫持你的流量。所以私有VPN服务器会给你安全感。通过按照这篇教程的步骤，你将在10分钟内搭建起自己的VPN服务器。

私有VPN的好处

简单： 即使不懂技术也能轻松地按步骤执行

快速： 只需10分钟就能跟着教程搭建起一个私有VPN

私有： 只有你自己使用的专属VPN

安全： 数据加密，密码保护，以及不会留下访问日志的VPN按需使用：你可以根据自己的需要启动或停止VPN服务器

全球： 在全球9个区域建立一个或多个VPN（包括美国、东京、新加坡）

设备支持： 支持PPTP和L2TP安全协议，也就是说你可以通过Android、iPhone、iPad、PC、MAC，甚至大多数路由器来使用VPN

开源： 你可以在github上查看源代码，提交代码。https://github.com/webdigi/AWS-VPN-Server-Setup

免费： AWS的新客户可以在第一年免费使用。

开始建立你的私有VPN服务器

1.首先你要有一个免费的亚马逊云服务账号访问 http://aws.amazon.com/free/ 完成注册。如果你已有亚马逊账号，请直接登陆。

注意：完成注册需要一张可以刷美元预售权的信用卡。

注意：注册过程中确认联系方式时，需要你语音读出pin码。

2.选择你的VPN所在区域这里指的是你的VPN服务器所在的地址。亚马逊的云服务器在全球很多区域都有数据中心，你可以选择其中之一。选择后，你的流量就会通过VPN服务器所在的地方连接互联网。在国内通常推荐东京或新加坡，网速会稍微快点。

3.在AWS控制面板中打开CLoudFormation 你可以直接点这里或者根据下图所示从AWS控制台中进入。

4.开始用CloudFormation创建堆栈在左上角点击“创建堆栈”按钮。

5.为堆栈设置模板我们可以使用别人配置好的模板，相当于复制了一份别人的机器，很多复杂的安装过程和配置过程都已经做好了，所以我们才能在10分钟就搭建起自己的服务器。直接选择“指定 Amazon S3 模板 URL”并将下面的链接粘贴上去，点击下一步即可。 https://s3.amazonaws.com/webdigi/VPN/Unified-Cloud-Formation.json 这里相当于用json文件描述了一个EC2主机的配置，可以直接下载看看文件的内容。

6.指定服务器的详细信息

堆栈名称: 也就是VPN的名称

speed： 选择Standard.VPN-Free已经足够大多数人使用了。当然如果你要看视频的话也有高速服务可供选择。

Username： 用于登陆VPN的用户名

VPNPassword： 用于登陆VPN的密码

VPNPhrase： 用于L2TP安全连接

7.不需要添加标签，直接下一步直接下一步

随后你可以对刚才配置的内容进行一次审核。直接点击创建就好。

8.等待创建完成等待创建完成这一步你可能需要等上两分钟左右。当状态变成绿色的CREATE_COMPLETE的时候，就创建完成啦。

9.获取私有VPN服务器IP地址在输出tab下查看IP地址。这就是你私有VPN服务器的IP地址，记下它，你需要用你的设备连接到这里。

连接你的私有vpn

到这里我们的服务器端设置就完成了。下面我们以windows为例展示如何连接到vpn

1.进入“设置-网络和INTERNET-VPN”，选择添加VPN链接

2.填写VPN信息

连接名称可以随便写。

服务器名称要写刚才第9步里获取到的ip地址。

VPN类型是PPTP。

登陆信息的类型选择用户名和密码

下面的用户名和密码是可选的，如果不填的话，就要在每次登陆时重新填写。

3.选择连接选中刚才添加好的VPN，点击连接，输入账号密码，等待出现完成连接

4.验证访问 http://ip.cn 验证是否连接成功。当页面中显示的ip地址与你VPN服务器地址相同时，即证明连接成功，实现科学上网。

fastlane - iOS持续部署神器

i@lipan.me (李攀) — Thu, 25 Aug 2016 00:00:00 +0000

先说一个严肃的问题，我们为什么需要持续部署（Continuous Deployment）？

为app提交、上传截图、发布等节省大把大把的时间（cry
iOS大哥蜜月旅行去了，iOS小哥要修复线上紧急bug并发布客户端版本，怎么破？不要在发布版本这件事情上仅依赖一个人
通过高频的小版本迭代来提高版本的质量

然后，我们来看一下实际工作中的iOS开发、打包和发布流程：

开发前，需要登录苹果开发者后台创建App、Provisioning Profiles、certificates等；
使用Xcode开发，然后将上述相关文件和证书配置好；
编译项目并自测；
Archive项目；
上传包到iTunes后台；
配置TestFlight，准备测试刚上传的版本；
发布测试版本；
测试发现问题，重回2；
测试完成，在iTunes后台提交版本截图、描述等信息；
提交App Store审核；

一直以来让iOS开发者头疼的问题就是上述10步繁琐的打包和发布流程，看似10步也不多，然而懂的人知道，这其中每一步都可能有坑，都可能都要花不少时间。然后，我们团队在做新项目的时候发现了一个神器，可以说是相见恨晚，这个神器就是fastlane，他几乎可以把上述流程全部自动化，而且还可以做的事情更多，想一下当初大把大把的时间都浪费在了这上面，现在终于可以解放的激动心情吧。

先介绍一下fastlane，fastlane是一个完全开源的项目，现在被Twitter收购，是Fabric的一部分，主要是提供自动化构建和发布的一系列的工具集合，他包括iOS和Android工具集，由于我们只在iOS上使用，所以这里仅介绍一下iOS相关的工具：

deliver: 上传应用截图、metadata信息和ipa包到iTunes，提交审核
snapshot: 在所有分辨率的iOS设备上截图并上传iTunes
frameit: 快速地把应用截图放入设备框里
pem: 自动生成推送使用到的的profiles
sigh: 创建、更新、下载和修复provisioning profiles，支持App Store, Ad Hoc, Development和企业profiles，而且可以自动添加测试设备UDID
produce: 使用命令行在iTunes和Dev后台创建iOS app
cert: 自动化创建和维护你的iOS签名证书
pilot: 管理TestFlight的测试版本和测试设备
boarding: 自动创建一个表单来邀请参与TestFlight的用户
gym: 编译、打包iOS app，生成签名的ipa文件
match: 通过git在团队中共享和同步你的证书和profiles，避免团队开发经常遇到的iOS证书不一致的蛋疼问题
scan: 跑测试用例

上述gym, sigh, match等几个工具可以说是极大提高效率的神器。

下图是一个简略fastlane工作流程：

总之，fastlane帮你统一定义、运行、自动化你的app发布流程，并且可以和其他第三方工具如CocoaPods等很好的结合，也可以和其他第三方持续集成(Continuous Integration)工具如Jenkins等完美的结合，不说了，从现在就开始快回去拯救你团队成员的生命吧～