团队贡献分分配规则

项目 内容
课程:北航-2020-春-软件工程 博客园班级博客
作业要求 团队贡献分分配规则
我们在这个课程的目标是 提升团队管理及合作能力,开发一项满意的工程项目
这个作业在哪个具体方面帮助我们实现目标 明确评分规则,确定团队模式

一、评分制度

我们的团队有7人之多,那么贡献分应当如何科学的分配,并且以这种分配方式得到队员最大的积极性,是一个十分重要的问题。我们不希望任何一个对小组做出卓越贡献的人,与那些做出贡献很少的人有相近的分数。于是,我们需要一种方式来合理的评价,使所有的分数评判都有据可循。

经过讨论,小组最终对于个人的评分定为两个部分:70%工作记录+30%互评。由于总分为7*50=350分,用于工作记录的评分占245分,用于互评的占105分。

1. 工作记录

A.通过什么来记录?

如下图所示为设计的问卷,基本上填完整个表只需要20s,而随着工作量的累加,所有人所做过的事情一目了然。

链接:NAG2020工作记录

团队贡献分分配规则_第1张图片

B.在工作记录里填什么?

自己做过的工作填入工作记录表中,这些事情对小组的贡献可能很小,比如在博客园对老师的评论进行回答,也可能较大,比如承担了某次作业的核心模块。最后填写对于本次工作的自评,作为最终该工作得分的参考。其中有以下例子:

  1. 撰写博客
  2. 回答评论
  3. 提出某个关键的idea
  4. 完成A模块
  5. 完成A模块测试
  6. 团队采访
  7. ...

注:

  • 除此之外,PM会在工作明细中记录一些负面记录,如“未参加某次会议”,“任务未按要求完成”等,组员不用记录
  • 在工作后要立马记录,问卷星会同时获取填表的时间
  • 时间因素很重要,最终可以对于每个人绘制工作明细及积分变化图,确保有证可寻

C.如何进行工作量自评?

大概参考以下模式,可以在此基础上进行调整。注意,我们尽量不要把任务分的粒度太粗,大模块尽量分成多个<6h的小模块完成,这样能更合理地分配贡献分。

世界上不存在完美的公平:我们所能做到的是尽可能保证相对公平,让努力的人无怨言,让无所作为的人承担自己行为的后果!

较少 较多 其他
工作量 组织会议 博客评论 撰写博客 完成小模块 完成大模块 未按时完成、完成质量差
花费时间 <1h 1h-2h 2h-4h 4h-6h 6h+ 缺席、迟到

D.如何通过工作记录评分?

在期末评定分数时,我们小组集体会对工作记录进行审核,每人的基础分是50分,每多做一件事,按照工作量自评加分(比如“少+少”= 2分,“中+中”=6分,未参加会议=-3分)。注意这里的自评只用作参考,最后需要在所有人的同意下进行评分。

对具体的工作得分进行审核及修改,最后累加,可以求出每个人在工作记录这一项中占比,分配工作记录对应的245分。

E.工作记录有什么好处?

  1. 有迹可循:以下是截止4.6的数据,我们可以清晰的看到填表的次数,以及工作量的大小,并可以进行交叉分析(工作量少的队员要加油了!):

    团队贡献分分配规则_第2张图片 团队贡献分分配规则_第3张图片 团队贡献分分配规则_第4张图片
  2. 工作重点分析

    通过我们每个人记录的关键词,最后能导出一个如下图所示的词云(4.6导出)。我们可以清楚的看到,我们团队做了哪些工作,以及哪些工作更为重要:

    团队贡献分分配规则_第5张图片

  3. ScrumMeeting博客自动生成

    我们不需要手动去记录并撰写博客,我们会写一个程序,定义好时间区间,并筛选时间区间内部的工作记录,将其绘制成一个表格的形式,并且自动生成贡献图(包括燃尽图、绘制贡献随时间变化的曲线)。我们不用为ScrumMeeting所担心,能更加集中注意力于开发之中。

2. 互评

A.如何进行打分?

互评可以作为得分的另一指标,但是因为互评机制在小组内部的缺陷性(可能有包庇心理,或者产生恶性行为)不能作为主要的指标。故只占用30%,即105分。

互评在期末进行,其最重要的一点是组员之间不能得知对方的评价,否则不能保证评价过程的公正性,最终很可能需要请求外人来为小组评分进行管理。

注意每个人给其他人打分都是相对的,你可以采用十分制、五分制,甚至百分制。我们的程序最终会标准化到比例,我们只用关心相对分数的高低。

B.打分后的算法

互评采用的是基于pagerank方法:每个人对其他组员进行打分,再求评价网络的特征值中心性,源代码见结尾,如下是一个评价矩阵样例:

IOS = np.array([[0, 60, 80, 30, 50, 70, 90],
                [90, 0, 60, 60, 50, 70, 80],
                [95, 70, 0, 50, 30, 70, 90],
                [80, 70, 60, 0, 30, 70, 100],
                [100, 70, 80, 50, 0, 70, 90],
                [95, 70, 75, 20, 30, 0, 90],
                [100, 70, 90, 50, 30, 70, 0], ], dtype=float)

其中矩阵IOS[i][j]表示i对j的打分,每个人对自己的打分均无效,按照此样例,最后我们计算得到如下权重结果:

求平均值的方法:
0.1943565415640354 0.14408315671547983 0.1562861288959408 0.09028915322751717 0.07898472468433956 0.14591700964047524 0.19008328527221202 
求pagerank的方法:
{0: 0.18136266441548196, 1: 0.14413252721735298, 2: 0.1558869740926204, 3: 0.10145840901984793, 4: 0.09361891909122047, 5: 0.1462122444804719, 6: 0.17732826168300472}

团队贡献分分配规则_第6张图片

pagerank(节点大小)相对于平均值(节点颜色)来说鲁棒性更高,也更可靠,对于网络中心性更高的节点的话语权更高,如图所示的0号就要比4号的话语权要高,故0号的评价也更权威和可靠。

import matplotlib.pyplot as plt
import networkx as nx
import numpy as np

N = IOS.shape[0]
for i in range(N):
    IOS[i][i] = 0
    IOS[i] /= sum(IOS[i])
print(IOS)

G = nx.DiGraph()
for i in range(N):
    G.add_node(i)
    for j in range(N):
        G.add_edge(i, j, weight=IOS[i][j])

print("求平均值的方法:")
for i in range(N):
    G.nodes[i]['average'] = sum(IOS[:, i])/N
    print(sum(IOS[:, i])/N, end=' ')
print()

print("求pagerank的方法:")
pr = nx.pagerank(G, alpha=0.85)
print(pr)
assert abs(sum(pr.values()) - 1) < 1e-5

nx.set_node_attributes(G, name='pagerank', values=pr)
node_size = [x['pagerank'] * 5000 for v, x in G.nodes(data=True)]
node_color = [G.nodes[node]['average'] for node in G.nodes]
edge_size = [float(d['weight'])*10 for (u, v, d) in G.edges(data=True)]
nx.draw(G, with_labels=True, node_size=node_size, node_color = node_color,
        width=edge_size, font_color='W')  # "#6CB6FF"
plt.show()

二、团队模式

1. 团队模式

读《构建之法》的团队模式中,详细对比了9种团队模式的优缺点,最后分析得到了作为一个软件工程的7人小团队,以一个功能团队或者业余剧团的模式最佳,准确的说是两种模式的结合体:

  • \(7=1+2*3\) ,即小组中一个PM和两个3人小组(分别对应前端和后端)
  • 3人小组内部交流紧密,对互相之间的工作较为熟悉,如一个小型业余剧团
  • 前端、后端、PM之间相互合作,制定较为严密的接口,如一个功能团队
  • PM负责整个工作流程的调整和工作的分配,并且可以参与部分工作

2. 开发流程

在开发流程上,由于小组7个人,准备采用子瀑布+渐进式模型(《构建之法》P106),3对小组之间所做的工作相对独立,对于每一小组的模块可以单独地进行测试。

团队贡献分分配规则_第7张图片

当然为了避免子瀑布模型到最后才能看到结果的劣势,我们在架构设计阶段就需要对Product backlog进行较为详尽的设计(详见如何制定Product backlog?),不仅要区分每一个结队小组要做什么模块,而且设计到每一个小组每一次迭代的结果。最终在每一次迭代之后,整个小组就能进行一次集成,集成结束后进入第二次迭代。这样产品能迅速出效果,借鉴了渐进交付式流程的思想。

最终开发流程图如下:

团队贡献分分配规则_第8张图片

3. 要求及规则

  1. 交流:能有效地和其他队员交流,从大的技术方向,到看似微小的问题。

  2. 说到做到:即“按时交付”。如果没有及时完成自己部分的工作或者完成质量较差,在工作记录中采取相应的减分措施,会减去其承担工作时大部分的分数。

  3. 接受团队赋予的角色并按要求工作:团队要完成任务,有很多事情要做,个人的能力即使很强,也要按照团队制定的流程工作,而不要认为自己不受流程约束。

  4. 全力投入团队的活动:小组会议、代码复审,都要全力以赴地参加,而不是游离于团队之外。未参加会议或迟到的队员在工作记录中采取相应的减分措施,暂定为-3分。

  5. 准备:在开会讨论之前,PM要做好准备工作。开始一个新功能之前,开发者要做好准备。

  6. 理性地工作:软件开发有很多个人的、感情驱动的因素,但是一个成熟的团队成员必须从事实和数据出发,按照流程,理性地工作。著名的艺术家Chuck Close说:灵感属于业余爱好者,而职业人士总是每天持续工作。

你可能感兴趣的:(团队贡献分分配规则)