4.27

在软件工程课程的学习进程中，敏捷开发作为一种灵活高效的软件开发理念与方法，彻底改变了我对传统软件开发模式的认知，也让我在理论结合实践的过程中，收获了技术思维与协作能力的双重提升。从前我对软件开发的理解，局限于“需求分析—设计—编码—测试—维护”的线性流程，认为只要严格遵循既定计划，就能顺利交付产品。但随着学习的深入，尤其是在接触并实践敏捷开发后，我才明白，在需求多变、市场快速迭代的当下，僵化的开发模式早已难以适应实际需求，而敏捷开发所倡导的“小步快跑、持续迭代、拥抱变化”，才是现代软件工程发展的核心趋势。

学习敏捷开发的核心，是理解其背后的核心理念与价值导向，而非单纯掌握某种具体工具或流程。通过学习我了解到，敏捷开发并非一个固定的方法，而是一套以用户价值为核心、以团队协作为基础的理念集合，其核心思想在于通过快速迭代、持续交付、紧密协作和不断反馈，应对变化莫测的需求，最终交付对客户有价值的产品。2001年签署的《敏捷软件开发宣言》奠定了敏捷的基石，其中“个体与互动高于流程与工具、可工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划”这四大核心价值，彻底打破了我对软件开发的固有认知。从前我总认为，详尽的文档、固定的流程是保证项目顺利推进的关键，却忽略了软件开发的本质是解决用户问题、交付可用产品，过度追求流程规范和文档完善，反而会降低开发效率，脱离实际需求。

在实践环节，我们以小组为单位，模拟了Scrum框架的完整开发流程，这让我对敏捷开发的实践要点有了更深刻的体会。Scrum作为最流行的敏捷框架，将开发过程划分为2-4周的固定迭代周期（Sprint），明确了产品负责人、Scrum Master和开发团队三大核心角色，通过Sprint计划会、每日站会、Sprint评审会和Sprint反思会四个核心会议，保障迭代过程的高效推进。在首次迭代中，我们小组曾陷入“盲目追求速度”的误区，忽略了需求梳理的重要性，导致开发过程中频繁出现需求模糊、任务冲突的问题，迭代交付的产品也未能满足预设的用户需求。这次失败让我深刻认识到，敏捷开发的“快”并非无序的快，而是建立在清晰需求、合理规划和高效协作基础上的有序迭代。

随后，我们根据敏捷宣言的原则，调整了工作方式：产品负责人牵头梳理用户需求，将需求拆解为可执行的小任务，并明确每个任务的优先级；每日站会严格控制在15分钟，每个成员同步自己的进度、计划和遇到的障碍，Scrum Master及时协调解决问题，避免内耗；迭代结束后，我们召开评审会，邀请“模拟客户”反馈意见，再通过反思会总结迭代中的不足，优化下一轮的开发流程。同时，我们还引入了XP极限编程的部分实践，采用结对编程、测试驱动开发（TDD）等方式，保证代码质量。在这个过程中，我深刻体会到了敏捷开发中“协作”的重要性——软件开发从来不是一个人的战斗，而是团队成员各司其职、高效配合的结果。产品负责人把握需求方向，Scrum Master保障流程顺畅，开发团队专注技术实现，每个人的工作都与团队目标紧密相关，只有通过充分的沟通、高效的协作，才能在短迭代周期内交付高质量的可用产品。