滿足您的最後期限：開發人員用來估算工作量的方法

大家好！要開始軟件開發，您需要了解大量理論。一些專家（例如，使用 Java 和其他語言的後端開發人員）了解更多，而其他人（例如，使用 JavaScript 和 React Native 的前端開發人員）可能了解得更少。也就是說，這兩個群體都必須擁有大量的技術知識和“組織”知識。這種“組織”知識是前端和後端開發人員重疊的一個領域。 今天我想談談這種非技術性的、組織性的知識的一個方面。今天我們將討論工作量估算。因為我只有使用敏捷方法的經驗（這被認為是最受歡迎的），更具體地說是 Scrum 框架，我將在Scrum的背景下考慮工作量估算。一開始，我必須說工作量估算很困難。對我來說，這是我作為開發人員工作中最具挑戰性/最不愉快的方面之一。有許多不同的因素需要考慮，這些因素會影響您對任務所需工作量的估計。此外，未來的發展計劃將基於您的估計。

如果你提供了一個錯誤的估計怎麼辦？

如果開發人員估計完成一項任務的時間遠遠多於最終花費在該任務上的時間，那麼他們的專業知識可能會受到質疑，因為估計非常不准確。換句話說，這是一個瘋狂的猜測。同時，如果開發人員沒有在預計的時間內完成工作，她就會危及客戶發布產品或新功能的計劃。這就是生意，生意就是錢。很少有顧客會對這樣的失誤感到滿意。事實上，這就是我不喜歡估算的原因——因為有時準確確定完成一項任務所需的時間非常棘手。

如何進行時間估算

通常，估算是以小時或故事點為單位的。我個人的偏好是使用故事點來進行估算。很難將具體的物理對象弄錯，但故事點更抽像一些。軟件開發團隊通常提供時間量的估計：小時、天、週、月。這些時間估計主要基於個人經驗、猜測和/或直覺。在這種情況下，開發人員只需查看任務並表達他們對需要多少時間的假設。因此，這些估計很少是準確的，因為影響工作持續時間的因素太多了。這就是為什麼許多使用敏捷方法的團隊也使用故事點的原因。讓我們開始吧！

什麼是故事點？

故事點是一種度量單位，用於表達對完全實現某項功能所需的總工作量的估計。也就是說，我們談論的是相對的複雜。團隊根據工作的複雜性、工作量以及風險或不確定性分配故事點的估計值。通常分配這些值是為了更有效地將工作分成更小的部分，從而消除歧義。隨著時間的推移，這有助於團隊了解他們在給定時間段內可以完成的工作，並幫助他們更準確地計劃後續工作。這聽起來可能完全違反直覺，但這種抽象確實很方便：它促使團隊就工作的複雜性做出艱難的決定。讓我們來看看在計劃時使用故事點的一些原因：

• 您可以避免不准確的時間估計。
• 與以時間為單位的估算不同，故事點可以讓您計算管理費用：團隊成員與客戶之間的溝通、各種團隊討論和計劃活動，以及不可預見的情況。
• 每個團隊將使用不同的尺度來估計他們的工作，這意味著他們的能力（以點為單位）會有所不同。
• 通過定義分配每個故事點的比例，您可以快速分配點而不會引起太多爭議。

如何不使用故事點

不幸的是，故事點經常被濫用。當故事點被用來評估人員、定義詳細的截止日期和資源時，以及當它們被誤認為是績效衡量標準時，它們可能會產生誤導。相反，團隊應該使用它們來了解每項任務的範圍/複雜性並設置優先級。也許被認為更困難的部分應該首先解決，這樣它們就可以在衝刺結束前完成，可能會將更容易的任務轉移到後面。讓我提醒您在Scrum方法論的背景下什麼是衝刺： 此時間段的長度在開發開始時確定，並由團隊和客戶商定。這可以是兩週或一個月的時間段，或任何其他時間段。通常，工作量估算是在每個衝刺開始時進行的，以便計劃可以在衝刺結束時完成的工作，屆時已完成的工作將交付給客戶。 該演示可幫助您查看產品開發進度、接收客戶反饋並根據客戶的願景調整項目的軌跡。但我們離題了一點。讓我們回到估計。如果只讓一個開發人員對所有任務進行估算，那就太主觀了。所以這個過程通常是一個團隊的努力。團隊可以使用多種技術來生成估算值。今天我們來看看最流行的技巧：scrum poker。此技術需要一名經理擔任scrum 撲克的主持人。這可以是scrum master或可能是PM的人。

什麼是 Scrum 撲克？

