48、软件开发中的沟通、测试与迭代指标管理

软件开发中的沟通、测试与迭代指标管理

1. 促进沟通

有效的沟通是项目成功的关键，尤其是对于分布在不同地理位置的团队。以下是一些促进沟通的方法和案例：
- 通过实例理解系统 ：在迭代开始时，团队可以通过多个实例来深入理解系统的各个方面。例如，测试人员 Mike 邀请产品负责人一起研究一个新实例，程序员和测试人员共同参与，经过数小时在白板上书写数字和绘制流程图，最终得出正确公式，确保大家达成共识。如果某种沟通方式（如白板绘图）效果不佳，可以尝试其他形式，如电子表格，以帮助业务专家更好地理解。
- 分布式团队的沟通挑战与解决方案 ：分布在不同地点和时区的团队需要付出更多努力来保持沟通。基本的沟通方式包括电话、电子邮件和即时通讯，但也应不断探索更好的协作工具。例如，团队中的程序员兼经理 Nanda 搬到印度后，他晚上工作，以便在丹佛团队的早上时段保持在线。他使用带有丹佛本地号码的手机，方便通过电话、即时通讯和电子邮件交流。团队会在早上安排会议，讨论故事估算、头脑风暴和迭代计划等，确保 Nanda 能够参与。尽管团队的生产力可能不如集中办公时高，但仍能受益于他的领域专业知识和软件知识。如果 Nanda 在印度招聘更多团队成员，可能需要解决更复杂的问题，如集成和构建的协调，并考虑采用更先进的技术解决方案。
- 远程测试人员的沟通实践 ：有时，测试人员可能是远程团队成员。例如，iLevel by Weyerhaeuser 的 Erika Boyer 住在东海岸，与丹佛的团队合作。她可以承担各种任务，如编写自动化测试的夹具或与程序员合作编写生产代码。为了与团队成员保持联系，她在即时通讯无响应时会打电话，因为丹佛办公室的每个工作区域都配备了电话。由于 Erika 比团队的每日站会提前工作几个小时，她会在这段时间独自完成一些工作，并与早到的团队成员合作，在当天晚些时候与其他程序员交流次日的工作计划。通过团队内部网的工具，她可以查看团队任务的状态和完成百分比。尽管身处异地，Erika 能够将测试技能传授给程序员，并发现他们的思维方式与测试人员不同。团队通过任务轮换充分利用这些不同的视角。

2. 回归测试

回归测试是确保软件质量的重要环节，以下是回归测试的相关要点：
- 自动化回归测试的重要性 ：除了刚开始进行自动化测试的团队，通常应具备覆盖先前迭代故事的自动化回归测试。这些测试应作为持续构建过程的一部分运行，至少应包含在每日构建中。如果尚未实现，团队应将此关键基础设施的实施列为优先事项，并共同探讨实现方法，计划在下一次迭代中启动构建过程。
- 保持构建“绿色” ：程序员在提交新代码前应运行所有自动化单元测试。但在持续构建中，单元测试可能会失败，原因可能是有人忘记在提交前运行测试，或者运行时环境或 IDE 存在差异。一旦单元测试失败，团队的首要任务（除了严重的生产问题）应是修复测试并恢复构建。不同团队采用不同方法确保构建保持“绿色”，例如：
- 邮件通知 ：Lisa 的团队在每次构建后通过邮件发送结果，构建失败时，提交失败代码的人通常会立即修复。
- 可视化提醒 ：ScrumMaster 会在“破坏构建”的人的桌子上放置一个填充玩具，作为需要立即修复的视觉提醒。
- 电子监控工具 ：一些团队使用交通灯、环境球、GUI 构建监控工具或其他电子可视化方式显示构建状态。当指示灯变红时，应停止新开发工作，优先修复构建。
- IDE 弹窗提醒 ：通过在每个人的 IDE 中弹出屏幕提示构建失败，直到点击“确定，我将修复构建”才会消失。在极端情况下，可能需要暂时注释掉失败的测试，但这对新手团队来说是危险的做法。必要时，团队成员应停止手头工作，直到构建恢复正常。
- 保持构建快速 ：构建过程应提供即时反馈，因此要尽量缩短时间。如果构建时间超过代码提交的平均频率，会导致构建积压，测试人员无法及时获取代码进行测试。XP 指南建议构建时间控制在 10 分钟以内，Lisa 的团队由于频繁提交代码，目标是将构建时间控制在 8 分钟以内。对于耗时较长的测试，如更新数据库的测试、单元级别以上的功能测试或 GUI 测试脚本，应在单独的构建过程中运行。如果硬件资源有限，团队可以在夜间运行包含完整测试套件的“完整”构建，在工作时间持续运行仅包含单元测试的“持续”构建。拥有一个独立的、持续运行的“完整”构建，包含所有回归测试套件是值得的投资。例如，Lisa 的团队每 90 分钟从“完整”构建中获得反馈，这在预防回归问题方面非常有价值。这个二级测试套件不会阻止程序员提交代码。
- 构建回归套件 ：在迭代过程中，自动化新测试并在通过后将其添加到回归套件中。不需要将每个边缘情况或排列组合都包含在回归套件中，应确保回归套件足够快速，以提供及时反馈。每个故事完成后，确认其功能的测试应包含在回归套件中，并成为常规构建周期的一部分。回归测试本身应进行版本控制，最好与生产代码存储在同一源代码控制系统中，这样在为生产版本标记代码时，标记也包含了与该代码匹配的所有测试版本。至少应每天备份测试代码。添加到回归套件后，测试的目的发生变化，不再用于驱动开发，而是检测系统中的意外更改或副作用。
- 检查“大局” ：除了自动化回归测试，还应编写任务卡，在更大的应用程序上下文中测试故事，并对系统的其他部分进行回归测试，以确保新故事不会产生负面影响。有时，即使有大量回归测试，手动探索性测试也是必要的。只有完成这些任务，故事才能被视为“完成”。

