團隊貢獻分分配規則

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