在“Agile 宣言”中，有几个强调 Agile 团队该如何协同工作的关键词。 其中包括相对于流程和工具而言更重视个体（及其交互）的价值。 各团队将这些价值作为转向 Agile 开发的原因之一。 在过去 10 年左右的时间内，自宣言发布以来，开发了各种版本的 Agile。 我将进一步介绍 TFS 2010 中的一些选项，通过这些选项可以采用两种 Agile 流程模板之一，此外也将介绍我们的 Microsoft 团队如何使用这些选项。

　　在几年前的重组中，Microsoft 软件开发团队关注的重点是确保让我们使用的工具也能为我们的客户 - 也就是您 - 所使用。 这样，我们就无法使用已存在多年的 Microsoft 内部工具。 我们的开发团队隶属管理与安全部门 (MSD)，侧重于构建使 Microsoft 能够为一系列用户提供服务的软件，这些用户包括：IT 用户、IT 管理员和工程师以及在线服务操作员。 简言之，我们的团队可能和您的团队一样，都是通过构建软件来增强或改善客户所依赖的业务。

　　在采用 Agile 之前，我们不重视客户反馈，团队成员之间因职务原因存在人为的隔阂，并且我们也无法将准确的情况反映给管理团队。 如果不改变这种状况，我们的整体效力将逐渐缩减，直到最后整个团队完全走向失败。

　　在我们转向 Agile 的过程中，我们希望注重团队成员之间的彼此交互，然后再侧重关注客户，最后才是关注流程。 在这次变革之前，我们花时间重点关注了与此相反的情况，也就是流程为先，客户其次，然后才是交互。 过去两年的成果为：我们如今能够做到侧重为团队提供强大支持、恢复对客户的关注，以及在正确的时间执行正确的解决方案。 下面我来介绍如何实现这些成果。

　　适合我们的可能也适合您

　　我们并不是一个独特的软件团队。 我们是一个年轻的团队，致力于开发能够直接带来业务价值的最高质量软件。 我们所有成员待在这个团队的时间都不超过三年。 正如我所说过的，我们一直在努力。

　　2010 年 3 月，我们决定必须开始做一些改变。 我们需要一种能够为我们服务的系统，而不是给我们造成障碍的系统，并且该系统还需要能够让我们专心提供客户价值。 除此之外，该系统应能够从我们团队及整个组织的各个层级监控和追踪进度。

　　当时，我们希望以 Agile 方式开发，但不知道该如何做。

　　引入 MSF Agile 5.0 版

　　我们在测试阶段早期就接触到了 TFS 2010，并决定使用 Microsoft Solutions Framework Agile 5.0 版（以下简称 MSF Agile）创建我们的某个项目。 我们当时在寻找一种能够帮助我们实现核心目标的流程模板，这些核心目标包括：实现有效的产品及冲刺规划；注重保持开发节奏；最重要的是增强我们与开发人员、测试人员及项目经理 (PM) 之间的交互。 MSF Agile 提供给我们的生命周期（参见图 1）似乎正是我们所寻找的。

图 1 MSF Agile 流程

　　MSF Agile 提供了多种工作项类型 (WIT) 来指导我们了解和使用 Agile。 我们首先检查了各个 WIT（如图 2 中所定义），以便了解如何有效地加以使用。

　　图 2 MSF Agile 中的工作项类型定义

　　我想着重强调的一点是，尽管我们研究了所有 WIT，但起初我们只使用其中的一部分。 实际上，我们关注的重点是用户案例、任务及错误。 直到几个月以后，甚至一年以后，我们才开始引入其他一些 WIT，如测试案例等。 迄今为止，我们的团队仍未使用问题这一 WIT，但这并不意味着该 WIT 对您不起作用。 像许多学习 Agile 的团队一样，我们采用我们喜欢的方式，丢弃我们不喜欢的方式。 我想着重强调的一点是，并非所有人都完全采用 Agile 软件开发，而 TFS 2010 正好利用 MSF Agile 模板提供了这种灵活性。

　　利用用户案例 WIT 提高业务价值

　　我们了解到 Agile 团队应该在用户案例方面投入大量精力，但我们并非突然就掌握这一点。 首先，我们的用户案例十分庞大，跨越了多个迭代。 它们在更大程度上是推动任务的主题，而不仅仅是促进增值的用户案例。

