| 项目 | 内容 |
|---|---|
| 课程：北航-2020-春-软件工程 | 博客园班级博客 |
| 作业要求 | 团队贡献分分配规则 |
| 我们在这个课程的目标是 | 提升团队管理及合作能力，开发一项满意的工程项目 |
| 这个作业在哪个具体方面帮助我们实现目标 | 明确评分规则，确定团队模式 |
一、评分制度
我们的团队有7人之多，那么贡献分应当如何科学的分配，并且以这种分配方式得到队员最大的积极性，是一个十分重要的问题。我们不希望任何一个对小组做出卓越贡献的人，与那些做出贡献很少的人有相近的分数。于是，我们需要一种方式来合理的评价，使所有的分数评判都有据可循。
经过讨论，小组最终对于个人的评分定为两个部分：70%工作记录+30%互评。由于总分为7*50=350分，用于工作记录的评分占245分，用于互评的占105分。
1. 工作记录
A.通过什么来记录？
如下图所示为设计的问卷，基本上填完整个表只需要20s，而随着工作量的累加，所有人所做过的事情一目了然。
链接：NAG2020工作记录
B.在工作记录里填什么？
自己做过的工作填入工作记录表中，这些事情对小组的贡献可能很小，比如在博客园对老师的评论进行回答，也可能较大，比如承担了某次作业的核心模块。最后填写对于本次工作的自评，作为最终该工作得分的参考。其中有以下例子：
- 撰写博客
- 回答评论
- 提出某个关键的idea
- 完成A模块
- 完成A模块测试
- 团队采访
- ...
注：
- 除此之外，PM会在工作明细中记录一些负面记录，如“未参加某次会议”，“任务未按要求完成”等，组员不用记录
- 在工作后要立马记录，问卷星会同时获取填表的时间
- 时间因素很重要，最终可以对于每个人绘制工作明细及积分变化图，确保有证可寻
C.如何进行工作量自评？
大概参考以下模式，可以在此基础上进行调整。注意，我们尽量不要把任务分的粒度太粗，大模块尽量分成多个<6h的小模块完成，这样能更合理地分配贡献分。
世界上不存在完美的公平：我们所能做到的是尽可能保证相对公平，让努力的人无怨言，让无所作为的人承担自己行为的后果！
| 少 | 较少 | 中 | 较多 | 多 | 其他 | |
|---|---|---|---|---|---|---|
| 工作量 | 组织会议 | 博客评论 | 撰写博客 | 完成小模块 | 完成大模块 | 未按时完成、完成质量差 |
| 花费时间 | <1h | 1h-2h | 2h-4h | 4h-6h | 6h+ | 缺席、迟到 |
D.如何通过工作记录评分？
在期末评定分数时，我们小组集体会对工作记录进行审核，每人的基础分是50分，每多做一件事，按照工作量自评加分（比如“少+少”= 2分，“中+中”=6分，未参加会议=-3分）。注意这里的自评只用作参考，最后需要在所有人的同意下进行评分。
对具体的工作得分进行审核及修改，最后累加，可以求出每个人在工作记录这一项中占比，分配工作记录对应的245分。
E.工作记录有什么好处？
-
有迹可循：以下是截止4.6的数据，我们可以清晰的看到填表的次数，以及工作量的大小，并可以进行交叉分析（工作量少的队员要加油了！）：
-
工作重点分析
通过我们每个人记录的关键词，最后能导出一个如下图所示的词云（4.6导出）。我们可以清楚的看到，我们团队做了哪些工作，以及哪些工作更为重要：
-
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. 要求及规则
-
交流：能有效地和其他队员交流，从大的技术方向，到看似微小的问题。
-
说到做到：即“按时交付”。如果没有及时完成自己部分的工作或者完成质量较差，在工作记录中采取相应的减分措施，会减去其承担工作时大部分的分数。
-
接受团队赋予的角色并按要求工作：团队要完成任务，有很多事情要做，个人的能力即使很强，也要按照团队制定的流程工作，而不要认为自己不受流程约束。
-
全力投入团队的活动：小组会议、代码复审，都要全力以赴地参加，而不是游离于团队之外。未参加会议或迟到的队员在工作记录中采取相应的减分措施，暂定为-3分。
-
准备：在开会讨论之前，PM要做好准备工作。开始一个新功能之前，开发者要做好准备。
-
理性地工作：软件开发有很多个人的、感情驱动的因素，但是一个成熟的团队成员必须从事实和数据出发，按照流程，理性地工作。著名的艺术家Chuck Close说：灵感属于业余爱好者，而职业人士总是每天持续工作。