协同开发实践概要
协同构建包括结对编程、正式检查、非正式技术复查、文档阅读,以及让其他开发人员共同承担创建代码及其他工作产品责任的技术。
- 协同构建是其他质量保证技术的补充;
- 协同构建有利于传授公司文化以及编程专业知识;
- 集体所有权适用于所有形式的协同构建;
- 在构建前后都应保持协作。
结对编程
成功运用结对编程的关键
- 用编码规范来支持结对编程;
- 不要让结对编程变成旁观;
- 不要强迫在简单的问题上使用结对编程;
- 有规律地对结对人员和分配的工作任务进行轮换;
- 鼓励双方跟上对方的步伐;
- 确认两个人都能看到显示器;
- 不要强迫程序员与自己关系紧张的人配对;
- 避免新手组合;
- 指定一个组长。
- 结对编程的好处
结对编程的好处
- 结对能够使人们在压力之下保持更好的状态;
- 能够改善代码质量;
- 能够缩短时间进度表;
- 传播公司文化,指导初级程序员,培养集体归属感。
核对表:有效的结对编程
- [ ] 是否已经有一个编码规范,以便让程序员始终把精力集中到编程,而不是编码风格的讨论上?
- [ ] 结对的双发是否都积极地参与?
- [ ] 是否避免了滥用结对编程,而是选择那些能够从中获得好处的工作进行结对编程?
- [ ] 是否有规律地对人员和工作任务进行轮换?
- [ ] 结对组合是否在开发速度和个性方面互相匹配?
- [ ] 是否有一个组长专注于项目管理以及与项目外的其他人沟通?
正式检查
虽然任何复查都设计了于都设计或者代码,但是正式检查(详查)还在几个关键问题上与普通复查有所区别。
- 详查表关注的是复查者过去所遇到的问题;
- 详查专注于缺陷的检测,而非修正;
- 复查人员腰围详查会议做好预先准备,并且带来一份他们所发现的已知问题列表;
- 参与者都被赋予了明确的角色;
- 详查的主持人不是被检查产品的作者;
- 详查的主持人应该已经接受过主持详查会议方面的培训;
- 只有在与会者都做好充分准备之后才会召开详查会议;
- 每次详查所收集的数据都会被应用到以后的详查中,以便对详查进行改进;
- 高层人员不参加详查会议,除非你们正在详查一个项目的计划,或者其他管理方面的资料,但技术负责人可能参加。
详查的一般步骤
- 计划;
- 概述;
- 准备;
- 详查会议;
- 相差报告;
- 返工;
- 跟进;
- 第三个小时的会议。
核对表:有效的详查
- [ ] 你是否有一个核对表,能让评论员将注意力集中于曾经发生过问题的领域?
- [ ] 你是否专注于找出错误,而不是修正他们?
- [ ] 你是否考虑制定某些视角或者场景,以帮助评论员在准备工作的时候集中注意力?
- [ ] 你是否给与评论员足够的时间在详查会议之前进行准备,是否每一个人都做了准备?
- [ ] 是否每一个参与者都扮演一个明确的角色——主持人、评论员及记录员等?
- [ ] 会议是否以某种高校的速度进行?
- [ ] 会议是否限制在两个小时以内?
- [ ] 是否所有相差会议的参与者都接受了如何进行详查的针对性培训,是否主持人接受了有关主持技巧方面的针对性培训?
- [ ] 是否将每次详查所发现的错误数据都收集起来,使你能调整本组织以后使用的核对表?
- [ ] 是否收集了准备速度和详查速度方面的数据,以便你去优化以后的准备和详查工作?
- [ ] 是否每次详查中被指派下去的活动都被正确跟进了,无论是通过主持人自己还是一词重新详查?
- [ ] 管理层是否理解他们不应参与详查会议?
- [ ] 是否有一个用于保证修正正确性的跟进计划?
其它类型的协同开发实践
- 走查;
- 代码阅读;
- 公开演示;
要点
- 协同开发时间往往能比测试发现跟多缺陷,并且更有效率;
- 协同开发实践所发现错误的类型通常跟测试所发现的不同,这意味着你需要同时使用详查和测试保证你软件的额质量;
- 正式检查通过运用核对表、准备工作、明确定义的角色以及对方法的持续改善,将缺陷侦测的效率提升至最高;
- 通常,结对编程拥有和详查相同的成本,并且能产生质量相当的代码;
- 正式检查可以应用咋出代码之外的很多工作成果上,例如需求、设计以及测试用例等;
- 走查和代码阅读是详查的替代方案。代码阅读更富有弹性,能有效地利用每个人的时间。
原文地址:https://www.cnblogs.com/liam-ji/p/11562955.html
时间: 2024-10-15 17:27:16