Agilean 近期参与了广深珠三地的敏捷社区活动，我以知微产品团队为例，分享了如何以10人分布式小团队，打造出一款支持千人组织敏捷运作的产品。话题得到小伙伴们的热烈反馈，因此将内容整理成文，与更多的朋友交流。

Agilean 作为国内最大的专业敏捷咨询公司，在这个行业已奋斗了十年，长期服务平安、招行等卓越公司。在中国企业科技化、创新化的大背景下，市场前景越来越好，但我们总觉得缺了款专业工具，来加速推动组织级的敏捷转型进程。三年前，Agilean 团队开始打造知微，初心是做出一个助推组织级敏捷转型的产品。

我们看到过一些不错的协同工具，或敏捷工具，发现它们多数聚焦于项目级、团队级问题，并且往往只针对研发团队。我们心中的知微，能打通业务、产品、研发、运维、运营等环节，帮助客户实现端到端的全流程管理闭环。

本文将分享知微的研发过程，细数其间遇到的挑战和解决思路。聊聊一个简单原型，如何成长为支撑千人组织敏捷运作的商用产品。

问题：异地办公，协同效率低，管理成本高

解决：用电子看板营造虚拟工作现场

知微的第一行代码，是三年前在北京香山会议中心敲下的。历历在目的，除了热烈的争论，各种外卖盒和零食，还有西山美丽的朝阳晚霞。在只有2个全栈开发同学的情况下，我们在3天内封闭完成了初始原型。第一年，我们将精力用于探索产品定位，两三个人的投入，没有感知到什么管理问题。

To B 产品打造是个精雕细琢，一点儿也急不得的过程。从第二年下半年开始，团队开始逐渐扩展，直至最近达到10人之多。下图是知微的人员构成：

随着产品逐渐稳定，目前现场同学的占比已经比较高了。但在团队走到当前规模的过程里，分布式办公是我们遇到的一个突出问题。异地协同导致沟通效率低，但管理成本又很高。于是，我们开始了「吃狗粮」之旅，即用知微来管理它自己的研发过程。

需要敏捷的组织往往是以脑力工作者为主的组织，脑力劳动的管理难点之一是工作过程不能被清晰「看见」，工作成果也就很难被实时评价。解决协同问题的第一要务是要能看见。我绝大多数时间都在客户现场，管理者80%-90%的时间不能和团队在一起，该如何实现「可见」？

第一步，我们用知微的电子看板功能，营造了虚拟的工作现场。在电子看板上，团队的工作内容、任务分配、进展阻碍等信息一目了然：

知微资深开发工程师 Walt：

最初，我们想做个能完美复刻并超越物理看板的电子看板。这个目标很快就实现了。

头两年，大家不在一起办公，分散在不同城市，我们就用知微的任务看板开每日站会。每个人点亮的（认领的）工作、协助他人的事情、受阻求助、任务进程等等信息非常清晰，10分钟的虚拟站会（语音或视频方式），团队能够快速对齐状态。同时辅以知微的日报功能，实现每日任务对齐并留痕。

另外，知微的讨论功能聚合了聊天和邮件两者的优点。我们在卡片上基于任务做即时沟通，讨论细节，@他人协助，这让远程沟通协作变得顺畅平滑。

为了实现快速聚焦，避免「看而不见」，过滤功能很快被开发出来。下图就是以「版本」为条件进行过滤，展现了当前版本所有故事的进展情况。

随着身处现场的同学越来越多，我们给团队配备了最好的物理工作现场：宽敞的办公室，午睡的行军床，随意取用的零食，每个同学都是顶配的Mac Pro笔记本和双屏显示器。「大脑+电脑」是我们最重要的生产工具，给研发同学配置最好的硬件设备，对企业来说，其实是非常划算的行为。

问题：什么都想做，什么都做不好

解决：整流，用看板构建优选机制

知微的第一批试点用户包括中华保险、上海银行、顺丰速运等企业。这些企业规模大、要求高，一时间，客户提出的反馈和需求数量呈火箭式上升。

那个阶段，我们一度掉进了「不聚焦」的陷阱，什么都想做，但什么都做不好。想服务好用户的诉求，也要考虑产品自身的规划，需求池常常处于饱和状态。随着团队越来越忙碌，心态越来越焦虑，我们下决心开始整流。

