第5周团队作业2:分数分配

经过我们团队的协商,我们一致认为在团队项目没有完成之前,是无法确定每个人的分数的。在整个程序的设计开发中,有很多不确定的因素,这可能会改变原始设定的分工。而整个团队在协调的过程中,必定与项目开始之前的任务分配有所不同,而各自的任务量也会有所改变。所以在这里只能提供一个大致的算法,在任务结束之后根据这个算法来分配分数。

首先,感谢嵩爷提供算法思想!

我们在项目开始之前,假定每个人的得分是x(注意,这个x不是50,所以绝不是平均主义)。

在项目的开发过程中,由PM调控整个开发团队,适当的调整每个人的任务量,并且记录每个人的任务完成情况等各种可以在最后评定中加减分的要素。

在项目结束之后,开会评定成绩。PM和每位开发人员都可以提出对于自己活着他人的加减分数的意见。如果半数以上成员认为可行,那么就承认加减分。

最后每个人的分数是(x+a),其中a是开会评定的加减分。将七个人的最终得分相加会得出式子:

7x+a1+a2+a3+a4+a5+a6+a7 = 50*7

可以算出x,继而算出每个人的成绩。

这个算法考虑了在完成项目时开会时成员很少会给他人扣分的情况。如果在项目开始之前将总共350分全部分配出去的话,就会导致没有多余的分数加给工作量大的成员。而如果重新按比例分配分数的话,会给分数比原来少的成员带来负面感情,影响以后的开发任务。而这个算法可以通过给人加分的方式变相的实现成员分数的整体调控。

不过我们给予这个加减分一些限制条件。比如

1、每个人的分数不会低于30分

2、每个人的分数不能高于70分

(以上两条纯属劫富济贫,请组内大神放过我们这些弱渣吧……)

3、请给PM酌情加分

(相对来说容易遗忘的成员,不过是整个团队的中流砥柱)

其他没有想好 (????)

当然,以上规则在当某成员几乎完全没有贡献的情况下不适用。

时间: 2024-11-03 21:50:05

第5周团队作业2:分数分配的相关文章

第5周团队作业2:团队贡献分分配

Echo队共有成员7人,团队贡献分共350分.我们经过讨论确定了一套分配团队贡献分的方案,现将相关内容记录如下: 一.方案原则 1.分数的分配应当能够反映出每位成员对团队的真实贡献.即贡献越多的成员将得到越多的团队贡献分,贡献较少的成员将获得相对较低的团队贡献分. 2.分数的分配方案应当充分调动成员的积极性.即对于积极参与团队贡献的成员,应当给予鼓励:对于较少参与团队贡献的成员,应让其感受到一种紧迫感. 二.方案考虑 1.每项作业要“悬赏”一定的分数,对全程参与的成员给予相应的分数.如此一来利于

Team--时代团队第一次迭代分数分配

紧张的第一次迭代落下帷幕,便到了分数分配这样令人揪心又无奈的日子.如何进行分数分配,以使大家都能满意,这一直是个难以非常好地处理的问题.幸运地是,我们团队的所有成员每个人都对本次迭代乃至整个项目过程付出了很多,每个人都尽力地做好自己的事情.这让分数分配的环节显得容易了许多. 最后我们根据上次例会产生的团队个人排名,并按照老师的"各人不同分"的要求,对此次迭代的各人分数进行了分配. 一.本次迭代团队个人排名及工作的简单介绍: 1.李帅. 李帅在本次迭代中主要负责了主要代码编写这一重要又较

第5周团队作业2 团队分数分配

经过讨论,我们组暂定如下的分配方式: 1.凡是认真完成自己任务的队员,都将有基础分30分(态度分). 2.将整个项目细化为不同的任务,列出一个任务清单,在综合.协调完每名成员的意愿后,我会分配清单中的任务给每名团员(存在能者多劳的现象,但会尽量平均分配).之后我们会开会协商每一项任务的分数(先将除去所有基础分后所剩的140分除以任务总数得到每项任务的基础分,再根据任务的难度等对基础分进行增减). 3.项目中如果存在“救场”现象,即某名成员在完成任务时遇到了困难,不得不让其他成员花费相当一部分时间

