敏捷/ XP估計

Question

我是配對編程的背景......你如何估計？一個5分的故事......分成3個任務......每個任務都由2個成員組成。這是否意味着它在一半時間內完成？

Answer 1

你估計使用點數。一對可達到的點數稱爲速度。選中此項：http://en.wikipedia.org/Planning_poker

Answer 2

大多數敏捷方法建議您應該以點爲單位進行估計。但是，有許多成功的團隊 - 包括幾個先進的高效率看板團隊 - 他們在幾個小時內就能估算出來。積分來自他們自己的遊戲，不正當的激勵和問題。因人而異。無論如何...

我聽說一組人完成一項任務的開發時間增加了25％。因此，這項任務將以62.5％的時間完成，使用兩個開發人員而不是一個開發人員。但是，知識共享的質量也經常增加。由於缺陷=返工和返工比第一次以正確的方式花費更長時間，結對編程通常會爲自己付出代價。這在不同的任務和技能水平上有所不同，例如：簡單的bug修復，新手程序員等等。

以我的經驗2/3的時間是一個不錯的棒球數字。它比1/2長，但比僅有1人少。

Sallyann Freudenberg是關於結對編程研究的好名字。你也可以檢查出維基百科頁面上的裁判：http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

Answer 3

對估計是要去多久： http://en.wikipedia.org/wiki/Pair_programming

本報告阿利斯泰爾·科克本和勞瑞·威廉姆斯在這個數字主要是承擔了由數據拿走這些。任何估算都是基於經驗 - 團隊對項目有更長的經驗，技術和成對合作的估算會更好。任何百分比，比如增加25％的配對等，只有在一開始時纔有用處 - 新項目和新技術團隊 - 除此之外，您還沒有其他基礎評估。一旦經驗開始建立，估算值將會提高。

但請記住，他們只是這一點 - 估計，這是我們的經驗幫助和知識，從我們本的理解得出未來的最佳猜測。這就像天氣預報 - 我們擁有的數據越多，預測者的經驗越豐富，但它只是一種預測，而不是現實。

這就是爲什麼分數如此之高，因爲它們可以幫助您估計一個參數 - 手頭的任務「多大」。

Answer 4

我總是強調故事大小調整過度估計。如果您可以最大限度地減少故事之間的大小差異，那麼估計就會變得不那麼有趣。也就是說，當任何兩個故事的規模差異很小時，估算活動就會失去價值，這有助於快速團隊收回估算成本，並將其推向某種生產性（如建築產品）。考慮到這一點，我會建議主動修剪積壓，並儘可能將五個小故事分成較小的小故事（仍然是薄的垂直切片）。在你的團隊經驗豐富之前，我建議你繼續有估算方，但是要對每張卡片提示1點的默認估計，並快速進行一致性檢查或討論，爲什麼有理由認爲是2或3。對於明顯大於3的任何事物，我建議挑戰以下兩個問題中的一個：「1」的基線值太小或者故事應該分開（或者更具體或者作爲史詩般追蹤）。

隨着團隊建立一個體面的速度，該活動可能有望將其從估計轉變爲單純的故事審查。那就是在計劃「這個故事有多大？」時的問題。變成「這個故事異常嗎？」後一個問題需要的時間要少得多。

Answer 5

1）考慮估算單位的一個簡單而具體的方法是完成故事所需的檢入次數。

如果您正在進行TDD，持續集成和重構，那麼您將在小塊工作中工作，保持構建綠色並定期檢查，因此在這些情況下，單個檢查可能是一個有意義的估計單位。

2）或者，考慮一天中不間斷配對時間的塊，例如在咖啡休息後，咖啡休息後到午餐，午餐後到午後休息時間，中午到回家時間 - 例如每天4個時間段......所以說4個單位是一天。這給你一個約束，你可以期望做一個interation ...

我個人去檢查的數量，因爲我可以粗略勾畫出涉及的任務，並得到簽入的想法數字。

登記數量的好處是，如果你正在配對與否，這並不重要 - 你只是追蹤你能做些什麼。