簡(jiǎn)介

軟件開發(fā)中的估算是個(gè)龐大的話題，我會(huì)在一系列文章中討論這個(gè)話題，這是第一篇。

我們會(huì)在很多不同場(chǎng)景下做估算，在這一系列文章中，我會(huì)盡可能涵蓋所能想到的場(chǎng)景，但觀點(diǎn)始終如一：在軟件項(xiàng)目中，不應(yīng)該基于估算做決定。對(duì)軟件產(chǎn)品提供方及其內(nèi)部和外部客戶而言，有比估算更好的替代方案，既經(jīng)濟(jì)又人性化。其中很多方案已應(yīng)用于公司實(shí)踐，發(fā)布產(chǎn)品給真實(shí)客戶，并產(chǎn)生了巨大的影響。

考慮到這個(gè)話題之繁雜，本文只針對(duì)特定場(chǎng)景，即一個(gè)scrum團(tuán)隊(duì)（或其他采用迭代式產(chǎn)品開發(fā)方法的團(tuán)隊(duì)）不使用估算來(lái)發(fā)布軟件產(chǎn)品的場(chǎng)景。規(guī)模擴(kuò)大或縮?。ㄔ黾踊驕p少團(tuán)隊(duì)成員）的問(wèn)題，在隨后一篇關(guān)于項(xiàng)目組合估算的帖子中會(huì)談及。

我們會(huì)按時(shí)發(fā)布嗎？

軟件開發(fā)團(tuán)隊(duì)在項(xiàng)目開始時(shí)以及項(xiàng)目過(guò)程中經(jīng)常被問(wèn)到這個(gè)問(wèn)題，這也是很多人認(rèn)為需要估算的主要原因。然而，多數(shù)人都在憑猜測(cè)做出的預(yù)測(cè)中掙扎著尋找確定性，這不是很諷刺嗎？我們都知道或者至少會(huì)懷疑，那不過(guò)是憑空猜數(shù)而已。我們不知道或不理解解決方案或業(yè)務(wù)領(lǐng)域，僅僅安慰自己說(shuō)這是個(gè)“經(jīng)驗(yàn)性的”或“快速而粗糙的”猜測(cè)，并為我們用這種方法做出重要商業(yè)決策進(jìn)行辯解。

開發(fā)軟件本質(zhì)上不可預(yù)測(cè)且無(wú)法重復(fù)。開發(fā)軟件時(shí)，我們不能像制造汽車零部件那樣，很容易地把工作分解成同樣尺寸、可重復(fù)生產(chǎn)的部件。與汽車生產(chǎn)不同，軟件完成前我們并不知道它到底長(zhǎng)什么樣。既然如此，怎么可能一開始就把工作分解好呢？軟件產(chǎn)品的每個(gè)迭代，新增的功能都是不同的。軟件開發(fā)是創(chuàng)造性的、不斷變化的嘗試，解決方案往往會(huì)在開發(fā)過(guò)程逐步呈現(xiàn)。正因如此，軟件項(xiàng)目中范圍不可能固定不變。即便真的可以固定范圍，越來(lái)越多的人也認(rèn)識(shí)到這是不可取的，因?yàn)檫@會(huì)阻礙（至少?zèng)]有擁抱）涌現(xiàn)的設(shè)計(jì)、需求、變化和革新。如果我們認(rèn)可項(xiàng)目的范圍始終在變，那么就不得不承認(rèn)，當(dāng)我們急急忙忙地想要“按時(shí)”“在預(yù)算內(nèi)”發(fā)布所謂固定的范圍時(shí)，交付日期就成了不斷移動(dòng)的球門柱。

如果說(shuō)“按時(shí)”和“在預(yù)算內(nèi)”通常是基于一個(gè)估算，而這個(gè)估算是交付軟件滿足預(yù)訂的需求所需要的時(shí)間和花費(fèi)，而不是具體的時(shí)間點(diǎn)或者預(yù)算約束，那么我們完全有可能比最初估算的晚一些交付軟件。我們也可能提前交付，或者我們剛剛好交付。問(wèn)題是，不管結(jié)果如何，估算有多“正確”真的很重要嗎？估算我們的工作對(duì)發(fā)布偉大的軟件或投資回報(bào)率真的會(huì)有正面或負(fù)面影響嗎？

