众所周知，ThoughtWorks是一家身体力行地倡导敏捷的公司，在这里敏捷已然成为一件政治正确的事，所有人都将它奉为圭臬。有时候真的很羡慕那些刚毕业就加入ThoughtWorks的年轻人，他们能有机会在这样一个快速发展瞬息万变的行业里，接触到这样一整套可以改变软件行业的理论实践。作为一个在软件行业摸爬滚打了十多年依旧头发浓密的中年程序员，分享一个我当年做过的瀑布流项目，希望作为一个反面教材，能够对大家理解敏捷有些许助益。
我毕业后接触到的第一个项目是一个物流行业的项目，当时依托于沿海某省发达的国际海运物流行业，公司决意投入人力物力打造一个国内先进的海运物流平台。这个平台的蓝图即使在现在看起来也不可谓不宏伟：将国际海运物流相关的集装箱场站，集装箱车队，报关行，货代，船运公司，检验检疫，海关等相关的单位和政府监管部门全部接入进来，使得原本通过线下的纸质单据传递的业务流程得以线上处理。
于是我便以软件开发工程师的身份加入了这个团队，开始了我为期两年的文档工程师的生活。还记得当时我们的总工跟我们说过的一段话：业务需求都没搞清楚就着急做设计，着急写代码？业务需求如果理解得不对，设计和开发做得越多，错的越多。
当时我们每隔2-3个月便会去拜访一次客户，与客户的一线业务操作人员一起检查我们前面一段时间所编写的某个模块的用户需求文档，然后跟他们收集另一个业务模块的业务需求。如此往复，周而复始，直到差不多一年半之后，我们才开始着手编写系统代码。直到有一天，我们给客户打电话说，好了，我们的系统做好了，这周末过去做部署。还记得每次去跟他们的业务人员收集需求时，被问得最多的一个问题就是，你们这个系统什么时候能做好。而每一次我们都只能尴尬的笑笑，说快了快了。但其实当时我们的心里根本没有底，谁也不知道这个系统什么时候能做好。
现在回想起来，这个项目真的是一个标准的瀑布模型，因为它完美的遵循了瀑布模型定义的全部流程和环节，它也是敏捷流程的一个完美的反面教材，因为它完美的犯了敏捷原则中能犯到的所有错误。
开发团队与客户团队完全割裂。客户在这个项目的开发过程中唯一的参与方式，就是每隔2-3个月跟我们一起审阅一份厚厚的需求分析说明书。这也使得客户形成一种甩手掌柜的心态，仿佛将这个软件系统做好完全是开发团队的事情。
过分强调文档的价值。客户在系统最终部署上线之前，从来没有机会看到他们投入大笔资金研发的系统，哪怕只是个最简单的登录界面。当时的系统文档在我们眼中就仿佛一份契约，一旦客户认可签字，就照单开发，全然不顾之后可能会发生的任何变化。
反馈环缺失或反馈环过长。2-3个月一次的沟通频率实在是太长了，以至于我们经常需要花大量的时候一起重温一下上一次我们聊了什么，聊到了哪儿。更有甚者，当我们再去的时候，才发现前面一个跟我们沟通过需求的业务人员甚至都已经离职一个多月了。
当然这一切的发生都有它的历史局限性，我相信如果现在接手这样一个复杂度的系统，我们完全可以用敏捷的方式，用更少的时间让它能够更好的工作。没办法，那就是一个瀑布模型大行其道的时代，瀑布模型便是那时候我们的圭臬。而现在我们将敏捷奉为圭臬，可是会不会当十年之后再回过头来看我们现在的某些敏捷实践的时候，也会发出我现在看十年前这个项目同样的感慨呢。
我们学习敏捷，除了学会各种敏捷实践，知道怎么做，还应该学习敏捷的价值观，理解为什么要这么做。因为敏捷是一种价值观，而不是一套方法论。敏捷从来都没有什么最佳实践，敏捷也从来都不仅仅是一套实践。只有充分的理解了敏捷，我们才能在我们的工作中根据项目的实际情况随心所欲的裁剪和组合一些现有的敏捷实践，甚至是创造出符合项目实际情况的新的敏捷实践，而不会违反敏捷的原则。
最后引用某位老师教给我的一句话与大家共勉：勿以器御心。
