敏捷實施中的估算與實際效果 - Ottinger

歡迎變更需求
在瀑布專案的更加靜態的世界中，一個專案始於最終目標。一個人確定“系統”完成後應該是什麼樣的。考慮到這種經過精心設計，經過仔細研究的最終狀態，人們將進行仔細的功能分解，併為各個部分分配時間估計。他們會合在一起完成整個過程。如果對各部分進行了適當的描述，它們可以由並行工作的不同人員來構建。為了保持精妙的計劃到位，專案將具有“變更管理小組”。畢竟，如果有任何一件事情花費的時間比預期的要長，那麼延遲或錯誤可能會蔓延開來，使整個專案晚了。當所有零件完成並裝配在一起時，最終的圖片有望出現，美麗而完整。
儘管使這種方法是可行的，但它不適用於產品開發；這是專門為合同程式設計專案開發的一個過程。
我有一個朋友，他在一家公司中擔任董事職務，該公司開發軟體來提供服務。幾年前，他們拒絕為端點API設計（即使同意端點可能很棒），而是逐步交付API。他們從客戶那裡學習了使用該功能的早期版本，並更改​​了其願景以適應客戶的實際需求。如果它們已實施端點API設計，則該功能可能無法提供所需的效果，它開闢了新的收入機會。
在產品環境中，產品概念正在不斷修訂。我們應該交付的內容可能與我們最初計劃交付的內容有很大差異。僅此一項就喪失了瀑布過程的資格。
也就是說，讓我們檢查基於產品的世界中的估算和計劃。
 

分解估算
關鍵問題之一是功能分解僅考慮將功能構建到現有產品中的實際成本的一小部分。
儘管存在更好的方法，但有些團隊估計故事點的努力/持續時間。故事要點是XP的一項發明，已移植到Scrum和其他方法中。這樣做的想法是從幾小時和幾天的時間中抽象出來，因為人們可以做出比絕對評估更為準確的相對評估（將一項工作與另一項工作進行比較）。
這種理論似乎已經足夠好，並且在過去不存在報告更高或更低數字的壓力的情況下，已經為團隊所用。

這就是為什麼不建議將故事點“標準化”為幾天或幾小時的原因。故事要點的全部要點是抽象出實際的時鐘和日曆時間。如果要在實際時間中進行估算，那麼故事點的形式化不會帶來任何好處。
為了提出一個“更好”（更可口）的估算，開明的經理讓程式設計師分解了工作並估算了各個部分，然後將最小估算加在一起。當然，估算的總和小於程式設計師的初始估算。
這種技術消除了方程式中的風險和不確定性，僅需花費很少的精力即可完成估算。
當執行實際任務並且實際時間擴充套件到原始估算的近似值時，找到較小估算值的任何樂趣通常會消失。這不是好的估算方式。
 

更好的估算？
可以理解的是，由於軟體專案反覆出現的不可預測性，管理人員可能會選擇專注於更準確，更準確地進行預測。
最合理的要求是開發團隊提供更可靠的估算。
團隊可以為估算提供內建的更多應急時間，但是很長的估算時間使團隊看上去似乎在“打沙袋”浪費時間，比嚴格需要的時間要多。懷疑他們可能沒有為實現公司目標而努力工作；因此，經理們努力工作以“降低估算”並返回到最初的可預測性問題。
這裡的問題不在於估算，而是超出估算領域的社會力量和技術力量。問題不在於您總體上不擅長估算，而是工作有太多風險，不確定性，延遲和中斷。
我們無法估算使用哪些預測性的方法。
所以，我們能做些什麼？

• 如果我們希望將來做出正確的預測，就必須刻畫並減少系統中的混亂情況。
• 意識到我們的計劃是軟性的，我們可以透過提供完整的端到端“walking skeleton”功能來降低風險，同時檢查並改善我們的開發和交付流程。
• 我們可以減少工作量，因此我們可以進行許多小規模，可以成功透過的減少可變性的實驗。
• 團隊可以保留能力，因此可以更輕鬆地吸收變化。畢竟，如果團隊100％被利用，則沒有能力花費檢查，檢查和改進他們的工作以使其可預測和高效。
• 透過逐步交付，我們可以即時調整和改進計劃，找到更節儉的方法來實現目標，甚至可以在向使用者學習的同時調整我們的目標。