3

我的小组即将迁移到 Team Foundation Server。事实上,我正在努力。

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

问题是 - 我不知道我们使用什么方法。我的意思是,我们没有积极使用一个。而且我对敏捷或其他方法还不够熟悉,不知道哪种方法(如果有的话)恰好适用于我们的工作方式。

有一些默认的方法吗?例如,如果我们经历一些非常生硬的过程(获取需求、代码、测试、推送到 QA、进行 QA 测试、推送到生产),它还有名字吗?

作为奖励,对于 TFS,一开始就选错了会受到什么惩罚?如果我们决定采用敏捷或其他方式,以后换档有多难?

4

3 回答 3

2

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

对于 TFS 开箱即用的两个(Agile 和 SCCM/Waterfall),这确实是您的流程问题 - 您是“尽早且经常”发布,随着错误的出现而发布较小的包,还是运行您的项目在大型迭代中,发布的频率要低得多,但具有明显的里程碑发布?

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

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

于 2009-01-22T17:00:38.810 回答
1

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

改变方法最取决于你的文化。机构往往抵制变革,而做一些个人。然而,这又取决于情况:如果现有情况明显被打破,一个机构有时可以做出让所有人都感到惊讶的快速改变。

有些方法比其他方法“更重”:那些更难改变或改变。即使是测试驱动开发也很“繁重”,因为事后采用它意味着向旧代码添加大量测试。大多数现实世界的过渡只是添加测试,因为文件是出于其他原因编辑的。同样,从 TDD 迁移到某种瀑布式风格将需要在大型废弃活页夹中记录大量代码

于 2009-01-22T16:56:37.397 回答
0

最基本的方法往往是您的迭代或“瀑布方法”,因为您只是一步一步地进行。不过,它似乎不再那么受欢迎了。

于 2009-01-22T16:46:56.073 回答