一個委外(Outsourcing)組織結構範例

一個委外(Outsourcing)組織的結構範例圖

一個委外(Outsourcing)組織結構範例
(縮略圖,點擊圖片鏈接看原圖)

雙方的期望是什麼?

  • 客戶端(發包單位)
    • On Schedule。
    • 系統符合所需要的功能與非功能性需求 (可以通過驗收測試)。
    • 契約內所議定的軟體設計規格(結構)。
    • 具堅固性(Robustness)、可擴充性(Scalability)、可測試性(Testability)的系統。
  • ISV(承包單位)
    • 承諾專案所議定的契約內容。
    • 釐清需求,界定系統範圍。
    • 控制與侷限需求的變動在專案的範圍內。
    • 驗收的交付是可以被驗證的。
    • 合理的利潤 ~ 成本、品質、規模與時程的調和。

符合雙方期望的核心要素?

  • 密切地溝通,釐清需求,界定系統開發範圍,議定系統的整體架構(Architecture)設計。
  • 版本(Release)交付時的接受度(Acceptance)測試,或稱之為驗收測試、功能測試。
  • 利用原型(Prototype)測試與驗證系統的結構性。

關於「CMMI」幾個問題的自我提問

  • 1986年由美國卡內基美隆大學的「軟體工程學院(SEI)」受到國防部委託而發展的。可以幫助軟體開發者改善軟體流程。
  • CMM軟體能力成熟度模式(Capability Maturity Model for Software,簡稱CMM或SW-CMM)
  • CMMI整合能力成熟度模式(Capability Maturity Model Integrated,簡稱CMMIsm)

因為前天看到國內某篇資訊雜誌訪談現任Borland的CPO(Chief Process Officer) Bill Curtis ,他對國內政府帶動軟體資訊產業走向 CMMI,深表期許與贊同。

Curtis 認為:CMMI導入,管理議題 重於技術開發。
又,記者問了一個問題:在CMMI的流程架構下,是不是很難凸顯個人的能力? Curtis 的回答是:不會,反而可以塑造出優秀的人才,寫程式不只是要凸顯個人的能力,而是在流程和專案管理方面的發揮。

整篇文章看起來,CMMI 是非常重視製程的品質與流程的管理。

因為政府輔導因素,還有,最重要的是,未來政府資訊系統的標案,會要求軟體廠商需具有 CMMI 認證的資格。所以,國內許多資訊廠商,趕忙著 “宣布” 他們已經通過了 CMMI Level-2 or 3,甚至朝向 Level 5 的終極目標邁進。

原來有些納悶,軟體開發工具大廠 Borland 會如此的支持 CMMI 的推動?
思考了一陣子,站在 Borland 的角度來思考與其的商業利益,就蠻清楚了。Borland 約兩年前陸續購併了許多輔助專案管理工具的廠商,包括當紅的 UML 塑模工具 Together,將這些工具整合成為軟體專案開發的 Total Solution,稱為 ALM( Application Lifecycle Management)。而為了推動 CMMI 的軟體廠商,的確是需要專案管理與開發工具的利器,這就正符合 Borland 的商業目的,會是成為最具 “潛力市場” 的目標客戶群了。

所以,對於 Borland 推動 CMMI 軟體工程實驗室,我就不會覺得意外了。
不過,有幾個對 CMMI 的一些問題,仍存於我的心中:

  1. 既然是稱為 “軟體能力成熟度”,那麼,除了可以協助管理與製程的成熟之外,專案開發團隊的 “成熟度” 是如何去學習與成長,以提升其成熟度?
  2. 政府的標案(以前輔導過幾家軟體廠商,就近多少知道一些),很奇怪的是,永遠時間都很趕。一個上億的案子,要求在幾個月內就完成含系統分析、設計與實做及建構部署。
    若永遠就是有哪一個先決幾近無法改變的事實:時間就是不夠,那麼,如何能在如此短的時間內開發出 “成熟” 的系統呢?

專案開發被要求在不合理的時程內交付,怎麼辦?

Problem:客戶經常要求軟體廠商在極短不合理的時間內完成交付系統的開發,該如何面對這一棘手的問題?

Solution:

  • 不要馬上被客戶主導,一下子就落入到細節內。
  • 釐清問題的本質,為什麼客戶會要求在不合理的限期內完成系統的交付。
  • 找出問題背後的問題,是否是?
    • 交付時程沒有那麼趕,可能是承辦人”無知”的情況下所造成的時程錯估。
    • 根本就是客戶承辦的關係人對這個系統開發案子起步太晚了。(所以,若關係人沒有推延,那麼,軟體廠商就確定系統可以如期交付 ;))
  • 思考對策,該如何應付這些背後潛藏的實際問題。
  • 站在中立的觀點,謀求對該專案能達成雙方在時程、成本、品質的一種均衡、雙贏的策略。

做一個不太成功的專案

許多軟體工程師,他們經常有滿腔熱血,希望能將他們對於在軟體開發上所學的技術與心得發揮應用在工作的專案上。

也有許多開發團隊,僅接受幾天的 UML 與 OO 的教育訓練,就想 “應用” 在專案開發上。

