從高鐵售票系統看CMMI
分類：
軟體的意見
對於Roger的《大砲開講 » Blog Archive » 高鐵售票系統品質差嗎？》 ，我有一些關於CMMI和軟體開發的想法。Roger 提到：
讀者，你認為是 CMMI 有問題？還是開發組織有問題？
我承認，我是不太喜歡CMMI，尤其不喜歡許多CMMI專家或軟工學者有意無意地忽視「人」的問題。在這個案例中，或許Roger 對於開發者的專案協調與程序遵循有疑問，我倒是覺得，開發者與CMMI，都有問題。
先看開發者。聯合報的新聞說，「神通電腦坦承：程式與旅客需求有落差」。我聽到這句話中有話說︰開發者認為這售票程式沒寫錯，但可惜的是，高鐵的旅客並不欣賞這「登機」用的售票程式。
嗯？「登機」的邏輯？我想起來了，飛機票常會超賣，我的確有過一大早去機場waiting的經驗。所以哩，旅客本來就該預期一個會超賣、會waiting的「飛機級高鐵」囉？
真是自以為是。
CMMI ML3 裡有個PA叫做 Validation，其目的在於證實未來提供的產品，放在預期的環境之後，能夠滿足其「預期的使用需求」。換句話說，Validation 是要確保 「你做了正確的事(You built the right thing)」。如果說，開發組織有機會，找些人來先行「體驗」一下這買票的過程，理應不難看出，旅客期待的高鐵是像坐火車、坐捷運，還是像坐飛機？(我還沒坐過高鐵，但是我坐飛機時可從來不用去售票機前買票！)
因此很明顯地，開發組織雖然通過了ML3，卻沒做好ML3裡的Validation；開發出來的程式或許符合SRS或RFP，但是不符合旅客們的預期。
不過，說完了開發的組織，這下我要說一說CMMI。其實CMMI不能算是開發流程，它其實是開發流程的「需求」，也就是說，你可以用各種奇奇怪怪的模型、方法、理論、實務，只要合乎那需求，那就 OK。那麼，CMMI給我們在「需求發展」上的指示是什麼？很簡單，要「用廣泛的方法確認需求」。
是該說CMMI精明，還是說不負責任？「用廣泛的方法確認需求」這真的太正確啦！卻也好像沒說一樣！我們開發者千方百計，不就是想搞楚清 What customers want? 不過，CMMI 的確也給了些例子，像是 product demo, prototype, simulation, scripts, scenario 等等。然而我依然覺得，這些例子都是一筆帶過，最終還是害那些不懂得顧客心理的開發組織，做一些自以為是的Validation，而非由外而內的 Validation。
最後，讀者，我的忠告︰你的顧客無法告訴你，他們不滿足的是什麼；但你仍然可以「用廣泛的方法確認需求」，把爛需求早點殺掉，以發掘顧客的不滿足是什麼。雖然是廢話，畢竟還是句正確的廢話！
備註︰
1. PA：Process Area，中譯作「流程領域」
2. Validation，中譯做「確認」
3. 需求發展︰Requirements Development，同樣是ML3的PA
參考：
CMMI的正式網站：http://www.sei.cmu.edu/cmmi/
CMMI 模式V1.1中文版：http://www.sei.cmu.edu/cmmi/translations/trad-chinese/models/
相關：大河馬的創意動物園: 大河馬看高鐵自動售票系統有評論高鐵售票系統UI的圖文評論。
今天，在神通電腦網站瀏覽了一下，發現他們是通過「能力成熟度整合模式第三級(CMMI Level 3)評鑑」，是 CMMI 有問題？還是神通電腦專案協調出現問題呢？
很多國內廠商通過了能力成熟度整合模式評鑑後，軟硬體品質真的會改善嗎？真的會遵循這些程序嗎？還是把它擺在角落呢？
讀者，你認為是 CMMI 有問題？還是開發組織有問題？
我承認，我是不太喜歡CMMI，尤其不喜歡許多CMMI專家或軟工學者有意無意地忽視「人」的問題。在這個案例中，或許Roger 對於開發者的專案協調與程序遵循有疑問，我倒是覺得，開發者與CMMI，都有問題。
先看開發者。聯合報的新聞說，「神通電腦坦承：程式與旅客需求有落差」。我聽到這句話中有話說︰開發者認為這售票程式沒寫錯，但可惜的是，高鐵的旅客並不欣賞這「登機」用的售票程式。
嗯？「登機」的邏輯？我想起來了，飛機票常會超賣，我的確有過一大早去機場waiting的經驗。所以哩，旅客本來就該預期一個會超賣、會waiting的「飛機級高鐵」囉？
真是自以為是。
CMMI ML3 裡有個PA叫做 Validation，其目的在於證實未來提供的產品，放在預期的環境之後，能夠滿足其「預期的使用需求」。換句話說，Validation 是要確保 「你做了正確的事(You built the right thing)」。如果說，開發組織有機會，找些人來先行「體驗」一下這買票的過程，理應不難看出，旅客期待的高鐵是像坐火車、坐捷運，還是像坐飛機？(我還沒坐過高鐵，但是我坐飛機時可從來不用去售票機前買票！)
因此很明顯地，開發組織雖然通過了ML3，卻沒做好ML3裡的Validation；開發出來的程式或許符合SRS或RFP，但是不符合旅客們的預期。
不過，說完了開發的組織，這下我要說一說CMMI。其實CMMI不能算是開發流程，它其實是開發流程的「需求」，也就是說，你可以用各種奇奇怪怪的模型、方法、理論、實務，只要合乎那需求，那就 OK。那麼，CMMI給我們在「需求發展」上的指示是什麼？很簡單，要「用廣泛的方法確認需求」。
是該說CMMI精明，還是說不負責任？「用廣泛的方法確認需求」這真的太正確啦！卻也好像沒說一樣！我們開發者千方百計，不就是想搞楚清 What customers want? 不過，CMMI 的確也給了些例子，像是 product demo, prototype, simulation, scripts, scenario 等等。然而我依然覺得，這些例子都是一筆帶過，最終還是害那些不懂得顧客心理的開發組織，做一些自以為是的Validation，而非由外而內的 Validation。
最後，讀者，我的忠告︰你的顧客無法告訴你，他們不滿足的是什麼；但你仍然可以「用廣泛的方法確認需求」，把爛需求早點殺掉，以發掘顧客的不滿足是什麼。雖然是廢話，畢竟還是句正確的廢話！
備註︰
1. PA：Process Area，中譯作「流程領域」
2. Validation，中譯做「確認」
3. 需求發展︰Requirements Development，同樣是ML3的PA
參考：
CMMI的正式網站：http://www.sei.cmu.edu/cmmi/
CMMI 模式V1.1中文版：http://www.sei.cmu.edu/cmmi/translations/trad-chinese/models/
相關：大河馬的創意動物園: 大河馬看高鐵自動售票系統有評論高鐵售票系統UI的圖文評論。
