Neil是”拋棄估算“運動的領軍人物之一，這篇文章是他”拋棄估算”系列的開篇之作。
（本文由Agilean學院 張迎輝，高寧，滿成圓譯，侯伯薇評審）
簡介
軟件開發中的估算是個龐大的話題，我會在一系列文章中討論這個話題，這是第一篇。
我們會在很多不同場景下做估算，在這一系列文章中，我會盡可能涵蓋所能想到的場景，但觀點始終如一：在軟件項目中，不應該基于估算做決定。對軟件產品提供方及其內部和外部客戶而言，有比估算更好的替代方案，既經濟又人性化。其中很多方案已應用于公司實踐，發布產品給真實客戶，并產生了巨大的影響。
考慮到這個話題之繁雜，本文只針對特定場景，即一個scrum團隊（或其他采用迭代式產品開發方法的團隊）不使用估算來發布軟件產品的場景。規模擴大或縮?。ㄔ黾踊驕p少團隊成員）的問題，在隨后一篇關于項目組合估算的帖子中會談及。
我們會按時發布嗎？
軟件開發團隊在項目開始時以及項目過程中經常被問到這個問題，這也是很多人認為需要估算的主要原因。然而，多數人都在憑猜測做出的預測中掙扎著尋找確定性，這不是很諷刺嗎？我們都知道或者至少會懷疑，那不過是憑空猜數而已。我們不知道或不理解解決方案或業務領域，僅僅安慰自己說這是個“經驗性的”或“快速而粗糙的”猜測，并為我們用這種方法做出重要商業決策進行辯解。
開發軟件本質上不可預測且無法重復。開發軟件時，我們不能像制造汽車零部件那樣，很容易地把工作分解成同樣尺寸、可重復生產的部件。與汽車生產不同，軟件完成前我們并不知道它到底長什么樣。既然如此，怎么可能一開始就把工作分解好呢？軟件產品的每個迭代，新增的功能都是不同的。軟件開發是創造性的、不斷變化的嘗試，解決方案往往會在開發過程逐步呈現。正因如此，軟件項目中范圍不可能固定不變。即便真的可以固定范圍，越來越多的人也認識到這是不可取的，因為這會阻礙（至少沒有擁抱）涌現的設計、需求、變化和革新。如果我們認可項目的范圍始終在變，那么就不得不承認，當我們急急忙忙地想要“按時”“在預算內”發布所謂固定的范圍時，交付日期就成了不斷移動的球門柱。
如果說“按時”和“在預算內”通常是基于一個估算，而這個估算是交付軟件滿足預訂的需求所需要的時間和花費，而不是具體的時間點或者預算約束，那么我們完全有可能比最初估算的晚一些交付軟件。我們也可能提前交付，或者我們剛剛好交付。問題是，不管結果如何，估算有多“正確”真的很重要嗎？估算我們的工作對發布偉大的軟件或投資回報率真的會有正面或負面影響嗎？
愿景是核心
為了構建軟件，我們需要有一個清晰的愿景，并對什么是成功達成共識。 當開始一個有潛在價值的軟件計劃時，我們需要很好地理解高層次目標，而不是達成目標的細節。這樣在真正迭代的時候，我們就能夠把下次迭代如何提高產品質量的即時策略與這些目標結合起來，比如接下來要構建什么，也就是Product Baclog里級別最高的條目。有人會試圖估算多久能夠發布軟件以達到一個或者多個高層次目標，然后基于這個估算來做出真實的決策，我認為這種方法很有問題。難道我們不想讓解決方案和架構涌現出來嗎？難道我們不想在產品逐步演化、在用戶面前變得越來越真實的時候，擁抱變化為客戶贏得競爭優勢嗎？這些都是敏捷宣言里面的關鍵原則。在真正敏捷的軟件開發方法中，我相信這些原則位于核心地位。
移除未知
與其依賴估算的準確性來提高可預測性，不如移除成本和發布日期的未知因素，把未知變成已知。Product Owner可以使用具體的預算和（或）時間約束來確定發布日期：比如“澳網開始三天前發布澳網公開賽應用”是確定的時間約束，還有“我們要用$30,000去做項目”是一個明確的資金預算約束。團隊可以根據約束條件確定產品增量的交付日期（比如每個Sprint的結束日期），這樣團隊在Sprint中就能把精力集中在產品的迭代上，并為更早發布和（或）低于預算的發布創造機會。每天憑一時沖動而改變優先級并不好。在沒有實際預算或者發布日期的時候，這種方法也很有用。不過一支能夠持續發布的成熟團隊（和組織），就沒必要預先確定增量的發布日期了。
估算Sprint速率是一種浪費
與其為了估算時間預先定下解決方案，或者每個Sprint預測完成多少個故事點，我認為團隊更應該一開始就承諾：在給定的日期、資金條件下，全力開發和交付最好的產品。在我看來，按速率制定發布計劃（“到發布日我們可以交付多少點數？”或“按照當前的需求范圍和速率，什么時候可以發布”）與迭代方法（整體的、演進式的產品改善）是抵觸的，這更像是純粹的增量方法（按預先定義的Product Backlog逐個交付功能）。
當我們做估算并使用速率作為計劃工具時，就是在假設一個時間段內能完成多少工作。為了讓這個信息有用且有意義，我們需要記錄很多東西（即：一份詳細估算過的Product Backlog）。如果我說花在那些最終未交付的backlog條目上的時間和金錢都浪費掉了，大家應該不會有太多異議，至少從精益的理念來看如此。
花在那些最終交付了的backlog條目上的時間和金錢又如何呢？為了回答這個問題，我得再問個問題：“Product Owner曾經因為一個故事的點數較小而提高它的優先級嗎？”如果答案是“否”，那我可以推斷，在這種環境下所有的估算都是浪費，因為估算不會帶來任何決策的變化（Product Owner僅根據故事的價值排序）；如果答案是“是”，那就是估算控制了決策，而我認為決策應該基于價值。先估算backlog，再根據速率制定發布計劃是一種基于成本的方法。盡管成本對于軟件項目和商業很重要，但如果僅僅根據成本來決策，那么我們現在使用的一些偉大軟件（例如Google、Fackbook、Apple、Yahoo、Spotify等公司的許多產品）永遠不會被創造出來，這也可以解釋為什么世界上有那么多昂貴、臃腫的垃圾軟件。
迭代，不要估算
我認為迭代（敏捷）開發完全是關于如何在固定成本下，用實驗方法而非猜測，基于用戶價值和（或）商業價值做出決策。所謂固定成本是指一支固定的團隊（例如Spotify公司的“squad”模式）按照預定的時間表發布。這個預定的時間表不同于“截止日期”：截止日期是基于想像中的約束條件為“確定的”范圍設定的發布日期。固定的成本和交付日期，讓我們更有信心去擁抱開發偉大產品時出現的寶貴的不確定性。
此外，固定的交付日期并不意味著我們在發布之日就停止開發產品，我們也許早已停止開發或者選擇繼續開發。固定的交付日期僅僅意味著，我們會根據開發過程中涌現的或潛在的價值不斷決定繼續或停止，而不是根據特定解決方案的估算成本做決定。
專注于拆分
我認為，從團隊的角度出發，提高拆分用戶故事的能力，價值遠遠大于“提升速度”。而且一定要在用到時才拆分用戶故事，任何過早的拆分都是浪費。對我而言，高效能團隊能夠頻繁交付可用的產品新功能，迅速得到用戶反饋，并為用戶創造價值。很明顯，新功能越小，交付才會越頻繁。頻繁的交付縮短了反饋周期，為Product Owner贏得了更多的學習機會，并能更靈活地調整優先級：涌現的新功能優先級也許會高于原先以為需要但已貶值的功能，甚至產品的方向都可能完全改變。在我看來，這一點才適應真正的商業敏捷力。
當團隊能夠頻繁地實現產品變更并交到用戶手上時，每個Sprint交付了多少用戶故事或功能點已經不重要了。在我看來，這才是軟件項目努力擁抱敏捷方法的關鍵原因。但是，只有拋棄了估算，我們才能釋放全部的生產力來為用戶創造最棒的產品。
本文轉載自：微信公眾號? 互聯網plus管理新范式
起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識
