雷神山/火神山，怎么就敏捷了
内容列表
背景
所有对于火神山、雷神山的新闻报道，均来自于这篇新闻。一切以官方新闻报道为准。
先抛结论
建议那些认为“雷神山/火神山是敏捷”的敏捷从业者，熟读敏捷软件开发宣言以及伴随的十二项原则并背诵。
这两个项目，怎么就敏捷了？怎么就成了敏捷项目了？现在为了鼓吹敏捷，已经不讲究基本原理了么？各位，请跟我念——敏捷不是筐，啥都往里装啊！
项目情况表述进行时
对这个问题进行讨论之前，我们先对项目进行一下分析，找出这个项目的核心价值与最终受益人，并结合项目交付方式来看最终是否符合敏捷。
核心价值
从新闻的消息分析，我们发现该项目的最终目的是“建设1000张床位的火神山”（雷神山建设之初的容量未知），即项目最终交付应该是若干张床位，供新冠病毒患者使用。
最终受益人
这里的最终受益人必须是直接从该项目中收益最大的人，因此只能定位成新冠病毒患者和相关医生。
项目交付方式
这部分没有找到官方新闻实时报道这件事情，但是从维基百科中关于火神山的页面中可以看到这样子的文字：
2020年2月3日，火神山医院开放床位50张，使用50张。[36] 2月5日，火神山医院开放床位76张，使用76张。[37] 2月7日，火神山医院开放床位86张，使用86张。[38] 2020年2月16日，火神山医院开放床位1014张，使用1014张；雷神山医院开放473张，使用473张。[39]
https://zh.wikipedia.org/wiki/%E7%81%AB%E7%A5%9E%E5%B1%B1%E5%8C%BB%E9%99%A2
项目分析进行时
所以当前的焦点就集中在：这种交付是否属于增量交付
以及是否每次增量都给新冠病毒患者带来了价值？
从我的角度，我认为这是不符合增量的概念的。在进行讨论之前我们先来看一张图：
这张图中表明的是典型的增量交付，那么增量交付的要求是什么？
- 每次交付的内容都可以满足客户一部分的需求。即如果0是完全没有满足，1是完全满足了，每次交付的数值应该是介于(0,1)之间的任意一个数字；
- 这部分需求不能重复，即不能两次交付一样的交付物；
- 每次交付的内容，都不足以代表整个项目。
反观火神山/雷神山医院的交付模式，每次交付的都是病床，那么对于单个客户来说，要么就是没有满足，要么就是满足了，所以只能是0或者1，二选一。
而且如果从交付物的性质来看，每次交付的东西都是一样的，只是规模不同而已，这也不符合我们对增量的定义和要求。
因此火神山/雷神山在交付方面，完全不符合增量的定义，至多是分批次交付，扩大受益人群罢了。如果用一个软件中的类比来说就是，逐步开发新特性供用户使用，从一开始的较少人使用，到逐步扩大受众人群，仅此而已。不同的是，软件仅仅是打开流量限制即可，而对于这种建筑类交付性的项目，还需要对最终病房进行物品添置，比如床、呼吸机之类。而就是这个逐步交付的过程，被人解读成敏捷，这也是一个有趣的现象。
至于工作的齐头并进也好、目标一致也罢，这都是传统项目管理的基本操作，如有不明白的，还请自行查阅PMBOK 中相关章节内容即可，不在本文讨论范围。
另外我也相信医院建好之后，可能会有往病房里增加一些设备的可能性，比如加个呼吸机、血氧仪，这个是肯定存在的。但这种叫增量么？这种叫敏捷么？恐怕不行吧。否则，岂不是我们的行政人员每天都在用敏捷的方式工作？这明显不符合实际情况。
哦，对了，更不要说新闻报道中不断讲的“拼命加班”、“加班加点”这种明显反敏捷的做法，如果有问题，请查看一下敏捷软件开发宣言的十二项原则的第九条即可。这种赤裸裸反敏捷的行为，我就不再过多解释了。
责任人、开发人员和用户要能够共同维持其步调稳定延续。
https://agilemanifesto.org/iso/zhchs/principles.html
鉴于其一次性交付以及最终用户的特点，结合新闻报道，我无法找到有任何“通过用户反馈来改进双山医院设计”的证据，如果有这些证据的各位，欢迎跟我联系。
退一万步来说，即使有迭代，考虑到建筑行业特点，必然是有极强的变更流程要求，这也进一步的推翻了敏捷的可能性。
基本到这里，我们就能确定火神山/雷神山属于敏捷这一块的说法，是站不住脚的。敏捷一般使用在需要探索以及高不确定性的项目中，而双山医院这个项目明显不符合这个特点。
这个项目说白了就是一个“目标非常明确（搭建可以供新冠病毒患者使用的病房）、范围明确（若干张病床）、阶段清楚（所有建筑项目的共同特点，这个是合规性要求）、分步骤交付（病房不是一次性都可用，交付有先后）的传统项目”罢了。
虽然到这里论证是结束了，但是我想就这个问题再稍微深入说两句关于敏捷的认知。
项目阶段 VS 迭代冲刺
这两个概念分不清楚，大概率是导致了双山医院被认为是敏捷的罪魁祸首。
我试着用我的理解来对这两个概念进行一些区分：
- 阶段是通过时序来对项目进行简化，将每个阶段的交付物明确出来。比如设计阶段最终目标就是为了交付设计文档，开发阶段是为了交付可用的代码。阶段性的交付物有很大可能对最终用户是没有价值的；
- 迭代是通过时间盒反逼优先级，从而将时间盒内交付物明确出来。通常来说迭代的交付物对最终用户是可以产生价值的，且这个价值只要客户没有提出反对意见，在后续的迭代开发过程中，将会持续存在；
- 阶段交付物，将会决定下个阶段是否开始，可以认为是门径管理中的“门”，它决定了项目是否可以通过这道门，继续向着目标前进；
- 迭代的交付物不存在门径的概念，而更多的是“用户反馈收集器”，通过用户反馈进行方向性调整，从而确保下个迭代目标可以更符合用户价值。
基于上面的一些对比，可能会发现，对于双山医院这种项目，有且只有可能是分阶段，而不是分迭代开发交付，这是建筑行业合规性的强制要求，否则楼盘开发商怕是做梦都能笑醒。
敏捷不是什么
关于敏捷是什么，我们已经说了太多了，再次不再赘述。但是对于敏捷不是什么，还是有一些可以去掰扯的。
首先，敏捷肯定不只是快。这次双山医院如此快速的交付，难免会刺激到一些人的神经，认为如此快的交付，跟敏捷肯定是挂钩的。殊不知敏捷从头到尾都没有谈过快速交付，仅仅是“持续不断的、尽早交付”，这与所说的快，还是有比较明显的区别的。敏捷寄希望于早交付从而获得反馈的方式，来抵消需求不确定带来的返工，而不是通过快达到交付的目的。敏捷自始至终的关注点都是价值，而不是“任务”或者“工作量”本身。
其次，敏捷不是一次性交付，且该交付必然是从局部走向整体。敏捷不会通过规模扩大来完成增量，而是通过不断交付一个完整产品的不同部分，从而完成功能版图的扩展，最终达到客户价值交付的目的。
最后，为现有系统增加新的功能，不一定是敏捷，也可以是瀑布。系统增加新功能是常态，判断是否敏捷要从交付的目的、方式方法和节奏来进行判断。否则所有系统开发，都可以归入到敏捷，这明显是与事实不符的。
敏捷不是筐，啥都往里装
现在敏捷还是比较火的，尤其是本次疫情中，如何多快好省的开发，又成了很多企业的思考题，因此敏捷又再度成为了一波焦点，毕竟敏捷宣传“价值交付”，还是很符合某些内容没有修练好的企业的诉求。
但我们需要知道，敏捷不是一个筐，什么都往里面放。敏捷有自己的边界，有自己的适用范围，它一定要可以“分步骤、分批次、逐步且有价值”的交付，否则那不是敏捷，而是一个分阶段（phase）的瀑布项目罢了。
不能看到快速交付就认为是敏捷，不能认为分阶段冲刺就是敏捷。敏捷没有那么肤浅（当然在现有培训加持下，敏捷的确有低B格化的趋势），它是一门管理学科，不同的是，它是基于经验，而不是基于数字的管理，通过经验来帮助我们找到最适合的方法，而不是过去通过SOP的方式来管理。因此对敏捷请心存敬畏，用心去学习，而不是张口就来。敏捷说到底，最核心的不过是宣言和原则，而且在过去的近20年的时间内，随着商业模式和工程模式的变化，其中部分内容看起来有点过时，有点不合时宜，但核心还是在，它们依然强调敏捷是理念，是一种管理模型。这是一门science，而不是单纯的经验合集。
写在最后
我个人而言，对敏捷和瀑布的感觉都是一样，并不觉得敏捷比瀑布高一筹，或者瀑布强压敏捷一头。这都是手段，最终目标都是“客户满意”，否则我们做项目到底在做什么呢？
但是！这不能成为有些人有意或者无意去模糊化敏捷和瀑布的区别的原因。我们心中可以做妥协，但是我们应该知道它到底是什么？或者说是什么的混合体，否则在敏捷或者瀑布的道路上，你将会失去方向，甚至会让你自己产生混乱的感觉，项目不该是二元论，敏捷瀑布共存也是常态，但我们需要明确知道有些东西是什么不是这么。否则无论是对项目经理还是项目本身，都是一种伤害。
因为，太伤身体。
