软件开发周期和IT核心竞争力的个人见解

近日在调研/设计/开发软件时想到一个有关于软件开发方面的问题，也可以说是两种软件开发的方法。阐述如下。
抛开软件的开发过程及那些瀑布开发模式，原型开发模式，xp开发模式等等不谈。软件开发需要面对一个实际的问题就是，无论哪种开发模式，都有一个开发周期，一个客户要求的交货，验货deadline截止日期。
我个人认为，根据截止日期的不同，实际上决定了软件的粗糙程度，当开发周期相对较短时，自然而然会选择原型开发或者xp开发模式，这些开发模式当然不是软件质量的核心问题，而一些黑盒测试实际上是无法对软件真正的高可复用性，可伸缩性打保票的。笔者认为，软件质量及可复用性归根到底实际上是架构师和开发人员的经验和功力所在。否则很多开发人员把自己的产品叫做baby呢。可参见笔者的另一篇文章，软件究竟是开发出来的，还是测试出来的问题。
一个软件，我们可以根据需求，用最简单，最直接，最原始的方式去实现它，实现起来相对容易，对开发人员要求也不高，项目进度也会很快，但是软件质量首先得不到保证，软件肯定也很粗糙，耦合性较强等等弱点，在今后的进一步应用和开发中肯定会凸显出来，如果有持续需求不断加入，那么这种软件的后续维护，开发工作将是非常困难和艰巨的。这种软件的最终结果往往是一期项目结束，二期新需求到来后，一期的架构已经完全不能适应新的需求，唯一的办法就是推倒重来，这等于是做了两个项目，如果两个项目能够互不影响，分别计价，那也仅仅是对企业和个人当前利益的保证。
事实上淘宝网的架构及开发就是按照这种模式来的，如果说淘宝处于业界前沿阵地，尚没有前人的经验可借鉴，而走了不少弯路，那么如果在已有前人涉险之后，我们就不应该再犯类似的错误了。
而另一种开发方式，在拿到需求后，架构师对潜在的需求及风险等做出足够的评估和预测，同时在高可复用性，可伸缩性方面做到充分的考虑和测试，虽然说仅仅这一步就已经使项目周期会大大增长，但这一步为今后项目的平稳过渡和易维护做到了充足的保证。将一个软件的耦合性尽量做到最低，粒度适中这个地步，即使一期项目会适当延期，但是当二期或者新的后续需求到来时，应用当前已知的这个框架仍然能够很好的适应新的系统，我们只需要在原有系统上适当调整改进即可，这样最终的结果，肯定比第一种工作方式不仅省去很多劳动力和时间，也使很多技术难点大大降低。最直接的场景就是，我们不需要搞封闭式开发和疯狂加班！这一直是我最为诟病的国内开发方法。
毫无疑问，第一种开发方式最好的结果，也是二期项目推倒重来，然后做到一个尽量的可伸缩性的，和第二种开发方式比较接近的新的构架和模式来完成任务，由于时间，人力，资源等诸多方面因素的限制，很难做到第二种开发方式描述的软件产品的程度。那么等于一个任务迭代了2次，第一次完全是一个半成品，敷衍客户而已，第二次的产品则勉强及格。或者换句话说，架构师，项目经理的眼光没有那么长远，还达不到一个任务一次就漂亮的完成的境界；而第二种开发方式，显然从一开始就以精品购物指南的心态去完成一个任务，各方各面都经过了仔细的推敲和测试，完成任务时自然是一个精品，软件的高可复用性，可伸缩性自然保证了项目可以不断持续延伸，同时毫无疑问彰显了架构师和项目经理深厚的行业背景经验和多年从业能力。
而国内软件行业的现状是什么呢？我想不用细说也可知。从这里可以看出国内软件人的浮躁心态和从业人员水平相对低下的现状，不仅是企业本身，项目管理者也根本没有耐心去真正踏踏实实去做一个项目，仅仅是项目需求到来之后，不加思考的用一个仅仅是当前适用的模式去完成它，而对于项目的后续发展，完全置若罔闻，这恐怕是国内架构师和项目经理最常见的思路。
可以看出，我们当前大部分的软件水平还仅仅停留在增删查改(CRUD)的水平上，而真正IT技术发达的国家已经意识到了如何更进一步的加速软件行业发展，那才是软件行业的核心竞争力，所以他们放心的把CRUD外包给我们，而我们自己的惰性也一再彰显，仅仅停留在CRUD的程度就已经满足知足，要知道这是远远不够的，只有在软硬件行业中掌握尖端，最前沿的核心技术，才可以步入信息化强国的行列，千万别以为会几个简单的增删查改就掌握了技术的全部，如果这样，软件外包的麻痹作用就达到了，美帝，日本等软件强国此时则在一旁偷笑。因此，请同行们戒骄戒躁，利用当前的外包契机，努力快速提高自身科技水平，大力钻研和创新出核心技术才是发展软件行业的上策。如何稳步提升我们的软件产品水平，是一个任重而道远的话题，但是相信从我做起，这一天的到来必然会越来越快。
最后，建议大家去读一下李开复的《世界因你不同》，在此书里我们沿着开复的职场轨迹，明显可以看到硅谷外企在核心IT技术，最前沿技术研发上的大力投入和持之以恒的耐心，因为只有这样，才能保证企业乃至国家的科技的核心竞争力。再回头想想，国内的大小软件作坊们，整天只是在自己涉足的行业/领域内摸爬滚打，搞搞简单的CURD，和国外信息技术列强有天壤之别的差距，可是还自认为掌握了IT核心竞争力，沾沾自喜，甚至立功筑碑。

