只要有软件研发团队，就会有团队带领。在不同的研发流程中，团队带领的职责会略有不同。

瀑布式开发

2001年，我入职德国自动化大厂，参与开发的第一个软件，严格意义上来说都不算产品，而是科研型软件。

团队从三个人开始，高峰时期三十多个人。研发严格按照瀑布式开发流程，前面半年，产品经理先写需求文档，洋洋洒洒几百页纸，之后架构师写设计文档，评审以后再开始写代码研发，历时将近一年，后面再交给系统测试，测试又超过半年。

这样干了两年，研发预算告罄，而我们却依然只有一个客户。那段时间老大经常不见身影，主要精力都在外面找钱找出路，各种选项都搬到台面。最后集团将整个研发团队整合到产品研发部门，目标是对外销售。

产品发布之后，老大又成了销售和产品经理，外面的客户有啥需求，就通知我们改。可是按照瀑布式研发流程，下一个版本需要一年以后发布。时常客户等不及，只能自己找解决方案，因此而流失的潜在客户不少。

后来老大干脆废除了瀑布式研发，客户要什么就先做，先交付。文档，测试后面再补，只是为了满足公司的产品研发流程。这样客户是留住了，我们内部产品版本管理混乱不堪，兼容性和质量都无法保证，研发苦不堪言。

我的第一任项目经理，更像一个初创公司老板。

迭代开发

后来离开了项目组，进入正规产品研发部门，开发公司新一代工控旗舰产品，算是真正进入了正规军。

项目按照迭代式流程开发，一个迭代两个月。产品经理定下每个迭代的目标，团队按照迭代计划顺序开发。比起第一个项目的做到哪里算哪里，迭代开发对开发进程的管理已经进了一大步。

迭代式开发

和严格的瀑布式研发流程相比，迭代式开发其实是将瀑布重叠迭代了。做一个非常简化的研发流程描述：第一个迭代产品经理写需求A，第二个迭代架构师做设计A，产品经理同时写下一个迭代的需求B，第三个迭代，研发开发需求A，架构师设计需求B，产品经理开始写需求C。

这种流水线式的开发流程，大大缩短了研发时间，从2005年左右开始慢慢流行成为软件研发的主流模式。

但是迭代开发还是有短板，就是每个迭代不能形成闭环。拿上面的简化流程做例子，需求A到了系统测试，已经流转了四到五个迭代了，如果一个迭代算两个月，从需求到验收，中间已经隔了十个月了，"反射弧"依然太长。在验收时，如果发现的只是实现的缺陷还好，碰到修改缺陷需要动架构或者是改需求的情况，还是一地鸡毛，鸡飞狗跳。

系统测试也是一样，前面半年基本上空闲，后面开始集成，测试任务加重，到了最后天天加班，还被骂测试不及时。

当时的研发团队，团队有项目经理，之下根据业务分工，设子项目经理。我在这个团队的角色是架构师兼子项目经理。中间项目经理断档还兼了半年的项目经理，时值金融危机，最大的痛苦是和HR一起处理了裁员。

在这个项目我历经两任项目经理，对我成长帮助颇大。

第一位项目经理是技术型的，不仅仅负责研发进度和人员，还负责整体架构。项目经理在产品研发岗多年，极为务实，对设计和开发要求都非常严格。我第一次的设计文档被他摔在桌子上，说里面空话废话连篇，有用的信息不多，看起来洋洋洒洒，对研发团队毫无用处。

在他手下工作三年，他耳提面命地带了我三年，我自我感觉迅速成长为一名实干的架构师。他的名言，做产品，要先能跑，然后是跑得稳，最后是跑得快（Make it work，make it stable，make it fast），今天还受益无穷。

第二任项目经理是管理型的，懂技术，但技术基本全部扔给我，他主要处理团队的人员，组织结构和外部关系。和第二任产品经理共事是我职业生涯里面几段舒适的时光之一，他把团队分工得井井有条，各安其职，各行其事。印象中几乎没有加什么班，但是任务从来没有超时和掉链子。

第二任项目经理的强大在于举重若轻，用德国人的冷静和不动声色处理工作问题。他的名言：团队有问题是常态，但是问题不解决，就会演变成危机。他的主要任务就是危机管理，简单地说，就是避免让团队大大小小，技术非技术的问题发展为危机。

敏捷开发

好时光总是不长，因为项目优秀，第二任项目经理被调到更重要的工作岗位，而我也从嵌入式研发被调到软件研发。

这是当时公司最大的工业软件项目，全球同步研发几千人，我们自己团队都有几百人，好几个项目经理，每个项目经理负责上百人的团队，再按业务分子项目，每个子项目经理再管二三十个人。

开始的产品研发也是迭代式，迭代式的短板在这种大型项目里面被显示得淋漓尽致。一个产品，分若干团队，每个团队再分若干项目，每个项目再分若干子项目，每个子项目在其他公司可能就已经是整个研发团队的规模了。和研发并列的，还有几百人的系统测试。

在这种规模下，让所有团队几千人全球同步开发的挑战之大可想而知。而产品研发总指挥就成了高危职业，每每因为产品发布时间延后不可控而黯然离职。在换到第四任产品总指挥的时候，管理层痛下决心，不惜一切代价改开发流程为敏捷开发。

敏捷开发要回溯到2001年，在犹他州瓦萨奇山的雪鸟（Snowbird）滑雪胜地洛奇酒店，17位软件开发领域的领军人物聚在一起聊天、滑雪、放松、并试图找到最佳软件开发流程的共同点。

