瀑布开发之旅

1970 年，18 岁的Bob在一家名为A.S.C.Tabulating公司做程序员，起初写代码的时候，Bob及其团队度过了一段艰难的日子。当时的工作是划分白班和夜班的，白班时，程序员先用铅笔把代码写在编码表格上，然后用打孔机在卡片上打孔，把仔细检查过的卡片交给计算机操作员，操作员则在夜班时进行编译和测试。但这一番操作下来，通常会花费几天的时间，且之后的每一轮修改都会花费大约一天的时间，团队就在日复一日地编码、编译、测试、修复Bug。这种开发模式在当时尤为普遍，因此生产效率低下的问题亟待解决。

为了缩短开发过程中反馈的时间，瀑布模型应运而生。该模型很好地解决了生产效率问题，并在 70、80 年代间迅速地占据了软件开发的大半江山，Bob及其团队也开始了“瀑布开发”之旅。

但是想象中精细的计划、完美的策略所打造的卓越成果并没有出现，Bob只能重新寻找能真正符合他期许的开发流程。在寻找过程中，35 岁的Bob与搭档Jim Newkirk（吉姆·纽柯克）相继加入新的公司——Clear Communication，与此同时，有家公司写了一个很流行的杀手应用，许多专业人士都买来用，这其中也包括Bob。之后令人感到失望的是，这一应用的版本发布周期变得越来越长，Bug开始积压，加载的时间也越来越长，系统崩溃的概率也越来越大。最终，大多数用户都选择不再使用这个程序。果不其然，不久，该公司就关门大吉了。

故事到这里还没有结束，偶然一天，Bob见到了那家公司的员工，才从这名员工的口中得知整个事情的前因后果：当时公司为了推动产品提早发布，非但没有重视代码质量，还一味地追求速度，导致代码乱七八糟，无法进行修改或管理，最终公司经营惨淡，宣布倒闭。“千里之堤，溃于蚁穴”，从这一事件中，Bob得出一个结论：代码的整洁是需要引起重视的。他认为，软件质量不仅依赖软件架构及项目管理，还与代码质量紧密相关。

意识到代码整洁的重要性之后，Bob心想，如果把瀑布模型与代码整洁结合在一起，那一定很完美。于是，在接下来很长的一段时间里，他同团队一起试图按照“分析—设计—编程”的方式实现产品交付。但这行不通。事实上，即使大家对代码整洁做出了规定，并且每次对需求的分析与设计非常正确，但一旦进入开发阶段，事情就开始变得不可控了，总是会因为突如其来的需求变化而打乱之前的计划，导致产品交付不能如期进行。在一次一次的实践过程中，Bob逐渐发现瀑布开发束缚住了自己的思想。就在他觉得连代码整洁也拯救不了这混乱流程的时候，敏捷开发初见苗头。