扫码阅读
手机扫码阅读
多团队协同开发的18条实践

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

项目协同开发面临着多团队合作的挑战,以下是一些提高协同开发效率的实践建议:
- 确立共同的目标和愿景以确保所有团队朝同一方向努力。
- 技术解耦,根据业务功能进行分工,每个团队尽可能独立地工作。
- 进行系统功能和数据处理的交底和评审,以减少接口遗漏。
- 跨团队进行接口需求和设计的技术交底。
- 计划排期时预留协同缓冲时间,以应对突发的协同任务。
- 在计划中安排联调同步的时间节点。
- 优先开发和测试接口功能。
- 通过数据共享而非消息传递的方式实现接口衔接。
- 指定唯一的接口变更负责人,所有变更通过此人进行。
- 接口定义要文档化、通过工具共享,并记录所有变更通知所有成员。
- 定义统一的架构模式、编码规范及界面风格。
- 定期同步各小组进展,并保持透明。
- 建立团队协同看板,可视化进展和协同障碍。
- 定期反思和改进协同方式。
- 通过团队快乐指数监测团队士气。
- 建立接口管理平台。
- 实现接口测试自动化。
- 复用需求构件化,以促进效率。
这些实践能帮助团队识别障碍、发现新的依赖关系和管理接口变更,从而提高多团队间的协同开发效率。
想要了解更多内容?


麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 216.2K
麦哲思科技任甲林的其他文章
案例:如何评价代码走查的效果?
实施了代码走查,效果如何呢?我们可以通过定量的数据进行分析!数据中隐藏着结论,我们要努力发现它!
敏捷方法中采集的度量数据
在敏捷方法中,要求度量的数据少之又少,可谓简单实用:规模:(1)故事点:用以估算工作量、度量开发效率。工作量: (2) 计划的工作量:用以排定项目计划。 (3) 剩余任务的计划工作量:用以跟踪项目进展。效率:(4)开发速度:每次迭代完成的需求的规模(如故事点),用以估算项目需要的迭代次数。其他度量元根据项目组的实际情况,可以由项目组自己定义。
再论:是否一定要做规模估计?
举个例子: 2009年1月1日,张三站在你面前,让你估计体重,你已知的确切信息是:张三是男士。根据你面前张三的形象,你估计其身高约在1米七五,看上去张三有点胖,比较结实,因此你估计张三的体重为75公斤。估计体重是你的目标,在估体重之前,实际上你先估计了张三的身高、胖瘦程度、结实程度。 2009年2月1日,你又见到了张三,让你再次估计体重,同样你已知的确切信息是:张三是男士。根据你面前张三的
软件开发的质量红线
质量红线是我的一个客户提出的概念,即质量管理的底线、最低要求、最低标准,无论在什么情况下,项目都不能违背这个底线,比如项目组在进行多快好省四个要素平衡时,无论如何平衡,都不能违背质量的最低要求。我认为这个名词很直观形象,因此借用一下。 在定义质量红线时应该从质量的投入与质量的产出两个方面进行定义。 质量的投入如: 评审投入的工作量;
杂谈Barry Boehm的软件工程七原则与敏捷实践
大概在5年以前曾经从网上搜到了Barry Boehm提出的软件工程的七原则(Seven Basic Principles of Software Engineering),这是Barry Boehm1983年发表的文章,在网上搜到的是别人对这七个原则的转译与介绍,看后觉得怪怪的,总是觉得有些地方不能准确把握这七个原则的含义。于是去google搜其原文,未果,最近终于搜到了原文,因此更能准确把握Ba
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线