构建之法阅读笔记03

第三章：敏捷开发与团队协作
​​我过去是怎么做的​​
过去，我在参与团队开发项目时，往往习惯于传统的瀑布模型，严格按照需求→设计→开发→测试的线性流程推进。这种模式下，需求变更被视为“干扰”，团队沟通主要集中在阶段交接时，导致问题积压到后期才暴露。例如，开发阶段发现需求不明确时，通常选择自行猜测而非及时反馈，造成功能与用户实际需求偏离。此外，团队分工过于僵化，成员间缺乏交叉协作，测试工作全部堆积到后期，导致工期紧张、质量难以保障。
​​结合书中所讲​​
《构建之法》第三章指出，敏捷开发的核心是通过迭代和增量交付应对变化，强调“个体与互动高于流程和工具”。书中以Scrum和Kanban为例，说明短周期迭代（如每日站会、Sprint评审）能快速暴露问题，通过持续反馈调整方向。例如，用户故事（User Story）和任务看板（Task Board）帮助团队聚焦价值交付，而非机械完成文档。此外，书中强调“自组织团队”的重要性——成员通过跨职能协作（如开发人员参与测试、测试人员早期介入需求评审）共同承担责任，而非依赖层级管理。
​​提出解决办法​​
​加强团队协作​​：推行每日15分钟站会，同步进展与阻塞问题，避免信息滞后。引入“结对编程”或“交叉评审”（如开发与测试互换角色1天/周），打破职能壁垒。​​改进度量方式​​：用燃尽图（Burn-down Chart）跟踪剩余工作量，而非代码量。定义“完成标准”（DoD），例如“功能必须通过自动化测试+用户验收”才算完成。