UML： 快速進入SA/SD 或專案管理人員必備工具，資訊管理人員／老闆必讀（第一篇：資訊人員篇）

學老半天（真的很久）
後來發現，被一堆人問了到底為何用 UML 圖，自己也疑惑了好久，最後發現他的價值

古代人狀況一：
以前都自己做程式，跟２－３個二人快速建製程式，效率又快又好，幹嘛那東西，太慢了～！

古代人狀況二：
所有的東西我有screen shot, input/output 都可以跟 user 需求到，幹嘛畫啥 UML
input/output 正確，中間邏輯我自己解決就好啦，甚麼 UML??

古代人狀況三：
有 SA/SD　規格都弄好了給我寫程式，我照本宣科就好，幹嘛學那？反正資訊人員工作挺好找的，換個工作又容易，又可加薪水，學那幹嘛？

古代人狀況四：
我好優秀喔，我一下就學會 UML, 也都畫得出來，也會分析，也會 coding, 工作也做得出來，然後呢？Domain know-how 不用了解啦，很會問、會畫圖，然後給下面人做 coding 就好啦。但是網站卻不賺錢。。。。。業務的錯啦，公司的錯啦。。。。

以上狀況
狀況一：
中小型企業公司商業邏輯簡單，當然這樣就夠了，但如果沒有乖乖的做好顯示層／邏輯層／商業邏輯層分開，以後要 refactor 你就很難了。如果架構開始變複雜，那就開始爆掉了，沒人想維護，離職開始

狀況二：
這跟一很像，中間邏輯自己解決，然後呢？沒分層好，你一直在增加自己的 "技術債務"，然後離職潮開始。

狀況三：
大公司分工清楚，這很好，但台灣以後直接跟對岸競爭，不會畫沒關係，先學會看吧

狀況四：
優秀的資訊人員應該像是名醫，你的病人（需求者或是老闆）跟你說他的症狀，你可以替他解決現在的問題和未來的問題（撇開道德風險不談）。
你有過去看名醫生排很久，然後他１分鐘就看完嗎？因為他看太多了，一眼看出問題在哪。

喔，that is great。

但是，你有時會不會覺得還是醫不好，他一直在症狀治療
或是告訴你他多懂，但你的病一直不好
你有看過 Doctor House　這部美國影片嗎？他最主要是說很多病因是由家中環境影起
所以他都會去派他的手下去看病患的家中去採集狀況。
不去了解 domain know-how 的自負工程師，就像不去真的了解病患家中實際環近狀況的醫生
一直用儀器治療，然後症狀治療，醫不好反正也不是我的問題，我又不是神。
但這樣真的是優秀的工程師嗎？

你可能會想。。。我又沒多拿錢。。。。我在公司地位很高了（或還不夠高），還是忙內鬥或向上管理等事務吧


但這樣真的是優秀的工程師嗎？




圖案來源：http://stuffkit.com/wp-content/uploads/2012/10/amazing-photos-2012-27.jpg

為何寫網誌?

夠了，我一直以來不太想寫這東西的原因很簡單

第一：
要讓別人找到你的網誌，你的內容必須有當下的價值，有潮流性的或參考類的就可以很容易被找到

第二：
如果要有長期被訂閱的價值，那你可能要有實質的（或人家以為你有）商業價值、實質效用／效果或娛樂性等。

如何快速做到（內容）：
一般人能快速做到的就是轉載其他的資訊來增加內容物，比如好餐廳／食物、專業技術分享等，就可以快速累積人氣。如果是潮流話題，那你能分享的話，那就更快速了。因為大家會想知道最新知識、如何成功、如何賺錢等就更靈光了。


但是。。。。人是會被用盡的，也就是時間有限，怎麼可能真的一直言之有物又分享不完，所以只能拿別人的物品或東西來ＰＯ了。。。。那跟我個性不合，我又不是做廣告的～！
最後大多變成廣告工具或網拍等，才能有比較巨額的金錢收入進來。。。。

我覺得我有些觀念要改，就這樣。。。。但要　change to a different way, my way.

看完 Kenming 的 "【外包開發與管理】從開發者角色看「兩地分工」開發流程"

啊,
很多東西要學習

看完了 Kenming 的文章 "【外包開發與管理】從開發者角色看「兩地分工」開發流程"
覺得是我一直想要找的架構
雖然我的目的是要內部分工, 不是要真的外包, 但其實也是個可以認真考慮的架構

最近新團隊人員一直加入, 如果沒有個架構可不行, 不然會大亂
所以除了安排好每個人的工作和發掘大家的專長是首要任務, 但又不能荒廢開發進度
所以有幾件重大事情需要盡快完成

１　團隊使用 UML 工具的普及度：
　　團隊人員已有人會用 StarUML但考慮要不要慢慢轉換到　Enterprise Archtect
　　參考軟體：StarUML, Enterprise Architect

２　人員架構的安排：
　　因為是新隊伍，所以必須快速的評估每個人的屬性和特值，但比起團隊的很多人，
　　我年資沒比他們高，要決定這些東西，只能去請教他們
　　參考資料：Kenming 的文章 "【外包開發與管理】從開發者角色看「兩地分工」開發流程"

３　Agile development, 敏捷開發：
　　哇，這東西聽起來是不錯，但執行起來還是需要有經驗的人來帶，
　　不然以後很難矯正回來。３人團隊和１０人團隊，畢竟方式完全不同。
　　聽過團隊之前的經驗都是原本公司自行開發的專案管理軟體或
　　直接用MS excel 或 MS Project 是不錯
　　但是，我希望可以有 敏捷開發的　iteration 概念，我覺得這才是王道
　　參考軟體：
　　VersionOne $$$$ --> Link 
　　Jira/Greenhopper $ --> Link
　　Rally　$$$$$ --> Link
　　OnTime $$ --> Link
　　Visual Studio $$$$$$ --> 整合，但是需要 VS ultimate 版本

待續.....