愿景是核心

為了構(gòu)建軟件，我們需要有一個(gè)清晰的愿景，并對(duì)什么是成功達(dá)成共識(shí)。 當(dāng)開始一個(gè)有潛在價(jià)值的軟件計(jì)劃時(shí)，我們需要很好地理解高層次目標(biāo)，而不是達(dá)成目標(biāo)的細(xì)節(jié)。這樣在真正迭代的時(shí)候，我們就能夠把下次迭代如何提高產(chǎn)品質(zhì)量的即時(shí)策略與這些目標(biāo)結(jié)合起來(lái)，比如接下來(lái)要構(gòu)建什么，也就是Product Baclog里級(jí)別最高的條目。有人會(huì)試圖估算多久能夠發(fā)布軟件以達(dá)到一個(gè)或者多個(gè)高層次目標(biāo)，然后基于這個(gè)估算來(lái)做出真實(shí)的決策，我認(rèn)為這種方法很有問(wèn)題。難道我們不想讓解決方案和架構(gòu)涌現(xiàn)出來(lái)嗎？難道我們不想在產(chǎn)品逐步演化、在用戶面前變得越來(lái)越真實(shí)的時(shí)候，擁抱變化為客戶贏得競(jìng)爭(zhēng)優(yōu)勢(shì)嗎？這些都是敏捷宣言里面的關(guān)鍵原則。在真正敏捷的軟件開發(fā)方法中，我相信這些原則位于核心地位。

移除未知

與其依賴估算的準(zhǔn)確性來(lái)提高可預(yù)測(cè)性，不如移除成本和發(fā)布日期的未知因素，把未知變成已知。Product Owner可以使用具體的預(yù)算和（或）時(shí)間約束來(lái)確定發(fā)布日期：比如“澳網(wǎng)開始三天前發(fā)布澳網(wǎng)公開賽應(yīng)用”是確定的時(shí)間約束，還有“我們要用$30,000去做項(xiàng)目”是一個(gè)明確的資金預(yù)算約束。團(tuán)隊(duì)可以根據(jù)約束條件確定產(chǎn)品增量的交付日期（比如每個(gè)Sprint的結(jié)束日期），這樣團(tuán)隊(duì)在Sprint中就能把精力集中在產(chǎn)品的迭代上，并為更早發(fā)布和（或）低于預(yù)算的發(fā)布創(chuàng)造機(jī)會(huì)。每天憑一時(shí)沖動(dòng)而改變優(yōu)先級(jí)并不好。在沒有實(shí)際預(yù)算或者發(fā)布日期的時(shí)候，這種方法也很有用。不過(guò)一支能夠持續(xù)發(fā)布的成熟團(tuán)隊(duì)（和組織），就沒必要預(yù)先確定增量的發(fā)布日期了。

估算Sprint速率是一種浪費(fèi)

與其為了估算時(shí)間預(yù)先定下解決方案，或者每個(gè)Sprint預(yù)測(cè)完成多少個(gè)故事點(diǎn)，我認(rèn)為團(tuán)隊(duì)更應(yīng)該一開始就承諾：在給定的日期、資金條件下，全力開發(fā)和交付最好的產(chǎn)品。在我看來(lái)，按速率制定發(fā)布計(jì)劃（“到發(fā)布日我們可以交付多少點(diǎn)數(shù)？”或“按照當(dāng)前的需求范圍和速率，什么時(shí)候可以發(fā)布”）與迭代方法（整體的、演進(jìn)式的產(chǎn)品改善）是抵觸的，這更像是純粹的增量方法（按預(yù)先定義的Product Backlog逐個(gè)交付功能）。

當(dāng)我們做估算并使用速率作為計(jì)劃工具時(shí)，就是在假設(shè)一個(gè)時(shí)間段內(nèi)能完成多少工作。為了讓這個(gè)信息有用且有意義，我們需要記錄很多東西（即：一份詳細(xì)估算過(guò)的Product Backlog）。如果我說(shuō)花在那些最終未交付的backlog條目上的時(shí)間和金錢都浪費(fèi)掉了，大家應(yīng)該不會(huì)有太多異議，至少?gòu)木娴睦砟顏?lái)看如此。

