nikochan.cc

导航

 

你认为每次项目的评分标准存在哪些问题,你认为的合理评分准则是怎样的(个人/结对/团队算三个)

评分的话我个人觉得是存在一些问题的。

第一,分数差异

问题:一个就是各班的成绩评分有高有低,有的班整体分数都比较高,有的班整体分数就比较低。这就导致最后平时分的划分的矛盾。虽然量化是标准的,但人这个变量是不统一的。

解决:暂无

第二,指标量化

问题:还有一个现实的问题就是团队项目是一个大的项目,我们判断一个团队给高分量化标准到底是什么?
是完成即可高分还是说要功能的完善?【如果完成即可高分那么结果请参照上世纪人民公社化的故事,结果怎么样我就不细说了...

解决我建议加入自评分和相关说明。

即阐述你为什么能得到这个分数,老师和助教也就可以针对你的自评来进行提问和打分。

没有任何人比自己更清楚自己的项目是怎么样的。自评分是对自己的认识,也是帮助别人来理解你的项目代码,阐述优点或者功能,或者数据结构,也可以更直观方便评分。

而这会更清楚的看出各个组在功能实现上的差异,哪个更难,哪个更简单,我想一目了然。这也回答了我上面的问题。

第三,展示博客

问题:团队的展示博客有时间和评分的两个问题。

在我看来,团队项目过程和结果同样重要,而到最后却因为考试没时间进行全体的项目结果展示,我认为这还是有些问题。应该调整一下,因为还是要有一个展示的过程在。而且,到了beta基本上就开始有期末考试的问题在了。

在评分上,Alpha阶段我当时生病回家没在学校。导致我们组alpha阶段展示只进行了前端展示,但同样出现展示问题的有好几组,最终老师给了我们最低分。老师的提先打分影响了大家的打分,因为大家也不会认真看展示内容,然后就按照老师打的排下来了。我们最后就是光荣的最后一名。

解决:时间方面,提前一下时间进度,留有时间作beta和展示。打分方面,建议是老师最后打分先让小组互评分,减少老师打分的影响,而互评分建议是其他班进行打分,而不是本班互相打分。

第四,博客&代码?

问题:有些人基本没写过代码,只是博客写得特别特别好,就可以拿高分?诸君如何看待这个事情呢?我承认这是严苛的博客评分制度的必然产物。

解决:我,无言以对,得分,但求心安。

其他。(后面还附有一些建议)

个人和结对倒是没有什么特别的评分问题。【我害怕没按照要求写,又得扣分了】

你的团队项目是否成功,如果重来一次你是否还会选择这个团队,为什么成功/失败;

是成功的。我仍然会选择这个团队。

首先团队里的组员大家都是极其向上的,想做好每一件事的人。每一次分配任务,写日志都会及时的完成。这是我们团队完成还算不错的基础。我并不算是一个铁腕的人,想想如果是另外的组员,想必会很难搞。

坦白讲,团队里很多女孩子都没有项目经验,对于开发,产品,PM也没有什么概念。

不过令我感到最开心的事是,大家找到了自己的兴趣点。

通过这个团队项目,有些人开始想学学python了,去看书,去找一些资源,去写写小东西。

有些人对前端感兴趣了,钻研前端,甚至以后想做这方面的工作。
有些人渐渐了解了PM,产品,运营的工作职责,也渐渐懂得了自己真正想做的事情。

在我看来,这是极好的!拿多少的分数从来不是授课的最重要的意义,因为在漫漫人生长路,这并没有任何意义,【当然我这个要出国的留学狗要GPA除外】而更重要的是找到一个方向,继续学习下去。

我从来不是一个讲空话的人,也没那么多宏图韬略,唯有实事求是。我敢确认团队中的每个人都有事情做了,或多或少的参与了开发,不是坐着拿成绩吃空饷的人。

我认为团队开发十分有意义,踏实做的项目比上那些空有其表的东西要实在的多。而主观的说,我们还可以写在简历上。

感谢团队的每个人,团队项目BETA结束后我们还去聚了餐。十分开心!!!

总结一下你们团队在做项目时大家的时间安排情况,可以匿名写;

编程的话,基本上我上课都会拿着电脑编程,晚上也会。不过我一般熬夜写,因为晚上感觉世界更安全,令我的心也沉静得多。

组员都超赞,坦白讲这次才真是理解了产品的重要性,有的时候我对于一个功能不太清楚该怎么写,我向他们抛出疑问,比如新的需求的内容。他们都会挺快响应的!基本上是全天候都会快速响应。

软件工程这门学问有很多 “知识点”, 这门课强调 “做中学” - 在实践中学习知识点。请问你们在项目的 需求/设计/实现/测试/发布/维护 阶段(一共6 个阶段)中都学到了什么 “知识点”, 每个阶段只要说明一个知识点就可以。

需求:学会了每种用户的需求分析所用到的方法,比如:问卷调查和线上采访(数量要有一定的要求),还有如何编写需求设计文档

设计:软件原型设计所用到的工具(如墨刀)

实现:在实现的过程中使用的项目进度安排工具(燃尽图),团队源代码管理(Git、Coding的使用)

测试:测试分为黑盒测试(通过界面的功能来测试)和白盒测试(通过测试代码看是否有bug),测试工具在结对的时候学了点单元测试

发布:了解到发布之前应该编写说明书,以便用户使用和维护人员的工作
维护:发布之后应该再次做调查,看用户使用情况以及反馈情况再进行完善

写在最后

还有一些建议:

1.建议使用Github。其实我不太知道为啥不使用Github,提交代码和coding基本一致,唯一差别大概是语言环境的不同。而Github上资源更加丰富,在求职的时候有些公司还会特意看你的github记录,如果是放到Github上,真的是项目参与的痕迹体现。

2.对于课程冲突的问题,大三下的强度挺高的,课程冲突这个问题无法避免。我建议把很多功能实现从扣分改为加分。每个人的追求是不同的,有些人过就好,有些人想学更多,有些人想拿高分。目的不同,上心程度也不一样,更重要的,编程程度也不同。如果一味的把要求定的太高,那学习成本就会陡增,编程水平一般的同学为了不扣分会花费更多的时间成本在上面。基础部分是必要完成的,其他的一些功能可以加分的,而且加分的观感比扣分要更好~


我是一个满腔热血富有情怀的中二少年,从小到大我接受的教育就是,有话直说实事求是。上学12载,也没少进行直谏,幸好老师大多善解人意,让我活到今天。这也造就了我现在的个性。课程基本结束,回看过去的三年。软件工程这门课的改革十分有意义。

本来是空洞的文字和概念,如果不通过动手实践,那它永远是空洞的文字。还是很感谢这个课程的改革,让更多的人进行了参与,参与可能会萌发兴趣。之前的很多实验也好,课设也好,大家都并没有真正上手去做,而这一次的软件工程却做到让很多人开始尝试。这也是我理想中课程的样子。

我们的目标是一致的,希望这门课真的有用,希望这门课能够学习到一些真东西。掏心窝子的话应该比假大空实在些,而这正是我这一学期上课之后的个人想法。

感谢老师和助教辛苦的付出,十分感谢真的。勇于做出改变并经常听取我们意见的张老师 我报以十分感谢!

构建之法这本书也不错,是少有的能读下来,并且很顺畅不费力的书。买了一本全新的,以后上班再读又是另一番感悟。

欢迎老师和我进行更进一步的交流!希望我们院的这门课可以越来越好。努力谦逊,不忘初心。E心E意,一心向前。

Niko 敬上

posted on 2017-06-25 11:40  Nikoちゃん  阅读(296)  评论(6编辑  收藏  举报