| 項目 | 內容 |
|---|---|
| 課程：北航-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說：靈感屬於業余愛好者，而職業人士總是每天持續工作。