linux一键安装包内置了apache,php,mysql这些应用程序,只需要下载解压缩即可运行禅道。从73版本开始,linux一键安装包分为32位和64位两个包,请大家根据 *** 作系统的情况下载相应的包。1、将安装包直接解压到/opt目录下,不要解压到别的目录
我自己从2010年8月开始接触和使用 禅道项目管理软件 ,由刚开始的只使用测试--Bug管理模块,到现在的所有模块均有在使用。
在不断的使用过程中,加上长期混迹在禅道QQ技术交流群,对禅道的使用,项目管理也有了深入的理解。
在QQ群里,同样的问题经常被问起,看起来是个小问题,其实里面却蕴含了项目管理的一些大道理。
因此,我以禅道使用为背景,再加上自己的拙见,整理了“六问禅道项目”系列使用分享,希望能达到抛砖引玉的效果。
欢迎吐槽指正。
不少童鞋都有在问:禅道里记录任务工时,输入日期和工时后,为什么还要输入剩余,这么简单的加减系统不会自动计算吗?
也就是说很多童鞋对任务工时有 误读 ,单纯的认为任务 预计剩余工时 = 最初预计工时 — 已经消耗工时。
具体解答问题之前,我们先来了解一下禅道里的工时概念:
最初预计: 创建任务时的最初预计工时。
已经消耗: 开发这个任务已花费的工时。
预计剩余: 完成这个任务还需要的工时。
套用一句老话“计划没有变化快”,以我的个人经历来说比较常见的任务开发状况:
1、某个任务最初预计工时是10,coding了5小时后,重新估算还要9小时才能完成,系统自动计算剩余工时的话是3小时。
2、某个任务最初预计工时是10,coding了5小时后,任务完成了,剩余工时为0,系统自动计算剩余工时的话还是3小时。
3、某个任务最初预计工时是10,coding了5小时后,重新估算还要1小时就可完成。系统自动计算剩余工时的话依旧是3小时。
或许你会反驳我,难道就不存在任务很完美的按预期开发并完成,最初预计与总消耗工时一致的情况吗?有,这种理想状况出现的频率足以让我们忽略掉它的存在。
还有个类似的问题:关于任务已消耗工时的自动更新。有不少童鞋说这个任务我coding了1天,已消耗工时就应该自动记为8小时呀。
错!鬼才知道这一天你都coding了些什么。
让系统自动更新任务已消耗和剩余工时,不仅是错误的认识,而且还会引发一些问题:
1、不能反映出任务的真实开发状况,导致任务剩余工时统计有误。
2、项目进度和燃尽图不能真实反映当前项目进展。禅道里项目进度(进度=项目任务总消耗工时/(项目任务总消耗工时+项目任务总剩余工时))和燃尽图都是通过统计任务的剩余工时来绘制的。
3、错误的数据让项目经理对项目全局的掌控有偏差,对项目的调整和决策出现失误。进而会导致出现项目延期,人员分工不合理,没有测试就匆忙发布,交付的产品Bug频出等一系列问题。
所以严格按照任务开发实际状况记录工时是很有必要的,而不能简单的让系统自动计算掩盖掉真实的数据。
关于任务工时更新,我比较推荐的做法:
1、最初预计工时在任务开始后,就不要再做修改。
2、开发人员每天及时更新任务状态和工时。
3、更新任务工时,结合实际开发状况重新估算剩余工时并记录。
4、允许任务的最初预计工时和总消耗工时存在偏差。任务完成后,二者对比以纠正自己的工时估算。
总结下来就是: 及时更新,重新估算,真实填写。
最后,简短粗暴的回答: 禅道里任务最初预计工时 ≠ 已经消耗工时 + 预计剩余工时。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)