　　一段时间后，我们了解到好的用户案例需要具备三个关键要素。 首先是标题，它简要地提示了案例所涉及的内容。 使用简短的标题更易于我们对用户案例进行堆叠排序，因为简短的标题更方便浏览。 其次是描述，一般以“作为 <用户类型>，我想 <目标>，这样一来 <原因>”的格式书写，提供了整个案例的背景内容。 也就是说，它为什么增值？它为谁增值？ 这就是客户价值！ 第三是验收标准，对于其价值，我们也只有在后来切换至 Microsoft Visual Studio Scrum 1.0（以下简称 Scrum 1.0）流程模板时才了解到。 验收标准向团队澄清了我们计划提供的内容。

　　随着我们在采用 Agile 方面日渐熟练起来，我们开始更多地了解了用户案例，以及该如何与利益相关者及客户展开关键对话。 我们不能只是专注于撰写优秀的用户案例。 我们还应该讨论自己的团队是否已对用户案例正确进行堆叠排序。 这样就可以在我们就工作顺序开始与客户展开良好且富有成效的对话时作为一个团队进一步得到成长。

　　软件团队（例如我们的团队）通常自己决定什么是重要的。 这与强调一切都应该以客户为中心的“Agile 宣言”相反。 为了填补这一差距，我们在用户案例 WIT 中使用堆叠排序字段来定义我们处理创造价值这一工作的顺序。 该字段促使我们与客户及合作伙伴展开对话，以确保我们的排列与他们一致。 通过使用简单的 TFS 查询，我们的利益相关者和客户可以明白需要提供有序工作列表以满足客户需求（这也在我们的仪表板上公布了，我将在稍后介绍这一点）。

　　MSF Agile 中的规划迭代

　　作为一个团队，我们希望改变过去那段功能在范围或规模方面不断增张却少有甚至没有警告的经历。 并且，我们也希望专注于价值，而非功能。 我们需要准确地规划工作、分配适量的资源并有效地考虑中断。

　　Agile 团队的工作划分为一些具有固定长度的迭代。 但是，一次迭代应持续多长时间呢？ 经过一番讨论，我们选择了四周的迭代，因为我们在不足四周的时间内无法提供准备就绪的软件。 几次迭代之后，我们发现很难在一次迭代内完成所有工作，因此我们试着将切换为六周。 然而，这使得反馈循环过长，因此我们又切换回四周的迭代。 大约 10 个月前，我们切换到两周冲刺，这使我们能够更快地得到反馈。

　　在选择了能够为客户提供最大价值的用户案例后，我们将这些用户案例分配至迭代。 我们的团队必须学会专注于构建较小的增量组件，而非庞大且通查为一个个整体的功能。 较小的组件使我们的团队能够在更精细的级别（例如 5 到 10 小时的增量内）评估工作。 这样也提高了测试人员的效力，因为组件规模较小，他们的测试周期通常就会较短。

　　出于资源配置目的，我们的团队过去常常花大量的时间专注于功能的“设计”及随后构建这些功能所需的成本。 在 MSF Agile 中，我们对每个案例使用一个对应的案例分数，然后使用“最初估计值”字段为工作赋予一定的价值，从而取代了上述内容。 我们使用冲刺规划中的规划扑克进行这种评估（有关规划扑克的详细信息，请参见 planningpoker.com）。 每天，我们会要求团队成员更新其“已完成工作”和“剩余工作”字段，从而根据迭代目标追踪我们的进度（参见图 3）。

　　图 3 管理 MSF Agile 中的规划估计

　　这是准确追踪日常工作的基础，并且我们发现当我们作为一个 Agile 团队共同努力时，工作会更出色、更高效。

　　随着我们团队的成熟，我们渐渐养成每天更新工作评估的习惯，使其成为我们正常流程的一部分。

　　MSF Agile 中的产品规划和迭代积压追踪工具

　　通过使用 MSF Agile 中的“产品规划”和“迭代积压”工作簿（参见图 4），我们得以提高自己估计可承担工作及可成功完成工作的能力。

图 4 MSF Agile 中的规划工作簿模板

