agile - ITIL 或 CMMI 对开发有何影响？

Question

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

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

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

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

Answer 1

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

我曾使用过 CMMI 和 Team Software Process (TSP)，它们都是 Watts Humphrey 和 Carnegie Mellon Software Engineering Institute 的产品。如果您致力于持续改进并相信测量是任​​何持续改进的核心，那么您会发现 CMMI 的价值。

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

专注于时间跟踪（打卡）、缺陷跟踪（错误配额）、代码行（如果你愿意的话，有很多“游戏”的方法），以及使你的过程可重复（让开发人员感觉像一个没有创新自由）关闭了许多开发人员。<--注意括号中厌倦的反驳。

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

如果做得好，你会从像 Scrum 这样的敏捷方法中获得同样的好处，其中重点再次放在可重复的迭代上，从每次迭代中学习，以及改进/缩小目标。带领团队采用敏捷方法或 CMMI 并从中获得全部价值需要大量的成熟度和经验。

敏捷是性感的，而 CMMI 与你所能得到的性感相去甚远，这就是为什么你很少听到它的原因。

Answer 2

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

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

这不会使一个好而另一个坏；主要影响用于描述每种方法的语言。也有很多例外——有一线经验的人擅长应用 CMMI，而经理则深谙敏捷。

谷歌搜索“敏捷 CMMI”，你会得到很多点击。我不想特别推荐一个，因为这是一场持续的辩论（即其中一些人完全是错误的）。

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

当神奇的思维开始出现时，错误和过度行为就开始了：“如果我们只是（在纸上）描述完美过程并准确记录它，人们就会遵循它，我们将获得完美的软件。” 它不是那样工作的。