整流，就是建立起需求优选机制，通过限制在制品，减少工作并行，让研发同学保持专注，从而提升流动效率，降低交付风险。

上面是团队当前截图。最左边一列，也就是作为起点的「想法」列内，有215张卡，意味着我们有215个想法/需求。但在第二列，也就是「选择」列内，只有7个需求，这7个需求是团队当前要聚焦的对象。

知微产品经理 ZYC ：

当初实行「整流」的思路很简单：先把积压需求阻挡在研发系统之外，避免加剧当前进程中的阻塞，让我们能腾出手来，快速优化研发流程。

在我们的工作过程中，「整流」在两个地方被突出体现。一是经过优选的需求进入「选择」列后，开始编写需求，出设计稿；二是高优先级的需求（卡片左上角有红点）会先进入研发计划，即进入「开发就绪」后的「优先」列。通常，排进下个版本的需求会先进入研发计划，具体下图可以看到。

小团队运行整流机制比较容易，但在大组织，整流就是一件有难度的事情。10个业务团队面对同一个研发部门，出现公地悲剧实属正常。没有哪个业务团队愿意主动缩减自己的需求，或者让自己的事情被最后完成，结果就是造成了研发过载。

有个很好的办法可以解决这个问题，就是引入研发与业务对齐的部落机制。通过划分部落制（虚拟部落也可），让庞大复杂的组织变得灵活，并通过知微确保运作机制的逐步落地。未来，我们将专门分享一个在千人规模的研发组织，两个月内引入部落制的成功案例。

问题：需求优先级天天变，澄清细化几乎不可能

解决：RISE 版本迭代节奏

做创新产品，很难在一开始就把需求想清楚。真实客户又不断带来新的挑战，于是，需求优先级变化成为常态，有一段时间，开发人员接到的需求很粗，要与产品经理反复澄清细化，大大降低了开发效能。

痛定思痛，我们开始了 RISE 版本迭代节奏：每个版本由需求迭代和研发迭代构成。还记得前面所说的整流吗？经过选择的需求会进入需求迭代，这时候，产品经理开始细化需求，设计师开始设计。需求经过内部评审后，进入「开发就绪」列，走到这里的需求才有资格进入之后的研发迭代。

那些不能及时完成澄清的需求，可能会延期到下一个版本。如果开发这时有富余产能，我们会把「优先」列之前的积压需求加入这个版本，让它进入研发迭代。我们在知微里构建了这个迭代机制，让它能够顺畅运行，具体如下图：

目前，知微基本每两周发布一个版本，下面是我们的迭代日历：

为了快速响应变化，我们采用了开放式迭代机制。团队不做估算，不承诺迭代范围，随时可以根据业务需要更改迭代内容（只要需求清楚）。高优先级需求完成之后，我们会关闭迭代，准备封版回归发布。

在这个阶段，我们开发出了矩形视图，来加强迭代管理能力。下图就是既按版本、又按个人展示的需求负责人分布情况，用来保证每个版本的容量和分工大体合理，也能同时看到前后两个迭代的整体进度情况。

发现卡片上有不同颜色的细条了吗？黄色代表需求处于澄清中，蓝色代表需求处于开发中，绿色代表需求处于测试中。如果一个版本的规划时间已经过半，但这个视图显示还是「一片黄」，意味着大部分需求仍在澄清中，这个版本就有比较大的逾期风险，需要开始进行干预或者调整。

通过这种方式，版本当前进程被直观展现出来。我们既能实时获取版本进度的整体状况，也能把视角细化到每个人、每个任务。「可视化」的价值在这里被大大体现：

• 人在一定时间、一定范围内关注到的信息有限，可视化要尽量把每个信息点的价值，以合适的形式展示出来；

• 在获取了大量有用细节的基础上，以不同的形式加工信息，能帮助管理者从不同角度，快速抓到重点，看到问题。

问题：需求积压越来越严重

解决：细粒，让开发过程加速流动

需求积压是让大多数研发团队头痛的问题，越是庞大的组织，这个问题越严重。观察发现，需求颗粒度过大是造成积压的重要原因。

