共计 2708 个字符，预计需要花费 7 分钟才能阅读完成。
拓展浏览：【研发治理 101 军规 001】两周迭代，造成团队继续习惯 | IDCF
【研发治理 101 军规 002】特种部队——更合乎不确定业务的组织架构设计 | IDCF
如果用一句话概述本篇的主题，那就是：关注 8 人团队的自组织性，构建百人团队的研发工作流。
Worktile 是在 15 年的时候引入的 Scrum。在那之前咱们并没有采纳规范的麻利实际框架，一是研发团队并不大；二是咱们本人的合作工具有足够的可视化能力。
但当咱们对外推出了第二款产品 Lesschat（起初 Worktile 企业版 / 合作版，绿色 Logo）当前，Worktile（这里指 Worktile 根底版，红色 Logo）须要继续更新，Lesschat 也须要继续更新，咱们该如何解决工作的优先级呢？
基于理论的问题，公司决定把参加 Lesschat 开发的工程师独立进去，装备上独立的产品负责人，组建了一个 8 人的 Scrum 团队。咱们落地 Scrum 的过程大略是这样的：
第一步：Scrum 团队启动会
首先，确定 Terry 大神为咱们的 PO，确定 Shaun Xu 大神为咱们的 Scrum Master。而后咱们独特制订了 Scrum 团队的工作协定：
由 PO 保护产品待办列表 Sprint 周期为 2 周 Scrum 各个会议的工夫、地点、内容代码提交形式故事点的规范 ……
第二步：先跑一个 Sprint
咱们在第一周周一的早上 10 点，开打算会议。由 PO 进行产品解说，阐明用户故事的优先级，由开发团队预估故事规模、拆分开发工作，以及最初承诺 Sprint 指标。
每天早上 10 点，咱们在工位左近的走廊里开站立会议。每人花两分钟的工夫同步工作进展。
咱们在第二周周五下午 4 点，开验收会议。由开发工作的负责人演示其实现的工作，而后由 PO 决定未实现的工作或新增的 Bug 要不要放在这个版本中。
在第二周周五下午 5 点，开回顾会议。每个人都说一说团队做的好的和不好的中央，咱们一起确定改良计划。
第三周周二的早晨，咱们部署了第一个 Sprint 实现的产品增量。避开周末上线是放心除了问题没人解决，多预留两天是为改 Bug。
第三步：两周一次，不断改进
这个习惯咱们保持到当初。
和很多团队一样，咱们在晚期也遇到了很多问题，比方：
- 前后端共同完成的用户故事预估起来往往偏差较大
- 挪动端小伙伴想要的 API 常常排不上号
- 突发的紧急任务（来自老板）打乱 Sprint 的打算
- 每天的站立会议阶段性的流于形式 ……不可胜数
咱们一直的发现自己的问题，一直的改良。随着一个又一个的 Sprint，们发现能够利用一些优良的工程实际晋升研发效率，比方简略设计、测试驱动开发、继续集成、继续部署等等。我总结咱们的实际如下图：
咱们在变，市场也在变，市场变了，咱们也要跟着变。大略在 16 年的时候，公司决定在 Lesschat 的根底上开发 Worktile 5.0，也就是企业版，面向的是企业场景，方向转变很大，对咱们研发来说又是一次考验。
忘了用了多久实现基础架构的调整，然而肯定很快，快到我曾经忘了遇到了什么艰难。
咱们在 16 年年底根本实现 Worktile 5.0，17 年年初对外公布。
5.0 上线后，Worktile 提供了一种新的企业服务形式，简略概述为：Worktile 平台 +Worktile 的各个子产品（音讯、工作、日历、网盘、审批等等）。
对于咱们研发来说，这里的挑战有两个：一是把各个子产品拆分进去，改为微服务的架构形式；二是研发团队的规模化麻利。第一个问题解决起来很简略，第二个问题的确考验了咱们。
开始的时候，咱们应答各个子产品的需要，采取的形式是打一枪换一个中央。艰深的解释就是，一个 Sprint 咱们投入到“日历”这个产品中，一个 Sprint 咱们投入到“网盘”这个产品中。
很显著，这样的形式不足以应答疾速变动的市场，因为来自“网盘”这个产品的需要往往要等好几个 Sprint 能力实现，对于客户来说这样的速度太慢了。
尽管从研发的角度，咱们是严格依照产品待办列表的优先级安顿 Sprint 工作的，然而这绝非是一个现实的安顿。另一方面，开发人数在增长，然而大家都在一个 Scrum 团队中，这样的团队散会效率越来越差，重大影响了开发工夫。
如何把团队级别的麻利回升到业务级别，这个问题越发重要，随着 Worktile 6.0、7.0 的开发，咱们缓缓的找到了感觉，下图是我总结的教训：
- 团队级别的麻利关注的是构建一个高效的自组织团队。这样的团队可能很好的实现开发工作，也可能利用优良的工程实际晋升自我的效率。
- 业务级别的麻利更加关注的是通过规模化治理研发团队，晋升研发效力，从而继续稳固的实现业务价值。
- 组织级别的麻利更加关注的是通过短缺的市场调研确定方向，而后通过产品的实在数据验证方向，为下一步决策提供根据。
具体实施起来的过程是这样的：
1）市场调研和需要评估
- 调研包含但不限于：行业动态、竞品剖析、客户反馈等
- 需要评估由市场、产品、技术等相干方的负责人参加
2）业务线的麻利
- 按季度或月确定研发指标
- 由技术负责人、架构师评估，由产品总负责人拆分为产品个性
- 由产品总负责人和各个产品负责人拆分个性
- 由技术、架构师、产品确定各个个性的规模和实现周期
- 将拆分后的用户故事放入各个 Scrum 团队的 PBI 中，设置优先级
- 各个 Scrum 团队打算各自的 Sprint 工作
- 各个 Scrum 团队代表每周同步各自的工作进展
- 按期进行各个模块、子产品的集成，部署到 UAT 环境
- 按期实现指标
3）验证需要和后续口头
- 进行必要的数据收集，例如重要页面的 QPS，转化率等等
- 进行数据分析
- 确定后续的产品改变方向
随着麻利实际深刻，咱们发现研发的效力问题是个全行业的问题。同时，通过数据分析，咱们发现自家客户 50% 以上是研发场景，那为什么不打造一个业余的研发管理工具赋能给咱们的客户呢？
于是 18 年，公司正式决定打造 Worktile 8.0（Worktile 研发版，现已独立品牌为 PingCode），19 年 8.0 上线。
在这个过程中，为了保障咱们的交付效率，咱们自研了一套继续交付平台，它能够为各个 Scrum 团队赋能，通过大量的配置化即可接入平台，轻松实现 CICD。
到目前为止，咱们的麻利曾经波及 100 人以上，有管理层、市场人员、产品、技术、运维，甚至还有 HR。
为什么我说 HR 也麻利呢？因为咱们的考核和升级制度，也从硬指标变为以驱动自主性为主，这不就是文化麻利的标记吗？
2020 年，为了给 Worktile 客户提供更好的服务，Worktile 8.0 正式更名为 PingCode，专一于服务研发场景的企业客户，而 Worktile 则持续服务于合作畛域的企业客户。
这对于咱们研发来说又是一个新的考验，然而这样的考验曾经不算什么难题了。
将来的市场还会变，然而咱们有足够的信念应答。
内容起源：孙敬云
作者：孙敬云