参与者都对当前软件开发的臃肿深有体会，觉得“轻量”这个术语非常适用。经过为期三天的讨论，他们在价值观和原则层面上达成共识，选择了 Agile（敏捷）一词并为其赋予了特殊的意义，制定并发布了软件行业历史上最为重要的文件之一：敏捷宣言。

敏捷宣言的详细内容和解释，大家可以在网上找到，这里再展开就收不住了。核心思想，是贴近客户，及时反馈，尽早发布和频繁地非文本沟通。

按照敏捷开发思路设计的软件开发流程不少，其中最流行的就是Scrum。

Scrum和迭代的最大区别，在于它让每个迭代（Scrum叫Sprint，冲刺）都闭环：在每一个迭代里面，研发完成需求，设计，实现和测试。所以理论上，每个Sprint的可以发布产品，功能在每个Sprint的积累下慢慢叠加。这也是CI/CD（持续集成/持续部署）的底层逻辑。

迭代式开发

Scrum不仅仅是一个研发流程，它也是一个软件产品研发团队能力的试金石。要在一个Sprint里面完成闭环，你需要让产品经理和研发沟通顺畅，需要有成熟的需求变更管理，需要架构师有能力让整体架构在保持稳定的基础下足够灵活，需要实践测试左移，把原来系统测试的工作转移到研发团队内部，还需要有高度自动化的测试系统，让测试验证自动高效。

Scrum倒逼研发团队提升武功内力，研发团队如果功力不够，Scrum也只是yet another process，换汤不换药，不会对改善你的研发现状有太多帮助。

当整个研发部开始敏捷转型的时候，我因为是首席架构师没有深入参与重组，从相对中立的视角看到了大型研发团队转型的痛苦。所有的研发部主管，项目经理，子项目经理全部站起来重新竞争新的职位。其间有人离职，有人主动提前退休，有优秀的研发工程师去做Scrum Master，有子项目经理竞争产品架构师，还有同事在重组的时候忽然发现自己无处可去。而在这么巨大晃动的同时，研发任务依然不变，产品还要按时发布。

还是回到团队带领。在Scrum架构里面是没有项目经理这个角色的。最接近的角色，是产品负责人，英文Product Owner，简称PO。

Scrum团队由三个主要角色构成：产品负责人PO、Scrum Master和开发团队。其中，PO负责定义"做什么"，Scrum Master负责"如何做"，而开发团队则专注于"做"本身  。

具体地说，PO给团队提需求，把需求拆解成一个个用户故事（User Story），然后把用户故事排好优先级放在待办列表（Backlog）里面，研发团队按照优先级实现用户故事，PO再验收。

在原始Scrum里面，PO是不能指定团队谁来实现哪个用户故事的，这是研发团队自己内部讨论决定的。Scrum Master也不是原来意义上的项目经理，更像一个裁判或者教练，在外面观察指导开发团队用正确的方法开发和优化。

团队改组到了Scrum时代后，我虽然不在特定研发团队，但是因为几个重要的产品功能，和几个团队深度合作过。打交道最多的，当然就是PO。但是很奇怪，我对那些PO没有太多的印象了，PO的工作似乎只剩下将产品经理的需求拆解成用户故事和排优先级，原来对项目经理的个人魅力和领导能力的要求所剩无几。

产品研发转型成敏捷后，解决了一些问题，同时又带来原来没有的新问题。这样又过了四年，我离开了工作二十多年的公司，在疫情期间做了逆行者，回国工作了。

后敏捷时代

业界有一个误解，敏捷开发就是Scrum。其实敏捷是一个理念，而Scrum只是实践这个理念的具体方法之一。敏捷并不等同于Scrum。

Scrum中的闭环迭代，客户反馈，小批量快速交付的原则的确是让软件研发提升了一个台阶。但是，实践Scrum四年以后，一些短板也逐渐显现。

有些短板源于教条主义，比如一定要物理看板，或者是没完没了的各种例会；有些源于对敏捷底层逻辑的误解，比如完全放弃设计文档。而在所有短板之中，最困扰我的，就是PO和Scrum Master这两个角色的设定。

这两个角色设定的迷惑，不在于他们的工作内容，而在于责任分担。在任何一个研发团队里面，我们都已经习惯了有一个第一责任人，对团队交付的功能，质量和时间负责。但是在Scrum的设定里面，PO只负责提用户故事，Scrum Master只是一个裁判或者教练，都不是第一责任人。

那么在Scrum里面，到底谁对交付负责呢？答案是Team（研发团队），也就是说，不是一个人，而是整个团队对交付负责。

设计Scrum的大牛，他实践的团队，大概都是武功高强，喜爱编程的武痴级高手。而事实上一个团队里面的成员能力，背景和意愿都参差不齐。所以，当交付不再由产品经理负责，而是由整个团队负责以后，可能每天上演的，不是漫威“复仇者联盟”的剧本，而是中国“三个和尚”的故事。交付的时间节点，功能和质量不仅无法保证，而且连发力点都没有。

所以到了国内，我们组建团队的时候，没有完全按照敏捷的书本教条，开启了后敏捷时代的实践。

在研发流程中，我们保留了Scrum的Sprint，保留了User Story，保留了测试左移和闭环，保留了CI/CD，保留了产品经理每个迭代的需求和验收。增加了设计文档的重要性，增加了中间里程碑节点Feature Cycle（4个Sprint)，增加了测试经理对每个团队测试覆盖率的检查。

最重要的，是取消了Scrum Master，将PO的工作重新赋予了原来项目经理的责任，管用户故事，管任务分配，管开发进度，重新成为团队第一责任人。