jim yeh on 五月 13th, 2006

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

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

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

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

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

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



     

4 Responses to “軟體開發能力的自我組織”

  1. [...] 記得我在《軟體開發能力的自我組織》中一文曾提過的:「專案實施Inspection時,成員的設計能力及software asset變得與日俱增,而且在團隊溝通上助益也很大」,就是一種共用件的有效運用,Inspection本身就是一種增進軟體品質的一種共享程序;同時透過團隊相互觀摩的良性循環,讓有經驗的開發人員分享設計與開發技巧,而達到共享人員的目的;最終的目的其實是要慢慢地形成如William所說的軟體資產(software asset)的目標,這不正是共享元件嗎? [...]

  2. [...] lessons learned,誠如我之前在〈軟體開發的團隊綜效〉中所提到的: 記得我在《軟體開發能力的自我組織》中 一文曾提過的:「專案實施 inspection 時,成員的設計能力及 software asset [...]

  3. [...] 所以,團隊合作重視每一個團隊成員與其互動的過程。在參與 software inspection 的過程中,除了可以達到知識分享的目的外,還會讓成員感到受他有受到重視,無形之間增加團隊向心力及凝聚力。當我們用工具檢驗程式碼時,並沒有辦法享受到這些好處,如同我在〈軟體開發能力的自我組織〉中曾經提到的: 公司缺少了像 Inspection 這樣的機制,任何的抽象思考、建模及各種提昇設計能力的技巧最多只能「孤芳自賞」,對組織開發能力的助益其實是有限的。「獨樂樂不如與眾樂樂」,當專案實施 Inspection 時,成員的設計能力及 software asset 變得與日俱增,而且在團隊溝通上助益也很大,可說是好處多多。 [...]

  4. [...] 最後,請容我做個小小的隱喻:用複雜系統來看專案管理,整個專案環境所能供給的資源是有限的(成本限制),而演化競爭者會和我們爭奪這些有限資源(時間限制),所以對一個複雜系統而言,必須達成演化的使命而創造對整體系統的價值最大化(規模限制)。要做到這點,複雜系統必須能依現狀來演化系統,用最經濟的方式創造最大的價值(技術限制),演化則是先對環境的做出假設,然後依據適者生存不適者淘汰的原則來進行演化,過程中會不斷地修正對環境的假設並改變系統行為以求適應環境,相信這樣的隱喻能更清楚專案假設與限制的差別。最後簡單回應一下喲哪桑學長所寫的〈假設的力量〉,資源的有限性及時間的急迫性是複雜系統難以掌控的,複雜系統只能根據環境所賦予的條件與競爭者的剌激來決定它要如何對環境做出假設以及演化行為,所以關鍵還是在軟體開發能力的自我組織呀。 [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">