Scrum vs.与CMMI

Question

我将我的项目推送到，以便有一些源代码管理。我正在自己开发这个项目。我以前从未使用过Scrum、敏捷或CMMI，我在http://msdn.microsoft.com/library/vstudio/ms400752.aspx上读到的详细描述假设了很多知识。(对于那些还不知道自己在说什么的人来说，这是毫无意义的。)

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

作为一个正在寻找源代码管理的单独开发人员，我应该从Scrum、Agile还是CMMI开始吗？

为了消除这个问题的观点基础，我将提出我的正式问题: Scrum、Agile和CMMI在Layman的术语中有什么区别？(但实际上，我只是想弄清楚从哪里开始！)

Answer 1

(我是一家公司(数字é)的联合创始人，该公司为各种技术组织建立并销售企业软件，因此我对以下主题有一些背景：)

敏捷和Scrum是相关的，因为它们是软件开发方法。敏捷是诸如Scrum、极限编程(，XP)等特定方法的总称。

另一方面，CMMI是一个质量管理框架，对于需要根据其总体能力和成熟度来衡量自己以演示软件工作的可重复质量的大型组织非常有用。组织可以使用多种软件开发方法--敏捷方法(如Scrum/ Kanban/ XP/ BDD/ TDD/等)、“传统”方法(瀑布式、迭代式)或混合(混合敏捷)，这取决于它们的业务需求。他们仍然可以使用CMMI作为一个全面的治理框架来衡量和开发他们的软件能力。

当然，作为一个单独的开发人员，您不需要担心CMMI！

敏捷方法通常让您能够以更低的风险、更大的成功机会和早期警告来构建您的软件，即您正在开发的产品可能不是正确的产品(我相信，您知道，不仅要正确地构建您的产品，而且还要构建正确的产品)。即使你是一个单独的开发人员，你必须有其他的人，你(需要)互动，特别是你的客户(S)。敏捷方法(如Scrum或Kanban )使您能够更频繁地向他们交付工作软件(每2-3周一次)，更经常地获得他们的反馈，并且比其他方法更经常地采取纠正步骤。看板帮助你更持续地做这件事。我推荐以下书，如果你还没读过其他书的话-

1. Scrum - Scrum的力量-杰夫·萨瑟兰
2. 看板-成功的进化变化为您的技术组织-由大卫安德森。(如果您需要对看板进行基本介绍，您可以在这里查看- 看板是什么？)

为了回答你的最后一个问题，我建议从看板开始。我的假设是，您已经有了一些流程来构建软件并将软件交付给您的客户。看板将帮助您映射现有流程，帮助您“可视化”它，并帮助您更频繁地/更连续地交付。并对您的流程进行改进，以帮助您在总体上更加敏捷。如果你想要更正式、更有条理的东西，你应该采用Scrum。它可能需要更大的努力--预先--但不要太担心它的正式结构，而是要关注它的基本意图，即更经常地向您的客户交付工作软件。

希望这能有所帮助。

干杯!

Answer 2

所有这些都是软件开发过程。

Scrum是非常协作的，你经常和你的团队讨论，这样每个人都可以知道发生了什么。作为一个团队，帮助有效地处理问题。

敏捷可以有很多东西。但是，当我经历了它，它是非常快速的开发与迭代。这样你就可以让产品开始工作，然后逐步地让它变得更好。快一点，这样你就可以在下一步之前得到反馈。

我没听太多CMMI的话