軟體開發能力的自我組織

在William’s blog看到一篇文章，在《軟體的庖丁解牛能力》中提到：

有人要我針對「沒有被替除掉的工作，就是更加知識密集、需要更多技術與經驗」舉幾個例子，當時我直接想到的是：抽象思考與 modeling 技能、API/framework/library 學習及掌握，以及 software asset 的情蒐／評估／萃取／修改／重構能力。

看到這一段話，促使我思考一個問題：兩個構面，用抽象思考來提昇設計能力及具體的知識分享來使設計資源重覆運用，理論上是應該這樣做的；但以從事軟體設計這種資訊及知識密集的工作多年的經驗，卻發現開發者所處的環境一直都是複雜且無秩序的，技術與經驗似乎無法克服混沌一片，沒有辦法為開發團隊或組織帶來預期的效果。

為什麼會這樣呢？有人會說環境不配合，也有人會說出錢的大爺眼光不夠遠，技術與經驗即使是正確的，但政治不正確就是不行，所以不要堅持了吧！個人再怎麼努力，環境似乎還是朝向崩解毀壞的方向改變，但複雜系統的觀點不是告訴我們：當受到外力的干擾時，系統內個體會自我組織尋求改變，以成長與反覆地演進來增強系統。但軟體開發的這個領域中，要如何自我組織，才能有效地讓我們不跟隨著環境慢慢地停滯與崩壞？

在不理想的軟體開發環境中，產能與產出多半不能平衡。太過重視產能，容易使軟體開發停留在技術宏觀及理論層次，但這樣會缺少的相對的有效產出，所有概念都只是空談；但如果太強調產出，我們很難適應環境變遷所造成的影响，浪費我們投入的產能，做出來的東西都是無用之物。產能與產出不能平衡時，勢必造成報酬遞減現象，而只有兩者相互回饋，才能形成技術與經驗的增強環路，達成報酬遞增的現象。

軟體開發能力的自我組織就是為了要讓產能與產出相互配合，然而該怎麼做呢？以過去的經驗，Inspection及Peer Riew的效果不錯。但如同William君提到「多半都是針對軟體除錯而做的，較少將 software asset 視為一個具有獨立完整意義的個體來對待」，大部分的人都是拿它來當做測試及除錯為主要的目的。幸運地，我過去曾任職過曾經拿它來做彼此教學相長的工具的公司，對software asset有非常正面的的意義；但很可惜地，能了解Inspection的好處的人實在不多，大部分的人都用除錯的眼光來看它。公司缺少了像Inspection這樣的機制，任何的抽象思考、建模及各種提昇設計能力的技巧最多只能「孤芳自賞」，對組織開發能力的助益其實是有限的。「獨樂樂不如與眾樂樂」，當專案實施Inspection時，成員的設計能力及software asset變得與日俱增，而且在團隊溝通上助益也很大，可說是好處多多。

Please follow and like us: