天天看點

《精益軟體度量——實踐者的觀察與思考》—第1章1.1節精益軟體開發的度量體系

本節書摘來自異步社群《精益軟體度量——實踐者的觀察與思考》一書中的第1章1.1節精益軟體開發的度量體系,作者張松,更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

第1章 度量謎題

精益軟體度量——實踐者的觀察與思考

“我們所能擁有的最美好的經曆是感受到神秘,它是觸發所有真正藝術和科學起源的基本情感。”

艾爾伯特·愛因斯坦(1879—1955)

按照ieee的定義,“軟體工程是将系統化、規則,以及可控的體系方法,應用于軟體設計、開發、操作和維護;換言之,即工程理念在軟體中的貫徹。”1看上去很美,不是嗎?當我們看到一個又一個軟體開發組織,特别是大型的組織,特别是擁有輝煌曆史的組織,把過程可控作為主要的管理目标時,一次又一次地驚訝于人們是如此容易被誤導,而我自己在開發管理的日常工作中,軟體工程那些條條框框所帶來的虛假的安全感,也曾使我一次又一次地迷失于其中。反思之後,我現在不得不重新審視軟體開發的目标和軟體工程方法的目的。

可控應該隻是我們在軟體開發管理中期望優化的屬性之一,而不是全部。退一步講,奧運會的口号或許比ieee的定義更好地诠釋了我們的目标——“更快,更高,更強”,還有一句俗話——“多、快、好、省”,我感覺也比ieee的那句話更全面。但是為什麼人們的注意力都放在了可控性上呢?雖然可控的生産過程可以幫助管理人員更有針對性地優化和改進。不過在向“多、快、好、省”的方向前進的過程中,管理層和項目管理人員的避險本能,在相當程度上扭曲了我們的注意力,有意無意地遺失了原始的目标。

風險源于不确定性。然而軟體之是以“軟”,就是由其生命周期中所面對的變化和不确定所決定的;從另一個角度講,不确定性又是與創新如影随行。跟其他行業相比,軟體領域的創新之活躍也不能不說與此密切相關,反過來說,那些非常确定、穩定的東西或許就不應該用軟體來實作,既然要開發軟體,就要正視其固有的變化性,利用其變化性取得優勢。

roger martin在他的著作《the design of business: why design thinking is the next competitive advantage》把知識的演進用一個知識漏鬥(knowledge funnel)生動形象地描述了出來。這個漏鬥總是從一個問題開始,需要經過謎題(mystery)、啟發(heuristic)和算法(algorithm)3個階段2 ,如圖1-1所示。

《精益軟體度量——實踐者的觀察與思考》—第1章1.1節精益軟體開發的度量體系

roger martin認為,複雜問題的解決總是從謎題階段開始。探索一個神秘的問題,可能會有無限種可能的方式。以我們的交通工具為例,人類一直在孜孜以求地擷取更快更好的交通工具。那麼如果說“更好的交通工具”是一個謎題,經過了幾千年的摸索,在工業革命之前,交通工具這個謎題曾經已經被降解成一系列的啟發式的問題。其中的兩個可能是:更好的馬車和更好的帆船。相對于謎題,啟發式問題是将探索的領域縮小到一個更加可控、可管理的大小。當有了這兩個啟發式的問題之後,人們就傾向于不再去考慮“更好的交通工具”這麼一個沒邊兒的問題,目标就變成了“如何制作更精緻的馬車,讓馬車更輕便、更結實”,“如何制作更大的帆船和有效的風帆,讓帆船載貨量更大,速度更快”。問題的解決聚焦在了産品的更新和演進,這兩個問題又被進一步降解成了一系列的算法化問題。算法化的問題指的是已經有固定的公式、模式來解決的問題。對于馬車和帆船的例子來講,馬車和帆船的制作就是一個算法化的問題,經過訓練的工匠能夠依據固定的流程和工藝,順利地重複制作多個産品。

不過世界并沒有就此止步。到了工業革命之後,伴随着技術限制的突破,“更好的馬車”和“更好的帆船”,這兩個啟發性的問題已經不再合理。我們需要重新回到“更好的交通工具”這個命題,将其降解成了另外一系列問題,“更好的汽車”、“更好的輪船”、“更好的飛機”……而那些醉心于舊的啟發性和算法性問題的人們或是行業,逐漸被時代所淘汰。我們可以看到,随着時間的變化、場景的轉換(陸地、海洋,還有天空、太空)、科技的突破,我們要解決的基本謎題可能會降解出不同的啟發式問題。

回到軟體開發這個謎題上來,gerald m. weinberg在他的《品質·軟體·管理—系統思路》中寫到“雖然人類的大腦或多或少存在些許的差别,然而都有一定的限制;随着程式規模的不斷增加,軟體的複雜度也将至少以平方的速度增加。”3weinberg稱其為自然軟體動力學。weinberg認為“軟體工程學的曆史過程,也就是人類試圖通過建立簡化方法,降低随着問題規模的擴大而提高的問題複雜度,進而不斷對規模/複雜度動力提出挑戰的曆史過程。如果沒有這種追求,也就不需要軟體工程專業了。”

軟體開發這個謎題,就像其他複雜而又會随着時間和場景不斷轉移重心的謎題一樣,我們似乎也有無數種的方式來做到一定程度的簡化,在某種程度上或是在某個方面上解決了這個問題。ieee對軟體工程的定義,“系統化、規則,并且可控”就是對這個謎題在一個次元(可控性)上簡化而得出的一個啟發式問題。

