ITIL或CMMI对开发有什么影响?[闭门]

ITIL更侧重于基础设施和支持方面,而不是开发方面,因此对ITIL的讨论可能更适合于开发中的以“IT”为重点的StackOverflow版本。顺便说一句,我不同意将另一个网站称为“IT”网站,因为它涵盖了大多数企业的基础设施、支持和开发……可能大部分StackOverflow用户都是IT部门的开发人员。

专注于时间跟踪(打卡)、缺陷跟踪(bug配额)、代码行(如果你愿意的话,有很多“游戏”的方式),以及让你的过程可重复(让开发人员感觉自己像一个没有创新自由的齿轮)让许多开发人员望而却步<——请注意括号中的厌倦的反参数。

事实仍然是,90%的开发人员(很少有人阅读StackOverflow或任何技术博客/网站)都是即兴创作的,他们严重缺乏自我意识,不知道改进的机会在哪里。对他们来说,过程的严格性和通过重复和测量促进的自我意识在质量上进行增量改进的机会是CMMI的重要组成部分。

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

敏捷是性感的,而CMMI离你能得到的性感还差得很远,这就是为什么你不常听说它的原因。

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

这并不意味着一个是好的,另一个是坏的;这主要影响描述每种方法的语言。也有很多例外——有经验的人擅长应用CMMI,而管理者擅长敏捷。

谷歌搜索“敏捷CMMI”,你会得到很多点击。我不想特别推荐一个,因为这是一个正在进行的辩论(也就是说,有些人完全错了)。

在分析日常软件开发工作时,这无疑是一个有用的想法。有一些重复性的活动,这些活动通常以类似的顺序组织,这是提出问题的一个很好的切入点,可以带来改进。你也可以通过询问什么是里程数来获得一些里程数 在什么条件下可以称为活动 管理

错误和过度始于神奇的思维:“如果我们只是描述(在纸上)完美的过程并准确地记录下来,人们就会遵循它,我们就会得到完美的软件。”这种方式行不通。