文章

開卷筆記-與熊共舞

waltzing-with-bear

軟件行業最為人所話柄的事就是不準時交貨,令人覺得行業還不夠成熟,沒有工程實踐等等。在這裏有不同的陣形,例如說軟件行業本質需求變動大,亦有人認為始終是設計方式不夠扎實。然而無論如何,天真地將限期定在某一樂觀日子,而忽略當中風險,是不負責任的管理者表現。此書談軟件行業的風險管理。

在技術層面上,這書教大家以風險圖以管理風險,就是一張顯示例如交付日期各種可能性的圖表。我們自然而然會先以工作範圍定一個時程,得出一個無風無浪的樂觀交付日期,然後腦力激盪各種可以阻礙計劃的風險,其出現的指標是甚麼,會有何種影響,是不是在要徑(Critical Path)之上,發生之後的成本和時程如何,而又在有紓緩(mitigation)措施下這風險的影響如何減少,預估其發生機率。找到這一大清單的風險後,就可以用軟件工具幫手得出風險圖,以作參考。而軟件開發有幾個核心風險,幾乎每個專案都必需考慮:時程錯誤、需求膨脹、人力流失、規格崩潰。

人們有很多藉口不管理風險,專案太小不值得、不確定性太大、沒有資料、影響績效等等。這其實都是在逃避問。沒有風險的專案並不值得做,因為風險相對帶來的是價值。除了藉口,有時候在正向思考的團隊,說出風險變成禁忌,一眾 can-do 態度,不容有人潑冷水。只有當風險不再是團隊口中的禁忌,風險得到管理時,團隊才可以積極地去冒險,找出更多的價值,隊員得到個人成長。將不確定性限制在一定範圍後,可以用最少成本預防。列出風險,可釐清隱晦不明的責任歸屬,並讓團隊聚焦在真正需要注意的地方。

作者特別用幾個篇章來談價值,軟件的價值也必需可量化,其中成本和報酬也必需跟風險有一樣的精細度。軟件的風險與價值是相對的,因為軟件值不得值得做,也就是值不值得冒某個風險。在量化分析各個風險的同時,也要有相對相當精確度的價值評估、分析、量化,然後才可以排優先次序,權行每個軟件功能價值與風險,決定要有甚麼功能。而作者認為,將軟件切分成不同版本,分階段交付,是降低風險的好方法。這還可以因應不同的形勢變化,邊交付邊決定某些功能的去留增減。這也就是敏捷開發談的東西。這在開發上必需要令到軟件可分段交付,在開發方法上需要如單元測試、重構、連續整合等等工程實踐來達成。

本書的譯者與作者對話,特別摘錄了一個有趣的問題:書在談風險管理的步驟上要求要將軟件一開始定義好不同元件,好用來作計劃和評估,有點像瀑布式開發。但一般敏捷開發都不會一開始談好所有元件,而是以有機的方式,逐個版本給用戶回饋,接近真正需求並改善設計。作者對此的回應是:他認為一開始就設計好是有可能的,而非得一定靠用戶回饋迴路才可以改善設計。事實上,有些軟件是不可能以回饋方式開發,例如太空船用的軟件,這時就得用上仔細設計,並考慮所有會出狀況的發生風險了。

回應

  1. Hi Jacky, quick questions.

    where you buy the books? you read a lot, it must be cost alot

    how do you discover book to read next?

  2. 這可以發表一篇吧..

    主要是樂文、誠品,有時是博客來
    基本上看到有興趣不太貴就會買,買買埋埋都應該幾多$…
    會平衡小說類與非小說類,
    至於下一本讀甚麼,主要是會轉類型,例如小說->科學->技術 ….

*