【问题标题】:Scrum and Fogbugz [closed]Scrum 和 Fogbugz [关闭]
【发布时间】:2008-11-24 21:38:21
【问题描述】:

有人同时使用 Fogbugz 和 Scrum 吗?

我们广泛使用 Fogbugz,我正在寻找任何可能将它用作 Scrum 一部分的人的想法。我找到了这两个项目,但它们已存档,无法进一步讨论。我对将 Scrum 概念映射到 Fogbugz 的想法特别感兴趣。

有些事情是相当明显的。发布和冲刺很好地相互映射。但是 Scrum 的其他部分并不真正适合。

http://support.fogcreek.com/default.asp?fogbugz.4.12143.4
http://support.fogcreek.com/default.asp?fogbugz.4.19971.3

我还认为创建一些轻量级的自定义东西来包裹 Fogbugz 可能并不难,这样我们就不必为了改进我们的软件流程集成而放弃我们最喜欢的工具之一。

编辑:

我正在添加一些更具体的问题。对这些项目的任何建议都会有所帮助:

  • 我们如何优先处理大型 只有 7 个优先级的积压 Fogbugz提供的级别?我们可以 修改要添加的数据库表 更多的水平,但这是一个 适合当前/预期 Fogbugz 模型?
  • 我们如何/在哪里 记录冲刺目标?
  • 我们如何记录取消的冲刺?
  • 我们如何记录冲刺审查?
  • 我们如何跟踪完成或取消 冲刺?

编辑#2:

Chris 下面的回复提醒了我,我们确实已经升级到 Fogbugz v7。它具有许多与敏捷、Scrum 和精益更紧密结合的强大功能,包括:

  • 项目积压(通过插件)
  • 自定义工作流程
  • 燃尽图
  • 看板(通过插件)

查看以下链接了解更多信息:
http://www.fogcreek.com/FogBugz/WhatsNew.html
http://www.fogcreek.com/FogBugz/Plugins/default.aspx?ixCategory=-3

编辑#3 添加 Perhentian 在他的回答中提到的链接以及我发现的另一个链接:

http://www.danielroot.info/2009/08/how-to-apply-scrum-using-fogbugz-7.html
http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

