艾伟也谈项目管理,如何评估软件进度

  这是一个评估项目完成和剩余百分比的指导说明。

  我还没看到了这个问题。 完成:0%, 剩余时间:2周左右。

  我看到了这个问题。 完成:50%, 剩余时间: 还要2周左右。

  我差不多都完成了。剩下的是一些很麻烦的东西,我真的不知道该怎么处理。 完成:90%, 剩余时间: 还要2周左右。

  所有的都做完了。只剩下文档、代码复查、测试和异常处理工作。 完成:99%, 剩余时间: 还要2周左右。

  文档、代码复查、测试、异常处理工作还是没有完成。实际上我是在已经完成的事情上精益求精。可是我刚刚发现了另外一个问题,看起来怪异的多。 完成:100%, 剩余时间:0周。

  [英文出处]:How To Estimate Software

时间: 2024-11-03 23:54:01

艾伟也谈项目管理,如何评估软件进度的相关文章

艾伟也谈项目管理,产品版本改造中的项目管理

近段时间,一直在负责一个产品版本改造(C/S系统进行B/S改造)的研发项目管理,在任务紧.时间短.团队成员又没有相关技术(Silverlight)背景的恶劣情况下,我带领包含我在内只有6个人员(5个研发人员,1个产品经理,产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了)的超小型项目团队,终于在公司给定的时间范围内完成了整个产品的版本改造.这其中经历了需求变更.技术风险.人员变动等诸多问题,项目任然取得了成功,这种使用新技术的试验项目能够取得成功不得不说有几分侥幸,更多的还是团队

艾伟也谈项目管理,技术管理中常见的几个问题

前几天跟朋友聊天时,朋友说他刚刚从一家知名软件公司面试出来,朋友去面试的是一家公司的技术管理岗位,所以在面试的时候被问及的问题也偏重于技术管理方面的问题,在与朋友的聊天中将这几个问题归纳了一下,大致归为如下几个问题. 在日常工作中你是如何行使管理职能的 这个问题以我的经验以及参考常见的一些开发方法,在实际中我都是早询问及晚反馈的方法.也就是早上上班后的半个小时内主动询问开发人员是否有不能及时解决的问题,如果有,组内组员讨论解决方法:下班的时候,组员可以以邮件或者其它方式汇报自己的进度,并评估当前

艾伟也谈项目管理,我也发软件开发团队的思考(侧重点是人员)

//上个月给我们老板的mail.洋洋洒洒6000多字. //为了方便公开,改了一下.以致可能有些地方前言不搭后语. //不管他同意不同意,先在我们组实行了再说. //请多大家多提提意见,日后看有没有机会找老板当面交流 经历的几个项目,项目的进度老是不尽如人意.更重要的是市场的开拓因为这些项目拖住了后退而无所作为. 我们现有的情况是:项目期限和最开始的保守估计都相去甚远,最后提交给客户的产品60%都是最后一个多月开发出来的,还有20%左右是以前就固有的固定模块.这几个项目我参与了编码,我对整个系统

艾伟也谈项目管理,软件开发前期设计时的注意事项

说起软件设计,我们可能每个人都做过,但是什么样的方案才是好的设计方案?如何才能设计出一个好的设计方案?在设计过程中需要注意哪些呢?不要总是说:低耦合.可维护性.可扩展性.简易性.可重用性等,本文试图另一个角度出发,带着前面的这些问题,使大家能明白那些问题的答案,并与大家一起探讨. 什么样的方案才是好的设计方案? 当我们完成了一个良好的设计方案后,我们回头再仔细分析是什么因素影响了我们的思路,使我们最终完成(确切的说是选择了)了这个设计方案(而不是另一个),我们会发现这些因素是:用户功能性的需求.

艾伟也谈项目管理,找出软件开发过程中的BUG,你需要火眼金睛

1)Bug大都出现在程序员的编码过程中.测试人员工作之一就是找出Bug,面对那些难以被人发现的Bug,测试人员通常会采取哪些手段?以您的经验,对广大测试人员有什么好的建议?对于开发人员,您有什么建议让他们减少Bug的产生? 之所以难以发现,大多是测试案例不够完整,检查测试案例是否全面覆盖了需求,等价类划得是不是够细有助于发现更多的问题. 如果已经发现的问题大多是猜测法发现的,那么惨了,这是一个天马行空的测试,所有的BUG都将是难以发现的BUG,碰运气吧.如果你真的是在这个不幸的团队,别伤心,你有

艾伟也谈项目管理,给敏捷软件开发的26条建议

我经常收集各种各样的至理名言,最近我重温敏捷软件开发:真正的问题是什么?下面是一份26条关键原则的清单,以指引敏捷软件开发团队. 1.完整地干完一件事后在开始另一件事:用厨房比喻来说就是:"先上这道菜,再开始做下一道".软件开发的最大问题就是同时开始几件事情,这将不可避免的造成某些工作被废弃,从而造成浪费.专注于一件事:完整地实现其功能:运行测试:编写文档:签入所有,把这当做一项工作完成,然后再开始下一件事. 2.不要破坏构建:非常明显,但必须被包含在任何软件开发建议清单中.程序员在签

艾伟也谈项目管理,利用简单的一元线性回归分析估计软件项目开发时间

引言       前两天一个朋友给我打电话,问我如何估计项目开发时间.对此我很诧异,问他以前他们是怎么估计的,他说以前基本都是大家开个会,大约都说说自己意见,最后负责人一拍脑袋,给出一个时间.不过这次遇到一个非常认真的客户,要求不但要估计出项目开发时间,还要明确说明具体的依据和估算方法,这下我这朋友有点犯难,才询问我.后来我翻阅了一些数理统计和项目估算方面的资料,告诉了他利用一元线性回归分析估计软件项目开发时间的方法.想到这种估算需要在一些开发团队很常见,所以在这里整理成文. 问题的定义及数学模

艾伟也谈项目管理,软件公司的两种管理方式

这篇文章是我的一个外国的同事Gareth推荐给我的,我和他一起工作过一段时间.他之所以觉得非常不错,是因为这篇文章让他身有体会,他觉得我也一定会有体会,并让我考虑一下翻译到我的blog上来.我看完后觉得很有代表性,而且觉得说得太对了,所以翻译过来,希望大家都读一读,最好转给你的公司老板. 这篇文章来源于 StakeExchange 上的一个问题--"为什么BA和PM的薪水要比程序员要高?",顶在一楼的回复分析了这个原因,并指出了两种管理文化. -------------------正文

艾伟也谈项目管理,谈软件协作:君子和而不同,小人同而不和

我们知道现在的软件开发最大的问题就是变化,其实这也不是软件本身的问题,我更觉得是软件的特点.因为他不像建筑,画个建筑图,一般不会偏到哪里去.然而很多需要软件的人,他可能希望软件能达到什么目的,至于具体是什么样子,他自己也不知道.大部分都是看到一部分想起一部分,自己也不断的修正.这也是为什么最近敏捷大行其道. 我甚至服务过一个客户,做一个公园系统,为的是送一张免费的VIP卡给业主,最终目的是卖房子. 既然软件的需求是不固定,也就是不断变化,所以我们签合同的时候往往有两种方式: 1.固定价格 这种就