我们正在审核Scrum并了解如何在我们的产品中实施它。由于它对我们来说相当新，大多数例子都遵循一个非常简单的循环，因此我们对它如何适用于我们的情况有一些疑问。
我们是少数开发人员的一个团队。我们有1个产品有几个并行产品版本。例如：
Foo/
/version_1
/version_2
/fork_a
/fork_b
版本1是我们的遗留版本，它主要接收错误修复，但我们需要从我们的主要开发版本支持端口偶尔的功能：版本2. fork_a和fork_b都是我们产品的特殊版本，Foo，它可以来自一个小额外功能的替代UI。目前，当制作一个分叉并完成它时，它被视为已关闭，并且没有任何东西被移回该分支。
我们的问题是所有这些产品版本都是并行开发的，我们无法想象如何维护它。 （我们计划使用TFS 2010作为我们的工具，因此任何直接示例都很有用。）
我们将所有东西视为不同的产品，每个产品都有自己的版本和冲刺。但这意味着需要在版本1中处理功能A而在版本_2中执行功能B的开发人员可以在并行冲刺中预订。我们基本上需要手动管理它。这意味着我们无法正确生成报告以使其可视化。
另一种想法是将所有内容视为单一产品并删除发布期限。或者使用季度版本并在其下进行所有产品的冲刺。但这意味着我们可以在为期一个月的冲刺的第一周内发布产品。我们如何合作呢？或者我们如何正确地查看单个产品发布的内容？因为工作开发人员X在sprint 1和2中所做的事情对于我们所针对的产品发布没有用处。
非常感谢任何有关如何管理此事的真实示例和想法。
答案 0 :(得分：1)
我们处理与Scrum团队类似的情况。我们有一个更广泛的产品，我们与一个团队（内部桌面应用程序，Web应用程序，Web服务）一起开发。所有这些都有一个共同的技术基础（C＃.NET），但是有各种各样的客户端和表示技术。我们实际上有足够的软件开发人员分成不同的团队，但我们没有足够大的支持演员（QA，DBA，BA）这样做。因此，我们最终修改了经典的Scrum方法，因为并非所有的故事都可以由整个团队处理，有些是更多的Web开发人员，有些是更多的桌面。我们仍然取得了很大的成功，每两周在与利益相关者合并的演示中获得对我们所有产品的反馈。我们也同步发布所有产品。
我认为最好的办法就是开始使用任何适合的过程，并在回顾过程中进行调整。由于所有敏捷流程都是根据您的具体情况量身定制的，因此不要过于沉迷于教科书。做一些“正确”的事情比在做任何事情时做的更好。
答案 1 :(得分：0)
要查看特定版本的工作，请在签入时使用工作项关联，这样您就可以简单地查询哪些项目进入哪个分支。
使用自动构建功能自动将变更集（以及工作项）与产品的内置版本相关联。这样很容易弄清楚哪些变化已经进入哪些二进制文件。
然后最后让营销人员决定如何命名/编号每个版本，技术版本号不必与营销版本相匹配，大多数微软产品就是一个很好的例子，Windows 7没有版本号为7，在内部使用6.1，构建7600.16385.090713-1255。
答案 2 :(得分：0)
我曾在团队中工作，像你拥有的一样运行树干和树枝。当时我们没有练习敏捷，但这并没有阻止我们用我们的常识来解决问题。如果我现在要再做一次，我会有一个主板，用于所有需要在sprint中发生的工作，但也有每个不同的分支/分支的子板。主板和子板每天在同一时间更新。子板仅提供每个叉/分支的故事和进度的可视化。主板上的所有内容仍然完成，以完成每个冲刺的标准。需要将版本同步到相同的sprint间隔（时间可能不同）以使团队保持在一起（没有并行冲刺）。