　　我们并没有因早期迭代过程中的失败而气馁 - 我们只是专注于不断改进。 在作为一个团队进行迭代规划期间，我们使用“产品规划”工作簿将用户案例分配至迭代。 我们试着让迭代在冲刺规划开始之前就设置起来，从而节省时间。 （有关创建迭代的详细信息，请参见 bit.ly/lakyZA。）随着对自己团队平均速度（我们在先前迭代中完成的案例分数）了解的增多，我们逐渐能够更好地浏览迭代之间的案例，并且对于自己可以在特定日期完成任务也有一定的信心。

　　在我们面向 Agile 进行的过渡中有一些最有价值的部分，其中之一就与我们使用“迭代积压”工作簿有直接关系。 在迭代规划期间，此工作簿提供了多个有帮助的 Microsoft Excel 选项卡。 下面讨论各个选项卡的用途。

　　工作簿中的第一个选项卡是“迭代积压”选项卡，显示了用户案例以及与之相关的所有后续任务。 该选项卡与一个 TFS 树查询绑定，使您能够以熟悉的树视图形式轻松查看用户案例以及作为子项的所有任务（有关树查询类型的详细信息，请参见 bit.ly/l0tv1K）。 您需要更新各个冲刺的查询，以便第一个选项卡能够显示当前分配至迭代的所有项。 您可以操作该选项卡中的数据，并可在不退出 Excel 的情况下将其重新发布至 TFS 服务器，这一做法就是我们在冲刺规划期间创建用户案例任务的方法（有关详细信息，请参见 bit.ly/lmPN4k）。

　　第二个选项卡是“区域与迭代”，可用于设置迭代的“开始日期”、“结束日期”及“迭代路径”，如图 5 所示。

图 5 MSF Agile 中“迭代积压”工作簿的开始和结束日期

　　对于复杂的项目，您可以利用区域路径确定工作簿范围。 作为一个较小的团队，我们很少限定到这一级别。 在具有多个区域且规模较大的团队中，对于各个区域路径，您可能会有不同的工作簿副本。

　　第三个选项卡是“中断”，可用于将团队成员因休假或节假日而无法继续实施项目的情况考虑在内。 尽管如此，该选项卡只允许您针对当前分配有迭代工作项的团队成员设置中断。 因此，在处理该选项卡之前，请确保您已经准确地安排工作任务并且已将团队成员分配至该选项卡（在第 1 个选项卡中，即“迭代积压”），否则团队成员的下拉列表将为空。

　　我们的团队发现第四个选项卡非常有用。 该选项卡称作“产能”，它根据迭代中的剩余工作和天数提供关于每位团队成员超出产能或产能不足的信息。 该选项卡也考虑了前面提到的“中断”选项卡中的信息。

　　“产能”选项卡可在团队成员之间转移任务，从而方便保持负载平衡。 作为一个团队，这正是我们在采用 Agile 之前所缺乏的能力，也就是要学会在较早阶段及时重新分配，而不是到了最后阶段才仓促行动。

　　为了计算产能，工作簿计算了每位团队成员的每天总产能（每天小时数），并将其乘以迭代中的剩余天数。 图 6 中所示的最终结果使我们能够从迭代的第一天（例如迭代规划）开始处理，从而自己我们所处的状况。

图 6 MSF Agile 团队产能规划

　　我们从每日站会中了解的内容是不断变化的。 在图 6 的情况下，所有团队成员都超出了产能，这让整个团队明白在此迭代内完成所有已规划的工作是不可能的。

　　我整理了关于工作簿使用方法的演练，并在我的博客上分享了更多详细信息，博客地址为 bit.ly/fZpzWx。

　　执行特定于团队的自定义

　　构建软件并非总是局限于一个团队。 事实上，它通常需要多个团队一起合作。 跨团队软件开发的难题是存在不同的“团队”流程。 有些团队采取瀑布式软件开发的做法，有些团队则利用 Scrum。 各个团队的独特做法通常会引发一些问题，我们的团队也不例外，因此也不能幸免。 实际上，虽然我们的两个团队都以 Agile 为基础，但我们使用 MSF Agile 的首批项目之一要求这两个团队使用不同的迭代长度和风格来进行交互。 由于 TFS 2010 提供了丰富且强大的能力来自定义任意 WIT（甚至创建一个全新的 WIT），于是它就凭借其灵活性在这一方面帮助了我们团队。 事实上，我们并不需要一个新的 WIT，只需要对现有的某个 WIT 进行调整。

