【问题标题】:Difference between VS2010 Scrum v1.0 vs MSF for Agile software development v5.0 or the latter is the superset? [closed]VS2010 Scrum v1.0 与 MSF for Agile software development v5.0 之间的区别还是后者是超集? [关闭]
【发布时间】:2011-04-14 15:34:23
【问题描述】:

两者之间的差异有多大 Visual Studio Scrum 1.0 & MSF for Agile Software Development v5.0 流程模板?

有人用过吗?

我们目前正在使用外部工具 (TRAC) 在我们的开发过程中实施 Scrum,因为 MS 在 TFS2010 中提出了额外的过程指南,这两件事让我非常困惑!

不确定,该采用哪一个!

【问题讨论】:

  • 无论答案是什么,您都不应该让工具决定您实施 Scrum 的方式(这也是为什么 Scrum 团队应该从简单的工具开始,例如卡片和 excel,并首先学习如何使用 Scrum 框架,而不是工具)。该工具不会使您的 Scrum 实施成功,如果您对 Trac 感到满意,请坚持使用它。

标签: tfs agile scrum


【解决方案1】:

你并不孤单!我们都使用过,错误地从 MSF Agile 5.0 模板开始。如果你专门使用 Scrum,我会使用 Scrum 1.0 模板。 Scrum 1.0 模板是由 Scrum 的创始人之一 Ken Schwaber 创建的。

MSF Agile 5.0 模板包含允许使用 excel 对报告数据进行大量控制的工作簿。但是,还有更多的缺点。它没有发布燃尽报告。为了生成可用的 sprint 燃尽图,您需要在任务中记录实际情况。产品积压很难保持整洁。用户故事是唯一的待办事项,因此跟踪工程高峰或非功能性需求很麻烦。

Sprint 1.0 使用“Sprint”工作项类型,这使得速度和燃尽变得轻而易举。

所以,就工具而言,它非常好。

【讨论】:

    【解决方案2】:

    我的背景总结:2005 年至今的 TFS 架构师/管理员。许多大大小小的开发组织从20个到7000个。公共和私营部门。 HIPAA、FDA、SOX 合规性。 ALM、SCM、RM。

    目前提供的答案试图从项目级别的角度回答这个问题,这是典型的,而不是从组织和维护的角度。并且还支持一个阵营或另一个阵营,这是应该避免的。

    您的问题的答案取决于您的情况。需要或希望在项目中看到什么类型的查询或报告?重申一下最重要的回应是:该工具不应该指示 Scrum,并且要配合它,项目是否需要有点灵活?

    从我与多个客户一起经历的真实世界场景中得出的结论是,他们通常从基本的 Microsoft Visual Studio Scrum 1.0 模板开始,然后向其中添加内容。即:查询、报告、工作项、仪表板等。这不可避免地将他们带回敏捷或 CMMI 模板,并添加了燃尽报告/查询/工作项。无论组织规模如何,都曾多次看到这种情况。

    Scrum 之神是否降临并为 TFS 创建了 scrum 模板也没关系。一个更重要的问题是“您的流程支持什么?人员遵循流程的纪律性如何;他们能在语义上达成一致吗?如果名称不匹配真的很麻烦,可以更改/添加/删除工作项类型/名称,这仍然是驱动它的过程。

    从纯粹的 TFS 角度来看,模板的一个真正重要的方面是,scrum 1.0 工作项可以比其他方式更容易地添加到敏捷 5.0 工作项中。为什么?字段和数据输入点已经存在于敏捷中,而它们在 scrum 中不存在。这反过来又减少了找出系统中存在的哪些字段可以重用而不会引起冲突的时间。

    听起来没有派别,我也尽量不这样做,这类似于说使用 Microsoft Word 会让人感到困惑,因为它有太多的特性/功能。大多数人会忽略这些特性/功能,直到有好奇心或需要使用它们。否则,公司不应该有支付 Microsoft Word 许可证的额外费用而只使用写字板。好奇心和需求促进了理解和知识。

    【讨论】:

      【解决方案3】:

      SCRUM 模板遵循一些 SCRUM 术语和人工制品。你有冲刺而不是迭代,你有用户故事而不是需求、任务、燃尽图等。但在我看来,TFS 很难使用,因为它不是很有效率。

      我们正在为 Visual Studio TFS 2008 使用类似的非 MS 模板。在我的第一个 SCRUM 项目中,我们直接使用 TFS 和 Excel 来收集用户故事、准备任务等。速度非常慢。仅仅为 4-5 个开发人员和 4 周的 sprint(我再也不会使用这么长的 sprint)创建任务就花了我大约两天的时间。太浪费了。此外,没有内置支持打印任务板的卡片。非 MS 模板的另一个缺点(不确定这是否与 MS 模板相同)是每个报告的错误都会立即添加到产品积压中(这是新的用户故事),无法收集约束,用户故事不会有接受标准的预定义字段,而任务没有用于完成任务的实时字段(有利于回顾估计)。如果您可以控制 TFS,则可以添加字段,但不是我的情况。

      我仍然必须使用 TFS(公司政策),但我正在尽可能多地在 TFS 之外处理用户故事和任务 - 纸笔效果最好。 TFS 仍然适用于跟踪 sprint 进度和自动生成的燃尽图,但您必须在任务数量、任务复杂性和 sprint 长度之间找到良好的平衡。

      【讨论】:

      • 我猜你的意思是你有“产品待办事项而不是用户故事”,因为它是 MSF For Agile 和 VS Scrum 模板之间的比较。
      【解决方案4】:

      此 MSDN 页面可能有用:Choose a Process Template

      它在突出以下 3 个默认流程模板之间的差异方面做得不错。

      • Visual Studio ALM 的 Scrum 流程模板
      • MSF for Agile Software Development v6.0
      • 用于 CMMI 过程改进 v6.0 的 MSF

      请记住,它是针对 Visual Studio 2012 工具套件的。

      【讨论】:

        【解决方案5】:

        Visual Studio Scrum 1.0 模板是从头开始构建的,以支持 Scrum,并尽可能使用 Scrum 术语。它是与 Scrum.org 和 Scrum 专业开发者计划合作开发的。如果您使用 Scrum,VSS 1.0 模板将比敏捷模板为您提供更少的摩擦。

        也就是说,您应该怀疑采用 TFS 和 VSS 1.0 模板是否可以比使用您现在使用的当前工具为您提供更好的价值。这里要问的问题是:您是否会从产品待办事项、Sprint 任务、代码检查、CI 构建、手动测试、编码测试、单元测试结果等的集成中受益?

        也许某些标准报告可以让您更好地了解产品增量的质量。例如。你好了吗?单元测试和代码覆盖率报告、测试报告、构建报告。这些是否有助于更好地回答这个问题?

        也许这些都不适用,使用您当前的解决方案是您团队改进的最佳方式。由您来试验和决定。

        (或者你可以雇用我,我很乐意在你在团队中工作并找出哪些问题可能会改善你的团队后帮助你做出决定;-)

        【讨论】:

          猜你喜欢
          • 2013-01-24
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2014-09-18
          • 1970-01-01
          • 1970-01-01
          • 2013-06-19
          • 1970-01-01
          相关资源
          最近更新 更多