软件项目是这样失败的。

谁也不知道城西银泰豪华的大楼是什么时候出现的。即使像我这样天天上下班都经过那里。

记忆里似乎巨大的塔吊和漫天的扬尘在那里飞舞了大半年，也许是一年有余。几个月前突然某一天经过时，看到了颇具规模的大厦似乎正在慢慢形成。直到最后几天，当最后一个丑陋的脚手架被拆掉，才发现这里竟凭空出现了如此巨大的庞然大物。

不禁感慨人类的才华和创造力。

相比之下软件行业似乎显得很渺小，通常很难向一个行外人介绍一款“伟大的软件”，因为他们很难理解一堆.dll和.exe的伟大之处。在他们眼里，只有一堆看不明白干什么用的奇奇怪怪文件和一个不见得多漂亮的图标，双击进入之后有功能A,B,C,D,E,F,G。

不幸的是，在多数人坚信“项目经理不需要懂技术”的巨大背景下，连项目经理本人也理解不了程序员们那些自称屌炸天的设计架构。

于是有了各种银弹，各种管理方法。其中之一有一个大家都耳熟能详甚至耳朵磨出茧的名字——敏捷。

快速迭代，快速发布可用版本。在看得见的功能一个接一个被“制造”出来，管理者比任何时候都心中有谱。于是他们在此之上又发明了以功能点来计算工作量等等诸如此类的时间管理方法。并对所有人说自己的项目用这管理方法进行的十分顺利。

某天一个管理者理所当然地听说并坚信了敏捷管理的出类拔萃所向披靡。他的团队正要建造一个像银泰城一样伟大的项目。

他理所当然地不想看到一堆开发者貌似很努力的敲打键盘然后产生一个个莫名其妙的带着各自后缀名却无一可以双击点开的文件。这种感觉加上一些基因带给他的莫名的不安全感让他觉得可怕，这些埋头敲键盘的家伙到底在干些甚么？他们拿走了不菲的薪水却很可能在搞一些跟工作压根没关系的东西。项目进度怎么样了？是不是该让他们加加班？是不是他们中有人技术不达标导致整体进度有问题却瞒着我好多领几个月薪水然后走人？这种无力感让他坐立不安。看着这群自称程序员的家伙天天上班下班就像看着工地里漫天的扬尘和出入其中的满载的黄沙车，工地上看上去一直是一片混乱，工队负责人告诉他在打地桩，可是，天知道发生着什么？

这次他决定采用更先进的管理方法，而这一方法已经被无数人证明科学且百分之百成功。敏捷，或是叫别的什么名字，管它呢。快速发布可用版本，快速迭代，基于功能点的计划，棒极了。

于是他把大楼图纸大致看了一遍，决定在第一个月完成第一层的最北边商铺，接下来两个月继续完成剩下的三个方向的。一开始总是会比较慢，因为那群程序员告诉他有许多设计什么的额外工作。计划是再接下来每两个月完成一层楼，这样完成整栋6层大楼需要13个月。加上测试和发布，15个月足矣。何况，第五层和第六层面积要小很多，应该会快不少。

他把所有人召集到一起开了一次长达一天的会，解释敏捷开发的成功案例和他的计划。所有开发人员都同意敏捷是时下最先进的管理模式，其中有两个似乎还看了不少相关的书籍教程觉得计划非常科学，在会议上盛赞了半天经理的英明神武，经理决定下次有机会提拔他们。项目红红火火的开始了。

 

 ----------------->>> 分割线  <<<----------------------

 

在经理强大的个人魅力感召下，敏捷进行的比想象得还要顺利。一开始几个员工自愿加班加点，后来更多的人加入了他们。几乎每天都能看到他们在会议上为新完成的功能欢呼雀跃。不出所料，一开始的工程在20天内就完成了。经理给了项目中每一个人一笔不菲的奖金并在部门会议上表扬了每一个人。开发人员充满干劲，能够拥有如此优秀的团队，简直是上天的恩赐，经理睡得比任何时候都踏实。白天有人向他提到项目架构的风险，也许该给他加点薪水了，明天也有必要向全员强调下保证质量。

项目进度一路高歌猛进，团队里的每一个人都坚信自己所在的团队是首屈一指的，没有别的团队能在如此短的时间里发布如此多的功能。在前6个月他们已经完成了相当于3层大楼的所有商铺，唯一的问题是有比较多的零散BUG，大概是士气高昂之下大家都没有把项目质量的要求太放在眼里，以往的经验来看这些不会成为风险，经理自己也觉得这没什么可担心的。

