博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
软件工程第3次作业 | 提问回顾与个人总结
阅读量:5129 次
发布时间:2019-06-13

本文共 2117 字,大约阅读时间需要 7 分钟。

项目 内容
本次作业所属课程
本次作业要求
我在本课程的目标 顺利通过课程
本次作业的帮助 回顾课程,总结经验

1、链接博客

2、提问的解答

  • “Bug”和“Feature”的关系:

经历了一学期的软工项目,我对bug和feature的关系有了更深的体会,首先一个功能的定义是很灵活的,例如我们的项目中认为无法看到自己的匿名评论是正常的,但是有的人可能认为是bug,此时这个功能是否需要修改一定程度上要看使用者的意见反馈,如果所有人除了开发者都认为这样是不合理,那么作为一个以服务用户为主要目的的项目,这个bug就应该被修改。无论工程量大小,因为开发者和用户在项目中是不同的地位。

  • 文档在敏捷开发中的必要性:

这一点我的体会是,敏捷开发是目的而文档时工具,当文档的撰写影响到了开发进度,此时他的重要性降低,当文档的撰写可以明显提升开发进度,此时文档就是促进敏捷开发的必要工具。某样工具的必要性从来没有准确的答案。在我们的项目中,有的文档是后期补全的,例如每个函数的接口定义,因为从事后端开发的人员自己都明白每个函数的意义,而交付给下一届是后续的任务,在开发过程中并不必要。但是我们撰写了数据库导入文档,git-flow控制文档,这些内容是所有人都需要了解的。此类文档的提供可以让大家不需要沟通就可以进行同样标准的开发的功能测试,是有利于敏捷开发的。

  • A/B测试的访客群组选取:

拿我们的软工项目举例,访客群组的选取就是直接在同学群体中发布网站,例如微信群和qq群。但是由于我们进行了严谨的版本控制,所以并没有进行A/B测试,每个版本的发布都是确定的统一布局格式。

  • 统一的表达方式:

在我们的数据库设计过程中,其实我们也不记得实体,关系等等的连接是否正确,但是在编码实现上只要是统一的,功能就是正确的。所以和文档一样,uml也仅仅是一个工具,统一的表达是为了不同开发者之间的良好沟通,他的必要性值得探讨,如果是仅在设计阶段,我认为不一定非要遵守格式规范。如果是作为一个公开的广泛流通的文档,那么这个图或表格的格式就很重要。

  • 好的想法不一定赢:

用户是上帝,坚持创新是成本是很高的,当你的付出得不到回报时,坚持是很难的。所以创新的推动是要得到支持的,仅凭一己之力是难以革新的。在我们的公课网项目中,可能某些设计我们开发者认为很好,但是用户的反馈并不是很理想,迫于推广压力我们只能修改。但是我仍然认为得到了支持的创新是能够良好的进行下去的。

3、学习过程的知识点

  • 需求:预留足够的空间扩展
  • 设计:头脑风暴,收集意见
  • 实现:尽早完成,留出debug的时间
  • 测试:用户是最好的测试者
  • 发布:谨慎发布,本地和服务器的统一
  • 维护阶段:bug的出现总是难以预料,尽早解决

4、心得体会

软件工程课程终于结束了,当了alpha阶段的pm之后,体会到了领导者的不易,同时由于本学期一直在准备出国的语言考试,时间非常紧,疲于处理人际关系和沟通交流方面,只能更改了pm位置,beta和gamma阶段的任务明显清了很多,但是做项目的热情也一点点的损耗殆尽,一方面在交流的过程中无可奈何的会出现偏差,导致功能实现的差强人意,另一方面由于大家的水平都不是很高,导致很多bug的出现让大家心力交瘁。让人不禁感叹一个项目的开发到维护是多么的困难。最难得就是和人沟通了,每个上了软件工程的同学可能学会了开发流程,但是却学不会沟通和交流。至于分数方面,我一直秉承着干多少活拿多少分,课程过程中也出现了和别人的矛盾,其他的组或许也有类似的情况,组与组之间也出现过摩擦,不过这应该就是团队项目无可避免的副作用吧。

最后再说几句吧,能够在一个氛围良好的团队工作是幸运的。作为一个团队的成员,每个人都是成年人,大家都很忙都很累,都有自己的事情要做,同时大家也都是平等的,有事情说的直白一点:强就多拿分,菜就要认,能者多劳不是没有道理。在本次软工的项目中说实话大部分的压力是来自隔壁组的,这一点也要感谢隔壁开发团队,为我们树立了很好的榜样。另外要说的是,很多bug的修复,功能的实现,可能几个同学一起讨论一天一夜。这些东西是不一定出现在issue上的。代码上存在很多问题,大家之间也不了解,可能造成了误会的产生。我在任pm期间,很多问题没有说的太明白,有可能拿到的成果我自己会进行一定程度的修改,但是贡献分上我不会写上自己的名字,在beta阶段和gamma阶段这种情况发生在很多团队成员身上,这在项目开发过程中都是难免的。这里是帮同组的同学说句话,大家都是一起努力为一个项目,可能技术水平不高,但是当你认为自己做了很多事情却没有得到相应的回报时,有没有想过,在你谈论付出的时候,你知道别人付出了多少么?当然这并不是一个严重的问题,因为就我本人而言并不是很在乎这个分数,制定这样的分数要求仅仅是为了满足课程组要求。不过我想说的是,在调查清楚或是当面讲明白很多事情前,妄下结论是不合理的。这里就事论事,推荐开诚布公,拒绝阴阳怪气。

软工经历并不是很愉快,终于结束了。希望各位今后生活愉快。

转载于:https://www.cnblogs.com/Retr0/p/11057970.html

你可能感兴趣的文章
java SE :标准输入/输出
查看>>
[ JAVA编程 ] double类型计算精度丢失问题及解决方法
查看>>
好玩的-记最近玩的几个经典ipad ios游戏
查看>>
PyQt5--EventSender
查看>>
Sql Server 中由数字转换为指定长度的字符串
查看>>
tmux的简单快捷键
查看>>
[Swift]LeetCode922.按奇偶排序数组 II | Sort Array By Parity II
查看>>
VC6.0调试技巧(一)(转)
查看>>
php match_model的简单使用
查看>>
SIP服务器性能测试工具SIPp使用指导(转)
查看>>
Vue_(组件通讯)子组件向父组件传值
查看>>
STM32单片机使用注意事项
查看>>
js window.open 参数设置
查看>>
032. asp.netWeb用户控件之一初识用户控件并为其自定义属性
查看>>
移动开发平台-应用之星app制作教程
查看>>
leetcode 459. 重复的子字符串(Repeated Substring Pattern)
查看>>
springboot No Identifier specified for entity的解决办法
查看>>
浅谈 unix, linux, ios, android 区别和联系
查看>>
51nod 1428 活动安排问题 (贪心+优先队列)
查看>>
Solaris11修改主机名
查看>>