47、软件开发中的缺陷处理与沟通协作

软件开发中的缺陷处理与沟通协作

一、缺陷处理策略

1.1 开发中修复缺陷

在开发过程中及时修复缺陷，能够减少后续流程中缺陷的出现。团队的开发速度可以包含修复缺陷的时间。随着时间推移，团队成员会了解到为一个故事修复测试人员发现的缺陷所需的时间。对于新的敏捷团队，开发阶段可能会遗留较多缺陷，但随着团队对工具和流程的熟悉，发现的缺陷数量会逐渐减少。一开始，可以为每个故事预留两小时或半天来修复相关缺陷。

1.2 不同的缺陷处理方式

• 稍后修复 ：一些团队认为，所有发现的缺陷都应先由客户确定优先级，再列入修复列表。他们觉得是否为真正的缺陷以及是否需要修复，完全由客户决定。
• 永不修复 ：团队识别出某个缺陷，但知道不会去修复它。可能是该部分代码后续需要彻底重写，因为功能会发生变化；也可能是该问题优先级极低或非常隐蔽，客户可能永远不会发现。如果经过评估确定是这种情况，建议直接关闭该缺陷，不要虚挂着，假装以后会修复。

1.3 记录缺陷的媒介选择

媒介类型	使用场景	优点	缺点
索引卡	- 有纪律的敏捷团队，在迭代内修复所有缺陷 - 希望让团队成员看到缺陷情况	- 贴在故事板上能直观展示未解决的问题，尤其是不同颜色的卡片 - 实体卡片更具存在感	- 记录详细信息的空间有限
缺陷跟踪系统（DTS）	- 团队分布分散 - 需要为审计目的跟踪缺陷或在发布说明中记录缺陷 - 有迭代中遗留的缺陷，需要后续修复 - 遗留系统存在大量缺陷	- 便于跟踪和管理缺陷	- 可能导致重要信息在项目中丢失，只看到数字而缺乏直观感受
不记录	团队有纪律，为每个发现的缺陷编写测试	- 测试能捕捉缺陷，无需额外记录	- 并非所有测试都易于自动化

1.4 处理缺陷的替代方法和建议

• 制定规则 ：例如设定“粉色卡片（代表缺陷）的数量任何时候都不应超过十张”的规则。每次团队回顾时重新审视这些规则。如果缺陷率下降，无需担心；如果趋势相反，则需分析缺陷的根本原因，并制定新规则来缓解问题。
• 修复所有缺陷 ：不要忘记修复迭代中发现的低优先级缺陷，因为它们会影响未来的开发。经验表明，“低优先级”和“快速修复”之间似乎有很强的相关性，建议在小的、孤立的缺陷演变成大的、复杂的问题之前解决它们。
• 合并缺陷 ：如果在一个区域发现大量缺陷，可以考虑将它们合并为一个增强功能或故事。例如，有人在 WestJet 移动应用中发现很多小问题，团队将这些问题归为一个新故事进行研究，最终得到了一个完善的功能。
• 将缺陷视为故事 ：如果一个“缺陷”实际上是缺失的功能，可以为其编写卡片并安排为一个故事。这些故事和其他故事一样进行估算和优先级排序，但要注意，缺陷故事可能不如产品待办事项列表中的新用户故事受关注，而且创建、排序和安排这些故事也需要时间。

1.5 隐藏的待办事项

缺陷报告描述的是软件的错误行为，而每个错误行为背后都有一个期望的行为，这可能对应着一个隐藏的用户故事。传统的缺陷跟踪系统可能是一个隐藏的待办事项列表。可以通过编写自动化测试来替代单独的缺陷报告，这样既能避免重复工作，又能在回顾时提供有用信息。例如，在一个项目中，通过将探索性测试的输出作为自动化测试而不是缺陷报告来处理，最终没有使用缺陷跟踪系统。

1.6 贴纸标记法

