研发管理

软件项目，是当前软件开发中最常见的资金投入和组织方式之一。它通常根据商业论证中预估的收益获得资金支持，并以临时团队的形式组织工作。这些团队往往只负责开发，项目结束后便随之解散。 与之不同，产品模式采用长期稳定的产品型团队。这类团队负责从构思、开发到运行的完整过程，并持续围绕某一业务问题或业务能力开展…

在软件开发项目中，人们经常会争论一个问题：时间究竟应该花在提升软件质量和代码质量上，还是应该用来发布更多有价值的功能？现实中，交付功能的压力往往占据上风。于是，许多开发者会抱怨：他们根本没有时间关注架构、内部质量和代码质量。 有一条著名的“贝特里奇标题定律”说：任何以问号结尾的标题，通常都可以用“否…

功能开关（Feature Toggle，也常称为 Feature Flag，功能标志）是一项非常实用的技术。它允许团队在不修改代码的情况下改变系统行为。功能开关常用于持续交付、基于主干的开发、灰度发布、金丝雀发布、A/B 测试和权限控制等场景。由于不同场景下的功能开关有不同的生命周期、动态性和管理方…

持续集成（Continuous Integration，简称 CI）是一种软件开发实践：团队成员频繁地将代码变更集成到共享主线，并通过自动化构建和测试尽早发现问题。它的核心价值在于缩短反馈周期、降低交付延期风险、减少集成过程中的浪费，并帮助团队长期维护健康的代码库。 本文将从实际开发流程出发，介绍持…

这篇文章最初由某海外大型科技公司的一位前敏捷教练发起。 多年来，我们一直在探索如何开展“大规模回顾”，也可以理解为大型项目复盘或跨团队项目回顾。所谓大规模回顾，是指如何从涉及数十个团队的大型、复杂、跨地域项目中收集经验教训，并将这些经验有效传播到组织内部。 过去，我们采用的是传统方式：把所有相关人员…

在某海外大型科技公司，变化是一种常态。敏捷教练的核心使命，是帮助团队和领导者在组织持续发展中保持高效、健康和持续成长。 敏捷原则早已融入这类公司的组织基因。因此，组织真正需要的并不是行业中常见的“转型教练”，而是一群能够随着组织需求变化而持续进化的敏捷教练。 在早期阶段，第一批敏捷教练主要服务于跨职…

这是我们关于某海外大型音频平台公司如何进行组件集群管理、以及如何大规模管理软件系统的系列文章第三部分。你也可以继续阅读本系列的第一部分和第二部分。 在本系列第三篇文章中，我们将介绍一种被称为“全代码库重构”的实践：也就是在数千个 Git 仓库中批量修改和重构代码。我们会分享，为了让这类大规模代码重构…

一位朋友在过去六个月里一直负责支持一个约 60 人的工程组织。毫不意外，组织里的大多数团队都觉得自己严重缺人。于是问题来了：招聘名额应该平均分配给所有缺人的团队，还是集中投入到一两个团队，直到它们的人员需求得到充分满足？ 这是一个很好的问题，因为它抓住了工程团队管理中最具挑战性的部分之一：如何在有限…

衡量开发者生产力，一直是一项复杂而艰巨的工作。传统指标通常聚焦于开发周期、交付速度和吞吐量，但这些指标存在明显局限，也很难单独回答“开发者生产力究竟如何”这一问题。 相比之下，定性指标提供了一种更有价值的路径：通过来自开发者自身的数据，理解他们的工作状态、协作体验、交付阻碍和真实感受。对企业而言，在…

开发者效能不是简单统计代码行数、功能数量或个人产出，而是看组织能否为开发者提供低摩擦、高反馈、可持续交付的工程环境。很多企业在技术转型中引入了微服务、DevOps、CI/CD、自动化测试和平台工程等新能力，但生产力并没有同步提升，原因往往在于工具和流程增加了复杂度，也放大了开发者的认知负担。 本文将…