建立团队和开发流程[关闭]

Question

根据您的经验

如果您有机会为小型开发团队设置开发流程。

请详细说明

• 您将实施的东西、工具、文档、方法。
• 您将如何实现这些？

我希望实现以下功能：

• 源代码管理
• 错误跟踪数据库
• 正式规范模板
• 代码审查
• 咖啡杯会议（简单的快速非正式会议，喝咖啡:)）
• 严格的编码约定

请记住，这是针对 C# .NET 的环境。

Answer 1

如果您计划购买或已经购买 MSDN 订阅，则许可方面的重大变化对 Team Foundation Server 2010 有利。服务器许可现在包含在 MSDN 中，并且为您提供了一个每个订阅的 CAL。更多许可详情请见here。

Team Foundation Server 将在一个软件包中满足您的几乎所有需求。我非常倾向于使用尽可能少的工具来完成工作，这也是我建议您考虑使用 Team Foundation Server 的原因之一。

关于您的具体要求的一些说明：

• 源代码管理 - Team Foundation Server 的主要功能之一。它运行良好且易于与 AD 组集成。我们为每个项目的角色设置了安全组，也为跨项目的角色设置了安全组。公司开发人员将成为“开发人员”SG 和他/她所参与的特定 SG 的一部分。这使我们能够为他们提供对他们正在从事的项目的完全访问权限以及对所有项目的读取权限。该系统的好处是承包商不属于通用开发组 - 有效地将他们分入项目中。
• 错误跟踪数据库 - 与源代码管理集成是一个明显的优势。通过使用一个包，您可以在工作项和变更集之间建立一种内置关系（您可以通过要求变更集仅在工作项的上下文中创建来进一步强制执行）。工作项关系非常好 - 并且会有所不同，具体取决于您的模板选择。 Microsoft 的 SCRUM 和 Agile 模板都经过深思熟虑，迄今为止都很好地满足了我们的需求。
• 正式规范模板 - 有几种方法可以解决这个问题。您可以为每个模板创建特定的工作项类型并预填充一些内容，或者如果您想要更传统的方法，您可以将文档模板存储在项目的文档树中（实际上是团队项目上的文档库门户网站）。
• 代码审查 - 内置了 Annotate（或 Blame，如果您愿意）等基本功能。还提供了差异工具 - 如果您不喜欢什么，您可以为其他人切换差异工具随它一起发货。 （我个人使用DevArt's CodeCompare。）至于实际审核过程，我是TeamReview的粉丝。
• 严格的编码约定 - 在我看来，StyleCop 是必须的。因此，我也相信 ReSharper 也是必须的。提供约定是一回事，但能够明显地将它们放在用户面前是另一回事。使用StyleCop for ReSharper 之类的内容将提供有关违反政策的实时反馈。您想要添加的任何不属于 StyeCop 的内容都可以通过自定义规则创建，并且您实际上可以将 SCFR 的 ReSharper 配置放在 TFS 中，以便团队共享。

您未明确提及的奖励项目：

• 构建管理 - Team Foundation Server 2010 中的构建工具已经过彻底改造。现在，构建被定义为使用 Workflow Foundation 的工作流，但仍然可以针对更复杂的构建场景手动操作 门控签入（通常称为“伙伴构建”）有助于将不良代码排除在主干之外。
• 测试管理 - 测试人员可以从 Visual Studio 2010 中的简化测试工具中受益。CodedUI 测试的自动化和测试实验室管理工具是 Visual Studio 发展的主要进步。让测试人员能够捕获机器的状态并自动将其插入到工作项目中是非常棒的，而且早就应该这样做了。此外，如果您最终使用了测试实验室工具，那么实际上能够在崩溃时捕获虚拟机的快照只是纯粹的肉汁。
• 协作 - 即使您一开始不打算使用它，为每个团队项目创建的团队项目门户网站也已经具备协作机会。仅就文档管理和项目 wiki 而言，它就物有所值。
• 报告 - 报告因您使用的模板而异，但大多数模板都有管理层关心的报告类型，随时可用。由于 TFS 团队也在多维数据集中呈现数据的方式，添加新报告相当简单。只需一点 SSRS 知识，您就可以立即创建详细的自定义报告。
• 计划 - 你没有提到你使用的是什么类型的方法 - 但敏捷模板内置了一些非常好的 sprint 计划工具。你从 Visual Studio 启动了一个 sprint 计划工作表，它在 Excel 中打开，并且您所做的任何更改都会反映在 TFS 中。非常适合团体计划会议。
• 支持 - 这对我来说是最重要的因素之一。将上述所有内容放在一个包中也意味着我只需要向一个供应商寻求支持。由于我订阅了 MSDN，因此能够在极少出现问题的情况下拨打一个电话号码，并且知道我已经支付了支持事件的费用，这对我来说非常宝贵。

话虽如此，TFS 确实有一点学习曲线。假设您遵循文档，安装和设置实际上非常简单。学习曲线来自于与 TFS 有很多关系的事实。您可能不会使用所有功能，因此您实际需要花在学习上的时间可能会有所不同。不过，与 Visual Studio（和 Office）的本机集成确实提供了一种无缝的感觉，这应该很好地转化为使用该系统的开发人员。

Answer 2

源代码管理：对于 .NET 环境，Team Server 是个好东西。如果您想要免费的解决方案，我喜欢 Mercurial。

错误跟踪： FogBugz（当然：）

规范模板：我认为定义这些应该是开发团队和业务部门之间的协作过程。从一个非常轻量级的框架开始，然后让它们不断发展，不要开出包含从未有人使用过的信息的庞大文档。

代码审查： 对等编程时间提供了丰富的这一点。向团队宣传良好做法 - 不要将其用作公开羞辱开发人员的方式。

会议：我是一个敏捷型的人，所以会议（站立会议）应该简短、切中要害，并且每天在同一时间举行。

编码约定：同样，如果您有有能力的开发人员，则不必规定严格的约定。作为一个团队就基本约定达成一致，并在必要时解决摩擦点。

Answer 3

如果您的团队可以为 Team Foundation Server 买单，那么您将在一个方便的软件包中拥有您想要的大部分功能。

• 源代码控制：基于变更集的配置控制系统，具有完整的分支支持。
• 错误跟踪数据库：工作项 - 可配置，包括错误跟踪和报告。
• 正式规范模板：工作项 - 可配置，包括需求 (CMMI)、场景（敏捷）、自定义类型等。
• 代码审查：工作项 - 就像任何其他 TFS 工作一样跟踪您的审查。 CMMI 流程模板附带一个审核工作项。
• 严格的编码约定 - 我听说有人integrating StyleCop with their check-in policy。

至于咖啡杯会议，您不需要任何工具。 :)