对软件开发过程可重复性的思考
发布于 2024-10-04
1977
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
硬件生产过程的重复性高,因为其产品功能和质量要求、生产设备、生产流程都是标准化的。硬件的生产力主要来自设备,因此其生产能力要求稳定且精确。相比之下,软件生产过程的重复性较弱,因为每个软件项目的需求、开发团队的经验和人数、开发方法和流程以及外部干扰都是不同的,软件的生产力依赖于人的能力。
硬件与软件生产过程的比较:
- 在硬件生产中,虽然人对生产质量有所影响,但更核心的是设备;而在软件生产中,人是核心的生产力。
- 硬件的原材料是有形的、易于控制差异性的物料;软件的原材料是需求,需求是抽象的,每个项目都不同。
- 硬件生产过程和方法标准化;软件开发过程和方法因需求和项目特点的不同而变化。
- 硬件生产环境相对稳定;软件开发容易受到外部干扰,工作可能被打断。
软件过程管理的思考:
- 我们需要考虑软件过程管理中可借鉴硬件生产过程的部分,思考哪些过程的可重复性类似于硬件生产。
- 探讨微观和宏观层面的相似性,以及不相似时的变通方法。
- 考虑使用SPC(统计过程控制)来管理稳定性高的过程,同时寻找方法来管理稳定性差的过程。
- 探讨降低Cpk(过程能力指数)目标值是否足以借鉴硬件的开发过程,或是否需要新的方法。
- 反思软件过程的可重复性是否直接影响开发能力的稳定性,及如何预测项目目标的达成。
- 讨论如果软件过程不可重复,软件管理是否就成为艺术,软件产品是否也成为艺术品。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 942.4K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
为什么高成熟度的实施周期比较长?
很多软件公司在实施完成CMMI3级后,考虑实施CMMI4级或5级,在制定最初的改进计划时往往对实施高成熟度的难度估计不足,制定了很乐观的改进计划,改进的周期比较短。当领导基于乐观的估计拍板后,就很难真正地在实施高成熟度时见到实效了。如果要对实施CMMI高成熟度进行一个合理的工期估算,首先就要对CMMI的高成熟度是什么有一个清晰的、正确的理解。本文试图通过类比的方式,通俗地说明高成熟度是什么,高成熟
QA例会的6个问题
QA人员在工作中要按照质量保证的流程进行工作,QA的主管要对QA的工作进行检查,如何检查呢?参考每日站立会议的方法,我认为无论是周例会还是月例会,在每次的QA例会上,建议每个QA都要回答清楚如下的6个问题: 1 本期检查了什么? 2 该检查未检查的过程或活动有哪些? 3 查出来了哪些不符合问题(NC)? 4 该解决未解决的NC有哪些? 5 后续的解决或改进措施有哪些?
如何选择度量元
选择度量元的5个原则 在设计度量体系时,要针对度量目标选择合适的度量元,同一个度量目标可以有多个度量元,究竟要如何选择合适的度量元呢,我们可以参考如下的5个原则进行选择: 原则1:对度量目标的表达能力,即度量元是否准确刻画了度量目标以及要解决的问题?比如,想要监督项目的进展,我们有如下三个选择: 1) 需求完成的百分比; 2) 活动完成的百分比; 3) 已完成活动的计划工作量/所有活动...
各阶段缺陷检出密度的统计分析案例
某企业积累了10个项目的历史度量数据,积累了5个阶段的缺陷密度,即从需求评审的缺陷密度,直至交付后3个月内的缺陷密度,计量单位统一为缺陷数/KLOC。 需求评审缺陷密度 设计评审缺陷密度 代码评审缺陷密度 测试发现缺陷密度 交付后缺陷密度 P1 ...
敏捷的过程改进方法:从经验教训中学习
每次去客户现场做差距分析或者运行检查,总是习惯于找他们的缺点,但是每次也总能从客户那里发现他们的优点,时间久了,慢慢地对缺陷麻木了,审丑疲劳了,只有发现他们的优点时,我才会精神一振,心情愉快。 今年1-2月份期间我去给一个客户做运行检查,整理完发现报告后,我查阅了那6个项目组的阶段总结报告与项目总结报告中的经验教训部分,我发现的60%的缺陷他们自己也感觉到了,只是没有人去提取、去系统的归纳整理、
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线