[I.3] 个人作业：结课总结

个人作业：结课总结

项目	内容
这个作业属于哪个课程	2025年春季软件工程(罗杰、任健)
这个作业的要求在哪里	个人作业：结课总结
我在这个课程的目标是	通过学习和团队合作，了解敏捷开发流程。提高个人编码素养，掌握软件工程的核心概念和方法。
这个作业在哪个具体方面帮助我实现目标	经过一学期的实践与学习，总结软件工程的学习收获，体会敏捷开发流程的特点。并结合自己的实际工作经验，分享自己的经验教训，帮助同学们更好地掌握软件工程的核心概念和方法。

问题回答

个人作业：阅读和提问

问题一

在实践的过程中确实精通的反面对应着这个人在不断地解决自己因不精通而产生的问题，这让他一直处于一种很忙的状态，我对此深有体会。
在beta开发阶段，由于自己的盲目自信，在开发某个功能模块时，在不到2~3天的情况完成了开发，就认为“不过如此”。直到功能完整落地，前前后后反复概览多次bug，其中就有作为组件和别处代码整合时，因为语法不兼容导致的问题，有因为浏览器本身兼容问题，这种问题在自己独立编写时很难考虑到，最终成为了一个蹩脚的程序员。

问题二

关于敏捷开发过程的技术债务，我认为在一个优秀的团队中是可以尽可能地减少它。但是人总不是上帝视角，在beta阶段确实更改了某些接口的逻辑即使在alpha阶段的设计自认为很全面。

本身来说技术债务的积累来源于团队本身在测试阶段的偷懒，毕竟越早测试越好，问题一直存在在哪里，若不解决，在最后的大屎山上动一发而前全身。在个人看来，债务不是敏捷开发的缺点，而是软件工程本身团队协作的缺陷。若团队的测试随着项目进展不断进行，技术债务的积累也不会太大，总体在团队可接受的范围。

问题三

在本人的团队中，由于大家对于软工具有较大的激情，总体进度是优于预期的。
我对于此问题的回答是，可以将初期任务分给最适合的那个人，这个人对于此模块的开发的预估经验和能力都比较高。而对于难度较高的模块，可以让团队中能力较强的人完成，由于无法预估难度，需要在团队中的人动态预估难度。当预期时间超过一个阈值后马上加入新的成员，以保证团队的进度。

悲观的策略至少在学生开发项目中不是非常必要，团队的预估只要有个精确到小时的大概值（根据任务难度给出）。由于学生软工间的职责并非一成不变，在该模块进度落后时可以调派人手，重新规划任务。

问题四

在课程前，我认为要找到一个两者的平衡值来确切完成一个高质量的软件。但是实际情况下，一个软件稳定的运行就是给一个用户最好的体验，而新功能或是小彩蛋的加入势必增大团队的工作量。诚然风险意味着回报，对于没有试错空间的团队来说，保证软件稳定才是最大收益。
可能我的回答不够好，所以附上GPT:

在敏捷开发中平衡软件稳定与优化，核心策略是：
变更分级：优先修复Bug/安全补丁，非破坏性优化（性能/UI微调）可频发，新功能/破坏性变更需谨慎；
渐进式交付：用特性开关控制功能可见性，通过金丝雀发布逐步开放给小范围用户验证，结合蓝绿部署实现零停机回滚；
自动化保障：建立完备的自动化测试套件（单元/集成/E2E）和持续交付流水线，设置质量门禁拦截风险；
监控兜底：实时监控生产环境，异常时快速回滚。
目标是以可控风险持续交付价值——高频优化但不扰用户，稳定运行仍持续进化。

问题五

失败者效应：失败者往往不能清晰地认识到自己的错误，总是坚信是自己不够努力或创新，即使存在其他层面的决策错误，甚至会敌视成功者。

学生团队由于经验不足，很可能在发布中碰壁，困难并非是因为自己在某方面做的不够好，反而是我们“做得太好”。适当调整自己的方向，盲目地创死别人只会浪费资源，加剧失败。
可以参考以下措施：

• 深度聚焦：锁定3-5名典型用户，通过 "上次如何解决？" 式访谈挖掘真实痛点，拒绝自嗨式设计；

• 极简验证：用纸面原型/现有工具（如微信接龙+在线表格）48小时内拼装核心功能MVP，投放真实场景；

• 数据决策：依据用户行为数据（如日活>70%保留，<30%立即回访）迭代，资源只投入验证过的需求；

• 价值锚点：创新仅服务于 "10倍提效/90%降本"（如食堂系统核心价值=省时＞技术炫技），让10个用户尖叫而非取悦千人。
  用低成本试错代替豪赌，使每次失败都转化为精准认知燃料，在资源耗尽前刺破伪需求泡沫。

新问题

在本书中涉及了猪，鸡，鹦鹉三种角色，这三种角色依据对于工程的投入程度分出，但这并不是根据个人能力给出。 我们的重大决定交给了猪，当猪是昏庸或平庸时，决策也会是失败的。首先在此反驳重大决定交给猪

第二个问题也是关于此的，如果猪拼尽全力也无法完成任务，那么我们应该交给鸡或鹦鹉处理？还是应该自己处理？毕竟这只体现了投入程度，并不是工作量，也不是能力担当。 有才干的人并不会因为投入少事实上做的就少。所以，在此提问，最后分数或绩效要根据角色给出吗，鸡或鹦鹉在团队中地位就一定低于猪吗？

收获的知识

需求分析： 根据市面上已有软件来分析用户的需求，可以将模糊需求拆解为纵向用户旅程，并制定详细的功能点。

设计阶段： 数据库和实体的定义要尽可能全面，可以由全组成员共同决定。在设计时应考虑到用户的使用习惯，并结合实际情况进行优化。

实现阶段：
持续集成（CI）的防崩溃价值
→ 体验 "小步快跑"提交：单次提交小，触发自动化构建（编译+单元测试），在合并前拦截因各种冲突导致的隐性BUG。

测试阶段：
测试是越早越好，否则问题就会扩大。同时，再怎么测试漏洞总会出现，比如安全问题未考虑到，助教黑入数据库。

发布阶段：
不确定的因素会在发布前和发布后的一段时间内大量暴露，充分的测试与稳定是十分必要的。同时，要在发布时根据不同用户给出不同的功能模块引导，以此可以定制化，最大化的获取用户。

维护阶段：
"代码是活的有机体" —— 需求会变、技术会旧、用户会成长，唯有通过自动化工具链+模块化设计+用户数据驱动，才能使系统在演化中保持生命力。

感想

在最开始选到敏捷开发时，由于听到某些传言，感觉自己很可能在大三下迎接一个非常差的课程。非常令人惊喜地是，这门课程并没有像之前的专业课十分枯燥。
个人作业中的书籍写的真的很棒，至少比北航“狼”的编写质量高了几个档次，在读完后，我就知晓敏捷开发这门课应该不错。在信息时代，能够耐心读完一本纸质书真得不常见了，课程组给我一次和微软高级程序员交流的机会通过文字。
在结对中，本人选择的队友十分可靠，由于在结对作业中写出感想，不再赘述。
我很幸运和几位志同道合，踏实肯干的伙伴一同参与了软工的开发，大家在会议室畅所欲言，激情讨论是6系之前课程不能给予我的。能在短期内做出一个自己都难以想象的软件是十分有成就感的，即使最后的发布并不是非常满意。
最后，我想说，软件工程是一门很有意思的学科，它既有理论，也有实践，更有团队合作，需要我们不断学习和提升自己。