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

Question

关闭。这个问题是off-topic .它目前不接受答案。












想改善这个问题吗？ Update the question所以它是 on-topic对于堆栈溢出。

10年前关闭。




Improve this question




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

我在学校听说过这些方法，对我来说这似乎是官僚主义的做法。

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

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

Answer 1

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

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

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

专注于时间跟踪(时钟打洞)、缺陷跟踪(错误配额)、代码行(如果您愿意，可以使用多种“游戏”方法)，并使您的过程可重复(让开发人员感觉像一个没有齿轮的齿轮)创新的自由)关闭了许多开发人员。 <-- 请注意括号中令人厌烦的反驳。

事实仍然是 90% 的开发人员(其中很少有人阅读 StackOverflow 或任何技术博客/网站)从臀部开始拍摄，并且严重缺乏自我意识，他们的改进机会在哪里。对他们来说，过程的严谨性和通过重复和测量促进的自我意识逐步提高质量的机会是 CMMI 的宝贵组成部分。

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

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