敏捷软工之提问回顾与个人总结

经过了一学期的奋战，敏捷软工这门课终于接近尾声。在这门课中，我主要经历了结对项目和团队项目两个项目的训练，整个过程虽然艰辛，但却收获颇丰，也让我对软件工程有了更加深入的思考。

对“阅读提问”的回答

问题一：单元测试应该谁来写？

经过结对项目以及团队项目的训练，我的结论是：单元测试应该由最熟悉这部分代码的人来写，且这个人有责任尽可能地提高对这份代码测试的覆盖率，不能随便测测拉倒。

在团队开发的时候，虽然我们团队有兼职测试的同学，但是我们不能总是指望把这部分工作交给他来做，毕竟我们团队的这位同学也有相当多自己的开发、运维和压测等更重要的任务要做。能够通过自己单元测试发现的问题，就尽量不要再麻烦管测试的同学，不然来回交流反馈 bug 会降低效率，且在 scrum meeting 或者 code review 的时候被反馈自己所写的代码存在低级的质量问题，也是挺尴尬的一件事情。

在经过几次熬夜修 bug 之后，我亲身体会到在写单元测试的时候，一定要想办法提高覆盖率，并且单元测试所检查的后置条件一定要写得细致一些，而要做到这一点则最好让最熟悉代码的同学来写。我印象比较深的一个 bug 是：有一个 API 需要返回所有未过期或者没有给定期限的 Offer 对象，我在最开始单元测试的时候对这个 API 只写了一个测试方法，该测试方法先在测试数据库中插入 3 个 Offer 对象，这 3 个分别是已过期、未过期以及没有指定日期的 Offer，而我在测试的时候只测试了返回回来的 Offer 个数是不是 2，相信细心的读者会发现，即使 API 判断过期的条件写反了，返回的也是 2 个 Offer（过期的 Offer 以及没指定过期时间的 Offer），而我确实把 API 中这个判断条件写反了。由于判断过期相关的字段的 default 值是 null，且最开始我们创建的 Offer 都没有指定该值，所以线上版本上大部分 Offer 是可以被返回的，但后期我们新加的指定了过期时间 due 的 Offer 却没法被返回，该 bug 直到后期才被细心的队友发现指出，还好修复该 bug 只需要我修改后端代码，不需要改前端，否则可能会严重影响小程序端的使用。经历过这次之后，我觉得自己再也不敢对自己所写模块的单元测试掉以轻心了。

问题二：服务于小部分典型用户的idea在本门课是否应该被鼓励继续下去？

对于此问题，我目前的回答是：

• 课程组方面尽量还是要尊重学生的意愿，因为可能有的团队的目标并不是用户量能达到多么多，可能只是单纯地想要借助这个机会，聚集几个人一起全身心去做一件事情，从中磨练自己的技术以及与人合作的能力。
• 学生方面如果决定要做这种项目，就要做好接受发布后成就感不足的心理准备。

问题三：敏捷软工是否适合作为课程开设？它能否达到相应的效果？

对于该问题，我目前的回答是：

• 平均 2 天左右一次的 scrum meeting 感觉比较紧张，碰上其他课程有 ddl 的时候大家都没太有实质性的进度时就比较尴尬，毕竟大家也不是像在工作时那样全职做软工。
• 虽然 scrum meeting 比较 push，但是冲刺阶段频繁的交流确实帮助了我们敏捷地完成现有的任务以及确认每个人新的任务，这比后期极限冲 ddl 还是好得多的。
• 通过亲身实践，我觉得敏捷方法还是适合作为课程来开设的，同学们的技术和沟通大概还是可以 hold 住的，但是在某些特殊时间段下敏捷可能就有点强人所难了。

问题四：非专业团队的PM是否需要兼职开发和测试？

对于该问题，我目前的回答是：

• 我们团队的实践情况是：由于 PM 不仅有过人的沟通能力以及产品意识，而且还拥有出色的 UI 设计能力以及美工能力，所以 PM 在整个过程中既代表整个团队和甲方扯需求、推我们的 ddl，又参与了较多前端开发环节。
• 通过我的观察，我们的 PM 在参与进开发之后有点太忙了，经常任务做到很晚，以至于白天需要联系的时候可能联系不上，scrum meeting 可能会推迟一小段时间时间才能开起来等等。
• 我个人的理解是：PM 尽可能还是专注于做 PM 本身的事情比较好，开发和测试尽可能地下放给队友来做；如果 PM 本身的技术水平确实非常强，那么可以去参与做小部分攻关任务或者给其他队友做一些指导等。

问题五：为什么读了书之后我提出的问题这么少？

在实践之后，我目前的想法是：

• 之前我在软件开发这方面没有真正很好地实践过，所以没有遇到过书里面提到的这样那样的问题，而第一次看到书里面写的东西的时候感觉有点懵懵的，不明觉厉，感觉书上说的好牛逼，所以才提不出来问题。但是在实践之后，当我真正遇到了一系列问题并使用书中所提到的解决方案去实践之后，才感觉第一遍读的时候好多东西没有考虑到，书上说的确实是有些道理的。这也告诉了我：有时候要提出一些问题，可能首先要对一些事物有基本的概念和实践，否则可能比较难提出有价值的问题。

