[2017BUAA软工助教]团队alpha得分总表

一、累计得分

项目	介绍	采访	贡献分	功能	技术	α例会	α发布	α测试	α展示	α事后	合计
满分	10	10	10	10	10	50	10	10	150	10	280
hotcode5	10	9	9	10	8	50	9	9	150	10	274
弗朗明哥舞步	10	9	7	6	8	45	10	8	137	10	250
NewTeam	10	9	8	10	9	50	10	8	140	10	264
sigma	10	6	7	6	7	50	10	9	129	10	244
PM=pokemon	10	7	7	6	7	50	10	6	108	10	221

二、alpha展示得分计算规则

1.得分表格

NewTeam	结果	工程质量	项目管理	努力程度	总分	排名
任老师	9	12	15	15	51	2
石浩然	12	13	12	12	49	3
陈鸿超	10	15	10	8	43	4
邹老师	-	-	-	-	60	1
桑boss	10	13	14	12	49	3
平均值	10.25	13.25	12.75	11.75	50.4	-

排名总和为13

Sigma	结果	工程质量	项目管理	努力程度	总分	排名
任老师	12	12	15	12	51	2
石浩然	11	10	12	13	46	4
陈鸿超	15	10	10	10	45	2
邹老师	-	-	-	-	45	4
桑boss	11	12	11	12	46	4
平均值	12.25	11	12	11.75	46.6	-

排名总和为16

PM=pokemon	结果	工程质量	项目管理	努力程度	总分	排名
任老师	12	12	9	15	48	4
石浩然	10	12	13	10	45	5
陈鸿超	10	5	8	5	28	5
邹老师	-	-	-	-	30	5
桑boss	11	12	10	11	44	5
平均值	10.75	10.25	10	10.25	39	-

排名总和为24

hotcode5	结果	工程质量	项目管理	努力程度	总分	排名
任老师	15	15	15	12	57	1
石浩然	14	13	14	14	55	1
陈鸿超	15	10	15	15	55	1
邹老师	-	-	-	-	50	3
桑boss	13	14	14	13	54	1
平均值	14.25	13	14.5	13.5	54.2	-

排名总和为7

弗朗明哥舞步	结果	工程质量	项目管理	努力程度	总分	排名
任老师	12	12	12	9	45	5
石浩然	13	13	13	12	51	2
陈鸿超	15	10	10	10	45	2
邹老师	-	-	-	-	55	2
桑boss	12	13	14	12	51	2
平均值	13	12	12.25	10.75	49.4	-

排名总和为13

2.互评表格

注:以下表格中每行表示最左列队伍对其他队伍的评价
排名总和表示该队伍获得的其他队伍的评价的排名总和

