标签: fogbugz

在一个项目期间观察了一年的估计我发现了一些奇怪的事情让我想知道基于证据的调度是否能在这里发挥作用？

• 个别程序员似乎有最喜欢的数字(例如2,4,8,16,30小时)
• 固定值(约为2)似乎低估了大任务,但这里的标准偏差很小
• 小任务(1或2小时)绝对分布广泛.平均而言,它们具有相同的平均低估因子2,但标准偏差很高:
  • 估计大约5分钟的拼写问题是1小时
  • 其他错误修正也估计1小时,但需要一天

那么,在估算期间让程序员将30小时任务分解为4或2小时步骤真的是个好主意吗？这不会提高标准偏差吗？(好吧,让他们分解 - 但也许在估计之后？!)

你知道redmine或trac的一个很好的替代品,它允许这样的功能吗？我也尝试过fogbugz,但是与svn资源库浏览器集成得太差了(而且没有代码审查支持的迹象).

我想知道是否有一种方法可以自动标记变更集,因为它在本地提交或推送到kiln存储库时.

我希望每个变更集都有一个带有版本/内部版本号的标记.我打算将我的版本/内部版本号存储在数据库中,并希望脚本从数据库中检索此值并向变更集添加标记.是否可以自动调用脚本来执行此操作作为提交后事件或推送到窑存储库时的推送后事件？

我也对任何其他方法都持开放态度,以便在每次提交/推送时实现自动标记.

我真的想知道为什么FogBugz在本地安装时坚持要关闭DEP？

我有几个WPF应用程序,我希望用户能够将这些应用程序中的错误直接记录到我的FogBugz数据库中.有什么办法可以做到吗？另外,我如何做到这一点,当他们的案例得到解决时,应用程序告诉他们呢？

我正在使用Fogbugz作为我的Bug跟踪软件,并且正按计划进行思考,以便我可以根据该计划暂时升级我的Bug跟踪软件.

我只是好奇其他人如何进行升级,以及多久.

如果您根据什么原因分享Bug跟踪软件升级的频率,那也很不错.

谢谢.

我目前在一家公司工作,使用FogBugz进行问题和错误跟踪,使用SourceGear Vault进行源代码管理.

我们现在介绍Team Foundation Server.显然,TFS将取代Vault进行源代码管理.我的问题是,满足以下要求:

• FogBugz案件的大量现有基础(有些显然是开放的)我们需要支持持续进行
• 支持服务台需要能够引发错误/支持呼叫
• 希望将源更改链接到案例编号

...使用FogBugz案例和TFS WorkItems之间的最佳分歧是什么？

• 是否有可能完全从FogBugz迁移到TFS？
• 如果无法从FogBugz迁移到TFS,那么将FogBugz案例和TFS工作项一起使用的最佳方法是什么？