ITIL或CMMI对开发有何影响？[关闭]

Question

我读了很多关于软件开发中哪些实践有效或无效的书籍。我从未在开发领域的任何网络广播、书籍或博客中听说过像 ITIL 或 CMMI 这样的方法。

我在学校听说过这些方法，对我来说，这似乎是官僚作风。

然而，我读过的每本关于开发的书籍都谈论协作，或者人而不是文档。（是的，很多敏捷书籍）

所以我的问题是：像 ITIL 或 CMMI 这样的方法对开发或开发人员的日常生活有一些影响或关系吗？你们是否有很棒的书籍或博客谈论我可以在开发团队中使用的这些方法中的一些好想法？

Answer 1

ITIL 更关注基础设施和支持方面，而不是开发，因此 ITIL 的讨论可能更适合于据称正在开发的 StackOverflow 的“IT”重点版本。顺便说一句，我不同意将其他网站称为“IT”重点，因为 IT 涵盖了大多数企业的基础设施、支持和开发……可能很大一部分 StackOverflow 用户是 IT 部门的开发人员。

我曾使用过 CMMI 和团队软件流程 (TSP)，这两个产品都是 Watts Humphrey 和卡内基梅隆软件工程研究所的产品。如果您致力于持续改进并相信测量是任​​何持续改进的核心，那么您会发现 CMMI 的价值。

CMMI（和 TSP）很容易出错，或者以疏远开发人员的方式，最终成为门面或在一堆认证中看起来不错的东西。看看印度的开发供应商……他们奇迹般地都是 CMMI 5 级。他们没有告诉您的是，他们组织中几乎总是有一个小项目或团队努力工作以获得认证，但他们组织中 95% 的人根本不存在可重复的实践。

重点关注时间跟踪（时钟打孔）、缺陷跟踪（错误配额）、代码行（如果您愿意的话，有很多“游戏”方法），以及使您的流程可重复（让开发人员感觉自己像一个没有齿轮的齿轮）。创新的自由）让许多开发人员望而却步。<-- 请注意括号中令人厌烦的反驳。

事实仍然是，90% 的开发人员（其中很少有人阅读 StackOverflow 或任何技术博客/网站）都是草率行事，并且严重缺乏对自己改进机会所在的自我意识。对于他们来说，流程的严格性以及通过重复和测量促进的自我意识逐步提高质量的机会是 CMMI 的重要组成部分。

如果做得好，您可以从 Scrum 等敏捷方法中获得相同的好处，其中重点又是可重复的迭代、从每次迭代中学习以及改进/缩小目标。领导团队采用敏捷方法或 CMMI 并充分利用它们的价值需要大量的成熟度和经验。

敏捷很性感，而 CMMI 却远非性感，这就是为什么你很少听说它。

Answer 2

敏捷采用往往是自下而上的：技术人员偶然发现它并将其推荐给管理层。

ITIL / CMMI往往是自上而下的：管理层偶然发现它并将其推向技术人员。

这不会使一个人好，另一个则不好;主要是影响用于描述每种方法的语言。还有很多例外 - 在壕沟方面有经验并且善于应用CMMI的人，以及熟悉敏捷的经理人。

Google for <！> quot; agile CMMI <！> quot;你会得到很多点击。我不想特别推荐一个，因为这是一个持续的辩论（即其中一些人是完全错误的。）

在我看来，进程的概念在分析日常软件开发工作时肯定是一个有用的想法。有一些经常性活动的想法，以及这些活动通常以类似的顺序组织，是提出导致改进的问题的一个很好的切入点。您还可以通过询问什么是可重复以及在什么条件下可以将活动称为托管来获得一些里程。

当神奇的思考开始时，错误和过度开始：<！>;如果我们只是描述（在纸上）完美过程并准确记录，人们将遵循它，我们将获得完美的软件。<！> QUOT;它没有那种方式。