第一次问题出现在第7个月中旬，有两个开发在例会上告诉大家ORM模块线程不安全。经理对此一头雾水，但似乎所有的开发人员都认为形势很严峻。有人提出在保证进度不拖慢太多的情况下进行一定程度的返工。有时候这在所难免，技术负责人说这就像是给大楼的第一层较小的柱子加一个支撑结构，应该很快就会完成。很快项目回到了正轨，只是更多的人偶尔提出设计架构的缺陷，但我们拥有如此优秀的团队，大家总会有办法做好它。项目进行到中旬，这往往是最考验项目经理能力的时候。经理表现出他在软件项目上的强大经验适时的激励组员，强调这个项目完成后公司能获得的巨大收益，所有人倍受鼓舞。

顺境只持续了两周，在第8个月初，计划中要进行的5个功能点开发有2个停摆，问题还是在ORM上。组里最年轻的程序员提出项目架构有巨大缺陷，需要大规模重构。其他所有人都认为这样做风险巨大，而我们目前面临的问题并没有想象中那么严重。只是需要在更大的层面上返工一下，然后在某些不能工作的地方做点特殊处理。经理这时候隐约感觉到似乎有点不对劲，好在项目进度已经足足提前了两个月，就算有问题也还有的是时间慢慢解决。他在例会上允诺了正在想公司为每一个组员争取利益，大家站在同一阵线上努力前进。例会非常成功，员工们又开始自愿加班。 

此后又有若干次功能开发上的问题，在大家集思广益下都一一得到解决，虽然进度的领先已经几乎不复存在，但大部分功能也已经可以工作了。

真正的问题出现在第11个月中旬，在所有人测试服务器负载时发现并行处理能力不足以支撑整个系统业务需求。开发人员分析后告诉经理这主要还是因为ORM多线程处理有问题，而目前模块间耦合十分严重又导致不可能单独替换掉ORM模块。这就像是大楼的承重结构有问题，不把整个楼拆除根本不可能换掉哪怕其中的一根柱子。而底层的数据结构设计也有很大的缺陷。产品经理开始妥协砍掉上层一些不太重要的功能以期待系统能满足大多数需求，可技术负责人说还是不行。时间仅剩4个月，这时候已经没有人说要从头搭建架构了，因为所有人都知道时间不够。经理也清楚，在没有把握的情况下自己跳进这坑里极有可能被坑死在里面，未来也没可能再在这个公司混下去了。大家开始质疑需求的合理性，推脱责任，和有问题的模块划清界限。越来越多的BUG被证明与架构缺陷有关，不大规模重构就无法修复。项目陷入了一片混乱，所有技术人员每天开会思考风险较小的办法处理，但似乎每个方案都被推翻。知道12月初，一些人开始提出除了大规模重写别无他法。经理为此每天无法入眠，他每天陪员工加班到深夜，恨不得自己也上去写两行代码，如果能帮上忙的话。他开始询问每一个技术细节，希望自己能为大家或多或少提供点意见。但这除了增加了更多的会议之外似乎没有什么效果，甚至有人抱怨他占用太多时间。

噩梦一般的日子又持续了两周，眼看离交付只剩3个月，经理感到前所未有的无力和沮丧。自家小区边又开始建造房子，灰蒙蒙看上去一片混乱，看不出来工地里在干什么。这种工程居然能够成功，果然造房子比造软件容易多了。

 

 ----------------->>> 分割线  <<<----------------------

 

部门领导每周都会询问这一重要项目的情况，以往经理总是会给出超出预期的答案。可最近连续几周项目没有任何进展，经理在周会上根本不敢面对大家。领导还在安慰他说努力努力，大家都在同一战线上。激励下属，作为这个民族管理学的最核心精髓，经理对此再熟悉不过。只是，假如一开始大家没有被热情冲昏头脑，是不是就会发现问题？会不会有人其实一开始就已经发现问题而没有说出来，只因为说出来会大家耻笑太悲观？

看着窗外远处建筑工地一片混乱的情景。也许房子只有这一种造法，前八个月注定尘土漫天，不会有一家商铺靓丽地出现在世界上，只有打桩机的轰鸣和巨大的钢筋混凝土柱子，商铺只在最后6个月以惊人的速度完成。

第二天，经理找来了所有的开发，询问了每一个人的意见后宣布，所有底层设计架构重做。

我们一起回到那一片漫天的尘土中去。