实践中对知识点的学习与理解

需求

实践了规范化的需求分析方法：NABCD分析。NABCD 考虑了用户需求、市场竞争等多方面的情况，按照这个思路进行分析，可以让我们自己也理清楚“要做一个什么样的软件”、“为什么要做一个这样的软件”等重要问题，防止“拿着一个假需求闷头做，最后做出来的东西没人用”这种尴尬的情况。

另外，我还充分体会到了需求的时效性（bushi），有些需求可能在需求分析阶段被认为是相当多用户的刚需，但在开发完成时可能因为各种原因（比如疫情和学校政策等等）从而变得不是那么需要了。

设计

通过参与编写功能规格说明以及技术规格说明，我亲身感受到了设计阶段要确定哪些问题，比如作为后端来说，我们要确定好数据库中所有的表，论证现有的表能不能满足我们从需求中抽象出的功能，能否应对可预见与不可预见的需求变化等等。

另外，我还更加深入地理解了设计的重要性。在之前我并没有过“自己所写的项目拿到线上工作”的经历，所以当时只是简单的认为“设计砸了大不了就是重构代码”，但这次软工告诉我设计出现问题的代价不只于此，需要调整的不仅仅是代码，还有服务器上现有的数据：要保证修改了数据库表的结构之后，数据库中的数据仍然是正确的。在比较坏的情况下，坏的设计在重构时既要改代码，又要把线上数据库中的数据 dump 出来，然后删库重新建表，最后把数据再插入回去，过程繁琐且风险很大。

实现

在实现阶段，我觉得收获是最大的：

• 第一次使用 django 框架做后端开发，初步了解了 django 框架是如何工作的，有能力自主编写实现所需要的 API 及其单元测试。
• 在实现过程中，通过 stackoverflow、框架技术文档以及向队友提问等各种手段解决问题，从而学会了如何快速定位以及解决开发过程中遇到的各种问题。
• 通过和队友使用 github，notion 等工具进行协作，我亲身实践了很多不错的开发规范，并从中收益良多：规范的分支以及 issue 能够让我们团队互相了解到别人在开发哪些部分的功能以及在修复哪些问题，并且能够让成员之间并行工作；前期频繁的 code review 能够对我这种对框架不熟悉的同学起到重要的教育意义，从而让我后续开发的代码质量有明显提高等等。

测试

在测试阶段，我最大的感受是体会到了在项目中留存可以直接运行的运行的单元测试的重要性。在项目开发阶段时，我们就编写了大量的单元测试，总共单元测试代码超过3000行，这不仅提高了我们第一遍开发时的代码质量，也在后期我们进行 API 重构时起到了回归测试的作用。现在想想，如果没有这些单元测试，那么可能团队开发时大部分时间都会用来交流本应该早已由开发者发现并修复的bug，开发效率也会下降很多。

发布

在发布阶段，我明白了要在多渠道进行宣发，才能够保证用户量。我们团队不像 OSome 团队那样天生拥有数百人的用户量，也没有灵境团队那样借助 B 站等平台做广泛的宣发，只进行了比较传统的宣发方式，再加上形势的变化所导致的潜在用户减少，所以 beta 阶段的用户增长不是很大，这在一定程度上说明我们在宣发方面可能确实存在一些问题。

维护

在维护阶段，我感受到了很实在的一点：假如你的产品已经上线了，那么发现问题时不能贸然直接在这个发布分支上改，要在开发分支改好并测过之后再找一个合适的时间（可能是深夜）把修改合过去，不然用户用着用着可能会发现软件寄了。

心得体会

个人博客作业

这是我第一次去做调研软件这类工作，在该部分我最大的收获是了解了要从哪些方面去评价或者比较软件，此外就是对于所调研的几款软件有了更加充分的认识，这也帮助了我解决了后面一部分结对以及团队项目开发时的工具使用问题。

结对项目

在这个阶段，我和 fzc 同学一起努力完成了“最长单词链”项目，在这个阶段我充分体会到了结对编程能够更好地查错、等等互相帮助与攻坚克难。未来如果遇到了比较难攻克或者比较紧急的任务，我觉得自己会尝试使用结对的方法来解决（不一定非要是写代码的任务）。

团队项目

团队项目方面的心得：

• 团队开发的过程中要持续保持交流，不要闷着头干，出了技术问题要及时和团队内部的“技术总监”交流，理解不了需求要及时和 PM 交流等等。
• 积极主动去领任务，得到的锻炼才会更多，才更加能提升自己的核心竞争力，这一点在进入职场时显得尤为重要（和光速“毕业”说拜拜）。
• 最后非常感谢这学期带我的队友们，他们对我在各个阶段提出的问题做了非常细致的指导，让我在这门课上接触到了很多之前想接触的东西！下一次合作不知道会是何时，在这之前我会努力去提升自己，下次的我一定可以独当一面！

最后

以上就是体贴手机为你收集整理的敏捷软工之提问回顾与个人总结敏捷软工之提问回顾与个人总结的全部内容，希望文章能够帮你解决敏捷软工之提问回顾与个人总结敏捷软工之提问回顾与个人总结所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。