互评结果	NewTeam	PM=pokemon	弗朗明哥舞步	sigma	hotcode5
NewTeam	/	3 1.软件的定义和设计不是特别清晰，成员的分工不够均衡。 2.实现了基本功能，有界面较好的可用软件，提供了用户反馈的渠道。 3.做了比较好的测试，软件质量较高	4 1.实现了基本功能，有简洁的界面，基本实现了alpha阶段的目标。 2.进度控制不够好，测试不够充分。 3.推广工作不够好，实际用户数量没有达到目标数量	2 1.对解决问题的过程有文档记录，比较彻底地解决了遗留的问题。 2.做了比较充分的测试，实现了基本功能和阶段目标。 3.成员分工和进度控制的比较好	1 1.管理工作做得比较好，分工比较均衡，可以根据进度对分工进行调整，有较好的代码规范和文档管理，贡献分分配较完善。 2.较完善地实现了阶段的目标和功能。 3.与用户的交互较好，有较充分的用户调研和较好的反馈渠道
PM=pokemon	1 优点：进度控制比较好，项目完成的比较优秀，各种环节有比较完善的实施。 缺点：在应用市场调查方面存在一些问题	/	3 优点：有着比较优秀的自顶向下设计，包括原型界面、预期功能等，成员分工比较合理，最后实现效果较好。 缺点：项目推广做的不够，没有及时收集用户反馈，测试工作做得不够完成，是事后补的，而不是一开始就在准备，因此体现不出效果	4 优点：讲解比较清晰，针对前面的问题有做出改进，后期目标比较明确，用户调查有明确目标对象。 缺点：人员分工存在一些问题，团队开发管理有些不足。PM对进度的把控不是很清晰，有些轻视PM的工作。	2 优点：讲解清晰流畅，团队和开发流程有比较好的管理，有较明确的目标和优先级分配，有完善的贡献分分配负责和会议记录。 缺点：对用户进行调查的力度不够，用用户类型的分类不够细致
弗朗明哥舞步	2 基本实现了目标，不过部分页面仍使用网页页面，未做优化，有些遗憾。 开发过程中出现了分工问题，得到了有效解决，能通过与博客园技术人员的沟通来解决API问题	4 没有创新点，UI不太完善，没有自己设计的贴图，功能与界面数量过少，有200下载量，说明有一点需求。 组织上比较混乱，PM没有做好游戏设计，导致游戏最核心的玩法丧失，遇到瓶颈，长时间未能得到解决，未能明确基本目标，如游戏规模	/	3 没有比较直观的了解成果的展示，此块不太好评价，根据PM所说，应该是基本完成了目标，用30的周用户量。 组织结构比较模糊，开发过程中有一段时间停滞，组织上有一些瑕疵，贡献分评分过程比较模糊	1 网站功能充分，UI设计不错，不支持响应式网页，对移动端界面支持得不太好，有充足的功能与压力测试。 有各类文档，有需求问卷，燃尽图十分理想，呈平稳下降态，有明确的分工信息与贡献分
sigma	2 优点：软件工程各个质量较好，使用了真实的数据，数据量达到了课程要求，现场演示比较清晰，合作氛围比较好，PM揽下了很多事项。缺点：用户数量未达到预期，UI有些简陋	4 软件工程各个质量较好，用户数量充足，使用了真是的数据，数据量达到了课程要求，现场演示清晰，暴露出过程中的一些问题，团队合作有一些问题，项目进度管理不太顺畅	1 软件工程各个环节质量有所欠缺，用户数量不太够，使用了真实的数据，数据量达到了课程要求，现场演示较为清晰，有较好的用户反馈，在设计时有过早设计的可能，导致后端和前端交互的接口不确定，有较为频繁的修改	/	3 软件工程各环节质量较好，实地演示质量较好，使用了真是的数据，数据量达到了课程要求， 团队合作据PM自述不太好，成员贡献比较细致，有遵守代码规范
hotcode5	1 对任务的计划很细致，对要实现的功能有明确的优先级差别，可以看出在开发时按照了事先的计划进行，实现了博客园基本功能，只是个别功能（如回复评论等）还有漏洞。用户量统计很棒，很详细，网站上放问卷好评，有利于收集信息。对工程质量的描述很详细，文档充足，分成若干小阶段很值得学习。	4 从介绍上看，这款游戏并不吸引我，PM所说的吸引“对游戏不感兴趣的同学”也能对这款游戏感兴趣，从何体现？为什么偏要玩这款游戏？在上周老师的提问中可以看出实际的软件公司经营情况和游戏中描述的有差别，游戏策划是如何收集素材的？如果能展示出游戏亮点就更好了。	3 基本实现了预期的功能，但存在一些漏洞，如匿名评价人如何对自己的言论免责，同一用户可以多次评价等，可能会导致评价出现不公平的情况。功能感觉有些简单，而且一些课找不到，用户数未更新	2 能力很强，处理14级遗留问题，在14级基础上增加了文档，说明文档还是很齐全的。进行了压力测试，再上一级基础上对设计有所加强，简化了上一级中处理问题的方法，界面风格很好，在项目管理上不如NewTeam，缺乏计划性，总体感觉开发难度是最大的，一边学习lavarel一边修改数据库，一边增加新功能，很强	/
排名总和	6	15	11	11	7

3.最终规则

取得分表格与互评表格中的排名总和之和，计算出来的数据与得分表格中平均分大致相符，因此采用了以下的规则：

• 将hotcode5得分（最高分54.2）映射至150分
• 其余团队展示得分 = 该团队得分平均值×（150/54.2）

三、个人建议

• 团队博客作业week3分为两个部分，一部分是团队介绍，另一部分是团队采访。
  • 关于团队介绍，只要在截止日期前写齐了团队介绍的都拿到了满分。
  • 关于团队采访，这部分的得分要结合两点：提问与回答和是否有自己的总结。这一点弗朗明哥舞步和NewTeam都有自己的总结，很好。
  • 另外提一句，我就提一句：在请学长接受采访的时候，希望能向学长说明清楚情况和背景，而不是上来就问：“请问你对学弟学妹学好软工有什么建议”:)

---

