上篇文章中，我讲了敏捷第一步-每日站立会，讲了我们平时是怎么开站立会的，其实15-30分钟就够了，绝对不是时间长得让你想拄拐那种。本文我们开始讲敏捷开发中的看板。没有看板之前，我们真的是在白板上画泳道，写卡片，挪动卡片，在白板前开站立会。现在支持任务看板的产品也越来越多了，大家开站立会也方便了，没必要真的站在一块白板前了，只要大家围成一圈，拿个 token 轮流讲就可以。今天我想分享下我是怎么使用

这是「[互联网公司研发效能团队建设] 」的第二篇。为啥研发效能要是一个相对独立的团队呢？独立的研发效能团队是最大化行使职能的必要保障。我一直认为组织架构是第二生产力(第一是人)。搭好台子好唱戏。台子左右不平，前高后低，再大的角都可能崴脚跌跟头。最近在想一个问题：研发效能算公司业务还是算基础平台、技术中台、技术工具？怎样才能做得更好？我们可以定义研发效能团队的工作边界是(需求管理+任务管理+...

研发效能这个词近几年火遍全网，各大企业都加入了研发效能治理的行列，开始梳理企业内部各个团队的研发流程，以期望找到企业降本增效的方向。抛开政治因素，研发效能治理我们到底是在谈什么呢？从企业高管的视角出发，一定是看到了一些问题，才会有研发效能治理这个话题。从实施者的视角出发，研发效能治理通常会变成一堆度量指标和加在自己身上的KPI。然而，实际操作下来，研发效能的治理很难有百试不爽的灵丹妙药，毕竟每个企