Scrum 撲克或計劃撲克是一種基於達成協議的估算技術。它主要用於估計未來工作的複雜程度或軟件開發任務的相對規模。我會馬上說scrum 撲克是一種常見的軟件開發實踐，您需要了解它的全部內容。它通常涉及一個應用程序或網站，以促進團隊協作創建對特定任務的估計。這是怎麼發生的？團隊從積壓工作中提取一些東西（一項新任務、一些功能）並簡要討論可能存在的陷阱以及與之相關的其他細微差別。然後每個參與者選擇一張卡片，卡片上的數字反映了他們的複雜性估計。哦，還有一件事，在進行這些估計時，我們使用斐波那契數列中的數字而不是普通數字。 斐波那契數列在scrum 撲克中很受歡迎，因為它們之間的差距越來越大（類似於金字塔的層次）。有些任務會非常複雜，我們無法通過少量的故事點逃脫懲罰。 有一些不尋常的卡片具有以下含義：

未知數量的端點

無限長的任務

需要休息一下

不太常見的估計方法使用：

• T 卹尺碼 — S、M、L、XL
• 犬種——吉娃娃、哈巴狗、臘腸犬、鬥牛犬等（我個人認為這是最奇怪的努力估算單位 =D）

然後，該團隊比較不同開發人員對同一任務給出的估計。如果他們同意，那就太好了！如果不是，則需要討論不同估計的原因（論據）。之後，團隊一起工作形成每個人或多或少都接受的單一估計。那麼為什麼還要用撲克來規劃嚴肅的軟件項目呢？你不得不承認這很奇怪。事實上，這種遊戲化鼓勵團隊成員獨立思考，邀請他們與隊友同時透露自己的估計。這反過來又避免了某些團隊成員依賴他人意見的情況。如果不這樣做，那麼經驗不足的開發人員會查看並專注於經驗豐富的團隊成員提供的估計，這將使他們自己的估計變得不那麼有用。但同時顯示估計值使得這基本上是不可能的。Atlassian 優惠在規劃過程中使用的 scrum 撲克應用程序。

工作量估算示例

假設您的團隊建立了以下比例來將故事點分配給估算值： 為每個任務玩Scrum 撲克，您提供如下估計：

• 您以前從未實現過類似的功能：+3
• 功能平均大小：+2
• 實施將非常複雜：+3
• 為功能編寫測試將非常複雜：+3

將每個組件加起來，你總共得到 11 個故事點，但沒有這樣的卡片，所以你建議 13。一位同事對任務提出了以下估計：

• 他以前做過類似的任務：+1
• 功能平均大小：+2
• 實現的平均複雜度：+2
• 為功能編寫測試的平均複雜度：+2

他的中間結果是 7 個故事點，但這個數字在斐波那契數列中不存在，所以他提交了一張最接近數字的卡片——8。其他團隊成員也根據自己的主觀看法做出估計。然後每個人都出示卡片，你會發現幾乎所有同事都給出了 13 的估計值，除了一位建議 8 的開發人員。在這種情況下，他可以發言說明他估計值較低的原因。假設他提供了這樣的理由：他以前做過同樣的任務，而且它並不像看起來那麼困難。最終，他說服團隊的其他成員將他們的想法從 13 個故事點改變為 8 個故事點，並表示他將幫助最終完成這項任務的人。或許他會自己做。無論如何，它不 其他人是否接受他的論點並不重要，因為不管怎樣，估計都會分配給任務，然後團隊會繼續考慮下一個。最初，估計是不准確的，對你計劃在下一個時間段（衝刺）完成的工作量的估計也是如此。畢竟，這些估計是使用估計得出的。一段時間後，也許三個月後，團隊將開始更準確地估計任務所需的時間，並且團隊在衝刺中能夠完成的平均工作量將變得​​顯而易見。但這是一個對工作範圍進行總體規劃的過程。它主要關注時間，但在這種情況下可能有許多不同的相關因素。例如，假設開發人員休假兩週。您將需要削減一定數量的計劃工作（計劃功能）。或者假設一個新的開發人員加入了團隊，但還沒有完全跟上進度，所以你需要讓她有時間通過入職流程。這可能是兩週，或多或少一周，具體取決於項目的複雜程度。今天就到這裡！我希望我稍微提高了您對工作量估算的了解，這是軟件開發的一個必要的非技術方面。如果您想更深入地了解這個主題，並了解 Scrum 的細節，我強烈建議您閱讀 Jeff Sutherland 的《SCRUM》一書。我不能對後果做出任何承諾，因為看完之後你會有一種煩人的渴望成為一名 scrum master =D