曾经有团队在处理遗留系统的大量缺陷时，开发人员拒绝使用缺陷跟踪系统，而测试人员又需要记录缺陷。团队达成了一个折中的方案：在与程序员配对测试时发现的缺陷当场修复，不记录；其他缺陷记录在 DTS 中。需要在当前迭代修复的缺陷记录在粉色卡片上，贴在故事板上。程序员修复缺陷后，在卡片背面记录修复情况，并贴上不同颜色的贴纸：蓝色表示准备好测试，绿色表示已验证修复，红色表示未修复需要更多工作。这种方法提高了缺陷的可见性，便于团队沟通和管理。

1.7 从简开始

建议尽可能使用简单的系统，根据需要增加复杂性。测试优先开发的代码在提交时通常缺陷较少。如果在新代码中发现大量缺陷，团队需要找出原因并采取行动，如缩短编码、集成和测试的周期，对有问题的遗留代码进行重新设计，或与业务专家更紧密合作以理解期望的功能。

graph LR
    A[发现缺陷] --> B{处理方式}
    B -->|开发中修复| C[修复缺陷]
    B -->|稍后修复| D[客户确定优先级后修复]
    B -->|永不修复| E[关闭缺陷]
    C --> F{记录方式}
    F -->|索引卡| G[贴在故事板展示]
    F -->|缺陷跟踪系统| H[系统跟踪管理]
    F -->|不记录| I[通过测试捕捉]

二、促进沟通协作

2.1 每日站会的作用

每日站会有助于团队保持紧密沟通。团队成员可以了解任务和故事的当前状态，互相帮助解决障碍。在站会上，程序员对工作任务的描述可能会暴露出他们对客户需求的误解，这就需要在站会后进行小组讨论。测试人员遇到测试问题时，也可以在站会后请求团队讨论。站会还能及时发现遗漏的任务，并当场编写新卡片。同时，站会是查看进度的好时机，可以使用故事板、燃尽图等大型可视化图表来保持专注，了解项目状态。如果迭代接近尾声，某个故事的编码工作停滞不前，应及时发出警示，寻求团队帮助。

2.2 测试人员促进沟通

测试人员可以确保团队成员之间充分沟通，推动迭代顺利进行。当程序员开始处理一个故事时，测试人员要与他们沟通，确保他们理解需求。即使程序员对业务和故事有较好的理解，开发过程中也难免会有问题。最好有客户直接解答问题，但有时业务专家难以解释清楚需求，或者程序员理解有误，此时测试人员可以帮助客户和程序员找到共同语言。促进沟通的方式包括在白板上画图、模拟界面、列出可能受影响的其他区域或通过实际例子进行说明。当沟通陷入僵局或混乱时，提出新的例子并聚焦于此。

2.3 友好竞争促进沟通

曾经有团队遇到开发人员与业务人员沟通不畅，测试人员也容易被排除在沟通之外的问题。项目经理想出了一个办法，给开发人员蓝色扑克筹码（标有“D”），测试人员红色筹码（标有“T”），业务人员黄色筹码（标有“B”）。当不同角色的人见面交流时，可以互相交换筹码，目标是收集到最完整的“T - B - D”组合。获胜者会得到一个定制的奖杯。最终，大家为了获得更多筹码，更积极地与他人交流。这说明可以通过创造性的方式让业务专家和程序员就需求进行沟通和达成一致。

graph LR
    A[每日站会] --> B[了解任务状态]
    A --> C[发现需求误解]
    A --> D[发现遗漏任务]
    B --> E[互相帮助解决障碍]
    C --> F[站会后小组讨论]
    D --> G[当场编写新卡片]
    H[测试人员] --> I[与程序员沟通需求]
    I --> J[帮助客户和程序员沟通]
    K[友好竞争] --> L[促进不同角色交流]

