開發人員使用什麼方法來評估任務？

大家好！開始發展所需的理論非常廣泛。有些專家（Java 和其他語言的後端開發人員）擁有更多的知識，而其他人（例如 JavaScript - React Native 的前端開發人員）擁有的知識則少一些。然而，他們兩人不僅必須擁有大量的技術知識，而且還必須擁有大量的「組織」知識。這種「組織」知識是前端和後端開發人員的交叉點之一。 今天我想談談這種非技術性、組織性知識的一個面向──關於任務評估（估計）。由於我只在敏捷方法論（實際上被認為是最受歡迎的）中工作，因此在其子部分Scrum中，我將考慮Scrum背景下的任務評估。我馬上就會說，評估（也稱為估計）是很困難的。對我個人來說，作為一名開發人員，這是工作中最困難/最不受歡迎的方面之一。有許多不同的因素需要考慮，這些因素會影響任務的評估。同時，進一步的發展計劃將基於您的預測。

如果您沒有獲得正確的評級怎麼辦？

如果開發人員在一項任務上花費的時間比最終花費的時間多，那麼他可能看起來不是最好的專家，因為估計非常不準確。可以說，一根手指伸向天空。同時，如果開發人員沒有在預計的時間內進行投資，他就會危及客戶發布產品/新功能的計畫。這是一門生意，而生意就意味著金錢，很少有顧客會喜歡這樣的穿刺。 這其實就是我不喜歡估算的原因，因為有時很難確定完成任務的確切時間。

時間是如何評估的？

通常，估算以小時或故事點為單位進行。就我個人而言，我更接近故事點的評估過程。如果手錶是有形的東西，那麼可能會被誤解，故事點則與其他更抽象的東西有關。通常，軟體開發團隊會以時間格式給予估算：小時、天、週、月。這種時間估計主要基於個人經驗、猜測或直覺。在這種情況下，開發人員只需查看任務並估計需要多長時間。因此，它們很少是準確的，因為有太多因素會影響完成工作的最後期限。因此，許多按照敏捷方法工作的團隊都使用故事點。讓我們弄清楚一下。

什麼是故事點

故事點是一種衡量單位，表示對完全實現某個工作領域（功能）所需的總工作量的評估。也就是這麼一個相對的複雜度。團隊根據工作的複雜性、工作範圍以及風險或不確定性來分配故事點。通常，分配這些值是為了更有效地將工作分解為更小的部分，從而消除不確定性。隨著時間的推移，這可以幫助團隊了解他們在給定時間內可以實現的目標，並幫助他們更準確地規劃下一個工作領域。這對你來說似乎完全違反直覺，但這種抽象實際上非常有用：它促使團隊對工作的複雜性做出更艱難的決定。讓我們看看在規劃中使用故事點的一些原因：

• 可以避免時間間隔的估計不準確；
• 與隨時間估算不同，間接成本可以更好地考慮：團隊成員和客戶之間的溝通、各種團隊討論和計劃以及不可預見的情況；
• 每個團隊都會以不同的標準對工作進行評分，這意味著他們的速度（以分數衡量）會有所不同；
• 透過定義分配每個故事點的比例，您可以快速分配點，而不會產生太多爭議。

如何不使用故事點

不幸的是，故事點經常被用於其他目的。當故事點被用來評估人員、定義詳細的截止日期和資源時，以及當它們被錯誤地視為績效衡量標準時，它們可能會有缺陷。相反，團隊需要使用它們來了解每項任務的工作量/複雜性並確定優先順序。可能應該先完成被評為較困難的部分，以便它們可以在衝刺結束之前完成，但較容易的部分可以推遲到以後。讓我提醒您Scrum方法論中的 sprint 是什麼： 這個時間段有多長是在開發之初由團隊和客戶協議確定的。這可以是兩週或一個月的時間段，或任何其他時間段。通常，任務估計是在衝刺開始時進行的，以便規劃衝刺結束時可能完成的工作量，此時已完成的工作交付給客戶。 它可以幫助您查看產品開發的進度，接收客戶的回饋並根據客戶的願景調整專案的開發。但我們仍然有點離題：讓我們回到估計。僅由一名開發人員評估任務過於主觀。因此，通常來說，這是團隊合作。團隊評估有很多技巧。今天我們就來看看其中最常使用的－Scrum 撲克。這項技術需要一位經理，他將是像這個Scrum 撲克遊戲的領導者那樣的人。這可能是專門從事Scrum Master或PM的人。

什麼是 Scrum 撲克

