敏捷开发就是一场多人运动
说到敏捷软件开发，很多人对各种名词如数家珍，从自组织团队到回顾会，从渗透式沟通到每天15分钟，从“个体与互动高于流程和工具”到“给客户演示已完成的功能”。但，有没有人想过，敏捷开发本身，其实是一种多人运动？
没错，多人运动。但不要误会，这种多人运费并非要大家去挑战极限，而是需要大家通力合作，这点请一定要记住。
敏捷与瀑布最大的不同在于，瀑布中，研发人员不是人，而是没有感情的编码机器，所有研发人员的工作，都在WBS（工作分解结构）中已经明确定义，并且下一步还被拆成了动作（即一个人可以独立完成的工作），并且根据对动作的估算、排序后，得到一个项目进度网络图。对研发人员而言，他们只需要成为这个链条上的一个节点，做好这个节点应该做的事情就行。
这里可以看出来瀑布的做法是“用局部拼成全貌”，即认为只要局部做好了，根据原先的计划做下去，就能得到我们想要的全貌。而且这里还有一个很重要的观念，就是监控（monitoring and controlling），这是我们下面需要好好讨论的。
瀑布中的监控，一般是监控所谓的基线，即当极限发生改变的时候，我们就需要开始走变更管理流程。
那这里到底说明了什么？这里表明的是一种线性关系，即因为“基线变了”，导致我们需要“走需求变更流程”。如果再深入下去，你会发现各种线性关系无处不在，常见的有这么几种：
因为A延期了，导致B延期了，最终整体延期
因为需求增加了，所以时间成本需要增加
因为某人离职了，所以我们要从其他组招人
如果要继续找，我能找出更多出来。我相信这些也是大家往常都听到过类似的话语，并且不少人也会同意。
但这真的对么？
局部看其实都是对的，因为A延期了，而B依赖于，所以B延期也是正常的。其他的也是同理。但这并不能在更大语境中（比如整个项目中）得出相同的结论。
A延期了，那么我们是否有办法可以削峰填谷、资源调配或者其他方式，来帮助我们加速B的完成，从而确保B按照原定计划完成？
需求增加了，我们有没有办法砍掉一些不那么重要的需求，确保需求总量的不变（这里只考虑产品研发，不过多考虑项目研发，项目的做法不太一样，因为项目的变更是可以伴随更多的成本投入的）
某人离职了，这部分工作能否不做？能不能有更简化的方案？能不能用开源方案？能不能直接外采？
这说明了什么？为什么我们说的好像也很有道理？
这说明了将各个局部加在一起，不能认为等同于整体。之所以有“多个局部相加就是整体”的错觉，是因为瀑布模式，在一定程度上降低了人的作用，将研发人员工作安排的明明白白后，虽然减少了不确定性，但也让研发失去了主动推动的激情，那么当遇到问题的时候，自然而然就会根据“原先设定好的方案”往下走就行了。啊，你说走不通？哦，那不管我的事情，那是你的计划没有做好。我们就是写代码的，根据你安排好的做就行了。
通过绝对的计划，对项目永远只能做到管中窥豹。影响项目交付的点太多，想要通过计划完全控制，怕是不现实。这也是上面的情况出现的根本原因。
张三跟李四打配合，昨天他们吵架了，今天他们是否可以根据计划工作？
研发做好了，测试的用例写完了，我们是否就可以根据计划进行测试？
代码测试完成了，集成测试完成了，是否就就意味着马上就可以上线了？
如果你的回答都是“可以”，那么这就太理想了。吵架了还能好好配合，这种可能存在，但你将这种小概率事件放到项目中，本身对于风险管控是不足的；测试如果昨天晚上吃小龙虾拉肚子了，今天去医院输液了，你是不是准备将笔记本给测试送到输液室？你们公司外面在施工，不小心光纤挖断了，你们公司所在园区网络直接断了，你准备怎么上线？打开4G热点上传么？
有人会说——你这个太极端了。是，我承认太极端，但是你是否敢说这个绝对不会出现？大概率是你不敢。而实际情况将会比这种想象的复杂的多，这也是更加不可控的原因。我就没有必要再加上诸如商业环境变化、人员变化、心情变化、丢数据、跟老婆吵架这种极有可能发生的、非小概率事件了。
因此，我们基本得出了“过分计划”的不可靠性。毕竟，项目环境中，很难可能是一个线性的，这就让过分详细的计划（包含了监控）的可信度大打折扣。抛开计划的成本，就是变更的成本都能让你哭。
既然过分计划不可信，那么我们该怎么办？
《敏捷软件开发宣言》早就给出了答案，那就是：
个体与互动 高于 流程和工具
敏捷软件开发宣言
而且从其手稿来看，这条在宣言中的位置都没有改动过，而其他三条是改动过的。这就给我们释放出了一个信号——这条很重要，非常重要。
与瀑布相对，敏捷一直提倡“价值交付”，即我们需要交付给客户的是价值，而不是过程。所以一开始，我们就可以聚焦最终的重点，让团队进行了聚焦。
而后，敏捷并没有规定所谓的标准流程（SOP，Standard of Process），而是用了“自组织团队（Self-Organized Team）”将过程完全托付给了研发团队，通过一线的员工，在边界内（敏捷的边界是价值）适当使用自己的权力，而不对其作出过份的约束。
这种做法的好处是很好的规避了一些所谓管理者（姑且认为Project Manager是管理者，虽然根本不是）无法解决，或者说无法通过一己之力解决的问题。比如上面我们举得三个例子中，项目经理到底是要做多少的计划，才能预见到有人会食物中毒，并且还得找出对应的应对方案！
那么我们该怎么做？如上所述，将这个职责，连同对应的权力，全部交给团队，即自组织团队中，团队决定怎么做（How）。这就让团队有动力遇到问题的时候，主动去处理而不会遭受太多的约束。这不仅可以让团队更有动力，也让团队在一定范围内可以发挥更大的创造力来解决问题，甚至有些方案都是我们想不到的。
拿我最喜欢做的“意面棉花糖”游戏，如果你限制了团队只能用现有资源，我见过最高的记录是1.2m，但一旦我将约束去掉，让团队可以找他们能找到的任意资源的时候，这个成绩最高直接跳到了3m之上。这恐怕可以说明一些问题。
而如果我们再深入到具体的技术细节、沟通细节，PM 就更加鞭长莫及了。甚至已经是不可能再给出任何具体的建议了。而团队由于身处其中，所以他们才是最有动力解决问题的人。一旦这种权力授予后，团队的沟通交流、互动将会大大增加，且各种方案层出不穷，甚至我还见过团队成员从其他团队找来外援帮助我们的情况。这些都让我对“个体与互动”对团队的解绑以及赋能过程，赞叹不已。
除此之外，再回到项目中各种不确定因素以及这些因素之间的相互影响来看，团队互动一旦产生，这些因素带来的不确定性其实也就不值一提了。在人与团队这种究极复杂体面前，所有其他复杂因素，都是小儿科。我们做的，不过是使用了更复杂的系统（人和团队）来对抗复杂（项目环境），从而获得在项目管理中的成功。
敏捷中最强大的武器，毫无疑问就是“个体与互动”，这个做法让研发团队可以更好发挥其潜力，进而利用这些潜力来对抗项目中的不可控因素，从而让我们对项目的结果更有信心。
并且敏捷也将软件开发工作返璞归真，让真正的建造者（研发人员）参与进来，并且鼓励创造者之间多多交流，通过自组织团队实现成员间的多人运动（嗯，沟通也是一种运动），从而发挥团队潜能并交付更多的价值。
迈开你的腿，张开你的嘴，把这项多人运动坚持到底。