关于软件开发进度的思考

关于软件开发进度的思考

flyfish 2015-3-23

1首先最重要的是项目要完成
2在项目中发生的真实情况比书本上的任何理论都重要
我要的是思考1，观察2

软件开发进度的管理需要方法，方法就要因人而异，因事而异
可能产生的原因
一、为了防止出现帕金森定律制定了一个不可能交付的时间，每天有根本无法完成的任务量。
帕金森定律表明：一个项目计划多少时间，它总能将之消耗完。

就像煮米饭，什么火候，多少时间都有预定，想要加大火候让米饭早熟，一不小心米饭就糊了

二、开发人员自身的水平
三、开发时间估算与真实时间差距大

1) 难题的解决时间
最难估算的是开发过程中遇到的难题和暂时没有发现的难题。
因为不知道到底需要多少时间解决
2) 过于乐观估计，什么事情都是按照一切美好的进行
3)  发生了2/8原则
80％的任务在20％的时间内完成
而剩余的20％的任务需要80％的时间。


难题解决策略
1判断难题是否可以绕过，采取其他方式解决
2设定解决时间，在限期工作时间段没有解决，绕过。
难题通常解决方式
就是问题分解，把大问题，分解成小问题，当分解多次之后，处理的是简单的问题


实际进度落后于计划进度怎么办？

1加班 
好处：可以免受责备，因为增加了工作的时间，都这么努力了还是没有完成。
坏处：程序员会出现差错不断，精疲力竭的状况，程序员能够控制的只有质量，在时间的压力之下只有牺牲代码质量。可以把加班比作马拉松赛跑，只适用于间歇性的和最后的冲刺。
少量加班可以，但不可持续，所以不可取。

2 加人
Brooks法则说：向进度落后的项目中增加人手，只会使项目更加落后。
最重要的是加什么样的人，神人加入就不一定了，但神人不易寻得。可取的概率性小。
简单就是人多不一定力量大。

所以解决方案如下：
1 需要再次调整开发计划，整个计划实际是一个动态的过程，用户需求本身就是不断变化的，
所以计划也不是一成不变的。所做的取舍最好是砍掉不切实际的功能，能在放在后期版本的功能就放后。

2 不能把时间排满，留出空余时间，就像路上如果都是车辆，没有空余，那么就会堵车，导致交通瘫痪。有了空余，车流动就加快了，还可以处理紧急情况。

软件开发是集体项目，最重要的是要一个高效的团队。

摘自《编程之道》
项目计划和公布的时间表，本身毫无意义。那些日期和项目进展的里程碑本质上不意味着什么。然而有一个秘密的时间表，它被所有工作于一个项目的人所理解。这个秘密的时间表从未被外界的关注所愚弄，也从未被操纵以迎合市场的方案。这个秘密的时间表总是被遵守，因为它反映了所有开发部成员之间的相互理解。当项目反映了这个现实时，程序会如期完成；当项目计划与此现实相矛盾时，程序会被延误


摘自《人月神话》
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
1/ 3计划
1/ 6编码
1/ 4构件测试和早期系统测试
1/ 4系统测试，所有的构件已完成