敏捷 or 穩健 開發??

接觸軟體工作一陣子，接觸了蠻多敘述與實際案例的開發訊息。其中有幾個如精實開發，敏捷開發或者比較傳統的穩健開發類型。在互相比較之下，可以看到各有其優缺點的觀點。

我對兩者個粗略概念如下：(以下概念不單只是存在於軟體開發)

A：敏捷開發是早期設計與取得雛型並得到實際的使用者(非開發者本人)的回饋，而不斷的精實修改朝向正確的方向。

B：而穩健開發比較著重在於完善的規劃，從大方向到小細節都定義完整在進行專案。

以上很粗略也可能不是針對其各家領域的核心思想，而我的看法以及應用的方向則是：

A：敏捷開發的應用是建立在"精實團隊人數"、"開發工具熟練度"、"未有正規化流程"三個點。(可能還有其他，有想到待補充)

B：穩健開發則是建立於"專業分工度"、"系統複雜度"、"已有正規化流程"等三個點。

只先各提出三點，而其中的定義套用在這兩種開發則可以簡易的敘述如下：

1. 團隊人數-有些團隊可能會受限於經費或者其他原因，希望/必須維持小型團隊
2. 開發工具熟練度-對於開發工具的熟練度，是否有深度與廣度的實際實力
3. 正規化流程-這點很重要，因為這包含了是否需要有對系統的"分析"、"設計"、"整合"等三大能力
4. 系統複雜度-複雜度建立在"跨領域的廣度"，以及"單一領域的深度"。
5. 專業分工度-與[開發工具熟練度][團隊人數]有交互涵蓋，這邊會想表達的是分工需要切割到多細。

以上，是對於一個系統進行開發時，其團隊所採取的方式所需考量的點。我的經驗只在於狹隘的幾個領域中，所以可能還需要在遇到新的專案或者在汲取新的概念消化後，進行增減的修正。後面會繼續記錄以上有提到的延伸文章。

軟體不軟體，硬體不硬體

我很幸運有些機會去過不同的工作工作過。想提出一些可能不應該提的檯面下問題，只是好奇心可以殺死一隻貓(若在While/ for loop內可以設定殺死無限多次)。

關於軟體的正版問題，因為我待過的某間公司，當初在推行自動化時，前一年並不是購買正版軟體(買什麼就別問了，跟我工作相關)，然後我曾經接案的公司也是如此。再來要提的是使用"流行版本軟體"本來就不是什麼不能說的秘密，學生時期或多或少都會使用到這類型的，而且現在大多數的學校都願意買校際版或者系所版本。只是一間公司營收數億到數十億，公司副總可以開千萬跑車，卻不願意花個幾萬到十幾萬的軟體，有點可笑。而在我待過的公司之間，曾經跟曾經為前主管的人討論過，他說了這麼有趣的一段話:

若公司要整合系統不買硬體那就是太過分了，而軟體還好。

所以軟體可以"偷用"(因為Copy & Paste即可)，而硬體不行，這樣說反而驗證就是因為幾乎沒有哪間公司可以跟廠商借儀器，然後一晚就可以複製出一台一樣的能力。

只是想說，同樣在評估專案計畫，軟體就如此隨性，硬體卻可以變通。硬體有所謂的租借日期，軟體一樣有試用日期。若硬體可以在短時間(租用日期內)可以評估是否可以使用，那軟體應該也行。當然!在台灣普遍不注重軟體的氛圍之下，很多公司都是從舊有人員去轉軟體(換領域很好，多學習也很好)，但是整體上根本不利業界的發展。(從此可以在衍生討論很多其他相關的問題!!!)

更甚者，當初一年多沒買正版軟體的前公司，卻願意花十幾到幾十萬讓員工去上教育訓練(一些教育訓練的價錢都很有"價值")，這種錯亂的價值觀念只能說令我啞口無言。

那時候沒想到，事後才想到想對那位先生說的是:
下次要評估新的系統，可以先去跟某某公司"借"一台儀器，借個一兩年等到系統可以使用後，再跟那間公司說我們想要跟你們買正版整套的儀器。不知道業界哪間儀器商可以說沒問題的，以後我要買儀器一定跟您們買(當然也會先借個一兩年評估啦，最好可以借了就不必付費，連租金都免!)~

PS:此文原本發布在其他專業論壇，稍微修正一些用詞遣字，重新發布在此，希望也有不同/相同想法的人回饋，以及有共同經驗的人可以提出。

當然我朋友是說:反正就是老闆貪小便宜心態.....

系統整合?機電整合?

不知是分工太細，還是無法分工？
任何領域都可以聽到"系統整合"，或者"系統整合商"等等之類的，但是，到底系統整合是整合硬體、整合軟體、整合軟硬體、或者是整合"使用者的需求"？？

而更多時候，我看到的都只是單純的"機電整合"，或者"自動化控制"！(就以我所知道的來說)

曾有趣聞，因為不重視"系統整合"，而導致台灣沒有很棒的"高階產品"，都是東拼西裝起來的"拼裝車"。而這呼應了我想表達的，"系統整合"到底是應該建立在甚麼樣的前提之下，才有意義？而若沒有完善的系統整合概念，機電整合派得上用場嗎？？常常聽聞到臺灣的光機電實力堅強，從一些不知道可不可靠的新聞跟期刊可以得知，開發單一元件或單一模組的能力，而巨型專案(這也需要定義)的成功度上少之又少。我想這背後的問題決不是我想像的這單純，當然還有各式各樣，各種領域裡的眉眉角角。也因此在有能力討論更深入之前，都盡量秉持著"本來就應該會做好"的角度去思考這些問題。

回到主題，開發一個案子，需要的團隊組合可以有很多種組成。例如曾經聽聞的，軟體開發，需要SA/SD/SE...etc等配置。不過常常也聽到身邊好友的公司，是一人兼數職。規模很小的專案也許可行，規模大的就不妥當。 如何安排？如何定義？也是需要方法與經驗去琢磨出的。

這篇算是好奇碎碎念文，因為在好奇之下，查詢以及與不少不同領域的友人深談，深深覺得各個領域的各自為政，以及無法有效率的拓領域合作。我想從標題想帶出的就是=
瞭解自己的不足、尊重不同領域的專業、找出以及遵循有效的方法。

醫療儀器研究與開發

昨日聽到了一段話：

Device by Design; Drug by Discover.

從FDA的歷年演進也可以看出個所以然，畢竟在1997年以前，醫療器材只針對製造端的品保與品管等相關GMP之類的控管，但在後來的醫療器材回收樣品中去分析(大量的錯誤產生)，發現大多數是並不是因為製造端的問題，而是在進入製造端"之前"的"設計"就有問題，也因此才會要求有Design Control等相關文件。

BUT, 這個"But"就是最重要的~

What is Design ? or How to define Design ?

我的註解是：根據"產品使用者預期的情景"而成的商品，就該從這個角度去定義如何設計。

越是跨領域的研究與開發，就更是需要更高視野的思考，或者白話一點就是很常見的"系統化"。只是當定義了系統的深度與廣度時，將同時也定義了團隊的組成與研究&開發的方法。

若是選了不符合的"方法"，那就容易導致不符合的"結果"了。
至於如何去定義方法、定義設計、定義團隊等等一堆無趣的名詞遊戲，將在後續不斷的修正自己的思緒而留下註解。

參考資料：
http://www.fda.gov/downloads/MedicalDevices/.../ucm070642.pdf