【问题讨论】:

    标签: project-management scrum fogbugz


    【解决方案1】:

    FogBugz 现在(从第 7 版开始)支持插件,这应该会让 Scrum 更容易使用。

    Tools for Agile / Scrum

    【讨论】:

      【解决方案2】:

      我们使用 FB 已经很长时间了,但最近开始正式确定我们对 Scrum 的使用。

      发现以下内容很有帮助:

      1. 为每个 Scrum sprint 使用一个标签。
      2. sprint 标签被输入到该 sprint 中的每个 FB 案例中。
      3. 我们有一个名为“Scrum Sprint Reports”的 Wiki
      4. 在该 Wiki 中,我们为每个新的 sprint 添加一篇文章(我们按周计算)。那篇文章的标签与 sprint 的标签相同。

      那么,以下事情会有所帮助:

      首先,如果你简单地通过标签搜索,你会发现:所有案例和特定的 Wiki 文章(即使在标题视图中也会显示目标)

      其次,我们创建了两个过滤器:一个过滤器用于在列表视图中显示该 scrum 的案例,第二个过滤器用于在饼图中显示打开/关闭的案例。当你度过这一周时,你希望能吃更多的馅饼。

      对此我唯一不喜欢的是我必须每周五修改我的两个过滤器,但至少要修改 TGIF。


      PS:只想提一下,FB Wiki Editor 比 7.0 中的更好,但实际上应该是 0.8 版本。距离稳定至少还有 2 个版本。

      【讨论】:

        【解决方案3】:

        在使用 FOGBUGZ 和 JIRA 进行敏捷之后,我认为这两种工具都不是支持模型的理想选择。你能不能让任何一个工作。是的。 JIRA 实际上要好一些,因为它能够自定义更多(创建用户故事等)但是如果你真的希望你的团队处于 SCRUM 模式,你需要让每个人都查看燃尽图,每个人都查看积压工作,我认为你应该看看像 SCRUMWORKS 这样的工具。基本版本是免费的,它会给你你想要的。使用 JIRA 和 Fogbugz 来完成它们的任务,跟踪错误和请求,但不是完整的 SCRUM 管理工具。'

        更新:您可以在 JIRA 中使用 Greenhopper 插件,这对于支持敏捷项目会更好。

        【讨论】:

          【解决方案4】:

          在 icanhascheezburger.com,我们使用 FogBugz,我们发现 FogBugz 在很多方面都很出色,但它在开箱即用的敏捷开发方面效果不佳。以下是我们要做的两件事:

          我们将讨论板用于每日 Scrum 报告,但 wiki 页面可能更适合此,因为您可以订阅它。

          我们还将优先级 7 用于积压工作。要查找所有积压案例,只需搜索:

          priority:7 project:"project name"
          

          该 API 将使编写一个小的 scrum 客户端变得非常容易。

          Kanban plugin for FogBugz

          【讨论】:

          • 如果您还没有找到它:Admin->Priority 允许您在 FogBugz 7 中自定义您的优先级标签。
          • 你应该在这里发布你的(很棒的)看板插件的链接:)
          【解决方案5】:

          我们目前正在一个基于 SCRUM 的项目中试用 FogBugz。

          我们仍然非常依赖 SCRUM(和 FogBugz),所以我们所做的可能不是“纯粹的”SCRUM。

          首先,我们将 Excel 用于发布待办事项,例如我们将在 x.xx 版本中提供什么

          我实际上写了一篇博客post 使用 FogBugz 作为积压工作,但最终还是选择了 Excel,因为回想起来我的提议有点复杂,而且我认为我并没有真正获得任何东西。

          在 backlog 电子表格中,我们保留了 back log 项目的名称、大小估计值,以便我们可以计算速度,以及一些其他信息,例如我们将在哪个 sprint 中交付每个项目。

          我们将产品规格保存在 FogBugz wiki 中,并从积压的每个条目中添加指向此的链接。

          在 Fogbugz 中,我们将发布映射到 sprint,并使用计划项来跟踪每个积压项的任务。

          在我们开始一个 sprint 之前,我们会选择我们将在这个 sprint 中交付哪些积压项目。在 FogBugz 中,我创建了一个新版本并将结束日期设置为两周后。然后,我们将选择的积压项目分解为任务,并将它们作为“计划项目”添加到发布中。

          每个人都像往常一样使用“工作中”菜单估算自己的任务并跟踪时间。团队成员每天都会修改他们的估计,然后我们可以使用各种报告来了解事情的进展情况。发货日期置信度图表为您提供了一种反向燃尽图。

          团队的每个成员还有一个他们每天编辑的“状态”计划项目,以记录每日站立会议的状态报告,例如。我昨天做了什么? , 我今天在做什么?我遇到了什么障碍?

          如您所见,我们实际上只是使用 FogBugz 进行任务管理。

          我们更多地为 EBS 和 Wiki 选择了它。

          到目前为止,它运行良好,但我使用的项目是一个 3 人 6 周的项目。

          希望这对您有所帮助。如果您需要任何说明,请告诉我。

          编辑:我也不是第一次尝试让完美的系统启动并运行。我非常喜欢尝试一些东西,如果它不起作用,那就改变它。不过到目前为止,FogBugz 的表现还不错。

          【讨论】:

            【解决方案6】:

            FogBugz 和 Scrum 可以充分协同工作。我认为你的问题很好,所以我会坚持回答这些问题......

            我们如何对只有 Fogbugz 提供的 7 个优先级的大量积压工作进行优先级排序?我们可以修改数据库表以添加更多级别,但这是否适合当前/预期的 Fogbugz 模型?

            恕我直言,7 太多了,无法管理,我发现前 3-4 名是可以管理的,除此之外,我还不如将所有内容归为一个“稍后”的积压工作。但是,FogBugz 文档或知识库文章偶尔会为添加了额外优先级的人提供指导,因此如果 FogBugz 不打算让您使用它,他们似乎很清楚它并基本上支持人们这样做。

            我们如何/在哪里记录冲刺目标? 我们在每个项目的 wiki 上都有一个“sprint review”页面。我们将最近的 sprint 记录在顶部,并使其成为一个巨大的页面(尽管我想我们最终会只保留最近一年或其他时间,因为这些页面变得越来越大)。我们使用的 sprint review 很简单,并且有一组必须由团队和 PM 完成的字段。 在 sprint 之前,我们记录一个目标和 SBL,在我们添加用于审查的字段之后。

            我们如何记录取消的 sprint?

            在上面提到的 sprint 审核页面中。

            我们如何记录冲刺审查? 我们如何跟踪已完成或取消的冲刺?

            我想你现在已经猜到我们如何处理这两个了:)

            我希望这对你和其他人的阅读有所帮助。我们确实有一些与 FB 估计相关的fogbugz hack,我没有在这里讨论,但如果您想进一步讨论,我很乐意这样做。也许您有一些经验可以分享,我可以从中学习?

            -斯科特

            【讨论】:

              【解决方案7】:

              查看新版本的 FogBugz。这里有一篇博客文章总结了支持 Scrum 的改进。我们使用它,它对我们很有效。

              http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

              【讨论】:

                【解决方案8】:

                我们使用 Scrumworks 和 JIRA。

                SCRUM 并未真正涵盖您如何实施 QA/QC 程序,敏捷的一部分是能够定义、改进、迭代流程。

                【讨论】:

                  【解决方案9】:

                  到目前为止很好。我将看看 Scrumworks。我们真的很喜欢 Fogbugz 并且团队对此很满意,所以这就是我尝试看看它是否可行的原因。

                  @Stefan,链接文章中关于产品 backlog 的建议之一是,可以在 Fogbugz 中实现项目 backlog,方法是创建一个可分配的同名版本,不带日期、正式合同结束时的日期,或一个遥远的未来。您是否尝试过或对您的方法可能更好的原因有任何想法?

                  【讨论】:

                    【解决方案10】:

                    我们将 FogBugz 用于 scrum,通过对项目 backlog 使用“发布”,然后为 sprint 创建发布,将项目从项目 backlog 发布移动到当前的 sprint 发布。每个项目都有一个估计值,我们可以从中构建一个燃尽图,如this earlier SO question 所示。

                    不,它并不理想,但效果很好。

                    【讨论】:

                      【解决方案11】:

                      开源工具trac有一个FogBugz integration,Scrum部分可以使用Agilo for Scrum,它基于trac,全面支持Scrum。

                      【讨论】:

                        猜你喜欢
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 2010-09-20
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 2011-02-17
                        相关资源
                        最近更新 更多