複雜度 – 軟體開發中最值得警惕的問題

複雜度
畫一個圓圈，圓圈裡面的部分代表你已經掌握的知識，圓圈外面是你未知的領域，圓形的線條代表目前狀態下，那些你已經認識到但還沒有被掌握的地區。
結論是你掌握得越多，你所認識到未掌握的東西也越多。

如果把這個比喻用於軟體開發過程，也是一個很有意思的現象:
這次圓圈裡面的部分代表複雜度(且不管複雜度具體應當包括哪些，怎樣衡量)，圓圈外面的部分代表風險，圓形的線條則代表項目過程中有可能遇到的風險。
結論是複雜度越高，項目的風險越大。

從字面意義理解複雜度，上面的結論是顯而易見的，但在具體項目中，我們卻經常因錯誤的主觀判斷，被複雜度擊倒。

有人會想到應當有個成熟度等級的因素，即對於同樣的複雜度(儘管沒有方法準確衡量，但我們假設在概念上已經有了)，成熟度等級越高，風險當然就會越低，就是說上面這個比喻的結論是錯誤的。
其實，複雜度的概念中應當包含對成熟度等級的考量，因為顯而易見的事實是，對於相同的問題，在問題域方面能力越強的人，完成它會越容易。就是說對於他而言複雜度比較低，但對於其他人可能複雜度就比較高。成熟度等級只是複雜度計算的一個因子，以反比的關係影響複雜度的值。

一些零散的思維
我們每天都在學習。拚命作項目過程中，我們會獲得項目中使用的具體技術相關的知識，獲得專案管理等項目過程相關比較綜合的知識和經驗。閑時總會閱讀很多技術文章，有針對性地深入研究。這些行為都是在提高自身的成熟度等級，降低解決問題時的複雜度。

個人覺得對某項技術掌握非常好，引入到了團隊/項目中，可結果不一定非常理想。因為使用相同的技術，對團隊不同人而言複雜度不一樣，它對團隊整體的複雜度決定它的運用效果。

技術功底比較強的專案經理，或者技術經理/總監等，他們考慮問題會比較全面些，就是說根據他們的經驗，對複雜度、風險方面的綜合性考慮會比較多。因此就會出現很多的現象: 他們常常對某個實現方案想追根究底，對準備新運用的技術提出很多質疑。他們希望多瞭解，然後用自己的經驗去計算這個複雜度的模型，進行評估決策。有時結果是堅決的反對使用某種技術或方案。
這個現象嚴重點的情況下，部屬就會覺得比較壓抑，沒有太多發揮、鍛煉的機會。
大家討論比較多的一個管理方面的問題(也經常提到諸葛亮的例子)，即領導太強，部屬可能很弱。
這些情況下，出發點應當主要是想評估和控制複雜度，但採用的方式帶來了管理上比較嚴重的負面效果。

商業產品的宣傳資料都會宣揚產品的特點，而隱藏產品本身包含的複雜度。有時候組織的決策層極度看好這個產品帶來的市場價值，卻不瞭解它對於組織而言的複雜度，急切地在組織內推廣運用，因此效果可能並不理想。有時開發人員自己也因產品的特性而影響了對複雜度的考量，而覺得該產品解決特定問題很好，實際運用結果可能證實並非是一個好的解決方案。

對技術掌握的成熟度等級可以降低運用的複雜度，因此可以投入成本學習研究，可以降低複雜度；採用迭代過程循序漸進的方式運用，一方面將複雜度分散到各個迭代階段進行解決，另一方面在迭代過程中逐步獲得的知識，也可以降低複雜度。

越是放光的技術、思想，越有可能影響技術人員對它的複雜度的判斷，因為人的思想是主觀的、感性的。放光的技術、思想對技術人員的感性衝擊，不亞於美女的效應，久經情場的老手對這種誘惑就能表現出比較強的把握度。

對複雜度的錯誤評估，經常是項目不順利的根本原因。