　　当时，我们正与 Microsoft 部署工具包 (MDT) 团队合作开发一种称为用户驱动安装的新功能 (bit.ly/kjySZk)。 它使最终用户能够更改其 Windows 7 台式机或笔记本电脑。 利用 Scrum 的 MDT 团队使用仅在 Microsoft 内部提供的专有工具，但我们的团队采用 TFS 2010。 除此之外，团队之间的交互有相当大的一部分主要侧重于在我们的团队提供新功能时出现的错误上以及在他们的团队拥有所有测试时进行的错误修复上。

　　两个团队在多次迭代时共同合作是为了查看在前几次迭代中如何奋力满足规定的产出要求（例如可交付的软件）。 我们的速度较慢。 作为一个团队，在与合作伙伴展开合作的几个月前，我们一直在使用 Agile，并在完成所有工作的情况下有节奏地完成了迭代。 为什么在冲刺阶段我们就突然无法实现计划的产出水平呢？

　　具有讽刺意味的是，变化在于我们在冲刺规划期间未能考虑到对错误的估计。 因此，我们通常一边开发新功能，一边处理合作伙伴团队要求我们修复的错误。 由于错误这一 WIT 没有基于时间的字段（例如“剩余工作”和“已完成工作”），我们的剩余工时从未提醒我们还有无法完成的工作。

　　TFS 2010 的自定义功能使得调整这种 WIT 以满足我们的需求变得非常简单。 我们更新了错误这一 WIT，使其包含时间字段，并将这些字段添加至“错误”表格，然后我们就可以通过迭代剩余工时追踪错误和任务。 有关如何向 WIT 中添加自定义字段（例如规划字段）的详细信息，请参见我的博客，地址为 bit.ly/gb1BOb。

　　TFS 与 Windows SharePoint Services 的集成

　　正如您所记得的，我们需要提高所在团队追踪进度的能力，并将其相应地报告给整个团队、合作伙伴及管理层。

　　TFS 2010 提供了现成的集成，使我们可以利用新的或现有的 Windows SharePoint Service (WSS)。 创建 MSF Agile 项目包括（如果需要）创建一个 SharePoint 站点，并且该站点需含有一个较好且可定制的仪表板。 由于我们的部分工作是增强团队内部以及团队与客户的交流，我们就利用了 TFS 随附的内置仪表板。 仪表板和 SharePoint 集成最吸引人的地方便是灵活性。 例如，标准 TFS 项目附带的仪表板就没有提供该仪表板视图中所需的全部内容。 我们想要更多。

　　这些仪表板使我们无需再每天通过电子邮件分享进度报告（例如“剩余工时”、“速度”或“错误数”），而是让我们的管理层及合作伙伴可以访问我们的 SharePoint 站点，从而以近乎实时的方式查看我们的进度。

　　与其他所有组织一样，当谈到在查看内容方面对什么感兴趣时，不同的人有不同的需求。 我们对仪表板进行了自定义，使其包含了其他一些报告，默认情况下这些报告在仪表板上处于未启用状态。 例如，管理团队每月会与我们的团队会面以审核我们所做的工作，并在我们按照 Agile 项目的生命周期继续执行任务时向我们提供反馈。 在其中一次会面期间，我们的一位关键领导人就问道，他是否可以查看我们正在处理的用户案例、我们的进度以及当前并不在冲刺阶段内的积压用户案例。 要了解更多有关我们如何利用仪表板以满足这位领导人需求的信息，请参见我的博客，地址为 bit.ly/jJ6XUp。

　　充分发挥 SharePoint 和 TFS 2010 项目的优势

　　如果您或您的公司已经拥有了企业版的 Microsoft Office SharePoint Server (MOSS)，则可利用与 MOSS 链接的 MSF Agile 项目来充分发挥全新水平的功能所带来的优势。 正如前面所提到的，TFS 2010 附带有 WSS，但 WSS 缺乏一些良好的企业就绪功能。

　　我们希望使用 MSF Agile 随附的一些优秀的 Excel 报告。 如 图 7 所示，这些报告提供了许多功能，例如使用 Excel Web Services (EWS) 在我们的项目仪表板上的 Web 部件中托管报告及其中的数据。

图 7 MSF Agile 中的 Excel 报告

　　当您的团队拥有一台或多台可用于团队项目的 SharePoint 2007 或 2010 Enterprise 服务器时，才能使用此功能。

