问题标签 [cmmi]

我阅读了一些软件开发人员的观点，他们为在敏捷方法中使用 CMMI 实践辩护。有可能同时使用这两个绝望的想法吗？如果可能的话，这不仅仅是一条冒险的道路吗？

有人可以向我解释为什么 CMMI 流程的 MSF 模板可以选择创建功能和类型功能的要求？

这两个选项有什么区别？

我是软件工程领域的初学者，因此我很难理解 CMMI。如果您能帮助我理解以下问题，我会很高兴。

• 关于项目中的文档，CMMI 告诉您什么？
• 我们应该在 CMMI 中对文档做些什么？

我将我的项目推送到 Visual Studio Online 以便进行一些源代码控制。我正在自己开发这个项目。我以前从未使用过 Scrum、Agile 或 CMMI，而且我阅读的详细描述似乎假设了很多知识。（对于那些还不知道他们在说什么的人来说，这是没有意义的。）

对我来说真正学习 Scrum、敏捷或 CMMI 的最佳方式是使用它们。但是从哪里开始呢？上面的链接对我没有帮助。

作为一个正在寻找源代码控制的独立开发人员，我应该从 Scrum、敏捷还是 CMMI 开始？

为了消除这个问题的基于意见，我将提出我的正式问题：

用 Layman 的话来说，Scrum、敏捷和 CMMI 有什么区别？

（但实际上，我只是想弄清楚从哪里开始！）

在用于 CMMI 的最新版本的 MSF 中，有一个新的工作项类型：Feature.

从理论上讲，一个特征包含一些要求作为它的孩子，它定义了一个投资组合。

Feature在与项目服务器集成时，使用 just和Task工作项类型进行同步是一种好习惯吗？

我目前正在从事一个敏捷的 .NET 开发项目，下个月将过渡到一个 CMMI 项目。关于如何将需求放在待办事项和每日站立会议中。CMMI 会议有何不同？如何确定要开展的工作项目？CMMI 规划使用哪些工具集？对于敏捷，我们使用 VS Team Services。

我是使用 TFS 的新手。

我创建了两个史诗（在它们下面有特性）：

1. [史诗]工作流程 1

   1. [特征]画面A
   2. [特征]画面B
   3. [特点]画面C

2. [史诗]工作流程 2

   1. [特征]屏幕X
   2. [特征]画面B
   3. [特点]画面C

如何在两个史诗之间“共享”功能“屏幕 B”和“屏幕 C”？或者如何组织这个层次结构？

我正在阅读有关 cmmi-dev 的书籍

我需要了解如何从组织内的 cmmi 实施开始。

我无法获得有关 cmmi 特定实现的任何好的资源

我们正在为我们的项目使用 VSTS 和 CMMI 模板。我在板上遇到了一个问题，我无法将现有的测试用例链接到需求。

我试过

• 转到需求级别并添加现有项目并将关系设置为“测试者”并添加我的测试用例。我可以看到需求级别的链接，但是测试用例没有显示在需求板上。
• 转到测试用例级别并添加到现有项目的链接并选择“需求”，但测试用例仍然不会显示在需求板上。

我是否只能向需求添加新测试但不能链接到现有测试用例？

我们的团队正在寻找一种将“需求”链接到“用户故事”（美国）以及将用户故事链接到需求的方法。为此，我们创建了一个看起来像这样的 TFS 树

集合 XYZ 项目（敏捷）。容纳所有用户故事 Project R (CMMI) 的容器。容纳所有要求的容器

然后，我们可以将“Project”中的用户故事直接链接到“Project R”中的需求，并将测试用例链接到每个用户故事。然后，该测试用例也可以直接链接到“项目 R”中的需求，以验证当测试用例通过时，需求已经完成。

这个想法是，我们可以在合同结束时提取所有测试计划，理论上这是客户可以用来验证所有要求是否得到满足的主测试计划。

混合不同的 sdlc 类型的项目级容器是一种不好的做法吗？甚至可以以一种格式导出报告，从而节省键入新测试计划文档的手工劳动。