複雜度並不適用於加法運算，例如同樣的問題，分解成1000個功能點，對每個功能點採用複雜度最低的方案，這種情況該問題的總體複雜度可能並不是最低。例如採用一個複雜度較高、較通用一些的方案來解決這1000個功能點，或者是解決裡面的500個功能點，這時該問題的總體複雜度可能更低(好像還是可以用加法得到這個結果，不過不是簡單的∑min(Xn)的關係)。
這隻是可能的情況，一個複雜度較高的解決方案在團隊中的運用，前面已經提到了它的作用方式。
但這最有可能出問題，因為作為技術負責人而言，理所當然的覺得某個複雜度較高的解決方案，對於項目總體的作用效果可能會比較明顯，即可以降低項目複雜度，但卻忽略或過低的評估它在團隊上的作用原則。

瀑布模型具有複雜度，如果組織在流程管理方面的成熟度等級很高，那麼瀑布模型運用的複雜度就低，能夠得到瀑布模型期望的效果。敏捷開發在開發流程上簡化，降低流程管理本身的複雜度；結對程式設計能夠提升個體的工作效率，提高品質，也能用複雜度來解釋？也許，在有向心力的創業團隊中，解決問題常能事半功倍；組織的各種激勵策略，都是為了提高員工工作效率；領導力優秀的管理者，都有各自獨特的方法激勵部屬。同樣的問題，人們願意投入更大的精力去解決、研究，其實一方面也就將學習，將自身能力提升的過程進行壓縮(應當不止於此，個人、團隊的效率問題可能並不是複雜度能夠解釋的)。
敏捷並非適用於所有組織，因為它將瀑布模型中被流程化的東西再次綜合起來，轉移到組織的個體單元上，也就是組織對流程管理的複雜度，被分發到組織的個體單元，輔助一些其它措施，例如迭代，例如結對程式設計中互相監督、學習、激勵等方式，使得這個複雜度降低(其實就是跟前面將問題分解為1000個功能點的情境採用了相反的方式，也許這是管理方面跟技術方面的區別，也有可能是軟體領域的管理跟其它領域的區別)。
如果這樣來理解，可以比較明顯的得到一個結論: 敏捷適合中、大型的組織，而並非小型組織。因為小型組織的競爭力，或者說運營管理的關鍵問題不在於流程上，而敏捷為了達到這個目的是添加了附加成本和風險的。人員流動而造成的組織知識的流失，影響比較大，擁有良好企業文化、理念、向心力的組織，運用風險會比較小，否則將是個巨大的隱患，或者以後可能需要投入彌補的成本將超越敏捷帶來的效益。
這些可能就是敏捷過程與瀑布模型比較本質一點的區別: 關鍵複雜度所在的位置不一樣。

如何運用
在管理中，一直在尋求量化的指標來進行考核、決策。既然複雜度好像是各個問題的本質，但它涉及的各個方面都只停留在經驗層面，能否有一個公式進行計算？
例如一個項目開始，有可供選擇的人員來建立項目團隊，有可供選擇的設計架構方案，以及各種平台、架構、技術等，如果對應這些組合都能計算出一個複雜度的值？
也許到達這種程度跟讓電腦自己去做項目一樣困難，也許以後會有類似的模型能夠運用，目前我們只有考慮如何更全面、深入的認識複雜度這個概念，完善我們的經驗模型(用經驗去評估複雜度的邏輯思維模型)，尤其是警惕美女效應。

把任何人在同一時間需要處理的本質(essential)複雜度的量減到最少；
不要讓偶然性(accidental)的複雜度無謂的快速增長。
軟體開發中任何其它技術目標都不如管理複雜度重要
--代碼大全2
其中本質的(essential)屬性指一件事物必須具備，如果不具備就不再是該事物的屬性；偶然的(accidental)屬性指一件事物碰巧具有的屬性，有沒有這些屬性都不影響事物本身。