本文探讨了在软件项目管理中如何通过有效代码量的概念来更准确地评估项目进度和个人能力。通过对经验与实际情况的对比，揭示了项目延期的常见原因，并提出了一种新的评估方法。
经验是很重要的,宝贵的.它是花了时间和金钱获取到的,它代表着一种历史,积累和传承
但是另外一个方面,经验的产生一定有它的各种条件,于是,很多时候过于被经验误导.换个说法叫做"教条主义"
经验虽然宝贵,但是未必正确! 未必科学! 随意性太强,无法量化,只能感觉.经验是差异化的.
还有一个说法是,经验是拿来束缚我们思想的,什么时候可以突破,进入下一个循环
----------------------------------------
在实际项目进度中,会有以下情况:
- 其他项目干扰
- 会议干扰
- 业务不熟悉导致的需求变动
- 意外情况
- 人员变动,人员水平预估不足
- 软硬件问题
- 知识点复杂度预估过低
- ...
上面罗列的这些情况一定会干扰进度,而且基本上会重复出现.
从经验学上我们都可以预估到这些问题的出现,但是出现的频率,次数,时间周期是咋样呢?
我们需要利用统计学来汇总这些吗?
其实不必要.我们已经提出了一个概念:有效代码量.
有效代码量=总代码量/代码总时间(建议单位:工作日)
不管项目过程中到底是什么干扰因素,只认为它是干扰因素.
它(们)让我花了更多的时间来写代码.
需要你理解的是在提及有效代码量的时候有两个概念:
- 个人有效代码量,用于个人能力评估
- 项目有效代码量,用于项目复杂度评估
嗯,你可能并不能理解我的思路和想法,那么我换个思路来描述:
-----------------------
一个注册页面(模块)会有多少行有效代码,你告诉我? 假设200
一个基本的CRUD模块会有多少行有效代码?假设400
(这里只算后台代码)
也就是说我们有600行代码需要人来完成对吧?
现在我们手里有A,B两个人:
A:每工作日200行代码.那么600行代码他需要3个工作日对伐?
B:每工作日400行代码,他需要1.5个工作日对吧?
但是经过之前的项目迭代,我们统计出的A,B有效代码量分别是:
A:60行,那么实际需要 10个工作日;
B:180行,需要3.33个工作日;
这个对比数据可能很夸张.但是事实可能就是这样:
独立的看一个模块,它可能确实只需要N1天.但是如果是10个模块或者更多,难道这个时间是N1+N2+...N10吗?
我们的思维习惯老是喜欢把一个孤立的事情简单想加,而考虑不到这些孤立的东西加在一起的时候构成了网络
我第一天能写出来的代码量假设是400,但是如果第二天我把第一天的代码改动了20%,其余时间开会了,第三天我有事请假了,第四天我在修补之前某个系统的代码,同时新写了100行代码;第五天,我在想着马上放假了,于是写了200行代码,改了50行代码.
一般来说我告诉别人的是:我每天可以写400行代码,
但是事实是这五天我只完成了700行代码,也就是说我每天平均只写了140行代码!
呵呵,现在知道了为啥进度总是延期了吧?知道为什么你总是要加班了把???
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
