太陽牌米先生 "芋圓製作實務" 課程感想(III)

二. 芋圓製作方法論與專案實務討論:
這堂課, 等於是聽聽太陽牌米先生認為我們該加強與平常累積實力的建議, 可以參考.

1. 多讀書:
米先生推薦了Effective in JAVA, 這本書在多年前, 曾在舊有的部門讀書會內掀起小小的旋風, 我也有買, 只是一直沒看完.
這書裡面有不少在寫JAVA時候的建議, 剛學JAVA的人或許有的會看不懂, 但可以先記在心裡, 等以後碰到就可以交互比對. 至於熟練JAVA的人, 可以藉機看看為什麼作者會這樣寫, 自己是不是也這樣覺得.

2. 加入有興趣的技術主題的Mail List:
加入有興趣的技術主題的Mail List, 多看別人的討論, 但是要注意最好挑選有名氣或已經穩定的Framework或Source code.

3. 成立個人或組織的no-time-constrained project:
這點呢, 前年老戰友們在聽完整套課程後, 有開個內部專案, 叫做便當系統, 就是仿照這樣的軟體開發流程製作的.
不過說真的, 如果老闆沒吭聲, 如果自己沒毅力, 如果組織沒計劃, 是一定做不下去的 ... 所以, 讓我想到, 乾脆自己搞個team來振作好了, 不然這樣下去也不是辦法.

4. Knowledge Sharing:
這很明顯, 組織裡的任何人都一樣, 個人要成長, 一定是教學互長, 缺一不可, 尤其大家是要出去打戰的, team work也很重要.
但是, 公司實施C&B之後, 個人年終說是只看PE, 卻又放上人員比例, 我覺得這樣會讓大家更不想分享知識, 因為分享的越多, 不等於越有可能被幹掉嗎? 我這當然是危言聳聽啦, 老闆英明!!!

5. 顧好JAVA的基本功、加強OO的活用度:
如果 ... 我們要號稱是一家熟悉JAVA的公司、我們是標榜用物件導向觀念開發專案、我們的價值是在軟體專案開發上 ... 你說該不該好好磨練?
根本真的很重要, 有的要從專案中累積, 有的要從教育訓練下手, 有的要讓員工的內心正本清源, 為官者不可不謹慎.

6. 加強Business Design Pattern的知識:
我個人認為, 這點不見得每個人都要做.
現代社會講求team work, 因此... 大家都要顧基本功, 有的人鑽研技術深度, 有的人鑽研Business Design Pattern以加強商業流程設計 ... 分工分工.

7. Tool Usage and debugging skill:
一定要找到好用的Tool, 但不該僅限於開發用的Tool, 要廣於尋找符合軟體專案開發或專案管理的工具, 以加速專案內的事項管理與追蹤.
系統效能監控的Tool也很重要, 可以加速專案開發的Tool也很重要, Debug和測試用的Tool也很重要...
再來就是要加快Debug的技術, 這和做專案的經驗、對程式開發的熟悉程度有密切的關連, 所以平常要有正規良好的開發流程與習慣(如Logging機制), 才能加速Debug.

8. 方法論:
終於介紹太陽牌"芋圓製作實務"方法論了.
其實"芋圓製作實務"方法論和RUP很像, 但是多了一些專案管理的知識在裡面.
例如: PM和Archi應該要把風險及早發現, 且要控制好; Archi應該要和各工程師維持良好關係; Use Case Document內的Flow可以寫"GET GUI-xxx", 以表示操作流程畫面 ... 等等.

至於工程師最在意(可能是討厭寫, 或者覺得很重要)的產出文件, 大概有以下幾類需要注意:
(1) Inception :
Vision : 最多不要超過一頁 - PM
Business Case : 可併入Vision內, 稍微描述.
Risk List : 風險列表, 一定要寫, 要誠實的寫, 也要讓客戶知道, 每次都要review. 對於political issue要有技巧的描述, 不然有可能會被客戶釘在牆壁上 - PM
Software Development Plan : 要累積做專案的經驗, 才能有辦法估計use case大概需要花費的成本等) - PM+Archi
Iteration Plan : PM+Archi
Project-Specific Template : 累積而成的template
Use Case Modeling Guideline :
Domain Model :
Glosarry :
(2) Elaboration :
Project-Specific Template : 做專案累積而成的template
Data Model : 企業系統最好要出, 不然到時候不知道Data是怎麼回事.
Iteration Plan : 可用xls做list, 方便控管與討論
Test Plan : 沒測試過的系統, 你敢用嗎?
(3) Transition :
The Product Build :
Release Note :
Installation Artifacts :

說真的, 我不討厭"芋圓製作實務"方法論, 裡頭還蠻有料的, 可以學習效法.
但是太陽牌到底在打什麼算盤? 要我們幫忙賣(等於我們輔佐一堆未來的敵人)? 還是真的可以拉近partner與太陽牌的關係, 共同創造雙贏?
而公司又再打什麼算盤? 是沒有想法還是還在想? 或者只是當純花錢維持關係? 或者是希望依此為開發流程? 到目前為止沒看到任何決策, 殘念.

做專案不是做LAB, 應該要用熟練的技術, 或者有把握用新技術才可以順利完成專案.
希望大家永遠記得這句話.