ITIL或CMMI对开发的影响是什么？

我阅读了很多关于哪些实践在软件开发中运行良好的书籍.我从来没有在开发领域的任何网络广播或书籍或博客中听到像ITIL或CMMI这样的方法.

我在学校里听说过这些方法,而对我而言似乎是官僚主义的做法.

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

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

ITIL更侧重于基础架构和支持方面,而不是开发,因此对ITIL的讨论可能更适合于可能正在开发的StackOverflow的"IT"聚焦版本.顺便说一句,我认为其他网站"IT"的重点是IT,因为IT包含大多数企业的基础架构,支持和开发......可能有很大一部分StackOverflow用户是IT部门的开发人员.

我曾与CMMI和团队软件过程(TSP)合作,这两个产品都是Watts Humphrey和Carnegie Mellon软件工程研究所的产品.如果您致力于持续改进并相信测量是任​​何持续改进的核心,那么您将在CMMI中找到价值.

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

重点关注时间跟踪(时钟打孔),缺陷跟踪(错误配额),代码行(如果你倾向于"游戏"的很多方法),并使你的过程可重复(使开发人员感觉像一个没有的齿轮创新的自由)关闭了许多开发人员.< - 注意括号中的jaded反驳参数.

事实上,90%的开发人员(其中很少有人阅读StackOverflow或任何技术博客/网站)都是从时髦的角度拍摄的,他们非常缺乏自我意识到改善的机会.对他们来说,过程严谨和机会,使通过自我意识的质量增量改进,重复和测量方便是CMMI的宝贵组件.

如果做得好,您可以从像Scrum这样的敏捷方法中获得相同的好处,重点在于可重复的迭代,从每次迭代中学习,以及改进/缩小目标.领导团队采用敏捷方法或CMMI并从中获取全部价值需要大量的成熟度和经验.

敏捷是性感的,CMMI与你能得到的性感差不多,这就是为什么你没有那么多听到它.