评论

6 楼 zhangping2056 2013-11-11  

不太暂同博主的观点，敏捷管理也强调测试，保证质量，前期也会做系统架构设计。快速迭代一能给投资者看到有价值的东西，二能尽快出成果让开发人员有成就感，增加动力，三能适应变化，防止最后因需求变化而造成的返工，四能保证人力资源的不浪费，让大家在项目的任何阶段都有事情做，五能。。。。好处就不一一列举了，综合看这个项目失败的原因还是因为前期架构设计没做好，应该是架构湿的责任，跟是否敏捷无关。

5 楼 sunlong 2013-11-10  

敏捷发布的产品是要经过严格测试，要保证质量的。

4 楼 xyz20003 2013-11-09  

jadedrip 写道

这是由于不懂技术都管理者总想尽快看到结果。所以构架出现问题，缺少设计过程和基础框架，代码耦合过度，因为要快速迭代开发，耦合的代码总是更容易写，不是么？


和老板说前三个月是打基础，什么成果都看不到，于是老板怕了，不允许，于是项目失败了，如此而已。

1.如果之前没有建立深厚的相互信任基础，尽早拿出成果，会让投资者感到安心。如果你出钱，三个月对方啥都没做出来，你会怎么想？你会希望对方给你一个什么交代？换位思考会让双方更容易理解。
2.重构也应该算一项开发任务，并估算时间。
  重构需要带着某个具体目的操作，比如解决重复代码导致的N多重复bug。比如使用更强的算法和设计模式提升性能。
  不要说：“代码太烂了，我要重构”或者“为了结构更完美，我要重构”。那样的完美主义做法，请自己在开发代码时一并解决。
  如果想把代码质量烂的责任扣给老板（项目经理），请在开发之前预先跟老板提出：“你要两天做完代码，代码肯定会包含不可预知的bug，你能容忍系统带bug上线吗？”如果老板确认可以带bug上线，责任就不在于你。但是如果你没有提醒，那么开发出巨烂代码的责任就是开发者的。
3.和老板说前三个月打基础，这种做法可不是敏捷。正式的敏捷团队，每个月都有交付。而且是可以让老板看到，可以操作的成果。先说自己是敏捷，最后啥都交付不出来，让投资人砍了。严重怀疑这个团队是被“伪”专家忽悠了。

3 楼 jadedrip 2013-11-09  

这是由于不懂技术都管理者总想尽快看到结果。所以构架出现问题，缺少设计过程和基础框架，代码耦合过度，因为要快速迭代开发，耦合的代码总是更容易写，不是么？


和老板说前三个月是打基础，什么成果都看不到，于是老板怕了，不允许，于是项目失败了，如此而已。

2 楼 testtest111 2013-11-09  

既然都知道问题所在了，就解决问题所在，产品到最后测试发现性能问题很普遍的现象，你的业务又没有发生根本的改变，这就失败了？一个服务的并发不够，那就上多个...能静态化的，缓存的，是否都能采用...

1 楼 xyz20003 2013-11-09  

额，是说因为技术储备不够，出现了严重bug，最终导致项目延期么？

这个似乎跟敏捷没关系啊。

而且，具体是什么问题都没有描述清楚：

猜测项目遇到的问题：
1.性能问题。解决方法是优化瓶颈点，没听说过因为性能问题导致推倒重做的，是被某人忽悠了吧？
2.底层存在严重bug，比如线程会串。屏经验猜想：
  (1).如果是底层有bug，修复底层策略，保证接口稳定即可。
  (2).如果是上层误用，只能返工。如果大家写代码完全一致，也可以考虑修改底层策略，适应上层应用。
      这种返工不是业务重写，api和技术层面的，业务逻辑并不改变，还要代码不是写的巨烂无比，工作量是可以预估的。
      不懂为啥没人愿意站出来挑这个事情。

关于性能测试：
  一般都是先支持功能，最后跑一遍性能，有瓶颈的优化一下，想象不出来，代码何等的烂，连逐点优化都做不到，必须推倒重来。

关于敏捷：
  敏捷不能解决技术能力弱的问题，如果你说我用了敏捷，就能让只会写jsp的同学，比会spring的同学代码结构更好，完全是不可能的。
  不过我从别人那里听到，敏捷的好处是快速失败，你看文章中的项目本来应该2个月以后才出问题，因为用了敏捷，提前两个月出了问题，只是最后问题没有解决，可能是技术能力，可能是其他什么问题。唉，唉。