团队作业三分数发布

检查项 分值 备注 编号 需求&原型改进 使用前的场景(痛点) 使用后的场景(痛点的解决) 1 主要回答: 1.客户的问题的场景我们是不是真的找到了? 2.我们为产品设定的使用场景是否真的会发生? 如果找不出有与目标用户沟通的痕迹,比如只是单纯的重复之前说过的用户痛点,可给 0 分或给低分 1 描述上次规格说明书不足的地方 0.25   2 规格说明书具体改进的内容发布在随笔上 0.75   3 用户场景描述 1 以完成某个目的为导向,按顺序描述各个操作步骤得1分.参照<构建之法>P2

软件工程-构建之法 团队作业七 成绩分配

团队:yousa_team成员:王天宁,程新松,李思雨,张翌辰,崔志雄,谭景元 王天宁:主要负责网站这部分的代码工作,以及大体方向的把握实际完成情况:很好的完成平台框架的搭建,本地的编码和测试工作,整体把握较好.(25分) 程新松:主要负责网站部分代码工作,团队博客的维护工作实际完成情况:主要负责团队的博客的撰写,尝试着放到服务器上,但是没有成功,编写测试案例(23分) 李思雨:文档的维护与管理实际完成情况:负责部分团队博客的维护,编写测试案例(22分) 张翌辰:主要负责网站部分代码工作实际完成

第9周团队作业

一.BUG BASH 我们团队这次集中找BUG时,主要发现了两个BUG BUG1: Symptom:在某些手机上,打开应用后,看到欢迎界面时就会“出现异常”,从而无法运行应用. 原因: BUG2: Symptom:手机未联网或者网络状况不好时,应用程序会直接崩溃 原因:应用向网络发送请求时是使用同步的方式,不是异步请求. BUG3: Symptom:当有些搜索没有结果时,如在搜索地点时输入“青菜”,程序会崩溃. 原因:某个函数返回的一个空结果,而后面的部分对这个结果进行引用,导致了异常的发生.

第5周团队作业1

一. 访问上学期项目团队,学习他们的得失: 经过我们对学长学姐的采访,我们发现几乎所有人在开发阶段最不愿意触碰的地方就是团队的daily scrum,尽管每个队伍有PM负责协调进度,负责撰写daily scrum,但是对于每日一个小meeting大家都表示不是很能理解.但是做完项目后,他们的感触是,daily scrum非常有必要,只有好的计划才能推动项目的进行.Daily scrum看似繁琐,但是确是最能体现团队在项目进行时问题的一个记录. 采访的团队中大部分的人对编程的兴趣远远大于文字工作.

第5周团队作业1:项目建议

在当下电子信息时代的洪潮中,团队项目的建设最火热的话题一方面是大数据信息的收集与处理,另一方面当然要算是乔布斯引领智能手机的异军突起,IOS与Android平台技术的日趋成熟使的无数手机APP软件在软件开发与设计方面大放异彩,经过我们小组的讨论,我们决定在顺应时代洪流的基础上充分发挥Android平台应用价值在平台上开发一款代码编缉器,我们小组的团队项目即是一款基于Android平台的移动端代码编辑器. (一)需求分析 在PC上的代码编辑软件我们已经司空见惯,从visual c++到codebl

团队作业4分数发布

检查项 分值 会议内容 2 代码迁入 2 心得体会或其他备注 2 燃尽图 1 会议照片 1 评论区反馈 2 基本分 10 编号 队名 博客 1 clearlove8 http://www.cnblogs.com/ThinkAlone/p/7861680.html 2 魔仙堡 http://www.cnblogs.com/zy-96/p/7861445.html 3 集大男子天团 http://www.cnblogs.com/royalchen/p/7834009.html 4 哥带你飞 http