[Agile] 多數決真的能找出共識嗎?

敏捷開發講求團隊合作,往往有很多事情需要大家共同決議,最常見的不外乎圓點貼紙(dot voting),用投票的方式快速找出共識。然而,在我閱讀《失控的多數決》後,對於簡單多數決,有了些微不同的看法。彙整記錄,提醒自己別輕易把多數決與共識劃上等號。

多數決的弊病

多數決最廣為人知的弊病就是「配票」問題。類似的選項很可能只因為票源被分散的關係,最後一同落選。類似的選項越多,落選的機會也就越大,這在選項很多的狀況下,不得不特別注意。真正的共識卻落榜,就尷尬了。

多數決合適時機

多數決適合用來決定無關緊要的事項,快速取得合宜的方針。簡單、快速,這在敏捷開發中也的確是個充分的好理由。但多數決意味者掌握半數的關鍵票數,便可絕對掌握結果,若總是存在特定的「半數族群」,長久下來造成分裂的可能性也隨之增加。為了縮小勝負之間的差距,可以考慮添加一些「隨機」因素,讓少數有機會翻盤,又能夠尊重多數意見。

更優秀的表決方式

不是所有討論事項都會如此「無關緊要」,總是存在需要慎重考慮的情況,這時就需要更優秀的表決方式。在談論何者公平之前,先來對優秀做個簡單的定義:

  1. 若有成對贏家,必為最高票。
  2. 若有成對輸家,必不為最高票。
所謂的成對贏家,就是選項倆倆比較,都能勝出的那個選項;成對輸家,就是選項倆倆比較都會落敗的選項。

除了多數決之外常見的四種表決方式:

  • 兩輪決選制:多數決一次取出前兩名,前兩名再表決一次。
  • 孔多賽規則(Condorcet method):即循環賽,也就是各選項兩兩對決,積分高的獲勝。
  • 同意投票:選民可不受限多選,最後獲得最高票數的項目獲勝。
  • 波達計數法(Borda Count):每位選民選出心中最高的 N 個志願,並排序。第一順位 N 分、第二順位 N-1 分,依此類推,最後計算總分。

以下是五種表決方式對於這個優秀定義的狀況:

  • 多數決:無法保證選出成對贏家,且有可能選出成對輸家。
  • 兩輪決選制:無法保證選出成對贏家,但保證不會選出成對輸家。
  • 孔多賽規則:同成對贏家、輸家定義,符合優秀條件。但!若不存在成對贏家(三選項互咬的狀況),便選不出優秀的唯一項目。
  • 同意投票:無法保證選出成對贏家,但保證不會選出成對輸家。
  • 波達計數法:無法保證選出成對贏家,但保證不會選出成對輸家。

從上述狀況簡單看來,多數決是頗悲劇的。而孔多賽規則看起來似乎頗不賴的,但有著不存在成對贏家的尷尬狀況,且計算麻煩,不太實用。其他三種票選方式在這個定義下看起來倒是很一致,都不會選到成對輸家,所以我們再考慮相對比較「尊重」成對贏家的方式。答案是「波達計數法」,雖然不保證成對贏家最高票,但可以保證絕不會敬陪末座。

孔多賽規則的尷尬情境,要統計出來才知道,若這時才說:「阿!有平分的項目,那我們改採 xxx 方式決勝吧!」都投那麼多次票了,用什麼方法投都將難以服眾阿!
結論:想慎重點,就用波達計數法吧!

選項為「連續」的狀況

偶爾會遇到一些選項為連續數值的狀況,例如估計 story 大小。這時就可考慮使用「中位選項」,取所有人投票結果的「中位數」做為最後決議結果,如此可確保不受極端值影響。除此之外,中位選項可確保成對贏家勝出

其實估計 Story 時若出現極端值,應該是要再討論一下,瞭解一下彼此想法,不會那麼魯莽的取中位數... :p

後記

  • 其實孔多賽規則遇到沒有成對贏家的狀況時,是有個更複雜的方式去計算誰比較接近民意,稱為「孔多賽。楊格計算法」,但過於複雜,不適合平時決策使用。
  • 若波達計數法的積分不是N、N-1、N-2、...,那還叫波達計數法嗎?結果會一樣嗎?答案是否定的。若是1、1/2、1/3、... 稱為道達魯規則,這種方式可能會選出成對輸家,其他計分方式亦有可能,要特別小心。