敏捷项目管理探讨
0、前言
自去年10月份到今年年初，一直在忙着开发公司的某个软件项目，平时也基本是996或007的工作状态，彼时根本没时间打理这个公众号，所以断更有好几个月了。
每次黄教授或其他朋友问起来，最近怎么不更新了？我都只好打哈哈，说过段时间，过段时间一定更。这话讲的次数多了之后，估计他们都已经有点不相信了。
最近项目开发阶段性完成，平时下班后或者周末稍微有了点自己的时间，终于可以将以往欠下的文章补上，那就从今天开始，继续我们之前的客观世界探索之旅，改造我们的世界观。
这半年来参与证券公司研发中心的组建与招聘工作，对国企的运作模式有了细致的观察，期间还专门去上海信息化培训中心专门学习了敏捷项目管理的培训，也进行了一系列的实践，所以最近的内容将围绕敏捷开发模式、技术人员招聘、券商信息化系统等一系列话题展开，与诸位探讨。
今天先从敏捷项目管理开始。
说起“敏捷”，很多人首先想到的是Scrum、Sprint、站会、看板、用户故事这些具体的方法和工具。实际上，如果仅仅把敏捷理解成一套项目管理流程，很容易学会形式，却没有真正理解它。
这半年参与项目之后，我越来越感觉到，敏捷真正改变的并不是“项目怎么开会”，而是我们如何认识软件项目、如何认识需求、如何认识人与组织之间的关系。
1、兴起的背景
敏捷的兴起，并不是因为某一天突然有人发明了一种更先进的项目管理方法，而是传统项目管理模式在软件行业发展过程中，逐渐暴露出了越来越明显的问题。
在很多传统项目中，项目往往按照“需求分析—概要设计—详细设计—编码—测试—上线”的顺序推进。
这种方式本身并没有错。
对于需求明确、技术成熟、变化较少的工程项目而言，提前规划、严格按照计划执行，是非常有效的。
问题在于，软件项目具有一个非常特殊的特点：
项目开始的时候，我们往往并不知道自己最终真正需要什么。
客户可能不知道。
业务部门可能不知道。
产品经理可能不知道。
甚至开发人员也不知道。
于是就出现了一个非常有意思的现象：
项目最开始花费大量时间讨论需求，形成了厚厚的需求文档；随后根据需求进行设计、开发和测试。等系统终于做出来以后，用户却发现：
“这不是我想要的东西。”
这并不一定是谁工作不认真，而是因为需求本身就是会变化的。
特别是在互联网、金融信息化、企业管理软件等领域，需求变化更加明显。
市场环境会变化，监管政策会变化，用户的使用习惯会变化，竞争对手会变化，公司管理制度也会变化。
甚至有时候，只有当一个功能真正做出来以后，用户才能第一次真正意识到：
“原来我真正想要的是这个。”
这就意味着，软件项目与传统建筑工程存在一个非常大的区别。
一栋楼在施工前，可以把绝大多数结构设计清楚；但软件系统往往必须在不断使用、不断反馈的过程中，才能逐渐明确最终形态。
因此，软件项目面对的核心问题并不是：
如何把一份确定的计划执行得更加精准？
而是：
如何在不断变化的环境中，以尽可能低的成本逐渐逼近正确答案？
这就是敏捷产生的重要背景。
如果把这个问题再抽象一层，就会发现，传统项目管理更适合解决“确定性问题”，而敏捷更适合解决“高度不确定性问题”。
2、主要内容
敏捷虽然有很多具体的方法论，但如果把Scrum、Kanban以及其他敏捷实践去掉一些表层形式，我认为其中最核心的思想主要包括几个方面。
2.1 小步迭代
传统项目经常追求“一次性把事情做完”。
敏捷则更强调：
先做出一个能够运行的版本，再不断完善。
把一个持续一年甚至两年的项目，拆成若干个较短的周期。
每一个周期都不是停留在讨论、设计和计划阶段，而是尽量产生一个可以验证的成果。
这样做的好处是，项目不会在漫长的开发过程中一直处于“看起来什么都没问题”的状态。
真正的问题，会更早暴露。
2.2 快速反馈
敏捷真正重要的其实不是“快”，而是“反馈”。
如果只是加快编码速度，但是方向错了，那么只会更快地做出错误的东西。
敏捷强调让开发人员、产品人员、业务人员和用户之间形成较短的反馈回路：
提出需求 → 开发 → 交付 → 使用 → 获得反馈 → 调整 → 再开发。
这个过程不断循环。
从某种意义上说，敏捷是在不断缩短这个反馈闭环。
反馈周期越短，错误发现得越早，纠错成本通常也越低。
2.3 持续交付价值
传统项目容易形成一种思维：
“项目完成以后才能体现价值。”
于是项目可能经过半年甚至一年，最终才上线。
敏捷则更加关注：
能不能不断交付真正有价值的东西。
一个功能完成了，就可以验证一个功能。
一个业务流程打通了，就可以验证一个业务流程。
一个核心模块完成了，就可以先投入实际使用。
这样项目本身就不再是一个黑箱。
管理层可以看到进度，业务部门可以看到结果，开发人员也可以尽快发现问题。
2.4 拥抱变化
敏捷并不是鼓励“需求随便改”。
真正的意思是：
当变化发生时，不应该简单地认为变化本身就是一种错误。
项目开始时掌握的信息永远有限。
随着项目推进，我们获取的信息越来越多，因此对原有需求产生修正，本身就是一种正常现象。
真正应该管理的，不是“让需求永远不变”，而是：
让需求变化变得可控。
比如，把重要程度不同的需求区分开来，把需求拆解成更小的任务，对新增需求进行优先级排序。
变化依然存在，但是变化不再意味着项目失控。
2.5 强调人与人的协作
敏捷还有一个非常重要的特点，就是强调团队协作。
传统管理往往容易把人理解成组织结构中的岗位：
产品经理负责需求，开发人员负责编码，测试人员负责测试，项目经理负责推动进度。
而敏捷更强调：
最终交付价值的是一个团队，而不是若干个彼此独立的岗位。
一个需求从产生到最终上线，需要很多角色共同参与。
如果产品、开发、测试、业务彼此之间存在巨大的信息壁垒，那么再完善的流程也很难真正提高效率。
因此，敏捷会特别强调沟通、透明和跨职能协作。
3、本质
如果仅仅停留在上述层面，敏捷仍然只是一套项目管理方法。
但我认为，敏捷真正有价值的地方，在于它背后对应着一套更加底层的认识论。
3.1 敏捷的本质是“在不确定性中不断逼近正确答案”
很多管理者喜欢计划。
因为计划能够带来确定感。
今天做到什么，明天做到什么，下个月完成什么，一切都安排得清清楚楚，看上去项目就被管理起来了。
但软件项目最麻烦的地方就在于：
计划可能本身就是错的。
如果前提错了，那么执行得越好，结果反而可能越糟。
因此，敏捷真正改变的是管理逻辑：
传统模式更加关注：
计划 → 执行 → 检查
而敏捷更强调：
假设 → 实践 → 获取反馈 → 修正假设 → 再实践
这其实和科学研究、工程实践、PDCA循环有非常强的相似性。
先提出一个假设，然后通过实际行动获得信息，再根据新的信息调整原来的认识。
所以从更底层来看，敏捷并不是“快一点做项目”，而是：
让组织具备更强的学习能力。
3.2 敏捷本质上也是一种“降低试错成本”的方法
任何复杂系统都不可能一次性获得正确答案。
既然错误无法完全避免，那么真正重要的事情就是：
尽可能早地发现错误，并尽可能低成本地纠正错误。
假设一个需求在项目第一周发现错误，可能只需要修改一个文档。
如果到了第六个月才发现错误，可能已经涉及数据库、接口、前端、测试、部署以及大量业务流程。
两者本质上是同一个错误，但是纠正成本完全不同。
因此，敏捷并不是消灭错误，而是在建立一个机制：
让错误更早暴露，让反馈更加及时，让修正更加便宜。
3.3 敏捷的核心不是“流程”，而是“反馈回路”
站会不是敏捷。
Sprint不是敏捷。
看板也不是敏捷。
甚至Scrum本身也只是实现敏捷思想的一种方法。
如果每天开站会，却没有真正解决问题；
如果每两周做一次Sprint，却没有真正形成产品迭代；
如果任务卡片管理得非常漂亮，但是用户从来没有参与反馈；
那么这些行为只是“敏捷的形式”，并没有形成真正的敏捷。
真正的敏捷，应该看一个团队的反馈回路是否足够短。
从需求出现，到形成产品，再到用户产生反馈，中间经历多长时间？
从发现问题，到完成修复，中间经历多长时间？
从一个错误被发现，到组织真正理解它的原因，中间经历多长时间？
这些问题，比“有没有每天站会”更加重要。
3.4 敏捷实际上是在管理“不确定性”
项目管理经常被理解成：
管进度、管成本、管质量。
但对于复杂的软件项目而言，更底层的问题其实是：
管理不确定性。
我们不知道用户最终想要什么。
不知道政策什么时候变化。
不知道技术方案是否真的可行。
不知道一个系统上线之后会产生什么新的问题。
敏捷所做的事情，就是通过拆分、迭代、反馈、验证等方式，把一个巨大的不确定性问题拆成许多个较小的不确定性问题。
这和一次性押注一个巨大项目相比，风险结构完全不同。
4、实践总结与发展建议
真正参与敏捷项目之后，我越来越感觉到：
敏捷最大的难点，从来不是技术，而是组织。
技术人员一般很容易理解迭代开发。
真正困难的是，当敏捷的方法进入一个层级复杂、部门众多、责任边界清晰的大型组织之后，原有的管理机制会与敏捷产生各种冲突。
4.1 最大的问题不是“不会敏捷”，而是“组织没有准备好”
很多公司引入敏捷之后，会出现一个非常典型的场景：
项目组开始使用Scrum。
每天开站会。
每两周一个Sprint。
系统里也建立了用户故事和任务。
但项目效率并没有明显提高。
原因很简单。
如果需求部门依然层层审批，采购流程依然需要几个月，测试环境申请依然需要走复杂流程，上线依然需要多个部门逐级签字，那么开发团队再敏捷，也无法改变整个系统的速度。
这实际上说明了一个问题：
敏捷不是一个团队的问题，而是一个组织的问题。
一个团队可以做到快速开发，但如果上下游都非常缓慢，那么整个价值链依然缓慢。
4.2 不要为了敏捷而敏捷
这是实践中非常容易出现的问题。
有些企业学习敏捷之后，会大量引入概念：
用户故事、燃尽图、Sprint、Backlog、站会、迭代评审、回顾会议……
然后大家每天忙着维护各种表格和工具。
最后发现：
原来管理工作比开发工作还多。
这就是典型的本末倒置。
工具的存在应该是为了帮助团队减少沟通成本、降低管理成本，而不是增加新的管理负担。
因此，敏捷实践应该遵循一个原则：
能用简单的方法解决的问题，就不要用复杂的方法。
4.3 敏捷并不意味着不要计划
这是我认为最容易被误解的一点。
有人认为敏捷就是“拥抱变化”，所以不用做长期计划。
实际上，恰恰相反。
敏捷仍然需要计划，只不过它不再假设未来所有事情都可以被准确预测。
我们可以制定方向，可以制定阶段目标，可以制定版本计划，可以估算工作量。
但是同时必须承认：
计划只是当前信息条件下的一种假设。
随着新信息出现，我们需要不断修正计划。
所以真正成熟的项目管理，不应该是：
“计划绝对不能变化。”
而应该是：
“计划可以变化，但变化必须有依据、有优先级、有成本意识。”
4.4 敏捷需要与具体行业结合
不同类型的软件项目，敏捷实践的方式也应该不同。
互联网产品可以快速上线、快速试错，所以迭代周期可以非常短。
金融行业则涉及稳定性、安全性、合规性、审计和风险控制，不可能简单复制互联网公司的敏捷方式。
尤其是在证券公司、银行等金融机构中，一些核心系统具有非常强的稳定性要求。
这意味着：
敏捷并不等于降低控制。
真正合理的方式应该是：
在可以快速试错的地方提高速度；
在必须严格控制的地方保持规范；
把“灵活”和“严谨”放在不同层次解决。
例如需求探索可以敏捷，研发过程可以迭代，但是涉及核心数据、生产系统、权限、安全和合规的环节，依然需要严格控制。
所以未来的敏捷发展，不应该是简单照搬某一种标准模型，而应该更加重视：
敏捷与行业特性的结合。
4.5 管理者需要改变对“计划”和“控制”的理解
传统管理中，一个优秀的管理者往往被认为是：
能够准确制定计划，并且让大家按照计划执行的人。
而在高度不确定的软件项目中，管理者还需要具备另一种能力：
能够快速识别变化，并及时调整资源和方向。
这实际上对管理者提出了更高要求。
因为“制定一个计划”并不难。
真正难的是：
当计划与现实发生冲突的时候，能不能承认原来的计划不合理；
当业务部门提出新需求的时候，能不能判断它的重要程度；
当项目延期的时候，能不能找到真正原因，而不是简单要求团队加班；
当一个方案已经被证明不可行的时候，能不能及时停止继续投入。
从这个角度来看，敏捷管理实际上对管理者的要求，比传统项目管理更高。
5、结语
这半年真正参与敏捷项目之后，我越来越觉得，敏捷并不仅仅是一种软件开发方法。
它更像是一种面对复杂世界的方法。
面对未知，我们先提出假设。
面对变化，我们及时调整。
面对错误，我们尽早暴露。
面对结果，我们不断复盘。
面对复杂问题，我们把它拆成可以不断验证的小问题。
从这个角度来看，敏捷与我们之前讨论过的第一性原理、系统论、信息论、实践论乃至PDCA循环之间，其实都有一些内在联系。
一个复杂系统之所以难以管理，往往不是因为我们没有足够强的执行力，而是因为我们掌握的信息不足、反馈太慢、试错成本太高。
因此，真正优秀的管理系统，并不是试图让未来完全按照计划发生，而是要建立一种机制：
即使未来发生变化，系统依然能够及时感知、快速响应，并不断向正确的方向修正。
这或许才是我理解的“敏捷”二字真正的含义。
而对于中国大量的大型企业、国企以及金融机构来说，未来真正值得讨论的，也许已经不是“要不要实行敏捷”，而是：
怎样把敏捷的思想，与现有的组织结构、管理制度、风险控制和行业特点结合起来。
这可能比学习几个Scrum术语，更值得我们认真研究。