- 浏览: 162567 次
- 性别:
- 来自: 华东
文章分类
最新评论
-
chen_miao:
我是初学者,请问,我在flex设计好了带有按钮和下拉框的界面, ...
ruby+flex实现天气预报 -
barrytyh:
很多技术人员都有想法,但忘了一个根本性的问题,谁在给你MONE ...
互联网创业与软件开发 -
fireflyman:
囧......
关于并发和并行 -
fireflyman:
你老再次出现了
谈谈互联网新产品如何起步 -
qhh394141930:
写得很详细,受教了。谢谢!
从瀑布模型、极限编程到敏捷开发
项目跟踪主要针对计划,是为了了解项目的实际进展情况而采取的活动。如了解成员工作完成情况,了解整个项目计划完成情况等内容。跟踪主要是为了及时了解项目中的问题,并及时解决,不使问题淤积而酿成严重后果。
个人认为项目跟踪还是必要的,因为它可以证明计划是否可实施,同时可以证明计划是否可以被完成。详细的计划可以提高跟踪的准确性,提高跟踪的效率和效果。粗糙的计划则会加大跟踪的工作量,并降低跟踪的效果。
但现在问题是项目计划往往会由于很多其他的原因出现变动,我所经常碰到的变动情况是是人员调动、员工士气低下、由于估算不准造成的工期调整等等。并且在实际的做法中,一般项目计划做的比较粗,那么项目跟踪就很难对计划的细节进行跟踪,目前我倒是没有找到一个科学的做法,还是靠经验凭感觉来来跟踪项目的进展,不知诸位有何高见
评论
17 楼
卡拉阿风
2008-10-08
敏捷+迭代开发确实好。
我赞同楼上有人提出的团队内成员的自管理氛围要有。
我发现团队内有人为了计划而忽略了代码的质量(计划是合理的)。
这个问题很严重
我赞同楼上有人提出的团队内成员的自管理氛围要有。
我发现团队内有人为了计划而忽略了代码的质量(计划是合理的)。
这个问题很严重
16 楼
y31307
2008-10-04
1、项目一定要进行生命周期的选型,确定各个里程碑的时间段。
2、用代码行或者经验值估算编码周期从而估算出各个阶段的时间及工作量。
3、需要项目经理对任务进行详细分解,包括文档的书写。
4、确定项目的会议机制,定期汇报项目进展情况及发生的问题及风险跟踪。
5、分配好QA的检查机制,由QA定期上报项目进度及问题、风险发生情况。
6、及时确定各阶段的进度对总体计划进行调整。
7、将项目不能解决的问题上报公司及用户,由项目管理委员会来确定项目的进度。
2、用代码行或者经验值估算编码周期从而估算出各个阶段的时间及工作量。
3、需要项目经理对任务进行详细分解,包括文档的书写。
4、确定项目的会议机制,定期汇报项目进展情况及发生的问题及风险跟踪。
5、分配好QA的检查机制,由QA定期上报项目进度及问题、风险发生情况。
6、及时确定各阶段的进度对总体计划进行调整。
7、将项目不能解决的问题上报公司及用户,由项目管理委员会来确定项目的进度。
15 楼
evanyuan
2008-09-22
<div class='quote_title'>gurudk 写道</div>
<div class='quote_div'>
<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<p><span style='font-size: small;'> 项目跟踪主要针对计划,是为了了解项目的实际进展情况而采取的活动。如了解成员工作完成情况,了解整个项目计划完成情况等内容。跟踪主要是为了及时了解项目中的问题,并及时解决,不使问题淤积而酿成严重后果。<br/> 个人认为项目跟踪还是必要的,因为它可以证明计划是否可实施,同时可以证明计划是否可以被完成。详细的计划可以提高跟踪的准确性,提高跟踪的效率和效果。粗糙的计划则会加大跟踪的工作量,并降低跟踪的效果。</span></p>
<p><span style='font-size: small;'> 但现在问题是项目计划往往会由于很多其他的原因出现变动,我所经常碰到的变动情况是是人员调动、员工士气低下、由于估算不准造成的工期调整等等。并且在实际的做法中,一般项目计划做的比较粗,那么项目跟踪就很难对计划的细节进行跟踪,目前我倒是没有找到一个科学的做法,还是靠经验凭感觉来来跟踪项目的进展,不知诸位有何高见 <br/></span></p>
</div>
<p> </p>
<p>最近在看Mike Cohn的一本书,敏捷估计和规划,里面说的很有同感,如果计划是基于任务的,就很难跟踪,但如果计划是基于发布的功能的,它里面用的是用户故事,就比较容易跟踪。这还涉及到完成标准的定义问题,实实在在的功能才是最合适的完成标准。 </p>
<p> </p>
<p>如果是想了解总体进度情况,可以用现在最常用的挣值分析法,简单易用,但要保证高层WBS的稳定。否则经常变,挣值也无法计算。</p>
<p> </p>
<p>另外,不改变的计划就是没用的计划,但是一般改的都是工作包底下的任务。WBS应该很少改,细节任务可以经常变。</p>
<p> </p>
<p>项目周会很重要,开好周会,会前要有议程,会后要有会议纪要,最好详细计划也在周会上一起出,任务要细分到半天到3天之内。</p>
<p> </p>
<p>还有,项目计划经常变的原因是忽略了很多任务,比如质量管理,评审,培训,沟通,配置管理,风险管理等下属项目计划,还有休假,开会,病假,软件内部发布,客户演示等一些容易忽略但又经常发生的任务。</p>
</div>
<p><br/><br/><br/>我觉得做软件开发项目,在一开始就把从项目头到尾三四层的WBS做好很难。项目开始阶段,根据经验先估算一两层的WBS,在每个阶段的进展过程中,逐步细化下一个阶段三四层的WBS</p>
<div class='quote_div'>
<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<p><span style='font-size: small;'> 项目跟踪主要针对计划,是为了了解项目的实际进展情况而采取的活动。如了解成员工作完成情况,了解整个项目计划完成情况等内容。跟踪主要是为了及时了解项目中的问题,并及时解决,不使问题淤积而酿成严重后果。<br/> 个人认为项目跟踪还是必要的,因为它可以证明计划是否可实施,同时可以证明计划是否可以被完成。详细的计划可以提高跟踪的准确性,提高跟踪的效率和效果。粗糙的计划则会加大跟踪的工作量,并降低跟踪的效果。</span></p>
<p><span style='font-size: small;'> 但现在问题是项目计划往往会由于很多其他的原因出现变动,我所经常碰到的变动情况是是人员调动、员工士气低下、由于估算不准造成的工期调整等等。并且在实际的做法中,一般项目计划做的比较粗,那么项目跟踪就很难对计划的细节进行跟踪,目前我倒是没有找到一个科学的做法,还是靠经验凭感觉来来跟踪项目的进展,不知诸位有何高见 <br/></span></p>
</div>
<p> </p>
<p>最近在看Mike Cohn的一本书,敏捷估计和规划,里面说的很有同感,如果计划是基于任务的,就很难跟踪,但如果计划是基于发布的功能的,它里面用的是用户故事,就比较容易跟踪。这还涉及到完成标准的定义问题,实实在在的功能才是最合适的完成标准。 </p>
<p> </p>
<p>如果是想了解总体进度情况,可以用现在最常用的挣值分析法,简单易用,但要保证高层WBS的稳定。否则经常变,挣值也无法计算。</p>
<p> </p>
<p>另外,不改变的计划就是没用的计划,但是一般改的都是工作包底下的任务。WBS应该很少改,细节任务可以经常变。</p>
<p> </p>
<p>项目周会很重要,开好周会,会前要有议程,会后要有会议纪要,最好详细计划也在周会上一起出,任务要细分到半天到3天之内。</p>
<p> </p>
<p>还有,项目计划经常变的原因是忽略了很多任务,比如质量管理,评审,培训,沟通,配置管理,风险管理等下属项目计划,还有休假,开会,病假,软件内部发布,客户演示等一些容易忽略但又经常发生的任务。</p>
</div>
<p><br/><br/><br/>我觉得做软件开发项目,在一开始就把从项目头到尾三四层的WBS做好很难。项目开始阶段,根据经验先估算一两层的WBS,在每个阶段的进展过程中,逐步细化下一个阶段三四层的WBS</p>
14 楼
mingo
2008-09-21
在我们公司,目前对于项目的跟踪主要从做了以下工作
1、每个项目开始时,都要制定里程碑计划。这个应该是少不了的,可能需要销售+PM+售前等一起定。一般两个里程碑之间的间隔不要过长,一个月为宜。
项目里程碑计划允许变更,但是要进行审核。
2、每个项目开始时,预估一下项目共需多少工作量。大致是多少人月。
3、每个项目开始时,先预估一下每月的人力投入情况,主要根据里程碑计划的需要。这个人力投入的合计与工作量要大致吻合。
这样,经过QA,项目立项就可以通过。
项目开展时,每个项目每周编写周报,周报里的本周任务不管完成没完成,都要把该时间段内里程碑的计划进行体现。周报里的下周计划也要体现里程碑计划。
我们目前这是比较粗粒度(每周)的跟踪,主要目标是控制进度和成本。
1、每个项目开始时,都要制定里程碑计划。这个应该是少不了的,可能需要销售+PM+售前等一起定。一般两个里程碑之间的间隔不要过长,一个月为宜。
项目里程碑计划允许变更,但是要进行审核。
2、每个项目开始时,预估一下项目共需多少工作量。大致是多少人月。
3、每个项目开始时,先预估一下每月的人力投入情况,主要根据里程碑计划的需要。这个人力投入的合计与工作量要大致吻合。
这样,经过QA,项目立项就可以通过。
项目开展时,每个项目每周编写周报,周报里的本周任务不管完成没完成,都要把该时间段内里程碑的计划进行体现。周报里的下周计划也要体现里程碑计划。
我们目前这是比较粗粒度(每周)的跟踪,主要目标是控制进度和成本。
13 楼
zhanghengfirst
2008-09-20
在这里学习的东西真是太多了.LZ的知识之广.佩服.
12 楼
nonocast
2008-09-18
之前我一度认为需要将任务作为参考基线,后来在看到'硝烟中的Scrum和Xp'的时候提出一个观点是任务本身就是因人因时间变化的,所以拿一个易变的东西作为参考量是不够合理的。
因为编程本身就是一个群人复杂的活动,很难真正量化到具体每小时干什么,所以取一个平衡的话,以功能(story/uc/backlog)作为整体进度,然后以一个相对短的时间作为sprint进行划分任务作为评估内部进度,通过burn-down chart(燃尽图)能够合理的体现出开发速度,进行相应的调整。
因为编程本身就是一个群人复杂的活动,很难真正量化到具体每小时干什么,所以取一个平衡的话,以功能(story/uc/backlog)作为整体进度,然后以一个相对短的时间作为sprint进行划分任务作为评估内部进度,通过burn-down chart(燃尽图)能够合理的体现出开发速度,进行相应的调整。
11 楼
neora
2008-09-16
liuqiang 写道
恩,你说的很对。
不过进度信息觉得还是需要专业人员去采集
不过进度信息觉得还是需要专业人员去采集
有个要点是要形成团队内成员的自管理氛围,成员自己汇报进度比采集进度更有效。我初步了解了scrum后发现这是一种很实用的模式,只是我们确实没有理论化,上升到方法论的高度。scrum同样强调“自管理”,缺乏自管理的开发团队,很难实施有效的敏捷开发。
10 楼
nmvr2600
2008-09-12
软件项目的目的是什么呢,简单说就是要在最后向客户交付一个产品。计划是什么呢?计划就是对项目过程的一个整体规划。跟踪(我理你你其实就是在说项目监控),就是要保证项目按照计划的中安排逐步进行。
想要监控的好,就首先要有一个好的计划。正如ls所说,项目计划总是会变动的,其实进行项目计划改动这本身就是项目监控的一部分。对于项目阶段的划分因为使用开发方法不同,划分的方法也不同,最起码要保证每个阶段的目标准确。至于每个阶段的时间,开始估算的可能不准,但是随着项目的进行,应该能够逐渐的接近实际需要时间。毕竟一个组织的生产效率是比较平稳的。
对于lz后面说的因为项目计划粗糙没法进行细节跟踪,我并不是很理解?这个细节到底要多细?假设你们公司会划分里程碑,那么你项目计划做到每一个里程碑会很困难吗?我觉得这是完全可以做到的。至于每个里程碑里面每天需要什么进度则需要灵活的掌握,不管使用什么方法,xplanner也好别的什么工具也好,里程碑的任务分解也是比较容易做到的。不管项目经理在里程碑是用什么方法去控制只要能达到里程碑计划项目进行就不会有什么问题。当然里程碑计划在开始的时候也能会估算的不准确,但是每个里程碑过后项目经理都可以去修正。重要的是不是说我这次没达到目标我就直接把计划往后退就可以了。每次出现问题都要去分析原因。推迟和提早完成都不是什么好事。假如说这次推迟了就要找到原因,想办法解决。是因为项目计划估算的不好就改计划,是因为某个技术问题或者某个人的问题导致了推迟就要想办法再下一个里程碑把这个问题解决掉。
所谓突发性的问题不管是什么问题,在一个公司里这些问题基本上都是会经常出现,这样的问题就应该开始的时候就纳入风险。
想要监控的好,就首先要有一个好的计划。正如ls所说,项目计划总是会变动的,其实进行项目计划改动这本身就是项目监控的一部分。对于项目阶段的划分因为使用开发方法不同,划分的方法也不同,最起码要保证每个阶段的目标准确。至于每个阶段的时间,开始估算的可能不准,但是随着项目的进行,应该能够逐渐的接近实际需要时间。毕竟一个组织的生产效率是比较平稳的。
对于lz后面说的因为项目计划粗糙没法进行细节跟踪,我并不是很理解?这个细节到底要多细?假设你们公司会划分里程碑,那么你项目计划做到每一个里程碑会很困难吗?我觉得这是完全可以做到的。至于每个里程碑里面每天需要什么进度则需要灵活的掌握,不管使用什么方法,xplanner也好别的什么工具也好,里程碑的任务分解也是比较容易做到的。不管项目经理在里程碑是用什么方法去控制只要能达到里程碑计划项目进行就不会有什么问题。当然里程碑计划在开始的时候也能会估算的不准确,但是每个里程碑过后项目经理都可以去修正。重要的是不是说我这次没达到目标我就直接把计划往后退就可以了。每次出现问题都要去分析原因。推迟和提早完成都不是什么好事。假如说这次推迟了就要找到原因,想办法解决。是因为项目计划估算的不好就改计划,是因为某个技术问题或者某个人的问题导致了推迟就要想办法再下一个里程碑把这个问题解决掉。
所谓突发性的问题不管是什么问题,在一个公司里这些问题基本上都是会经常出现,这样的问题就应该开始的时候就纳入风险。
9 楼
gurudk
2008-09-10
<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<p><span style='font-size: small;'> 项目跟踪主要针对计划,是为了了解项目的实际进展情况而采取的活动。如了解成员工作完成情况,了解整个项目计划完成情况等内容。跟踪主要是为了及时了解项目中的问题,并及时解决,不使问题淤积而酿成严重后果。<br/> 个人认为项目跟踪还是必要的,因为它可以证明计划是否可实施,同时可以证明计划是否可以被完成。详细的计划可以提高跟踪的准确性,提高跟踪的效率和效果。粗糙的计划则会加大跟踪的工作量,并降低跟踪的效果。</span></p>
<p><span style='font-size: small;'> 但现在问题是项目计划往往会由于很多其他的原因出现变动,我所经常碰到的变动情况是是人员调动、员工士气低下、由于估算不准造成的工期调整等等。并且在实际的做法中,一般项目计划做的比较粗,那么项目跟踪就很难对计划的细节进行跟踪,目前我倒是没有找到一个科学的做法,还是靠经验凭感觉来来跟踪项目的进展,不知诸位有何高见 <br/></span></p>
</div>
<p> </p>
<p>最近在看Mike Cohn的一本书,敏捷估计和规划,里面说的很有同感,如果计划是基于任务的,就很难跟踪,但如果计划是基于发布的功能的,它里面用的是用户故事,就比较容易跟踪。这还涉及到完成标准的定义问题,实实在在的功能才是最合适的完成标准。 </p>
<p> </p>
<p>如果是想了解总体进度情况,可以用现在最常用的挣值分析法,简单易用,但要保证高层WBS的稳定。否则经常变,挣值也无法计算。</p>
<p> </p>
<p>另外,不改变的计划就是没用的计划,但是一般改的都是工作包底下的任务。WBS应该很少改,细节任务可以经常变。</p>
<p> </p>
<p>项目周会很重要,开好周会,会前要有议程,会后要有会议纪要,最好详细计划也在周会上一起出,任务要细分到半天到3天之内。</p>
<p> </p>
<p>还有,项目计划经常变的原因是忽略了很多任务,比如质量管理,评审,培训,沟通,配置管理,风险管理等下属项目计划,还有休假,开会,病假,软件内部发布,客户演示等一些容易忽略但又经常发生的任务。</p>
<div class='quote_div'>
<p><span style='font-size: small;'> 项目跟踪主要针对计划,是为了了解项目的实际进展情况而采取的活动。如了解成员工作完成情况,了解整个项目计划完成情况等内容。跟踪主要是为了及时了解项目中的问题,并及时解决,不使问题淤积而酿成严重后果。<br/> 个人认为项目跟踪还是必要的,因为它可以证明计划是否可实施,同时可以证明计划是否可以被完成。详细的计划可以提高跟踪的准确性,提高跟踪的效率和效果。粗糙的计划则会加大跟踪的工作量,并降低跟踪的效果。</span></p>
<p><span style='font-size: small;'> 但现在问题是项目计划往往会由于很多其他的原因出现变动,我所经常碰到的变动情况是是人员调动、员工士气低下、由于估算不准造成的工期调整等等。并且在实际的做法中,一般项目计划做的比较粗,那么项目跟踪就很难对计划的细节进行跟踪,目前我倒是没有找到一个科学的做法,还是靠经验凭感觉来来跟踪项目的进展,不知诸位有何高见 <br/></span></p>
</div>
<p> </p>
<p>最近在看Mike Cohn的一本书,敏捷估计和规划,里面说的很有同感,如果计划是基于任务的,就很难跟踪,但如果计划是基于发布的功能的,它里面用的是用户故事,就比较容易跟踪。这还涉及到完成标准的定义问题,实实在在的功能才是最合适的完成标准。 </p>
<p> </p>
<p>如果是想了解总体进度情况,可以用现在最常用的挣值分析法,简单易用,但要保证高层WBS的稳定。否则经常变,挣值也无法计算。</p>
<p> </p>
<p>另外,不改变的计划就是没用的计划,但是一般改的都是工作包底下的任务。WBS应该很少改,细节任务可以经常变。</p>
<p> </p>
<p>项目周会很重要,开好周会,会前要有议程,会后要有会议纪要,最好详细计划也在周会上一起出,任务要细分到半天到3天之内。</p>
<p> </p>
<p>还有,项目计划经常变的原因是忽略了很多任务,比如质量管理,评审,培训,沟通,配置管理,风险管理等下属项目计划,还有休假,开会,病假,软件内部发布,客户演示等一些容易忽略但又经常发生的任务。</p>
8 楼
Joo
2008-09-10
liuqiang 写道
恩,你说的很对。
不过进度信息觉得还是需要专业人员去采集
在国内即便是在国外一些公司也不能把分工分这么细的 处于成本考虑BOSS是不会让一个人专门干这个不出效益的活的
不过进度信息觉得还是需要专业人员去采集
我现在是直接打uc当作刻度来衡量,但是发现还不能准确反映实际情况,摸索中
7 楼
liuqiang
2008-09-09
恩,你说的很对。
不过进度信息觉得还是需要专业人员去采集
不过进度信息觉得还是需要专业人员去采集
6 楼
celine
2008-09-09
<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<p><span style='font-size: small;'> 项目跟踪主要针对计划,是为了了解项目的实际进展情况而采取的活动。如了解成员工作完成情况,了解整个项目计划完成情况等内容。跟踪主要是为了及时了解项目中的问题,并及时解决,不使问题淤积而酿成严重后果。<br/> 个人认为项目跟踪还是必要的,因为它可以证明计划是否可实施,同时可以证明计划是否可以被完成。详细的计划可以提高跟踪的准确性,提高跟踪的效率和效果。粗糙的计划则会加大跟踪的工作量,并降低跟踪的效果。</span></p>
<p><span style='font-size: small;'> 但现在问题是项目计划往往会由于很多其他的原因出现变动,我所经常碰到的变动情况是是人员调动、员工士气低下、由于估算不准造成的工期调整等等。<strong>并且在实际的做法中,一般项目计划做的比较粗,那么项目跟踪就很难对计划的细节进行跟踪,</strong>目前我倒是没有找到一个科学的做法,还是靠经验凭感觉来来跟踪项目的进展,不知诸位有何高见 <br/></span></p>
</div>
<p> </p>
<p>你不将计划做细,就根本不具备可跟踪性</p>
<p>一次将计划做好完全是不可能的,但是可以逐步细化,至少一个比较短的时间段内(如一个月)的计划是要细化的</p>
<p>计划肯定会变化,而且应该有A计划,B计划。。。。人员调动、估算不准等等因素在计划之初就应该考虑到并有应对措施</p>
<p>跟踪麽,没有什么难的,加强沟通就是了,在有些大项目里,我们甚至会安排一个文员来收集所有进度信息,不需要有什么技能</p>
<p>控制才是困难</p>
<p> </p>
<div class='quote_div'>
<p><span style='font-size: small;'> 项目跟踪主要针对计划,是为了了解项目的实际进展情况而采取的活动。如了解成员工作完成情况,了解整个项目计划完成情况等内容。跟踪主要是为了及时了解项目中的问题,并及时解决,不使问题淤积而酿成严重后果。<br/> 个人认为项目跟踪还是必要的,因为它可以证明计划是否可实施,同时可以证明计划是否可以被完成。详细的计划可以提高跟踪的准确性,提高跟踪的效率和效果。粗糙的计划则会加大跟踪的工作量,并降低跟踪的效果。</span></p>
<p><span style='font-size: small;'> 但现在问题是项目计划往往会由于很多其他的原因出现变动,我所经常碰到的变动情况是是人员调动、员工士气低下、由于估算不准造成的工期调整等等。<strong>并且在实际的做法中,一般项目计划做的比较粗,那么项目跟踪就很难对计划的细节进行跟踪,</strong>目前我倒是没有找到一个科学的做法,还是靠经验凭感觉来来跟踪项目的进展,不知诸位有何高见 <br/></span></p>
</div>
<p> </p>
<p>你不将计划做细,就根本不具备可跟踪性</p>
<p>一次将计划做好完全是不可能的,但是可以逐步细化,至少一个比较短的时间段内(如一个月)的计划是要细化的</p>
<p>计划肯定会变化,而且应该有A计划,B计划。。。。人员调动、估算不准等等因素在计划之初就应该考虑到并有应对措施</p>
<p>跟踪麽,没有什么难的,加强沟通就是了,在有些大项目里,我们甚至会安排一个文员来收集所有进度信息,不需要有什么技能</p>
<p>控制才是困难</p>
<p> </p>
5 楼
zqrain
2008-09-09
Joo 写道
楼上的和楼上楼上的楼上的能不能详细说说SCRUM?
最好baidu一下先
或者看看这里http://controlchaos.com/
4 楼
Joo
2008-09-09
楼上的和楼上楼上的楼上的能不能详细说说SCRUM?
3 楼
welllove53
2008-09-09
Scrum的方法大家都在用,只是没有Scrum理论化而已
2 楼
liuqiang
2008-09-08
<div class='quote_title'>zqrain 写道</div>
<div class='quote_div'>process visualization方面,可以借鉴一下Scrum燃尺图的做法。 <br/><br/>很好,很实用!</div>
<p> </p>
<p> 恩,谢谢你,回头我研究下</p>
<div class='quote_div'>process visualization方面,可以借鉴一下Scrum燃尺图的做法。 <br/><br/>很好,很实用!</div>
<p> </p>
<p> 恩,谢谢你,回头我研究下</p>
1 楼
zqrain
2008-09-08
process visualization方面,可以借鉴一下Scrum燃尺图的做法。
很好,很实用!
很好,很实用!
发表评论
-
谈谈互联网新产品如何起步
2011-02-16 17:56 1270很多时候, 我们刚做完一个互联网产品,由于产品很粗糙, 功 ... -
育娃网---探索国内育儿社区的新思路
2009-12-22 19:55 310个人认为,这个市场是一个充满前景的垂直行业,到底应该从哪 ... -
关于社交网络的一点思考
2009-09-23 12:16 1717只要是给人设计的 ... -
对产品和运营的几点思索
2009-09-07 22:04 20941、做一个产品需要首先考虑,是卖内容还是卖功能, 切不可都做 ... -
命运掌握在自己手中
2009-09-07 13:57 747李彦宏独家撰文:命运 ... -
强者必学的定律
2009-07-06 10:03 7901、蓝斯登原则:在你往 ... -
如何快速通过CMMI评估
2008-12-15 11:39 1398终于访谈结束 ... -
对WebGame行业的一点看法
2008-09-22 10:20 1373之前不怎么上 ... -
CMMI 名词辨析:检查点 里程碑 基线
2008-09-06 10:02 2573我实施CMMI的过 ... -
互联网创业与软件开发
2008-09-04 22:57 2136最近与一位创业公司的朋友私下交流了一些项目管理和软 ... -
创业公司如何用人(转CSDN老紫竹的一篇颇有见地的文章)
2008-08-29 14:32 4170创业不是用钱就能堆 ... -
新手到底新在什么地方
2008-08-22 21:29 2142接触项目管理也有一段时间了,给我感触比较深的还是 ... -
从瀑布模型、极限编程到敏捷开发
2008-08-18 21:11 2871软件开发是一种对人 ... -
QA真的能保证质量吗?
2008-08-15 21:20 4295我最早接触QA是去年在一家大型制造型企业实习的时候,在这种企业 ... -
我们不是在做技术决策,我们在玩
2008-07-31 12:58 3346在这里我不想一 ... -
小公司如何做项目管理(下)
2008-07-22 10:09 1769在上篇文章里, ... -
小公司如何做项目管理(上)
2008-07-21 08:09 2328我所在的公司和大多数国内IT公司一样,十几到几十人的规模,每 ... -
如何编制软件测试用例
2008-06-20 12:52 1982如何设计编制软件测试 ... -
阿里要走102年 阿里的工程师能走多远?
2008-03-19 20:30 1225转载自 http://java.csdn.net/index. ... -
如何快速通过CMMI评估
2008-03-14 22:12 1252终于访谈结束 ...
相关推荐
因此,有效地进行项目跟踪控制,是确保项目成功交付的关键。 软件项目跟踪控制的基本步骤可以细分为五个主要部分: 首先,建立标准。这意味着为项目定义清晰的目标和完成标准,这些标准应涵盖项目范围、进度、成本...
* 项目经理负责依据经评审、批准的项目开发计划书进行项目跟踪和监督。 * 项目组全体成员必须按时如实填写个人工作周报/工作日志,项目经理汇总形成项目组周报,跟踪过程度量数据,了解并掌握项目状态及存在的主要...
随着电子商务项目的复杂性和不确定性因素的增多,如何有效地进行项目跟踪与控制,已成为电子商务项目管理者亟需解决的问题。 项目跟踪管理的核心在于通过建立一个全面的项目管理信息系统,实现对项目进展的持续和...
同时,熟悉GitHub的工作流程和API也是使用GitRelease的前提,因为它是基于GitHub进行项目跟踪的。 总之,GitRelease是面向JavaScript和Vue.js开发者的项目管理工具,它简化了GitHub项目的跟踪和协作,提高了开发...
JIRA是一款功能强大的项目管理工具,能够帮助团队成员进行项目跟踪、任务管理、缺陷跟踪等。Jenkins是一款自动化构建工具,能够帮助团队成员自动化构建、测试和部署软件。 在本文中,我们将详细介绍如何使用JIRA和...
总结来说,软件项目跟踪控制是一个持续的反馈过程,通过监控、测量、分析和调整,确保项目按预定标准和计划进行。华中科技大学软件学院的这堂课详细介绍了跟踪控制的各个方面,对于理解如何在实践中实施有效的项目...
"项目跟踪管理系统"是一个专为毕业设计而构建的软件应用,它利用了Java技术栈,具体为JDK 1.8版本,以及关系型数据库管理系统MySQL。系统的核心是SSM框架,即Spring、Spring MVC和MyBatis的组合,这三大组件在Java ...
为实现这一目标,他们制定了一套详尽的《项目跟踪管理办法》,该办法不仅涉及项目执行的全周期,同时也关注于客户满意度的持续跟踪和反馈收集,通过这一系列措施以确保金融项目的成功执行。 项目启动阶段是项目管理...
北京证券投资银行部为提升自身服务质量,确保业务流程的顺利进行,同时对业务人员进行有效的考核,制定了一套名为《项目跟踪管理办法》的内部管理制度。本文将对这份制度范本的主要内容和相关知识点进行详细解读,...
【资源说明】 1、该资源包括项目的全部源码,下载可以直接使用! 2、本项目适合作为计算机、数学、电子信息等专业的...改进fDSST算法进行行人跟踪,融合CN和HOG特征进行跟踪,使用YOLO进行目标检测(matlab源码+项目
项目管理跟踪报告是项目执行过程中不可或缺的一个环节,它用于记录项目的进度、问题、资源使用以及风险管理等关键信息,确保项目按计划顺利进行。以下是对"3.1 项目管理跟踪报告模板"中涉及的关键知识点的详细说明:...
本项目实战中,开发者将YOLOv10用于目标检测,检测到的目标会被馈送到DeepSORT中进行跟踪。通过结合这两种技术,可以实现对视频中移动目标的精确、稳定跟踪,即使在目标重叠、遮挡或者光照变化等复杂情况下也能保持...
### 项目月度跟踪报告模板知识点详解 #### 一、报告基本信息 - **报告期**:报告期指定了具体的年份和月份,用于记录报告所覆盖的时间段。 - **发送对象 (To)**:报告发送的对象,通常是项目相关方或者上级管理者...
- 智能化管理:通过PM2系统进行项目跟踪、评估、风险分析和报告。 - 决策依据:定期检查项目进展、支出合理性、质量跟踪、投入产出比、风险和下一步工作重点。 5. 项目绩效评估: EVMS结合费用和时间,通过图表...
本文将围绕“跟踪项目开发系统”的Java源码进行深度解析,帮助开发者深入了解系统的架构设计、功能实现以及优化技巧。首先,我们需要获取源码,这通常包含在压缩包中,如本例中的`javaSrc652.zip`。 **1. 获取与...
项目风险跟踪问题跟踪表 易于对项目的风险进行持续跟踪
项目变更状态跟踪一览表是项目管理中的一种重要工具,旨在确保项目变更的顺利进行和跟踪。通过使用该表格,项目团队可以更好地管理变更,避免项目风险,提高项目质量和效率。 在项目管理中,变更管理是非常重要的一...
OpenCV是一个强大的计算机视觉库,它提供了丰富的功能用于图像处理、模式识别以及视频...通过这个项目,你可以深入理解OpenCV如何与摄像头交互,如何使用预训练模型进行目标检测,以及如何应用卡尔曼滤波进行实时跟踪。
全程跟踪审计是对建设项目从立项到竣工验收的每一个环节进行实时监控和审核,以评估其真实、合规和经济效益。这种审计方式强调在项目生命周期内的持续介入,旨在早期发现并解决问题,防止潜在的违规行为和损失浪费。...
《csla 项目跟踪程序ProjectTracker CS 3.7版详解》 在IT行业中,有效的项目管理是确保项目成功的关键因素。为此,许多开发者和团队引入了专门的项目跟踪工具,其中“csla 项目跟踪程序ProjectTracker CS 3.7版”是...