3. 资源准备

在迭代开始时，确保测试环境、测试数据和测试工具就绪，以满足本次迭代故事的测试需求。尽管可能已经提前预估了这些需求，但有些要求可能在开始处理故事时才会变得明显。团队应与数据库专家、系统管理员和其他成员合作，建立所需的额外基础设施。此外，如果引入外部资源进行性能、可用性、安全性等方面的测试，应让他们参与每日站会和与客户的讨论，并与他们合作，帮助他们理解团队的目标，同时这也是学习新技能的机会。

4. 迭代指标

迭代指标对于理解编码和测试活动的进展至关重要。在开始测量数据点和分析结果之前，应明确要解决的问题。以下是一些常见的迭代指标：
- 测量进度 ：团队需要了解在迭代的任何时间点已完成的工作量和剩余工作量，以及何时需要制定备用计划。常用的测量方法包括迭代燃尽图和任务的估计时间与实际时间对比，但这些方法对不同团队的价值可能不同。故事或任务板是一种直观的方式来了解迭代状态，特别是使用颜色编码时。如果太多测试任务卡仍在“待办”列，或者编码任务卡移动到“已完成”或“已测试”列的数量不足，团队应考虑采取措施确保所有测试完成。例如，一些团队成员可能需要停止编码，开始承担测试任务，或者将某个故事或不太关键的部分推迟到下一次迭代。虚拟和物理故事板都可以实现这一目的，通过创造性的视觉效果使问题一目了然。需要注意的是，只有在所有适当级别的测试完成后，故事才能被视为“完成”。即使团队不跟踪任务级别的燃尽情况，也可以在故事级别进行跟踪。了解团队每次迭代的工作量（速度）有助于制定整体发布计划和每次迭代的优先级调整。如果故事规模大致相同，了解每次迭代完成的故事数量可能就足够了。尽管计划具有一定的不确定性，但了解在特定发布日期前可以完成多少故事或下一季度可能完成哪些故事仍然是有帮助的。
- 缺陷指标 ：收集缺陷指标可能非常耗时，因此在开始测量之前应明确目标。例如，缺陷遏制是一个常见的指标，但在敏捷开发中，由于整个团队共同负责质量，且工作过程相互交织，很难确定缺陷是何时引入系统的。因此，在敏捷开发中，这种指标可能并非必要。然而，如果发现大量缺陷漏检，可能需要跟踪缺陷类型，以解决根本原因。例如，如果某些缺陷可以通过单元测试发现，可能需要为程序员提供更多编写单元测试的培训；如果是需求遗漏或误解导致的缺陷，可能需要在迭代计划中投入更多时间或完善验收测试。如果团队实行零缺陷容忍政策，可能不需要在编码和测试期间跟踪缺陷，故事板上的简单卡片即可提供所需信息。选择测量的指标应尽量简单。例如，一个组织跟踪了多个版本中 DTS 记录的缺陷数量，通过图表展示了一年半的趋势。开始时，发布到 QA 进行最终测试后发现的问题数量较多，客户在用户验收测试（UAT）期间也发现了更多问题。随着时间推移，记录的缺陷数量逐渐减少，当团队和客户对质量有信心时，就不再需要这些指标。因此，当指标不再有用时，应停止使用。
- 有用的迭代指标标准 ：多个团队共同参与同一产品发布时，在迭代结束时收集指标有助于确保所有团队以相同的标准完成迭代。以下是一些潜在可发布软件的标准及判断方法：
- 冲刺交付物重构并符合编码标准 ：使用静态分析工具，关注有用且可操作的数据。例如，使用开源工具 FindBugs，关注每个冲刺中优先级为一的问题数量是否增加，并相应进行纠正。
- 冲刺交付物经过单元测试 ：查看每个冲刺的代码覆盖率结果，统计单元测试覆盖率在 0% - 30%（低覆盖率）、31% - 55%（平均覆盖率）和 56% - 100%（高覆盖率）范围内的包数量。如果采用测试驱动开发，新包的覆盖率应在 56% - 100% 范围内，高覆盖率范围的增加是理想的。
- 冲刺交付物通过自动化验收测试 ：将自动化验收测试与质量管理系统中的需求进行映射，在迭代结束时生成覆盖率报告，确保所有选定为迭代目标的需求都有通过的测试。未显示通过测试覆盖率的需求视为未完成。同样的方法也可以通过故事卡在公告板上实现。
- 冲刺交付物成功集成 ：检查持续集成构建测试结果，确保通过。在冲刺期间运行其他集成测试，并在下次迭代开始前进行修正。如果集成测试失败，应谨慎开始新的迭代。
- 冲刺交付物无缺陷 ：迭代期间完成的需求应无缺陷。
- 产品能否在 30 天内发布 ：评估产品是否具备在 30 天内发布的条件。

