第十五周总结：课程总结

本学期，王教授带我们学习了软件工程这一本专业的核心科目。本课程以 “做中学” 为核心理念，打破传统软件工程生命周期的教学模式，遵循软件工程师职业发展路径，设计了从软件维护、修改 Bug 到项目需求分析的渐进式学习体系。课程内容涵盖理论基础、实践技能与团队协作三大模块，形成了完整的知识闭环。
在理论层面，课程系统讲解了软件工程的核心概念与方法论。从软件开发流程中的瀑布模型、增量模型、螺旋模型等传统模型，到敏捷开发中的 Scrum 框架、用户故事与每日站会机制，全面覆盖了不同开发范式的适用场景与实施要点。例如，在讲解 Scrum 时，详细阐述了产品负责人、Scrum Master 和开发团队的角色分工，以及 Sprint 计划会议、每日站会等仪式的操作流程，使学生理解敏捷开发如何通过迭代和反馈机制应对需求变化。
实践技能培养贯穿课程始终，通过个人作业、结对项目与团队项目三级实践体系，提升学生的动手能力。个人作业如 “学习记录 APP” 开发，要求完成用户注册、目标设定等基础功能，锻炼独立开发能力；结对开发项目则强调两人协作，通过驾驶员与领航员角色轮换，实践代码审查、设计讨论等协作流程；团队项目则模拟真实软件开发场景，从需求分析、架构设计到测试部署，全流程实践软件工程方法。
团队协作与项目管理也是课程的重要内容。通过 NABCD 模型指导需求分析，运用 PSP表格记录开发时间，借助燃尽图监控项目进度。同时，课程引入团队角色分工，如产品经理、架构师、开发工程师等，让学生体验不同岗位的职责与协作方式，理解团队绩效评估的多维标准。通过课程学习，我建立了对软件工程的系统性认知。过去对软件开发的理解停留在代码编写层面，而课程让我认识到，软件开发是需求分析、设计、实现、测试、维护的全生命周期过程，每个环节都需严谨的方法支撑。例如，在需求分析阶段，NABCD 模型帮助我们从用户需求出发，思考解决方案的独特性与竞争优势，避免了 “闭门造车” 式的开发。与此同时，对敏捷开发的深入学习颠覆了我对传统开发模式的认知。Scrum 框架中的迭代开发、每日站会和燃尽图等工具，使开发过程透明化、可量化，能够快速响应需求变更。在团队项目中，我们采用 Sprint 迭代模式，每两周交付可运行的功能模块，通过用户反馈持续优化，相比传统瀑布模型，这种方式显著提高了开发效率与产品质量。
理论之外，我们也锻炼了实践技能，从单人作战到团队协作层面。
个人作业阶段，我掌握了 PSP 表格的使用，通过记录计划时间与实际耗时，发现自己在需求分析阶段的时间估算偏差较大，后续通过增加原型设计环节，提高了时间预估的准确性。结对开发中，与搭档的代码审查与设计讨论，让我意识到单人开发时容易忽视的边界情况，例如输入验证的完整性、异常处理的健壮性等，这种协作模式显著提升了代码质量。团队项目是对综合能力的最大挑战。作为团队的架构师，我需要协调成员分工，设计系统模块接口，并确保技术方案的可行性。同时，运用敏捷开发中的用户故事拆分任务，将复杂功能分解为可量化的用户需求，如 “作为学生，我希望每日总结能自动同步博客链接”，这种方式使开发目标更清晰，团队协作更高效。
王教授还注重我们思维方式从技术导向到用户导向的认知转变。课程强调 “用户需求至上” 的理念，通过典型用户分析与场景描述，让我学会从用户视角思考问题。例如，在设计 “科技政策查询系统” 时，我们分析了政府工作人员、科研人员等不同用户的使用场景，发现政府人员更关注政策的权威性与更新及时性，而科研人员则重视政策与研究方向的匹配度，基于这些差异，我们优化了搜索算法与结果展示方式，提升了用户体验。项目估计模块的学习让我认识到量化思维的重要性。过去认为项目时间估算 “差不多就行”，而课程通过 Wide-band Delphi 法、历史数据参考等方法，指导我们科学估算工作量。在团队项目中，我们参考类似功能的开发耗时，结合团队成员的技术水平，将总工作量分解到每个迭代周期，虽然实际开发中仍有偏差，但这种量化方法为进度管理提供了重要依据。
最后是我对课程改进的三点问题或者建议：
1.作业丰富，量有一点点大。课程作业涵盖阅读笔记、每日博客、项目开发等多个维度，部分同学反映作业量过大，导致部分任务流于形式。
2.希望在团队项目的过程中，获得一定的点拨，以此来减少病急乱投医消耗大量时间的情况。
3.希望将课程目标再稍微细化一些。
软件工程课程不仅传授了专业知识与技能，更重要的是培养了我们的工程思维与职业素养。通过全流程的项目实践，我深刻体会到软件开发是技术、管理、沟通的综合体，任何一个环节的疏漏都可能导致项目失败。未来，我将继续运用课程中学到的方法，在实际工作中不断积累经验，从 “代码实现者” 成长为 “问题解决者”，为高质量软件产品的研发贡献力量。