　　当 TFS 2010 在创建 MSF Agile 项目期间检测到 SharePoint Enterprise 服务器时，它会创建一个包含 EWS 报告和 SQL Server Reporting Services (SSRS) 报告的仪表板。 由于我们获得了使用“代码改动”和“错误 (按指派)”等报告的能力，加上还可以使用 MSF Agile 中提供的“燃尽”和“燃速”等报告，这种灵活性就赋予了我们很多能力。

　　维护 SharePoint 仪表板时，我们团队遇到的一个关键问题是管理，具体而言就是谁负责及时更新仪表板上的报告。 例如，当我们团队每两周迭代一次时，剩余工时的开始日期和结束日期需要每两周更新一次，否则仪表板数据就无法保持最新状态。 我们对仪表板的维护持续了几个月，但随着时间的推移，我们开始寻求自动创建这些报告的方式，或者希望找到更简单的方法来追踪迭代。 我们过渡之后不久（将近一年），便发布了 Scrum 1.0（可从 bit.ly/fdojaD 中下载）。

　　Agile：回顾非常重要

　　随着我们作为一个 Agile 团队不断发展，我们一起花了很多时间来专注于改善团队、流程及执行过程。 这通常是在我们完成迭代之后，最后结束时就是冲刺审核（根据冲刺目标进行检查）和回顾。 作为一个 Agile 团队，往往容易忽视回顾，我们有时也确实会这样，这使得我们不得不重新在这方面投入努力。

　　在 MSF Agile 中，TFS 使您能够通过项目 SharePoint 站点中提供的迭代积压模板来追踪回顾。 此工作簿使您能够追踪自己的速度、您做得较好的方面以及您可以稍加改善的方面（参见 图 8）。

图 8 MSF Agile 迭代回顾模板

　　作为一个团队，我们引以为傲的不仅是专注于在回顾方面获得改善，同时也包括不断重新评估我们所做的一切。 尽管我们的学习大多发生在回顾期间，但随着技术的发展，我们也会对 Agile 流程进行调整。 在我们的情况中，当 Microsoft 发布一个称为 Scrum 1.0 的新流程模板且我们不能予以忽略时（事实上，我们对此表示热烈欢迎），TFS 会得到改进。

　　我们向 Scrum 1.0 的过渡

　　尽管我们的团队不打算严格按照基于 Scrum 的模式开展工作，但还是在许多方面与 Scrum 团队类似。 在采用 MSF Agile 之前，我们使用了产品积压项 (PBI) 等术语，然后过渡到了用户案例。

　　和之前一样，我们决定选择一个周期较短的项目来评估新的 Scrum 1.0 流程模板。 这和我们采用 MSF Agile 时的做法十分相似：我们花时间让自己熟悉 Scrum 1.0 模板中可用的 WIT。 如图 9 所示，尽管术语稍有不同，但许多定义还是相似的。

　　图 9 Scrum 1.0 中的工作项类型定义

　　我们很快在 Scrum 1.0 中发现了一项重大更改，那就是称为“冲刺”的 WIT。 该 WIT 允许 Scrum 1.0 团队在 TFS 2010 中为其冲刺定义具体的开始和结束日期、追踪此冲刺的目标以及存储回顾说明。 正如我之前提到的，MSF Agile 在“迭代积压”工作簿中提供了相似功能，以及有关回顾的 Microsoft Word 模板。 将冲刺、目标及回顾作为一个工作项并能向其中分配工作，这对我们而言是一项极具吸引力的更改。 这是我们从 MSF Agile 转至 Scrum 1.0 的主要原因。

　　我们团队中管理功能仪表板、报告及其他迭代产物的 PM 们发现，他们通常会花大量时间更新报告，以便向我们的团队和合作伙伴反映最新的时间点视图。 另一方面，Scrum 1.0 拥有一个我们分配冲刺日期的冲刺 WIT。 然后，“剩余工时”报告使用冲刺工作项中的信息来显示正确的日期范围（参见图 10）。

图 10 Scrum 1.0 中的冲刺剩余工时示例

　　它简单、无缝且恰好适合我们可在冲刺规划期间从事的工作。 我们不再需要自定义报告以设置开始日期或结束日期 - 现在当我们在冲刺规划之前创建冲刺工作项时，它已经为我们设置好了。