• 在贡献分分配这部分：
  • hotcode5的贡献分分配方法是所有组中最复杂的，每一个任务的评分涉及到了很多依赖项，并最终使用两个公式进行计算。越复杂的公式也许会越公平，但是公式越复杂，一定越考验PM的执行能力。在之后的冲刺阶段，PM在每一次例会博客中都会更新个人贡献分。我认为这一组在这方面完成得相当好:D但是同样，PM也说，这样的分配方式也弊端，例如对难度的把握够准确，等。
  • NewTeam的贡献分分配博客则对不同人员的工作质量进行了明确的定义，这是其他组没有的。另外这一组的贡献分有一个特点就是操作简单。但是贡献分中不能体现成员完成的任务的难度，这里可能是一个可以改进的点。
  • 弗朗明哥舞步虽然提出了鼓励加分项，但是，每个项目具体应该如何加分则没有进一步的说明了。同时，分配规则中缺少衡量任务完成情况的指标。
  • PM=pokemon，回答几个问题：1.初始任务分数是如何评定的，有什么规范？2.sch的作用是什么？如何判断sch的值？最终的个人得分应该如何计算？是每日贡献分的和吗？
  • sigma的贡献分分配规则应该是最简单的。PM的理由是不想在团队内部造成过于紧张的竞争氛围与没有相关经验，这两个理由都可以理解。希望在阶段结束后核算贡献分时，PM能给出一个合理的分配结果，并进行相应的解释。

---

• Scrum Meeting博客共十篇，每篇五分，只有在alpha迭代的冲刺阶段（10.24-11.8）完成的博客才能计分。发布阶段时发布的scrum Meeting博客不算，提前写好的Scrum Meeting博客不算。博客需要包括照片，燃尽图，签入记录等一共四个要素才有效，得五分。
  • hotcode5团队的例会博客完成得很好，每次博客都更新了成员贡献分，严格按照之前制定的标准执行了。不知道其他团队这一点完成的怎样:D
  • NewTeam团队的团队博客排版很好，其他团队可以向他们团队学习:D
  • PM=pokemon团队11.7号一天发布了六篇Scrum Meeting博客，建议以后不要这样做了XP
  • 另外PM=pokemon和弗朗明哥舞步的例会博客没有按顺序发布，我是强迫症，看着有一点不舒服，虽然不扣分，但是建议以后不要这样做了。如果PM把博客的任务分配到了人，如果他当天没有完成，请对他进行相应的惩罚:)，如果是PM自己的锅，PM自己看着办吧XP

---

• 在功能规格说明书这部分
  • hotcode5的说明书完成得相当好，有十分详细清楚的原型图、功能列表、验收标准，对用户进行了分类，并针对不同的用户分析了不同的用户场景。
  • NewTeam的说明书除了内容充实，在阅读体验上也很棒：排版清晰，图片大小便于阅读，博客提供了目录等等。
  • 其他团队在这方面做得则需要向上述的两组看齐，希望能将工作做得更细致:D

---

• 在技术规格说明书这部分：
  • hotcode5的技术规格说明书中为什么没有对你们组使用的前端技术进行说明？
  • PM=pokemon定义了很多函数并且对每个函数进行了解释，是否可以提供一个清晰明了的图片来完成这个工作呢？另外说明书的内容过度口语化了。同样，说明书缺少UI（cocos creator）的部分。
  • NewTeam在说明API时，希望学习一下hotcode5和弗朗明哥舞步，使用清楚的语言说明API的参数、与返回值的类型和格式要求。
  • hotcode5和弗朗明哥舞步则缺少对异常、错误情况的处理，BTW PM=pokemon也是。
  • 弗朗明哥舞步的markdown显示出现了问题，为什么写完发布之后不看一看呢？

---

• 测试报告这部分hotcode5、NewTeam、sigma和弗朗明哥舞步完成的都挺好的，PM=pokemon的稍有欠缺。
  • NewTeam，是否能将WeTest测试平台的测试标准公布一下，另外，是否展示了完整的兼容性报告？另外，由于你们的APP实际上只有前端，所以测试重心应该在前端上，例如页面是否正常显示，布局是否正常，是否存在组件未加载等等，按照树状结构自动遍历App所有控件并覆盖异常分支。而目前的稳定性测试测试的实际上是博客园提供的API。这里可能是一个可以改进的地方:)
  • sigma和弗朗明哥舞步，你们修正了多少在测试中发现的BUG？剩下的BUG是否有对应的修正计划？
  • PM=pokemon的测试计划可以修改一下格式，分条、按点列出来，这样会有条理很多。就像这样：
    • 测试结果中只有issue的链接，能否在博客中直接说明检查到的bug？能否说明清楚修复与不修复的原因？
    • 报告提出的bug一共分了三个部分，中间还穿插了一段兼容性测试，博客的条理稍有欠缺:),可能是一个可以改进的点。
    • 请考虑一个合理的bug修复计划:)

---

• 发布说明，大家的发布说明都很好，没有什么问题，hotcode5展示的功能可能稍微少了一些:D

四、请各位再接再厉！继续努力！

五、PS

1.李奕君和李欣泽
2.方科栋和赵奕
出现了贡献分相同的情况