我怎样才能确定我们使用的编程方法（如果有的话）？

Question

我的小组即将转移到Team Foundation Server。实际上，我正在努力。

您要决定的一件事是您正在使用哪种方法 - 敏捷，CMMI等。

事情是 - 我不知道我们使用什么方法。我的意思是，我们没有积极地使用它。我对敏捷或其他方法并不熟悉，知道哪些方法适用于我们正在做的事情。

是否有一些默认方法？如果我们经历一些非常生硬的过程（获得需求，代码，测试，推送到QA，进行QA测试，推送到生产），那么它是否还有一个名称呢？

作为奖励，使用TFS，一开始就选择错误的惩罚是什么？如果我们决定采用敏捷或其他什么方式，以后换档有多难？

Answer 1

切换methodoligies没有重大损失 - 您只需在安装时选择一个默认值，然后您可以选择您将用于任何给定项目的那个。事实上，它只与TFS最初如何配置Sharepoint项目页面有关 - 您可以在创建页面后添加任何内容，因此如果您决定更改项目的方法，则不难做到。

对于TFS开箱即用的两个（敏捷和SCCM /瀑布），这真的是你的过程问题 - 你是否“早期和经常”发布，随着错误的进入，小包发布，或者你在大型迭代中运行您的项目，发布的频率更低，但有明显的里程碑版本？

要问的问题（虽然不完全准确，但总能帮助我）：产品是否具有对最终用户有意义的版本号？例如，许多网站都是敏捷的，因为它们不断发布改进和补丁，并且通常不会有巨大的改进/大修，而像MS Office这样的产品有一个有意义的版本号（2003年，2007年等），这是更可能是SCCM。

如果您没有明确的方法，那么现在是开发方法的好时机 - 决定哪个发布周期对您有意义，在每个发布周期中创建项目并查看TFS自动为您设置的内容 - 执行进度指示器和Sharepoint页面有意义吗？有什么明显缺失的吗？

Answer 2

如果您无法辨别方法，那么您正在使用临时方法。它可能类似于现有的方法（偶然）。但请注意，遵循方法与成功不同。我已经看到许多失败的方法论重型项目，并且大量的“裤子座位”项目取得了巨大的成功（如果尘埃落定可能需要进行一些重构）。

改变方法取决于你的文化而不是任何东西。机构倾向于抵制变革，并做一些个人。然而，它再次依赖于情况：如果现有的情况明显被打破，机构有时可能会做出令所有人感到惊讶的快速变化。

某些方法比其他方法“更重”：那些更难以改变或来自。甚至测试驱动开发也是“沉重的”，因为在事实之后采用它将意味着在旧代码中添加批次测试。大多数真实世界的转换只是在出于其他原因编辑文件时添加测试。同样，从TDD迁移到某种瀑布式样式需要在大型废弃粘合剂中记录 lot 代码。

Answer 3

最基本的方法往往是你的迭代或“瀑布式方法”，因为你只需要从一步到另一步。不过，它似乎不再受欢迎了。