　　总的来说，MSF Agile 和 Scrum 1.0 为 Agile 团队提供了不同的选择。 决定使用哪一个取决于您，当然，就像取决于我们团队一样。 图 11 是一张表格，其中列出了每个流程模板的 WIT 及其如何相互配合。 对于所有通过 TFS 2010 采用 Agile 软件开发的新团队，我所建议的第一件事仍然是深入了解如何使用每个 WIT。

　　图 11 MSF Agile 与 Scrum 1.0 中的工作项类型比较

　　要了解更多有关流程模板区别的信息，请参见我的博客，地址为 bit.ly/i5tF2G。

　　在 Scrum 1.0 项目中使用迭代工作簿

　　随着我们团队的发展以及 TFS 2010 中创建了更多的项目，我们发现自己丢失了迭代工作簿。 迭代工作簿极大地帮助了我们了解中断，更为重要的是，它还帮助我们从冲刺层面上了解了团队的产能。 正因为如此，作为一个团队，我们将工作簿自定义为与 Scrum 1.0 兼容。

　　这种更改的关键要点并不是说 Scrum 1.0 对我们不起作用。 实际上，这只是说我们错过了此工作簿提供的许多功能。 我的队友 John Socha-Leialoha（博客地址为 blogs.msdn.com/b/jsocha）阐述了如何修改“迭代积压”工作簿，从而使其与 Scrum 1.0 模板兼容。 工作簿本身无法工作，导致此结果的部分原因是因为它使用的数据存储于 Scrum 中不可用的字段中。 在他的博客文章中，他侧重向他人介绍了该如何学习我们团队让工作簿与 Scrum 1.0 项目兼容。 最终结果是我们的团队得以在规划和站会期间使用工作簿来追踪产能。 我们发现的一个缺点是，默认情况下，Scrum 1.0 无法在规划期间将工作分配给各位成员。 相反，工作以有序的方式直接堆叠排序并放入积压队列中。 因此，要想与工作簿兼容，我们必须将所有工作分配给各位成员，以便我们能查看产能。

　　基于领域的追踪与 Scrum 1.0 中的分配目标

　　正如我所提到的，将工作分配给团队成员的过程中会出现问题。 对于我们拥有一名开发人员、一名测试人员及一名 PM 的项目，将工作分配给各位成员这一任务很好开展。 但是，让我们难以掌控的地方是项目中有些领域的产能会根据我们团队的动态状况而变化。 例如，某项功能可能对应三名开发人员、两名测试人员及一名 PM。 当工作的分配取决于谁在当时有空时，您该如何将工作“分解”给各位成员？

　　切换至 Scrum 1.0 模板后，我们的团队做了一项巨大改变，也就是从将工作分配给各位成员转向侧重基于领域的分配。 我们在 Scrum 1.0 上运行的首批项目失败了是因为我们将工作分配给各位成员而非各个领域。 我们在团队中讨论了这一问题，并决定使用一个称为“活动”的领域字段，但在工作项中我们还是将其更名为“领域”（参见图 12）。

图 12 Scrum 1.0 中基于领域的分配

　　这样，只要我们添加了资源或从功能团队中抽取了资源（可以自行调整），我们就可以一目了然地看出开发人员、测试人员及 PM 的产能。

　　综合讲述

　　我们的 Agile 之旅并不完整，仍然有其他许多机会可以精简我们的流程。 在 Agile 方面有一种不当的说法，那就是 Agile 团队没有专业领域之分。 作为一个团队，我们认为这是完全不准确的。 相反，我们了解到 Agile 团队具有高水平的专业领域。 在转向 Agile 之前，我们的团队缺乏有效的流程，很遗憾，也就缺乏了专业领域。 转向 TFS 2010 并采用 MSF Agile 流程模板之后，我们开始走向成熟，并培养了侧重学习和适应的精神。

　　我们的适应精神帮助我们从使用 MSF Agile 流程模板发展为拥有今天的成就：现在，我们使用 Scrum 1.0 流程模板，作为一个团队，我们感觉自己基本上成功实现了目标。我们希望我们的经历为您带来了一定的启示，可以激励您让自己的团队转向 TFS 2010 并采用这些流程模板之一。

　　当然，如果没有 TFS 2010，我们的团队不会取得今天的成就。 最后还是重复一遍，这是一则关于某个团队凭借 TFS 2010 成功采用 Agile 的故事。

it知识库：在 TFS 2010 中运用 Agile，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。