上图是知微的累积流图功能，可以看到需求交付时效和在制品数量的变化，表明需求积压在逐渐加剧。

解决方法是把需求缩小到合适的颗粒度，加速需求流动，加速质量反馈，这点在知微团队得到了很好地执行。我们最早用在线文档工具写需求文档，随着知微支持富文本编辑，需求都写在了知微的卡片上，需求颗粒度从源头就被控制起来了。

当然，只有细粒度需求是不够的，还要让需求流动起来。真正的敏捷团队与伪敏捷团队有个明显区别：伪敏捷团队会体现出明显的小瀑布特征。例如，在某个时间段，所有的卡片会集中在开发区域，一些卡片进入了开发的「已完成」列，但没有卡片进入「测试」状态。

不仅细粒度，还要有整体的流动性。每天都有故事在开发，也都有故事在测试。

知微特意加入了协助加速需求流动的设计：看板层层嵌套，价值流灵活定义，在需求之间建立关联关系等等，用户能按照实际情况进行需求分层，并通过知微进行「想法-故事-任务」的组合管理。

下图是我们团队的状态，任务卡片正在从「开发」向「测试」持续流动。开发完成标准，是开发同学向测试同学 showcase，在测试环境演示交付功能。测试同学也会及时启动测试，尽快将需求提交给产品经理验收。

问题：变化太快了，优先级怎么快速对齐

解决：引入「点亮」机制

随着客户增加，知微团队遇到了另一个挑战：外部环境在不断变化，我们怎么才能快速对齐优先级，保持高效协作。

举个简单例子：一个需求上周客户还说很急，这周客户就改变了主意，但是由于没及时内部对齐，后端同学还在开发。或者，后端同学开发完成的内容，前端同学没有注意到，一直被搁置在那里，造成延误。

于是，我们借鉴物理看板给工作任务贴照片的机制，开发了「点亮」功能。下图里姓名处有底色的卡片，即为被该同学点亮的卡。一张卡片被点亮，代表这张卡片今天由点亮者处理。每个人同时最多点亮三张卡片，意味着同一时间的并行工作不要超过三项。

另外，「点亮」是透明给整个团队的，同学们会根据点亮的情况，自主发起前后端对齐，避免失焦和遗漏。除此之外，大家每天早上9点半之前，都会发出当天日报。我则根据当前情况和不断变化的优先级，确保团队聚焦在最优先的工作上，做到力出一孔。

问题：手工测试，质量问题突出

解决：建立自动化测试和流水线

有一段时间，知微团队以手工测试为主，质量问题比较突出。随着产品功能逐步稳定，我们增加了一名测试同学，确保有足够人力来编写自动化测试。

现在，知微已经有了500多个自动化测试案例，各主要服务的覆盖率都达到了40%-50%。

当然，做好自动化测试，光有测试案例是不够的，还要解决环境、隔离和数据问题。

先说环境问题。环境一定要充足，知微团队只有10个人，却有6套环境：

• CI 环境：专门用于后端代码自动质量守护，每15分钟编译打包一次，并执行核心测试案例，测试结果及时推送到其他工具；

• 开发联调环境：CI 通过后，由前端手工部署，用于前后端开发手工联调；

• UAT 测试环境：用于手工测试和验收测试，我们自己的日常协作就用这个环境，第一时间发现问题；

• 灰度环境：用于生产前的灰度测试，正式发布公网前会灰度测试2-3天；

• 生产环境：用于支持知微公网用户；

• 私网测试环境：用于模拟私网客户环境，在给客户部署前，先进行专项测试。

再是隔离问题。在 CI 环境，我们不可能构建出测试所需的所有关联系统。知微团队使用自研的 mock api 工具来模拟外部关联系统，模拟外部接口返回，从而完成隔离稳定的接口测试。

最后是数据问题。我们通过构建测试金数据，30分钟内构造出自动化回归需要使用的测试数据。由于做到了无痕测试，这组测试数据可以反复使用。

目前，知微的接口测试案例基本实现了0噪音。每次测试案例失败，都意味着一定是脚本、程序或者数据出了问题。以这些测试案例为机制，知微团队构建了完整的 CI/CD 自动化流水线（见下图），具体包括构建流水线、部署流水线、分析流水线。