花在那些最終交付了的backlog條目上的時(shí)間和金錢又如何呢？為了回答這個(gè)問(wèn)題，我得再問(wèn)個(gè)問(wèn)題：“Product Owner曾經(jīng)因?yàn)橐粋€(gè)故事的點(diǎn)數(shù)較小而提高它的優(yōu)先級(jí)嗎？”如果答案是“否”，那我可以推斷，在這種環(huán)境下所有的估算都是浪費(fèi)，因?yàn)楣浪悴粫?huì)帶來(lái)任何決策的變化（Product Owner僅根據(jù)故事的價(jià)值排序）；如果答案是“是”，那就是估算控制了決策，而我認(rèn)為決策應(yīng)該基于價(jià)值。先估算backlog，再根據(jù)速率制定發(fā)布計(jì)劃是一種基于成本的方法。盡管成本對(duì)于軟件項(xiàng)目和商業(yè)很重要，但如果僅僅根據(jù)成本來(lái)決策，那么我們現(xiàn)在使用的一些偉大軟件（例如Google、Fackbook、Apple、Yahoo、Spotify等公司的許多產(chǎn)品）永遠(yuǎn)不會(huì)被創(chuàng)造出來(lái)，這也可以解釋為什么世界上有那么多昂貴、臃腫的垃圾軟件。

迭代，不要估算

我認(rèn)為迭代（敏捷）開發(fā)完全是關(guān)于如何在固定成本下，用實(shí)驗(yàn)方法而非猜測(cè)，基于用戶價(jià)值和（或）商業(yè)價(jià)值做出決策。所謂固定成本是指一支固定的團(tuán)隊(duì)（例如Spotify公司的“squad”模式）按照預(yù)定的時(shí)間表發(fā)布。這個(gè)預(yù)定的時(shí)間表不同于“截止日期”：截止日期是基于想像中的約束條件為“確定的”范圍設(shè)定的發(fā)布日期。固定的成本和交付日期，讓我們更有信心去擁抱開發(fā)偉大產(chǎn)品時(shí)出現(xiàn)的寶貴的不確定性。

此外，固定的交付日期并不意味著我們?cè)诎l(fā)布之日就停止開發(fā)產(chǎn)品，我們也許早已停止開發(fā)或者選擇繼續(xù)開發(fā)。固定的交付日期僅僅意味著，我們會(huì)根據(jù)開發(fā)過(guò)程中涌現(xiàn)的或潛在的價(jià)值不斷決定繼續(xù)或停止，而不是根據(jù)特定解決方案的估算成本做決定。

專注于拆分

我認(rèn)為，從團(tuán)隊(duì)的角度出發(fā)，提高拆分用戶故事的能力，價(jià)值遠(yuǎn)遠(yuǎn)大于“提升速度”。而且一定要在用到時(shí)才拆分用戶故事，任何過(guò)早的拆分都是浪費(fèi)。對(duì)我而言，高效能團(tuán)隊(duì)能夠頻繁交付可用的產(chǎn)品新功能，迅速得到用戶反饋，并為用戶創(chuàng)造價(jià)值。很明顯，新功能越小，交付才會(huì)越頻繁。頻繁的交付縮短了反饋周期，為Product Owner贏得了更多的學(xué)習(xí)機(jī)會(huì)，并能更靈活地調(diào)整優(yōu)先級(jí)：涌現(xiàn)的新功能優(yōu)先級(jí)也許會(huì)高于原先以為需要但已貶值的功能，甚至產(chǎn)品的方向都可能完全改變。在我看來(lái)，這一點(diǎn)才適應(yīng)真正的商業(yè)敏捷力。

當(dāng)團(tuán)隊(duì)能夠頻繁地實(shí)現(xiàn)產(chǎn)品變更并交到用戶手上時(shí)，每個(gè)Sprint交付了多少用戶故事或功能點(diǎn)已經(jīng)不重要了。在我看來(lái)，這才是軟件項(xiàng)目努力擁抱敏捷方法的關(guān)鍵原因。但是，只有拋棄了估算，我們才能釋放全部的生產(chǎn)力來(lái)為用戶創(chuàng)造最棒的產(chǎn)品。

本文轉(zhuǎn)載自：微信公眾號(hào)? 互聯(lián)網(wǎng)plus管理新范式