在项目实施过程中，程序员的估算准确性是合理完成计划的关键一环
然而，在实际实施过程中，往往受到各种因素的影响，导致程序员不能/不愿合理估算实施情况
往往是高手过于乐观，然后发现来不及，然后本着负责任的态度要加班加点
新手根本估算不出，唯上级之命，能做则做，不能做也没有责任意识
以下是可能导致程序员估算不准确的因素
1、对需要估算的任务理解不清
2、采用了新的技术
3、不善于对付技术主管或项目经理的压力
4、不善于估计风险
5、不善于估计和其他人的协同工作
6、不善于应对变化
7、难于控制自己的工作效率
8、微妙的心理因素，不愿意让人看低自己的能力
9、博弈心态，故 ...
通常一个项目都会有某个里程碑代表项目告一段落，可能是商务到款/初验/上线/专家评审会/……等等。
然而在这个节点之后，还有多少工作量呢？
有些项目可能一点工作量都没有，有些项目的工作量可能极大，应该如何界定和估算项目后期的工作量呢？
关键在于评估当前版本对用户需求的满足程度，假设有若干个“用户”“接触”过这个系统
用户类型：用户方领导、用户方的IT人员、用户方业务代表、该系统的正式用户、不知道从哪里找来的“专家”
用户个性：负责、应付、挑剔、糨糊
接触类型：看、简单试用、测试、正式使用。
接触次数和时间：短时间的频繁接触、长时间的非频繁接触、长时间的频繁接触
工作量估算原理：
进入实施阶段之后，随着需求的不断明确，项目团队人员的不断充实，原来前期的风险逐渐不存在，工作量估算的意义大大加强。
又可以分为：个人工作量估算、团队工作量估算两个方面，从时间尺度上来又可分为短阶段工作量估算和长阶段工作量估算。
本文主要讲团队长阶段工作量估算（一般在一个月以上），它和很多因素有很密切的关系，我通常将它划分为以前几点：
1、所采用的过程。
在瀑布式过程下，风险会不断积累，应对变化的能力较弱，往往按计划发布了第一个版本，但是之后又由于需求或设计变更的幅度出现了大量工作量。相当多的团队就在这时失去了对工作量的控制。
在迭代式过程下，风险会较早的暴露以便针对性的解决， ...
工作量估算是商务报价、人力资源调配、进度安排等各项工作的重要依据。
我的工作之一是在项目前期进行工作量估算。
大多数情况下，所能获得的信息都是不完全的（包括业务和技术方面），如何突破这些不完全的信息迷雾，是我一直极为头痛的问题。
目前主要通过评估以下要素来得出，针对这些要素，要尽可能获得比较确实的信息，如果无法获得，则需要根据经验进行评估。
功能性需求：业务对象的数量、业务对象间相互关联的数量、单个业务对象的逻辑复杂度
流程数量、各流程间相互关联的情况、单个流程的节点数量、授权要求
非功能性需求：用户数、稳定性要求、可靠性要求、运行时间要求、响应速度要求、安全性要求、可扩展性要求、可维护性要求 ...
clamp
- 浏览: 49266 次
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
数学和软件
对我们一般程序员来讲，如果将两者结合起来，是有相当难度的。不但要掌大量高等数学知 ...
-- by blackanger -
数学和软件
我觉得软件开发有个三个主要问题：做什么；怎么做；为什么这么做。数学有助于后两个问 ...
-- by cookoo -
数学和软件
hurricane1026 写道庄表伟 写道数学<>逻辑学 软件开发，更 ...
-- by cookoo -
数学和软件(3)——从勾股 ...
不否认软件和数学有一定的关系，但是这样的对应关系是不是有点牵强了。。。 。。。 ...
-- by blackanger -
数学和软件
我的理解是： 数学好的人，可以把软件用纯数学的语言来描述，这种方式也许只能数学水 ...
-- by blackanger
评论排行榜