• 构建流水线：在给定时间产生一个质量满足初步要求、用于部署的包，构建流水线只执行核心回归案例，保证在15分钟内完成打包；

• 部署流水线：把包部署到特定环境；

• 分析流水线：对代码进行全面质量扫描，避免风险。分析流水线会执行Sonar 代码扫描和全量接口测试回归。每天中午和晚上执行两次，提供全面的质量反馈。

想了解自动化质量守护和流水线的讲解，可以参考我们的 DEER 研发效能提升路线图。

问题：时间长了，缺陷开始积压

解决：建立分级修复机制，缺陷每日清零

自动化测试上线后，每天都会发现一些新的缺陷。最初团队没有养成及时修复的习惯，于是，缺陷积压出现了。

后来，经过内部回顾会议讨论，我们建立了缺陷看板，明确了缺陷的分级修复机制。只要是当前版本需要修复的缺陷，就争取当天修复完成，当天测试验证。

下面是我们的缺陷修复时效图。自从今年8月执行缺陷每日清零后，修复时效出现了明显的优化，控制在了2天之内完成缺陷修复。

未来：效能持续优化，如何度量和跟踪

解决：建立对度量指标体系的全面支持

知微脱胎于咨询，初心是让组织尽可能容易地从「不够敏捷」走到「足够敏捷」，以组织级管理工具的形式支持这个过程的平稳进行，顺利落地。

组织在变得「足够敏捷」的过程中，如何制定持续优化策略要有科学、合理的依据。其中，重要的是设定指标，量化并统计效能的改善。

为此，知微逐渐丰富自己的度量体系，目前完全实现了对 DEF 体系内指标的支持，能够统计组织效能改善状况，展示问题，并为组织制定效能持续优化策略提供数据支撑。

以 leadtime 为例，它指从「意向提出」到「完成上线」的整个时间周期，通常包括意向形成、需求讨论、设计定稿、开发、测试、上线几个时间段。下图是知微团队近两年的 leadtime 分布统计，我们可以实现对这一指标的分段统计。

Leadtime 还涉及一个有趣的事情：展示了开发同学经常为整体交付慢背锅。很多人以为交付慢是因为开发太慢，但从上图可以看到，开发环节的耗时少于其他环节，需求分析、测试、验收这几个环节耗时更多。

这也是知微做分段统计功能的原因。主观判断容易有误，用数据说话更真实有效。分段计算，让需求完成链条中不同阶段的具体耗时一目了然，团队可以快速发现影响整体交付速度的环节，找到真正的痛点，从而采取有针对性的改善措施。

上图是知微研发团队近3年需求耗费时长的统计，统计结果较好地符合了韦伯分布，即存在一个众数尖峰和一条长尾。排除掉异常时间的影响后，我们就可以用它进行整体交付时效和响应指标的预测。

总结

知微是一个组织级敏捷助推器。本文给出了知微在科技敏捷领域的应用思路，它也可以直接用于业务敏捷、创新敏捷、绩效敏捷等其他方案之中，后面我们将分别撰文阐述。

本文通过知微研发过程中遇到的问题和我们的解决思路，分享了一款典型 To B 产品的诞生和迭代历程。其中，穿插了 Agilean 提出的 FLEET 研发效能提升框架、RISE 版本迭代机制、DEF 研发效能模型等等，想详细了解，可以参考文末的推荐阅读。

需求管理是研发管理最重要的部分之一，知微研发中遇到的问题大部分与需求管理相关。我们有成熟的需求管理解决方案，既包括小团队简单的单层需求管理，也有大型组织复杂的多层需求管理。在 Agilean 公众号，回复「需求管理」，可以获取知微的需求管理解决方案。

目前，知微已经开启了面向企业客户的免费试用邀请。感兴趣的小伙伴，可以扫码关注 Agilean 公众号，回复「试用」或点击「知微试用」自定义菜单，联系我们申请试用。

封面图来自 Pexels ，基于 CC0 协议。

RECOMMEND

推荐阅读

FLEET 精益研发效能提升框架

DEF 研发效能度量体系

DEER 研发效能提升路线图

RISE 版本迭代日历