Scrum 撲克- 或計劃撲克 - 是一種基於達成協議的評估技術。主要用於評估軟體開發過程中未來工作的複雜性或要解決的任務的相對量。我會立即指出，Scrum 撲克是開發中的常見做法，您肯定需要知道它是什麼樣的野獸。對於此過程，我們通常使用某種應用程式或網站來組織對特定任務的團隊評估。這是怎麼發生的？團隊採用待辦事項（新任務、功能），簡要討論可能的陷阱以及與之相關的其他細微差別。然後每位參與者選擇一張卡片，上面的數字代表他們的難度等級。哦，對了，估算的時候，用的不是通常的級數，而是斐波那契數列。 斐波那契數列在Scrum 撲克中非常流行，因為它們之間的差距隨著時間的推移而增加（讓人想起金字塔等級）。有些任務非常複雜，少量的故事點無法實現。 異常卡片說明：

端點數量未知

無限長的任務

需要休息一下

較罕見的估算方法：

• T 卹尺寸 - S、M、L、XL
• 或狗——吉娃娃、哈巴狗、臘腸犬、鬥牛犬等（在我看來，這是評估任務的最奇怪的單位=D）

然後，團隊會比較不同開發人員對相同問題給出的估計，如果他們同意，那就太好了！如果不是，就有必要討論評估差異的原因（論點）。之後，我們可以共同得到一個單一的估計，每個人，無論是正數或負數，都會同意。那麼，為什麼撲克甚至被用來規劃一個嚴肅的軟體專案呢？畢竟，這有些奇怪。事實上，這種遊戲化鼓勵團隊成員獨立思考，要求他們與隊友同時展現自己的成果。這反過來又避免了依賴其他團隊成員的觀點。否則，經驗不足的開發人員將查看並依賴經驗豐富的團隊成員的評估，這將否定他們自己的評估的有用性。但隨著成績同時公開，基本上是不可能的了。Atlassian是 Scrum Poker 調度應用程式的範例。

任務評估範例

讓我們假設您的團隊已經確定了一定的故事點評估尺度： Scrum Poker從一項任務開始，您可以這樣評估它：

• 您以前從未使用過類似功能的實作 - +3
• 中型任務的功能 - +2
• 任務的實施具有較高的複雜性 - +3
• 為此函數編寫測試的複雜度很高 - +3

結果，您獲得了 11 個故事點，但由於沒有這樣的卡片，您提供了 13 個故事點。您的另一位同事評估了該任務：

• 之前遇到類似的問題 - +1
• 中型任務的功能 - +2
• 任務的實施具有平均複雜度 - +2
• 為此函數編寫測試的平均複雜度 - +2

結果，他得到了 7 個故事點，但斐波那契數中沒有這樣的東西，他放了一張最接近的數字 - 8 的卡片。其他團隊成員相應地根據他們的主觀觀點給出估計。接下來，您展示結果，發現幾乎所有同事都給出了 13 的估計值，除了一名開發人員給出了 8 分。在這種情況下，他獲得了發言權並給出了理由。舉個例子，他們是這樣的：他以前也解決過同樣的問題，而且這並不像看起來那麼困難，最後他說服了其他團隊成員將他們的解決方案從 13 故事改為 8 故事點，說他會幫助任何承擔這項任務的人解決這個問題。或者，最終，他會自己做。一般來說，其他人是否聽他的論點並不重要，因為無論如何，都會為這項任務分配一個評級，而團隊將繼續熟悉下一項任務。 第一次，估計將不準確，您計劃在下一段時間（衝刺）完成的工作量的估計也是如此。畢竟，這些估計都是根據估計精確做出的。一段時間後，大約三個月，團隊將開始更準確地估計任務，團隊每個衝刺可以完成的平均工作量將變得​​可見。但這是工作範圍的總體規劃，更多的是時間問題，在這種情況下可能有很多不同的因素會產生影響。例如，一位開發人員休假了兩週。也就是說，您需要劃掉一定程度的計畫工作（計畫功能）。或者一個新的開發人員加入了團隊，但你不需要完全依賴他，因為… 你需要考慮適應專案所需的時間，稱為入職。這可能是兩週，加上或減去一周，具體取決於專案的複雜程度。 今天就到這裡了，希望我對問題估計這樣的非技術性知識部分的知識有所提升。如果您想更深入地了解這個主題以及 Scrum 的細節，我強烈建議您閱讀 Jeff Sutherland 所寫的《SCRUM》一書。我不能保證後果，因為也許之後你會產生成為 Scrum Master 的惱人願望 =D