有很好的抱負及理想當然是很好。不過,將新技術、新的開發流程應用在傳統的專案上,其風險很大。還不是普通的大,是真的很大的風險!

幾個關鍵的問題思考:

  • 團隊成員們的接受度如何?
  • 團隊其他成員的技術及技能夠不夠?
  • 該專案的開發時程及預算等資源,夠你 “實驗” 一些新的技術與製程嗎?
  • 最危險的是,導入新技術及製程的當事人或團隊,真的足夠具備該有的觀念與知識嗎?

例如,專案導入 “Use Case” 及 所謂 “物件導向” 技術。若對 “封裝(Encapsulation)” 沒有足夠的認知,根本不瞭解 “廣度” 與 “深度” 的表達,是很難寫好 “Use Case” 的;對 “Control”、”Entity”、”Boundary” Object 的責任(Responsibility)及本質都不清楚的話,該如何設計物件結構及表達物件之間的互動合作?;對於 “Stateless” 與 “Stateful” 物件都不知如何設計與搭配,又該如何開發 N-Tier 的應用系統呢?

單一個問題,是容易在專案開發的過程中,逐漸的克服及解決。但,一旦許多的問題一併發生時,那麼,難以發現的複雜度就呈現出來了。而且,無論如何,就是無法解決這些問題,而且,專案又面臨時程的壓力,結果,為了趕工,粗製濫造,一開始所懷抱的理想,早就拋諸腦後了。

個人一向不主張 “現學現賣”,風險實在太高了。
若真要應用在 “專案開發” 上,那麼,最好是不要好高騖遠,往前走一小步,做一個不太成功的專案

什麼意思呢?
只將一項新的技術或觀念應用在一個小型的專案上。

例如,我常主張,要讓一個專案 “看來很成功”,最重要的一件事,就是要能與客戶達成相互之間的 “平衡(或者稱之為妥協)”。
要如何平衡? 測試先行(Test First)是最佳的利器!

開發團隊撰寫功能測試的測試程式碼;客戶負責提供寫測試的 “劇本(Scenario)”。越簡單越好,可不要搞什麼 “Test Case” 之類的,也就是測試不要以文件、測試列表等這些 “Paper” 來表達,太容易發生糾紛了。
自動化,就是自動化!!所有的功能均能以測試程式碼來執行自動化的測試,若其中之一的功能沒有通過,自然就反應在測試的結果。而功能一改,自然,測試碼也必須跟著更改。功能為什麼更改?也就相對反應客戶需要對其更改的功能 “負責任”,因為,測試劇本是由客戶所提供的。

“測試先行” 簡不簡單? 技術上是蠻簡單的,但,實際執行起來可不簡單,因為,牽涉到開發人員心理層面及與客戶溝通(必須說服其撰寫測試劇本)等諸多問題。

若能成功導入單一一個新的技術與觀念,提升團隊的經驗、技能與信心。那麼,再漸增地加上一些 “新技術”,如 “Use Case” 表達需求、”Class Model” 表達領域物件的結構...等。

人們往往希望做事能面面俱到,但最後卻往往都面面不俱到。
做一個不是太成功的專案,往前一小步;勝過什麼都想做,到最後卻反而一團遭而無法收拾的專案。

奈米機率日

軟體系統開發是充滿著高度風險的產業,在整個專案開發過程中都充滿著不確定性.
因為某種程度的不確定性,相對地就不容易量化,那麼,又如何去預估實際的交付時程呢?

用人月? 是一種計量的單位,但相對也是一個 “神話”,因為誤差大到可以忽略這種單位的計量。
用人月所預估可以交付系統的期限,依據業界的經驗法則,是不可能完成交付的。
只是,講 “不可能完成”,老闆會不高興。

從 “與熊共舞” 一書中,學到了一個非常有趣的術語。

我們不要說在那個交付期限 “不可能完成”,而是改口為 “可能完成”。不過,該期限交付點的交付機率,稱之為 “奈米機率日(nano-percent date)”
因為那天順利交付的機率大概只有 十億分之一 ;D

{Draft} Open Source 的 “Business Model” 思考

從 Jimmy 網站一文:「專案成功的要素」

才知道,原來 Jimmy 參加了「國際開放源碼」的研討會,聽了一場Patric McGovern(Director, SourceForge.net)的演講。

最重要的是, Jimmy 節錄了 “Open Source 成功的關鍵” (感謝!對我實在太有幫助了) ^^”

全球最大open source開發網站的主持人,他不但用Apple的Keynote製作了超炫的3D轉場投影片,還提到了一個有趣的觀察;他認為一個成功的開放原碼專案通常有這些關鍵:[全文:]

1. 要有趣!讓人覺得有吸引力
2. 可與其他的軟體相互結合(e.g. blog + photo album + wiki + forum + …)
3. 傾聽使用者的回應
4. 提供良好的vision給使用者參考
5. release early, release often

這一年來,我個人也一直在觀察思考 “Open Source” 這個 “社群”。
前四點,我大概都有想到,但第五點,完全沒有想到!!
哇哈哈 ~ 讓我在對 “Open Source Business Model” 研究的思考上提供了太大太大的幫助了。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal