团队贡献分分配规则

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

1、评分制度

咱们的团队有7人之多，那么贡献分应当如何科学的分配，而且以这种分配方式获得队员最大的积极性，是一个十分重要的问题。咱们不但愿任何一个对小组作出卓越贡献的人，与那些作出贡献不多的人有相近的分数。因而，咱们须要一种方式来合理的评价，使全部的分数评判都有据可循。

通过讨论，小组最终对于我的的评分定为两个部分：70%工做记录+30%互评。因为总分为7*50=350分，用于工做记录的评分占245分，用于互评的占105分。

1. 工做记录

A.经过什么来记录？

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

连接：NAG2020工做记录

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. 工做重点分析

   经过咱们每一个人记录的关键词，最后能导出一个以下图所示的词云（4.6导出）。咱们能够清楚的看到，咱们团队作了哪些工做，以及哪些工做更为重要：

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}

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()

2、团队模式

1. 团队模式

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

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

2. 开发流程

在开发流程上，因为小组7我的，准备采用子瀑布+渐进式模型（《构建之法》P106），3对小组之间所作的工做相对独立，对于每一小组的模块能够单独地进行测试。

固然为了不子瀑布模型到最后才能看到结果的劣势，咱们在架构设计阶段就须要对Product backlog进行较为详尽的设计（详见如何制定Product backlog？），不只要区分每个结队小组要作什么模块，并且设计到每个小组每一次迭代的结果。最终在每一次迭代以后，整个小组就能进行一次集成，集成结束后进入第二次迭代。这样产品能迅速出效果，借鉴了渐进交付式流程的思想。

最终开发流程图以下：

3. 要求及规则

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

2. 说到作到：即“按时交付”。若是没有及时完成本身部分的工做或者完成质量较差，在工做记录中采起相应的减分措施，会减去其承担工做时大部分的分数。

3. 接受团队赋予的角色并按要求工做：团队要完成任务，有不少事情要作，我的的能力即便很强，也要按照团队制定的流程工做，而不要认为本身不受流程约束。

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

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

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