聊聊流程改善與 CMM(I)

[Mac-Mangobear]

http://picasaweb.google.com.tw/liangyun.wang2

好像又空了很久齁，不過我還記得之前跟大家討論的是軟體架構啦，這次來談談流程好啦
上個學期上的 Seminar for Software Process 課程，比較像是用大量的閱讀來洗腦，就是希望能把
流程的概念灌進管理人的腦子裡。 這門課的講師 Dr.Mark Paulk 是 CMM 當年的主要計畫成員之一。


流程這個字的意義，簡單來說是 可以重複的做事方法，也就是每次遇到相同的問題，我們都可以使用相同的劇本，
微調以後就上陣。或許有的人會說，我們組織太小，我們做的事情太簡單，沒有流程。這實在是不太可能的，大部分
的時候，我們只是沒有把流程具體化、文字化而已，大部分的組織，對於正常的事務，都還是有些既定處理方法的。
要不要把流程給文字化，當然有得討論，因為很多時候真的有些麻煩。


好，現在我們有共識了，雖然未必訴諸文字，但是大部分的事務都有既定的處理方法。接下來就是要看這套方法的效果
如何？比方說，我們發現目前的流程是拿到需求就開始寫程式，通常都沒有經過設計與設計審查的階段。寫完程式之後，
自己測試一下就 check in，等下個月由測試部門去測試。測試部門反映問題回來之後，我要想一想、找出錯誤的地方
加以修改，然後再送測試，直到正確為止。


這樣的流程有甚麼問題呢？一點問題也沒有。之前與大家談軟體架構的時候就提過，並不存在
絕對判斷好壞的標準，完全看計畫相關人士（stakeholder，通常就是客戶、管理階層、開發人員等等）
感興趣的是甚麼。
在談流程改善的時候，Mark 跟我們說，最重要的就是 business interest。若是流程改善的行動沒有
商業利益作為基礎，就得不到管理階層真心的支持，行動很容易就會失敗，或者流於形式。這個論點應該是很容易了解的。
假設管理階層交付的任務是減少產品開發的時間，希望由客戶提出需求到移交的時間，可以盡量縮短。第一件事情就是


回答：現在要花多少時間？經過收集或者翻查一些資料（請注意資料收集本身也是要花時間與成本的喔）
平均說來，從客戶希望增加一項（事前預估為）小型功能，到這個功能真的可以出現在給客戶的版本裡，
大概是 100 工作小時，延遲大約兩個月。


接下來就要回答:時間到哪裡去了？可能是除錯花太久，所以是程式寫不好，應該加強設計審查。
可能是測試週期過長，所以應該增加人手或者精簡測試。可能是需求定義不清楚導致重工太多，
可能要加強需求撰寫人員（可能是分析師、客戶代表、或者部門主管，都無所謂）的訓練，
或者增加期中向客戶簡報展示紙上原型的階段。


原因或者解決的方法，不需要我多說，只要有適當的資料，大部分的人都看得出來，問題是如何取得資料、
得知改善的效果，以及不再犯同樣的錯誤？


取得資料本身可以是固定的流程收集所有工作，或者以專案的形式分析小部分，其實蠻需要經驗的，
專業的顧問可能會更有幫助，Mark 常說大家有需要可以找他啊 ^_^
假設我們繼續收集資料，發現對於同樣類型的功能，工作小時數變少了，延遲也縮短到一個半月，皆大歡喜。
又增加了規定把改善對策加入到每個人的工作流程裡，更利用部門間的會報把經驗分享出去。
經過幾次這樣的循環，公司的流程就會越來越成熟，而 CMM 就是評估個別領域流程 "成熟度" 的方法。


CMM（現在的版本叫 CMMI） 不是 "作" 出來的，也不應該當成 "目標"，而應該是在內部不斷進行流程改善，
累積到一個程度看看我們跟別人相比夠不夠成熟的一項參考。 Mark 本人是 CMM 的主筆，也接觸過很多為了
取得政府標案製造假證據畫虎爛通過 CMM/CMMI 認證的例子（顯然美國人在這方面也沒有比較好啦），
他不斷地強調這對品質或者生產力是沒有用處的。


要是有人對流程改善或者品質管制有興趣的話，也可以繼續談談，或者大家對 security 比較有興趣呢？
這個學期（對，暑期） 我修了一門 independent study，題目是尋找 security 對現有系統架構的影響。


至於 studio project，我們進度還不錯，經過兩個 sprint，客戶對於第一次 release 頗為滿意。目前最大的問題是
老師們覺得我們在流程計畫與掌控上的著力不夠，花太多時間在寫程式了。我身為 tracking manager，責無旁貸啊。

[Philosopher]

我對流程改善很有興趣，請繼續分享精彩心得。

[Mac-Mangobear]

