敏捷开发相关实践的深度剖析

### 敏捷开发相关实践的深度剖析 #### 1. QA 工作跟踪 在敏捷项目管理中，QA（Quality Assurance）工作的跟踪是一个常被提及的问题。很多人会问：能否像跟踪开发工作一样跟踪 QA 工作呢？例如，能否将所有 QA 活动和工作列入待办事项列表，基于 QA 人员计划和假定的 QA 速度进行迭代和发布规划，以及生成 QA 状态报告（如燃尽图或燃升图）。 在实际项目中，QA 工作面临诸多挑战。比如，在第一个投资银行项目里，QA 团队有 6 人（4 人在岸，2 人离岸），需支持 5 个开发团队（约 30 名开发者）。该团队存在的问题包括：没有对故事进行 QA 估算；QA 在无跟踪的非故事活动上花费大量时间；QA 与开发者的比例为 1:5。第二个电商零售 IT 部门的 QA 团队，3 人支持 6 名开发者，他们将开发速度与 QA 速度混为一谈，迭代规划仅考虑开发速度，且每个故事的 QA 估算偏差较大，同时 QA 团队成员还常被抽调去支持发布测试和其他非项目相关活动。 为解决这些问题，可采用以下方法： - **创建完整的 QA 待办事项列表**：包含所有故事以及非故事 QA 任务，并注明每个故事安排在哪个开发迭代和 QA 迭代中。 - **使用“三角测量”规则进行 QA 估算**：即根据故事与其他一个或多个故事的关系来估算，QA 应有自己的基准 QA 故事，在估算时与其他 QA 故事进行三角测量。 - **分离 QA 速度和开发速度**：分别规划 QA 迭代，提供每个迭代的 QA 状态报告和燃升图。 采用这些方法后，项目取得了良好效果： |效果|详情| | ---- | ---- | |更好地管理 QA 工作量|通过完整的 QA 待办事项列表和每个故事的 QA 估算，团队对 QA 范围有了清晰认识。| |更好地管理 QA 非故事活动|将非故事活动列入待办事项列表并与故事一起排序，QA 团队可在每个迭代中安排这些活动，处理技术债务。| |更好地跟踪 QA 速度和负载因子|分别跟踪有助于 QA 迭代规划、速度测量和监控以及团队状态报告。| |更好地管理 QA 团队人员配置|基于完整范围、团队速度、项目发布计划和日期，QA 团队能确定所需人员数量，确保项目按时发布。| |澄清团队速度的定义|避免将 QA 速度与团队速度混淆，防止误导业务用户和向上级管理层传达错误的团队状态。| #### 2. 敏捷环境中的构建通知 在敏捷软件开发项目中，持续集成（Continuous Integration，CI）至关重要。它是指在代码库发生任何更改后，自动对整个代码库进行编译、部署和测试的实践，通常每天会进行多次。集成完成后，开发者及时了解结果以便立即修复问题十分关键，因为未检测到的错误可能导致更多问题。 以往有研究评估了单个开发者使用持续集成确保新代码通过回归和单元测试的情况，发现持续集成对编程任务的完成有积极影响。还有人创建了使用熔岩灯的构建通知系统，通过红、绿两盏灯告知开发者构建状态。 为评估不同的通知机制，进行了一个为期三周的实验，比较了电子邮件、熔岩灯和 BuildBot 三种方式： - **第一周**：仅向导致构建失败的开发者发送电子邮件。 - **第二周**：安装一对 Java 熔岩灯显示构建状态。 - **第三周**：使用 BuildBot 作为物理通知设备。 实验结果如下： |通知机制|优点|缺点| | ---- | ---- | ---- | |电子邮件|几乎即时、简单、不受位置限制、不干扰他人，能显示完整的构建失败信息|过多邮件会变成垃圾邮件| |熔岩灯|简单、不干扰、有趣|很多参与者因隔断墙没注意到，信息有限，开发者需在同一房间才能看到| |BuildBot|有趣且新颖|会通知所有人，有人担心它会单独指出某个开发者| 总体而言，引入持续集成通知设备时需考虑团队的社交性质。对于敏捷开发团队，最有效的方式可能是结合一个公开可见但不干扰的环境通知和一个虚拟通知。 #### 3. 使用 COLLECE 群件系统支持分布式结对编程 COLLECE（COLLaborative Edition, Compilation and Execution）系统是一个群件工具，可让位于不同工作站的用户实时协作编写计算机程