扫码阅读
手机扫码阅读
先敏捷再规范
62 2024-10-04
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:先敏捷再规范
文章来源:
麦哲思科技任甲林
扫码关注公众号
文章讨论了在软件开发中先采用敏捷方法再过渡到规范方法的策略。由于直接采纳规范方法可能遇到较大阻力和难以持久的效果,敏捷方法以其短期见效和调整幅度小的特点更易于被开发人员接受。这种策略认为,大多数人关注短期利益,因此过程改进应从满足他们的需求开始。
敏捷方法适应变化,通过即时调整计划来处理近期变化,而不是过多关注未来可能的变化。这种方法虽然减少了文档和管理活动,但并不意味着这些元素的完全缺失。敏捷方法强调面对面的口头交流,并通过迭代方法和强调最终交付物的质量而非中间产物,来保证产品的质量。
在敏捷方法中,角色包括教练、客户和程序员,教练兼具项目经理和过程指导者的角色。尽管敏捷方法减少了管理文档,依然需要进行计划和估算工作量等管理活动,只是形式上更为精简。而对于非必要交付的需求和设计文档,则选择简化,因为它们经常变化,简化可以减少维护工作量。
文章最后提出,高效的个人比规范的过程更重要。一个自我管理的团队,有共同的价值观,能够快速协同合作,即使没有严格的规范也可以成功。敏捷方法体现了实用主义哲学,适用于小规模团队的过程改进。但随着团队规模增长,可能需要回到更加规范的方法。
想要了解更多内容?
查看原文:先敏捷再规范
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
420 篇文章
浏览 79.4K
麦哲思科技任甲林的其他文章
为谁而活
我最近在反思人生存的目的,后来在和朋友的一次聊天中,总结了如下结论,从最根本上来讲,人活着就2个目的: 1 为自己而活。 最常见的是一些社会精英,这一类的人往往高举着为事业而奋斗,为理想而奋斗的旗号,抛家舍业,劳苦工作,其实,他们是为自己而活,是为了让自己快乐而活,实现了自己的价值,他们很高兴,很快乐,古语讲:一将功成万骨枯,得到的是自己快乐,而丧失了其他的很多东西。 2 为孩子而活。 世
Lehman的软件演化定律
自20世纪70年代以来,M. M. Lehman通过对软件系统演化现象的观察,陆续总结了8条定律,称之为定律并非那么严谨,但是对于认识软件维护的规律,改进软件维护的过程具有很好的指导意义。1 (1974年)持续变更定律。系统必须持续调整以适应各种变化,否则这些系统将变得越来越不令人满意。2 (1974年)复杂度增长定律。随着系统的演化,其复杂度会逐渐增加,除非采取措施来降低或保持其复杂度。3 (1974年)自我调整定律。软件演化过程的是自调整的,每次演化版本的度量数据近似正态分布。4 .
风险来源与风险分类的区别与联系
CMMI 1.2的RSKM 过程域的SP1.1为:Determine risk sources and categories,在该实践中明确区分了风险来源与风险分类。确定风险的来源和分类是为了全面、系统地识别潜在风险,合并类似风险的规避措施。风险来源用于在项目或组织内确定风险产生的原因。对项目来讲有许多风险来源,包括内部和外部的。风险来源标识了风险可能发生的常见领域。常见的内部和外部风险来源有:•
TSP中的10个量化法则
TSP(Team software process)是Humphery提倡的解决CMM如何做的一个模型,他认为采用了TSP之后,可以加快企业达到CMMI5级的速度,可以提高企业的质量。在TSP中Humphery提出多项度量数据,我从中整理了如下的10个量化法则和大家分享,其中前5个法则是关于工作量的分布,后5个法则是关于质量的。其实这些法则中具体数值的大小完全可以商榷,但是最关键的是蕴含在这些数值
实例:评审速度与缺陷密度之间的相关性
某公司的项目分为两类:MIS类软件开发与嵌入式软件开发,对这两类项目的需求评审的速率与需求评审发现的缺陷密度分别积累了度量数据,分别见表一和表二,共计52次的需求评审数据。 表一:MIS软件开发项目的需求评审度量数据 表二:嵌入式软件开发项目的需求评审度量数据 对这两类项目的需求评审的速率与缺陷密度分别画散点图如图一和图二所示。 图一:MIS软件开发项目需求评审的缺陷密度
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线