通过合理运用这些沟通方法、回归测试策略、资源准备和迭代指标管理，团队可以提高软件开发的效率和质量，确保项目的成功交付。

5. 沟通与测试策略的实际应用案例分析

为了更直观地理解上述沟通、测试及指标管理方法在实际中的应用，我们来看几个具体案例。

5.1 分布式团队沟通案例

某软件开发公司有两个团队，一个在国内，一个在国外，他们共同开发一款大型软件。在项目初期，由于沟通不畅，出现了需求理解不一致、进度不同步等问题。后来，他们借鉴了前面提到的分布式团队沟通方法：
- 建立固定沟通时间 ：根据两个地区的时差，确定了每天早上国内团队和晚上国外团队的共同沟通时段，用于讨论项目进展、问题解决和计划安排。
- 多样化沟通工具 ：除了常规的邮件和即时通讯，还引入了视频会议工具，方便成员面对面交流。同时，使用项目管理工具实时更新任务状态和进度，让每个成员都能清楚了解项目全貌。
- 文化差异管理 ：考虑到两个团队的文化差异，在沟通中更加注重表达方式和理解方式的差异。例如，国外团队更注重直接表达，而国内团队可能相对委婉，通过培训和交流，让成员们更好地适应这种差异。

通过这些措施，团队的沟通效率得到了显著提高，项目进度也更加顺利。

5.2 回归测试案例

一家互联网公司的软件产品在不断迭代更新过程中，经常出现新功能引入导致旧功能出现问题的情况。为了解决这个问题，他们加强了回归测试：
- 自动化回归测试框架搭建 ：开发了一套自动化回归测试框架，将之前迭代的重要测试用例纳入其中，并确保其能在持续构建过程中自动运行。
- 构建监控机制 ：采用了交通灯和 IDE 弹窗提醒的方式，当构建失败时，相关人员能立即收到通知并进行修复。同时，对每次构建的结果进行详细记录和分析，找出问题的根源。
- 测试用例优化 ：定期对回归测试用例进行评估和优化，去除不必要的测试用例，添加新的关键测试用例，确保测试用例既能覆盖关键功能，又能保持测试的高效性。

