2011/3/11 參加了一場IT架構師的座談
主講人都是很厲害的高手 聽完他們的經驗分享 真的受用無窮
我記錄下一些對我有影響的topic 期待未來的案例能夠找到best solution
Session 1 企業軟體開發的生命周期管理
1.1 這場主要是講在台灣的軟工流程 有一般的標準流程(ex.瀑布式) 也有提到Agile => 是由user驅動,從需求端開始完成開發
1.2 案子越大通常老闆要越強勢 才有可能成功
1.3 In Taiwan, 企業文化仍倒向客戶端這邊 所以客戶需求 > 一切
1.4 所以當面對客戶或老闆不合理的需求時 要有能力說"不"
但不是直接硬碰硬的說不 你不要做 事情仍是換你的同事做 終究是團隊裡其他成員會擔下來
1.5 說"不" 是件藝術 你要提出替代方案 或是證據 說服客戶或是老闆
1.6 當跟客戶談需求時 客戶常常會説 我不知道需求是什麼?
此時需要你不斷的去引導 溝通
PS. 客戶需求時常會變 所以每次談的內容都一定要記錄下來
1.7 客戶不會管你的架構設計的好不好 只會理他的需求有沒有達成
但是架構設計的好 軟體才活得長久
1.8 Architect的工作 (1) 設計 (2) 決定技術 (3)提出solution
1.9 趨勢的張書源顧問決定技術的條件之一 就是挑選至少會活2年的技術
他的工作做了很多POC (Proof of Concept, 證明新技術是否能用)
1.10 張顧問認為整合新舊系統or解決擴建問題 目前最佳的solution就是SOA
1.11 標準的流程是 分析->產出文件(確認需求)->實作
但在台灣常常會反過來 顧問群裡有人覺得反過來也不錯 至少最後出來的文件才是最正確版本的文件
1.12 胡百敬顧問認為一定要先分析才能控制需求 確認專案範圍程度
他認為沒想好就動工必定會失敗 越早寫越早死
1.13 如果有委外 一定要拿source code 不然根本無法維護
1.14 如何處理複雜的專案呢?
(1) 固定IO(應該是指單位化的意思)
(2) 做小規模UnitTest(應該也是指單位化)
1.15 如何讓後人可以維護你的程式呢?
(1) 埋break point 讓人知道你上次dubug到這裡
0 意見:
張貼留言