這裡真的只有你我兩人啦：）

mac

On 6月25日, 上午10時59分, Philosopher <murphyc...@gmail.com> wrote:
> 我對流程改善很有興趣，請繼續分享精彩心得。

[Canaan Kao]

曾經，我也對流程感到興趣。
後來，發現這東西跟"人"有太多的關係，而做罷.....

2008/6/26 Mac-Mangobear <LiangY...@gmail.com>:

[Canaan Kao]

打太快了，是"作罷"，非"做罷"。

2008/6/27 Canaan Kao <canaa...@gmail.com>:

[Philosopher]

[Mac]

這樣的流程有甚麼問題呢？一點問題也沒有。之前與大家談軟體架構的時候就提過，並不存在
絕對判斷好壞的標準，完全看計畫相關人士（stakeholder，通常就是客戶、管理階層、開發人員等等）
感興趣的是甚麼。
在談流程改善的時候，Mark 跟我們說，最重要的就是 business interest。若是流程改善的行動沒有
商業利益作為基礎，就得不到管理階層真心的支持，行動很容易就會失敗，或者流於形式。

[Philosopher]

我覺得這段是重點，寫得很好。點出了目的。目的是驅動一切的基礎。所有的行動，要滿足目的才有意義。

<<Documenting Software Architecture>>一書，也提到，document撰寫時，要考慮到stakeholder
是誰，對於不同的stakeholder，感興趣的層面不同，需要表達的層面也會不同。

[Mac]

這裡真的只有你我兩人啦：）

[Philosopher]

有很多潛水的人了。至少有Canaan浮出來了。
Cannan，為什麼作罷？可以分享一下你遇到的情況嗎？有沒有先得到管理階層的支持，然後做溝通，取得足夠的共識？

[Canaan Kao]

簡單地說，再好的流程終究也需要"人"去執行，
主管支不支持是個問題，屬下要不要真心誠意地照做也是個問題，
很多事不是 do or quit 這樣簡單 @_@
從實際操作經驗上來看，人的問題是推流程之前必須解決的，
我會作罷是因為人的問題，不是因為流程本身 :-)

我忘了誰說過："沒有永遠的朋友，也沒有永遠的敵人，只有利益是永遠的。"
通常新的流程一定會帶來某些成面的好處，
為什麼對公司有好處的事，管理階層會不支持呢？
那要看這好處到底事什麼，是短期的利益？長期的利益？
或是長久執行後會帶來品質的提昇？

對屬下來說，新流程無論最後會導致什麼，對他們來說最直接的都是改變，
是心悅誠服地 fellow ，還是陽奉陰違地做做表面功夫，
都會影響到這個流程的結果。

不好的結果，就會導致流程的成效差，成效差又會影響到主管對這個流程的信任度，
如此循環.... @_@

我又忘了誰講過:"戰略因為勝利而顯得正確"，這好像是馬後炮，
似乎戰略的正確與否是由戰爭的結果來決定？
正確的戰略卻導致敗仗，那它還是正確的嗎？

對應過來說，正確的流程一定可以順利執行，且執行的結果一定是好的？
還是說，能夠順利執行且帶來好結果的就是正確的流程？

這些問題似乎有點扯，大家有興趣或許也可以多多分享 :-)

不過從做研究的角度上，我們可以先假設人的問題都已經被解決，
單純地討論流程本身。

--
Canaan

2008/6/28 Philosopher <murph...@gmail.com>:

[Mac-Mangobear]

嗯，如果說我在這裡洗腦一年至今有甚麼成效的話，就是相信了：沒有正確的流程 這回事

我們這組的主要指導老師 Mel 常說，幾乎任何流程都 work。（另外一位指導老師則常常說，唯一 work 的流程就是......）

這裡試著教學生，流程本身是流動的，幾個大方向抓到後，是根據現實的需要與環境的條件，在持續調整流程的

您提到人的因素，是普遍存在的限制，也會影響到適合這種條件的流程。當然這樣的流程是否成熟可以通過 CMMi 認證又是另外一回事囉。

Documenting Software Architecture 這本書也是課堂參考資料之一，但是我們學得很亂，因為每個人對於應該如何
document architecture 還是無法統一見解啊。

mac

On 6月28日, 上午2時25分, "Canaan Kao" <canaan....@gmail.com> wrote:
>
> 對應過來說，正確的流程一定可以順利執行，且執行的結果一定是好的？
> 還是說，能夠順利執行且帶來好結果的就是正確的流程？
>
> 這些問題似乎有點扯，大家有興趣或許也可以多多分享 :-)
>
> 不過從做研究的角度上，我們可以先假設人的問題都已經被解決，
> 單純地討論流程本身。
>
> --
> Canaan
>

> 2008/6/28 Philosopher <murphyc...@gmail.com>:
>