更好的團隊合作估算方法：計畫撲克

在執行軟體專案時，常常使用截止日期來逆向計算工時，然而這種做法有時會使程式工程師無法確保完成品質，容易導致他們形成「先求有，再求好」的思維。此外，一些專案經理可能會認為程式工程師的日常工作狀況不佳，因此將初始時間乘以一個倍數作為緩衝時間。

事實上，程式工程師不會因為時間變長而變得更有效率，過度放寬截止日期不會提高他們的工作效率。

確實，工時無法精確預測，但可以採取一些方法達到「相對客觀」的估算。在整個工時評估的問題上，需求的複雜度與工時往往呈正相關，因此分析需求複雜度變得非常重要。計畫撲克（Planning Poker）是一種敏捷軟體開發中常用的估算技巧，用於評估軟體開發任務的工作量或複雜度。它是一種團隊合作的估算方法，通常在敏捷或迭代開發過程中使用。

在使用敏捷軟體開發框架（如Scrum）進行專案時，其中一個關鍵的會議是每個新專案開始時進行的計畫會議。在此會議，團隊會共同計畫他們認為在該次迭代中可以完成的工作量。團隊在這個會議中使用計畫撲克技巧，此技巧允許他們共同估算待辦工作的複雜度。

執行計畫撲克時，建議參與人數不宜過多，亞馬遜（Amazon）的Jeffrey Bezos以確保會議參與人數不超過2個比薩餐點能夠供應的人數而聞名，Steve Jobs則著稱於要求那些在會議中沒有具體目的的人離開。計畫撲克的基本流程如下：

1.團隊選擇要估算的任務或項目。
 
2.每位團隊成員手中拿著1組特殊的估算卡片，上面列有不同的數字或尺寸，例如：1、2、3、5、8、13、20、40、100（代表估算的相對大小）以及一張 "?"/"?" 卡片（代表不確定或需要進一步討論）。

3.由專案經理或項目負責人將任務的內容和要求介紹給團隊成員。

4.所有團隊成員同時選擇一張卡片，代表他們對該任務估算的工作量或複雜度。

5.當所有成員都選好卡片後，將卡片翻面，統一揭開。

6.如果估算的數字差異不大，則取得一致的估算值，進行下一個任務的估算；如果估算的數字差異較大，則進行討論，並再次進行選擇直到取得一致。

7.重複上述步驟，直到所有的任務都被估算完畢。

計畫撲克使用創造性模糊進行初步估算，同時避免深陷於絕對數字的困境。創造性模糊之所以存在，是因為現實與理想之間存在著相當大的差距，由於各種限制條件，我們無法精確地量化事物。因此，通過創造模糊的空間，可以避免對數值進行不必要的分析。對於專案經理來說，與其評估一個無法實現的時間表，不如評估更加準確客觀的時間表。這樣一來，團隊成員可以第一時間了解與專案預計時程相差多遠，同時在資源有限的情況下，也可以更好地安排需求的優先順序或尋求其他幫助。

然而，計畫撲克只是一種估算工具，而非確定性預測。它提供一種相對客觀的方式來評估工作量，但仍需要在實際執行過程中進行調整和迭代。此外，團隊成員的參與和互動至關重要，並且需要專案經理的引導和支持。

因此，在進行軟體專案時，筆者建議結合計畫撲克等估算方法和敏捷開發的原則，注重團隊合作、溝通和迭代。這樣的方式能夠更好地應對專案的不確定性，提高工作效率和品質，並確保順利完成專案目標。(作者為國立陽明交通大學資工系終身講座教授暨華邦電子講座)

亞馬遜創辦人Jeffrey Preston "Jeff" Bezos。