我读了很多关于哪些实践在软件开发中运作良好的书籍。 我从未在任何网络广播或开发领域的书籍或博客中听说像ITIL或CMMI这样的方法。
我在学校听说过这些方法，对我而言似乎是官僚主义的做法。
然而，我读过的每本关于开发的书都谈到了协作，或者人们谈论文档。 （是的，很多敏捷书籍）
所以我的问题是：像ITIL或CMMI这样的方法是否会对开发或开发人员的日常生活产生一些影响或关系？您是否有很好的书籍或博客可以在开发团队中使用的这些方法论中讨论一些好的想法？
答案 0 :(得分：9)
ITIL更侧重于基础架构和支持方面，而不是开发，因此对ITIL的讨论可能更适合于可能正在开发的StackOverflow的“IT”重点版本。顺便说一下，我认为其他网站“IT”的重点在于IT包含大多数企业的基础架构，支持和开发......可能有很大一部分StackOverflow用户是IT部门的开发人员。
我曾与CMMI和团队软件过程（TSP）合作，这两个产品都是Watts Humphrey和Carnegie Mellon Software Engineering Institute的产品。如果您致力于持续改进并相信测量是任何持续改进的核心，那么您将在CMMI中找到价值。
很容易使CMMI（和TSP）错误或以疏远开发人员的方式最终成为装饰窗口或者在一堆认证上看起来不错的东西。看看印度的开发供应商......他们奇迹般地是所有CMMI级别5.他们没有告诉你的是，他们组织中的一个小项目或团队几乎总是努力获得认证，但是可重复的实践他们95％的组织都没有。
专注于时间跟踪（时钟打孔），缺陷跟踪（错误配额），代码行（如果您倾向于“游戏”的很多方法），并使您的流程可重复（让开发人员感觉像是cog没有创新的自由）关闭了许多开发人员。 ＆lt; - 注意括号中的jaded反驳参数。
事实仍然是90％的开发人员（其中很少有人阅读StackOverflow或任何技术博客/网站）从时髦的角度拍摄，并且非常缺乏自我意识到他们改善的机会在哪里居住。对于他们来说，过程的严谨性和机会通过重复和测量促进的自我意识来提高质量，是CMMI的重要组成部分。
如果做得好，您可以从像Scrum这样的敏捷方法中获得相同的好处，重点在于可重复的迭代，从每次迭代中学习，以及改进/缩小目标。领导团队采用敏捷方法或CMMI并从中获取全部价值需要很多成熟度和经验。
敏捷是性感的，CMMI与你能得到的性感差不多，这就是你没有听到它的原因。
答案 1 :(得分：4)
敏捷采用往往是自下而上的：技术人员偶然发现它并将其推荐给管理层。
ITIL / CMMI往往是自上而下的：管理层偶然发现它并将其推向技术人员。
这不会使一个人好，另一个则不好;主要是影响用于描述每种方法的语言。还有很多例外 - 在壕沟方面有经验并且善于应用CMMI的人，以及熟悉敏捷的经理人。
谷歌的“敏捷CMMI”，你会得到很多点击。我不想特别推荐一个，因为这是一个持续的辩论（即其中一些人是完全错误的。）
在我看来，进程的概念在分析日常软件开发工作时肯定是一个有用的想法。有一些经常性活动的想法，以及这些活动通常以类似的顺序组织，是提出导致改进的问题的一个很好的切入点。您还可以通过询问什么是可重复以及在什么条件下可以将活动称为托管来获得一些里程。
当神奇的思维开始时，错误和过度开始：“如果我们只是描述（在纸上）完美过程并准确记录，人们将遵循它，我们将获得完美的软件。”它没有那种方式。