楼主你是写程序的还是算卦的。不仅知道会不会有后继项目，而且还知道后期项目的需求，还能做出先知先觉的架构设计。

概括得有水平，不得不赞 

事实上我做了这么些年项目，国内很少项目的需求是没有变化的，而且大部分项目都是一期，二期，三期，甚至四期，五期的做。难道贵同仁所做的项目全是只按照客户一开始提出的初始的，基本的一些需求来做，之后再也不会有后续跟进的需求么？我觉得能做这样的项目真是太幸福了哈。
另外，可以说我这篇文章针对的是国内普遍存在的项目状态。

一句话，核心竞争力就是人。如何招人，招什么人，如何用人，如何评估人的价值，如何留住人。
关键在于如何评估人的价值。这点做好了，其他就有了。

楼上的理解和我不一样，看了《世界因你不同》之后，可以明显发现，高精尖技术，例如语音识别，人工智能，cpu芯片技术等等，全都被美帝等科技强国把持着，而且国家立法规定有专利保护等等，不准泄密。
而我们所谓的计算机技术，99%都是所谓的CRUD，甚至神州数码这种国人值得骄傲的上市公司，也仅仅是千篇一律的什么税务的，金融的，物流的CRUD，这就是国家推崇的企业信息化。根本没有掌握科技世界核心的高精尖技术。
当然，应该认识到，要想有朝一日掌握和发展自己的核心技术，先做好基本的CRUD是必须的。

楼主你面临的问题，是所有开发人员面临的共同问题，而且答案也已经很明确了，一切尽在 Extreme Programming.
Kent Beck 写了一本书《解析极限编程-拥抱变化》，我就不再转述了。

我之前也是xp迭代开发的忠实拥趸，毕竟Kent是大师嘛，但是经过几次实践后，一个非常严重的问题是，任何开发任务或者项目，如果是同一组人，连续迭代开发3次以上，他们的开发激情，热情将全部丧失殆尽，几乎没有人愿意再进行第4，第5次迭代，可以说，做这个项目已经做皮了，如果继续进行迭代开发，工作效率将一落千丈，同时软件质量并不能保证，这是我的切身体会，尤其是在用hibernate处理关联表之间的CRUD。而如果多次迭代不是同一组人进行，那我看不如叫做推倒重来更加贴切，难道ls的没有过类似经历么？
如果没有，可以试着对一个项目迭代4，5次开发，顺便tuti也可以发现自己可以忍受重复劳动的极限点，何乐而不为。大师坚韧不拔的毅力看来我是不能具有了。
如果在设计一个框架的时候，就高瞻远瞩的预见到大量潜在需求，追求架构的可伸缩性和良好的可复用，延续性，尽量减少无止境的迭代开发，只能在质量，时间，兴趣，激情等等诸多因素中实现双赢。

我没理解你所说的“一个项目迭代4，5次开发”是什么意思？
你能说明一下你们实践的XP都具体做点什么吗？

我理解楼主的意思是这样的
1. 几乎所有的项目需求是要变的
2. 所以不应该迭代，主要应该靠开始的设计和评估来应对以后可能的变化