如何在Scrum中拋棄估算活動

0 評論 9879 瀏覽 6 收藏 12 分鐘

Neil是”拋棄估算“運(yùn)動的領(lǐng)軍人物之一,這篇文章是他”拋棄估算”系列的開篇之作。

(本文由Agilean學(xué)院 張迎輝,高寧,滿成圓譯,侯伯薇評審)

簡介

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

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

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

我們會按時發(fā)布嗎?

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

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

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

愿景是核心

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

移除未知

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

估算Sprint速率是一種浪費

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

當(dāng)我們做估算并使用速率作為計劃工具時,就是在假設(shè)一個時間段內(nèi)能完成多少工作。為了讓這個信息有用且有意義,我們需要記錄很多東西(即:一份詳細(xì)估算過的Product Backlog)。如果我說花在那些最終未交付的backlog條目上的時間和金錢都浪費掉了,大家應(yīng)該不會有太多異議,至少從精益的理念來看如此。

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

迭代,不要估算

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

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

專注于拆分

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

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

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!