在软件开发过程中，合理的缺陷处理策略和良好的沟通协作机制是确保项目顺利进行、提高软件质量的关键。团队应根据自身情况选择合适的方法，并不断优化和改进。

三、持续优化与改进

3.1 迭代回顾的重要性

迭代回顾是团队持续优化的重要环节。在回顾中，团队可以重新审视之前制定的规则，如粉色卡片数量的限制。根据缺陷率的变化趋势，决定是否需要调整规则。如果缺陷率下降，说明当前的策略和流程有效，可以继续保持；如果缺陷率上升，则需要深入分析根本原因。例如，可能是需求理解不准确、编码规范执行不到位或者测试覆盖不全面等。通过迭代回顾，团队可以总结经验教训，为后续的迭代提供改进方向。

3.2 持续改进的具体措施

• 优化流程 ：根据迭代回顾的结果，对开发、测试和缺陷处理流程进行优化。例如，如果发现缺陷在不同阶段的流转效率低下，可以简化流程，减少不必要的环节。
• 加强培训 ：如果发现团队成员在某些技术或业务方面存在不足，可以组织相关的培训。比如，程序员对新的编码规范不熟悉，就可以开展专门的培训课程。
• 引入新技术 ：随着技术的不断发展，适时引入新的工具和技术可以提高开发效率和软件质量。例如，采用更先进的自动化测试框架，提高测试的覆盖率和准确性。

3.3 建立反馈机制

建立有效的反馈机制可以让团队成员及时了解项目的状态和问题。除了每日站会和迭代回顾，还可以设置定期的项目进度汇报、问题反馈渠道等。例如，团队成员可以通过在线文档随时记录遇到的问题和建议，供大家讨论和解决。

优化措施	具体内容
优化流程	简化缺陷流转环节，提高效率
加强培训	针对技术和业务不足开展培训
引入新技术	采用先进的自动化测试框架等
建立反馈机制	定期汇报、设置问题反馈渠道

graph LR
    A[迭代回顾] --> B{缺陷率变化}
    B -->|下降| C[保持当前策略]
    B -->|上升| D[分析根本原因]
    D --> E[优化流程]
    D --> F[加强培训]
    D --> G[引入新技术]
    A --> H[建立反馈机制]
    E --> I[持续改进]
    F --> I
    G --> I
    H --> I

四、案例分析与总结

4.1 案例分析

通过前面提到的几个案例，我们可以看到不同团队在缺陷处理和沟通协作方面的成功经验。例如，WestJet 团队将移动应用中的小问题合并为一个新故事，最终得到了完善的功能；某个团队通过贴纸标记法提高了缺陷的可见性和管理效率；还有团队通过友好竞争的方式解决了沟通不畅的问题。这些案例都表明，团队需要根据自身的实际情况，灵活运用各种方法和策略。

4.2 总结

在软件开发中，缺陷处理和沟通协作是相辅相成的。合理的缺陷处理策略可以减少软件中的缺陷，提高软件质量；而良好的沟通协作机制可以确保团队成员之间信息畅通，及时解决问题。团队应该从以下几个方面入手：
- 选择合适的缺陷处理方式 ：根据项目的特点和团队的实际情况，选择索引卡、缺陷跟踪系统或不记录等方式来处理缺陷。
- 加强沟通协作 ：利用每日站会、测试人员的协调等方式，促进团队成员之间的沟通和合作。
- 持续优化改进 ：通过迭代回顾、优化流程、加强培训等措施，不断提高团队的开发能力和软件质量。

要点	具体内容
缺陷处理	选择合适的记录媒介，如索引卡、DTS 等
沟通协作	每日站会、测试人员促进沟通、友好竞争等
持续优化	迭代回顾、优化流程、加强培训、引入新技术

总之，软件开发是一个复杂的过程，需要团队成员共同努力，不断探索和实践，才能找到最适合自己的方法，提高软件的质量和开发效率。希望以上的内容能为软件开发团队提供一些有益的参考和启示。