经过一段时间的实践，软件的稳定性得到了大幅提升，回归问题明显减少。

6. 迭代指标的可视化展示与分析

迭代指标的可视化展示能够让团队成员更直观地了解项目进展和质量情况。以下是几种常见的可视化方式及其分析：

6.1 迭代燃尽图

迭代燃尽图以时间为横轴，剩余工作量为纵轴，直观地展示了团队在迭代过程中完成工作的进度。通过观察燃尽图的走势，可以判断团队的工作效率和进度是否符合预期。如果燃尽图的斜率过缓，说明工作进度较慢，可能需要调整计划或增加资源；如果斜率过陡，可能存在过度承诺或工作分配不合理的问题。

6.2 缺陷趋势图

缺陷趋势图展示了在不同阶段发现的缺陷数量变化趋势。通过分析缺陷趋势图，可以了解项目的质量状况和缺陷产生的规律。例如，如果在某个阶段缺陷数量突然增加，可能需要检查该阶段的工作流程或人员操作是否存在问题。

6.3 代码覆盖率图

代码覆盖率图显示了代码被测试用例覆盖的比例。高代码覆盖率通常意味着代码的测试较为充分，但也不能完全代表代码的质量。通过分析代码覆盖率图，可以找出未被覆盖的代码区域，有针对性地增加测试用例，提高代码的可靠性。

以下是一个简单的表格，总结了这些可视化方式及其作用：
| 可视化方式 | 作用 |
| — | — |
| 迭代燃尽图 | 展示迭代进度，判断工作效率和进度是否符合预期 |
| 缺陷趋势图 | 了解项目质量状况和缺陷产生规律 |
| 代码覆盖率图 | 找出未被覆盖的代码区域，提高代码可靠性 |

7. 总结与建议

7.1 总结

在软件开发过程中，有效的沟通、完善的测试策略和合理的指标管理是确保项目成功的关键因素。分布式团队需要通过多样化的沟通方式和工具，克服地理和文化差异带来的挑战；回归测试要注重自动化、快速性和有效性，以保证软件的质量和稳定性；资源准备要提前规划，确保测试环境和工具的就绪；迭代指标的选择和分析要根据团队的实际情况，以简单、实用为原则。

7.2 建议

• 持续学习与改进 ：软件开发行业不断发展，新的技术和方法层出不穷。团队成员应保持学习的热情，不断探索和尝试新的沟通、测试和指标管理方法，以适应行业的变化。
• 团队协作与沟通 ：加强团队成员之间的协作和沟通，建立良好的团队氛围。通过定期的团队会议、培训和交流活动，提高团队的凝聚力和战斗力。
• 数据驱动决策 ：充分利用迭代指标提供的数据，进行科学的决策。在制定计划、调整策略和分配资源时，以数据为依据，提高决策的准确性和有效性。

通过以上的方法和建议，团队可以更好地应对软件开发过程中的各种挑战，提高项目的成功率和软件的质量。

下面是一个 mermaid 格式的流程图，展示了软件开发过程中沟通、测试和指标管理的整体流程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([项目启动]):::startend --> B(团队沟通规划):::process
    B --> C(资源准备):::process
    C --> D(迭代开发):::process
    D --> E{是否完成迭代?}:::decision
    E -->|否| D
    E -->|是| F(回归测试):::process
    F --> G{测试是否通过?}:::decision
    G -->|否| H(缺陷修复):::process
    H --> D
    G -->|是| I(迭代指标分析):::process
    I --> J{指标是否达标?}:::decision
    J -->|否| K(调整策略):::process
    K --> D
    J -->|是| L([项目交付]):::startend

这个流程图清晰地展示了从项目启动到交付的整个过程，包括团队沟通、资源准备、迭代开发、回归测试、指标分析等关键环节，以及各个环节之间的循环和决策点。通过这个流程图，团队成员可以更好地理解项目的整体流程，明确自己在每个阶段的任务和职责。