过程改进不能这样啊
发布于 2024-10-04
1122
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
过程改进是一项长期的活动,涉及到公司各层面的参与和认识。公司高层对软件规范管理的认识、负责过程改进人员对规范管理理论的理解、规范体系的推广、开发人员对规范管理的认识,以及管理问题的解决和优化措施的实施,都需要时间来逐步完善。真正实现管理体系的制度化是一个漫长的过程,不可能短时间内完成。
成功和稳定的发展遵循客观规律,忽视这些规律将会导致失败。所有的改进过程都需要时间,并且需要在实践中不断验证和强化,才能最终成为固定的习惯和标准。急功近利的做法最终会导致悲惨的结局。
尽管如此,一些公司和个人仍然选择忽略这一点,原因包括:
- 有足够的资本可以耗费,但这种行为最终会导致资源耗尽。
- 后果尚未显现,正如古人所说:“善有善报,恶有恶报,不是不报,时候未到。”
- 已经意识到了问题的后果,却未能正确分析和找到原因,还有机会改正。
- 虽然对原因和后果看得清楚,但是由于环境或其他因素的限制,感到无可奈何。
- 固有的本性难以改变,对于这种情况,或许已无法挽救。
看到急功近利的公司,作者感到担忧。虽然无法像菩萨那样普度众生,但作者希望能够帮助到一些公司,即使只是一家也好。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 829.7K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
需求与设计人员如何配合工作?
在软件开发的过程中 ,经常出现需求与设计脱节的现象,如设计人员按照自己的理解去设计,没有遵从需求去设计系统;需求人员做完需求定义后,交给设计人员去设计,撒手不管了等等,为了使需求与设计人员更好的协作,建议采取如下的措施:Ø 需求人员与设计人员一定要分离,否则无法解决需求文档化的问题,但是文档并不能解决所有的沟通的问题,还需要面对面的沟通。Ø 需求评审设计人员一定要参加,设计评审需求
COSMIC案例:发票处理功能的规模度量
原始需求描述:1)收费功能,可以选择打印收据、增值税普通发票和增值税专用发票。(1)打印收据:收费时,系统直接打印收据。收费完成后,系统弹出对话框询问客户是否生成电子发票。Ø选择“是”,系统直接生成电子发票并将电子发票信息以短信的形式发送到客户的手机中;Ø选择“否”,则完成收费过程,不生成电子发票。(2)打印增值税普通发票:收费时,系统直接打印增值税普通发票。(3)打印增值税专用发票:收费时,系统直接打印增值税专用发票。梳理后的需求 ...
如何保证测试的完备性?
经验法则如下:1 测试人员参与需求评审,需求人员参与测试用例的评审不懂需求,不了解需求的测试人员是不可能设计出完备的测试用例的。测试人员参与需求评审一是可以评审需求的可测试性,二是了解需求。 需求人员评审测试用例可以检验用例的完备性,判断测试人员是否理解了需求。2 系统测试用例覆盖每一个场景场景是在需求中描述的用户使用系统的一条操作路径。覆盖每个场景是系统测试用例设计的基本要求。3 集成测试用例
迭代总结会议的旁观感想
初创团队,迭代总结会议以后,有哪些可以改进的地方呢?
给程序员的18个忠告
1 想清楚,写清楚,说清楚,才是真正的清楚!2 多花点时间沟通清楚需求,才能把握正确方向!3 修复需求错误的成本是代码错误的几十倍!4 程序员最大的坏习惯就是:急于动手写代码! 5 提高开发效率的捷径:一次做对,不返工!6 写代码之前三件事: 弄清楚做什么; 说清楚怎么做; 想清楚怎么测!7 职业的程序员设计程序,业余的程序员调试程序;8 拷贝粘贴式的作业方式,最容易导入b
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线