roger在書中提出了兩種思考問題的方式:分析性思維和啟發性思維4。分析性思維的驅動力是标準化,消除個體的判斷所帶來的偏見和差異,而啟發性思維的驅動力是發現和創新。這兩種思路在具體實作上展現出的差別在于,分析性思維傾向于可靠性,而啟發性思維傾向于有效性。

ieee的這個定義,因為并不直接關注更好地開發軟體本身,明顯帶着可靠性的傾向,對于有效性則顯得缺乏應有的關注。我猜測這應該是1965年到1985年軟體危機的産物。那個時代,計算機行業剛剛擺脫萌芽期,硬體能力大幅提升,人們開始在各種領域嘗試用計算機軟體來解決愈來愈複雜的問題。大型軟體項目紛紛出現,可又紛紛失敗,軟體開發就像怪獸,失去了控制,主要的表現是大幅地逾時和超預算,又或是軟體的品質極不靠譜。為了解決這個謎題,可靠性似乎是理所當然的,也是最迫切的切入點。

度量體系給人的直覺感受就是可以提高開發過程和開發結果的可靠性,但可靠和成功,這兩者真的是等價的嗎?度量本身似乎就是一個分析性思維的産物,但這并不妨礙我們回歸問題本身,同時利用分析性和啟發性思維,判斷到底哪些要素跟“成功”更相關,并嘗試用一個度量體系來幫助我們在動蕩的環境中捕捉和把控這些要素。

1the institute of electrical and electronics ehgineers, 1990。

2 martin, 2009

3傑拉爾德·溫伯格, 2004, 頁 169

4martin, 2009

本文僅用于學習和交流目的,不代表異步社群觀點。非商業轉載請注明作譯者、出處,并保留本文的原始連結。

1.1 精益軟體開發的度量體系

度量本身不是目的,是手段。我問過很多人,你們這兒度量資訊是在什麼地方用呀?我經常聽到的是,“現在不是都要用數字說話嘛,咱得搞點兒量化管理”,“這玩意兒(數字)就是給上面看看,沒啥用”,“沒這些數字,我怎麼知道下面的人幹得咋樣?”我們發現:

在很多情況下,資料的生産者不是資料的使用者;

資料的生産者沒什麼動力去分辨資訊的價值,也不關心資訊準确與否;

資料的生産者關心的是資料是否會對自己帶來懲罰或是收益,而不是資料跟軟體開發的關系;

在很多管理者的認識當中,度量的主要目的,是確定事情在掌控之中,為的是獲得可靠性和安全感;

相對于“更高效的開發軟體”這樣模糊的目标而言,很多一線人員對度量名額的使用其實更加一個簡單、清晰、樸實——一旦開發出了問題,一個自我保護的理由就是“我已經滿足了度量的要求了呀?”

軟體項目中可能出現各種各樣的沖突,權衡并把握住進度、品質和人員能力提升等各種不同目标,總是要消耗掉項目管理人員很多的腦細胞。可是不管多麼努力,做出的決定仍然不是得罪了這個,就是讓那一個不爽。 度量體系中的名額通常是那些複雜、模糊的目标經過分解和簡化的結果。一套度量體系被實施之後,很多人都有一種光明初現的感覺,好像做決定變得有章可循,容易多了。出于趨利避害的考慮,人們經常會把目光聚焦在片面滿足相對明确的名額上,回避了對綜合的項目目标和複雜上下文的思考和權衡。

為了規避名額替代目标的陷阱,我們希望在設計和營運度量體系的時候,将各類相關人員都融入到一個共同的理念之下。

精益的一個核心理念是持續改進,豐田澳洲技術中心(toyota technical center – australia)對持續改進的诠釋是:“我們從來不認為目前的成功是我們最終的成就。我們從來不會滿足于目前所處的位置,而是會一直竭盡全力,尋求最佳的思路持續改善我們的工作:我們熱衷于創造更好的替代方案,質疑已有的成果,尋求新的成功定義”1。挺複雜的一句話,咱老祖宗在3000多年前,隻用了9個字就把這事兒說清楚了。商湯王,也就是商朝的開國君主,在他自己的洗澡盆兒上刻了一行字以自勉:“苟日新,日日新,又日新”2,就是提醒自己:棄舊圖新是每天都要幹的事兒。

如圖1-2所示,在理念上,我們希望把度量的重心從“控制”轉向“改進”。雖然控制和改進都是對系統采取的幹預性措施,“控制”給人造成的心理暗示是圍繞着靜态目标而行動;而“改進”則将動态的目标植入人們的思維模式。這有助于我們在識别軟體開發的成功路徑時,由可靠性轉向一個更廣泛的視角。

在這樣的理念指導下,度量體系的作用就是提供資訊來幫我們知道現在哪裡,距離目标到底有多遠,我們是否在向目标前進,進展的程度如何。是以簡單地說,度量是通過對目标位置、相對位置、移動方向的描述,幫助組織達成其業務目标。

《精益軟體度量——實踐者的觀察與思考》—第1章1.1節精益軟體開發的度量體系

我們把度量體系的實作分成3個不同的層次 ——理念、設計、應用,如圖1-3所示。

《精益軟體度量——實踐者的觀察與思考》—第1章1.1節精益軟體開發的度量體系

在後續的第2、3、4章,我們會從組織目标、軟體産品開發過程中的決策場景,以及名額體系架構3方面來分析度量體系的設計。第5章至第12章會系統地讨論幾個主要的度量次元。而在最後的3章裡,将會嘗試驗證導入和推廣實施兩個階段,讨論如何在一個組織内建立起一個有效、有價值的度量機制。

不過在那之前,我們需要進一步就理念上澄清一下,本書中的度量是什麼?不是什麼?

《大學》第三章:“湯之《盤銘》曰:‘苟日新,日日新,又日新。’”

繼續閱讀