扫码阅读
手机扫码阅读
多团队协同开发的18条实践
20 2024-10-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:多团队协同开发的18条实践
文章来源:
麦哲思科技任甲林
扫码关注公众号
项目协同开发面临着多团队合作的挑战,以下是一些提高协同开发效率的实践建议:
- 确立共同的目标和愿景以确保所有团队朝同一方向努力。
- 技术解耦,根据业务功能进行分工,每个团队尽可能独立地工作。
- 进行系统功能和数据处理的交底和评审,以减少接口遗漏。
- 跨团队进行接口需求和设计的技术交底。
- 计划排期时预留协同缓冲时间,以应对突发的协同任务。
- 在计划中安排联调同步的时间节点。
- 优先开发和测试接口功能。
- 通过数据共享而非消息传递的方式实现接口衔接。
- 指定唯一的接口变更负责人,所有变更通过此人进行。
- 接口定义要文档化、通过工具共享,并记录所有变更通知所有成员。
- 定义统一的架构模式、编码规范及界面风格。
- 定期同步各小组进展,并保持透明。
- 建立团队协同看板,可视化进展和协同障碍。
- 定期反思和改进协同方式。
- 通过团队快乐指数监测团队士气。
- 建立接口管理平台。
- 实现接口测试自动化。
- 复用需求构件化,以促进效率。
这些实践能帮助团队识别障碍、发现新的依赖关系和管理接口变更,从而提高多团队间的协同开发效率。
想要了解更多内容?
查看原文:多团队协同开发的18条实践
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
420 篇文章
浏览 63.3K
麦哲思科技任甲林的其他文章
需求变更对软件质量的影响
根据我们的经验,需求变更越多,造成的软件修改越多,bug也就会越多,事实是否如此呢?需要我们根据历史的数据进行检验。某企业采集了历史上多个项目的的需求变更次数、交付代码的规模、软件测试发现的缺陷个数,参见下表,基于这些历史数据我们分析一下,看看我们的经验结论是否成立。表一:需求变更的历史数据 ID 需求变更数 代码规模LOC 总缺陷数 测试缺陷密度bugs/KLOC
快速学习COSMIC方法之四:早期快速估算功能规模的方法
在介绍详细的COSMIC方法之前,我们先介绍一下在项目早期,在需求没有详细到可测试的程度时,如何估算软件的规模。实际上很多公司为了减少度量的工作量,往往采用近似的估算方法进行确定项目的预算。 进行快速估算的原理为:通过分析历史的粗颗粒度需求与实际规模之间的相关关系,找到二者之间的换算关系,然后对于新的粗颗粒度需求参考历史的换算关系快速地得到近似规模。这里的粗颗粒度需求的规模可以是功能处理个数
TSP中的10个量化法则
TSP(Team software process)是Humphery提倡的解决CMM如何做的一个模型,他认为采用了TSP之后,可以加快企业达到CMMI5级的速度,可以提高企业的质量。在TSP中Humphery提出多项度量数据,我从中整理了如下的10个量化法则和大家分享,其中前5个法则是关于工作量的分布,后5个法则是关于质量的。其实这些法则中具体数值的大小完全可以商榷,但是最关键的是蕴含在这些数值
白话透解验收标准(AC)与完成标准(DoD)的区别
Accept criteria 与 Definition of Done是敏捷开发中的两个概念,容易混淆。AC是针对每个需求定义的。DoD是针对所有需求,任务,迭代,交付定义的。打个比方解释二者的区别:需求1:晚饭吃饱。验收标准AC: 1 牛肉+蔬菜+啤酒; 2 18点到19点之间完成。需求2:午饭吃饱。验收标准AC: ...
过程描述的方法
图片: 图片: 在CMMI模型中提供了一种描述过程元素的方法,包含了12个要素:• 过程角色(Process roles):哪些角色参与本过程的哪些活动,可以用角色-职责矩阵表示• 适用的过程和产品标准(Applicable process and product standards),包括企业内的或者企业外的• 适用的规程、方法、工具和资源(Applicable procedures, meth
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线