团队贡献分分配规则

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

一、评分制度

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

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

1. 工作记录

A.通过什么来记录？

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

链接：NAG2020工作记录

ScreenClip

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的数据，我们可以清晰的看到填表的次数，以及工作量的大小，并可以进行交叉分析（工作量少的队员要加油了！）：

    ScreenClip ScreenClip ScreenClip

  2. 工作重点分析

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

    ScreenClip

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

二、团队模式

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说：灵感属于业余爱好者，而职业人士总是每天持续工作。

posted @ 2020-03-19 11:32  ITAS2024  阅读(2185)  评论(5)  编辑  收藏  举报