the DevOps journey (0) - 敏捷開發真和每個開發人員有關?

作者： -

#不想看廢話，直接按這裡跳到重點

這年頭大多數人已經沒有耐心，已經很難看完一整篇長篇大論，因為這樣，這幾年我們寫blog的時候，幾乎都零零碎碎，這使得許多學員面對知識的掌握，也變得片片斷斷。

如果可以，我希望能夠把我們這幾年面對軟體開發方法，以及ALM/DevOps的一些經驗，有條理一點的整理出來，如果你有興趣，不妨嘗試慢慢的看看，如果實在已經不習慣看長篇文章，也可以挑有興趣的重點來讀。

開始一段新的旅程

這一系列的標題中有個字眼『journey』，第一次看到這個字…是在一場研討會，我忘了是TechEd還是Build，印象中研討會的主題是Metro Style App(現在應該不多人還記得這個名字了吧?)，主講人用journey這個字眼來描述學習一種技術的過程，我覺得真TxD的太貼切了…

不知道你有沒有發現，最近五年，軟體開發的潮流根本就是一場journey，而且非常像是我最愛的影集Star Trek Voyager中的旅程。你該怎麼形容這段旅程呢? 圖乎其來? 充滿意外? 不僅如此，大夥摸著石頭過河…似乎根本沒人能告訴你往哪個方向才是對的，你也不知道怎麼走才會到終點…這差不多就是這部影集當中的旅程。

若用來描述最近五年軟體開發技術的發展，根本是整個貼切到不行，而且從Web、前端、行動裝置、開發方法、框架…幾乎都逃不過這場journey魔咒，所有的技術都是在途(on the road)，一點都沒有發展成熟的跡象…

當然，如果旅程總是只為了看到終點倒也世俗了些，旅程的過程中還是有很多意外的小驚喜，以及足以令人回味的點滴，不管是你早已遺忘的Metro Style Application，或是充斥各種消耗型框架的所謂前端開發技術，又或者是我們要討論的這個主題 – ALM/DevOps。

關於開發方法的重要性

身為一個以寫程式起家的開發人員，就一個軟體開發人員的生命週期來看，我算是到了很老的時候，才願意承認軟體專案/產品的開發過程中，最重要的可能不是開發技術，而是開發方法。

技術能力的強度，是進入軟體(專案/產品)開發領域的入場券，它就是一塊敲門磚，技術能力的強度，決定了你敲門的力道。然而一但當門打開，你開始了一個專案，進入了一個團隊，參與了一個產品的研發，技術能力對成果的影響力，可能就開始慢慢式微了。請注意，個人技術能力可能會影響開發團隊產出的品質和數量，然而開發團隊產出的品質和數量卻很可能跟軟體專案的『成果』沒有絕對的正相關。

什麼意思? 我們看過太多技術能力很強的個人或團隊，但經手的專案或產品開發依舊是失敗的很徹底的。例子很多，不好一個一個舉。你可以盡其所能地回憶你自己參與過的專案，你應該會發現，團隊的技術能力決定了你能不能做某個案子(或產品)，但開發方法和團隊的素養，則決定了案子做得好不好，能不能順利結案。

由於軟體開發與一般工程營造迥異的特性，使得軟體開發這件事情，並不單單的工程行為，也是創作行為…這導致，追求技術的極致，其實對軟體專案沒有絕對的幫助，技術能力一旦到了某一個點之後，對於整體專案的幫助就迅速下滑…

像是上面這張圖，技術能力到一個臨界點之後，再怎麼提升，對於軟體專案的價值與效益其實影響開始遞減。

怎麼觀察? 如果你身為PM或Team Leader，當你開始慢慢發現，手上專案所發生的問題/瓶頸，大多跟技術無關，而是跟時程、溝通、預估…等非技術因素有關的時候，就表示，你的團隊可以在技術能力提升上稍稍休息，而該開始補強一下開發方法和專案管理能力。

總的來說，我接觸到的年輕團隊，大多都是技術能力遠勝於專案管理能力，至於開發方法，則往往都還有很多的成長的空間。

正在糾結?到底要不要踏入敏捷開發?

如果要談論開發方法，這幾年你不可能避開『敏捷開發(Agile Development)』，相較於傳統的瀑布式開發，敏捷開發在意的是自適應性(Self-Adaptive這個字硬翻很怪，我覺得你可以把這個字想成『應變能力』)，而傳統的瀑布式開發，在意的是『計畫導向』，簡單一句話，就是要你『stick to the plan』。

上課時，我會推薦學員一定要看Martin Fowler的這篇文章: http://martinfowler.com/articles/newMethodology.html

如果你需要中文翻譯，他位於:
http://www.jianshu.com/p/e042ed1d79b0

我假設你已經讀完了，我要說，這篇文章非常經典，字字珠璣，他解釋了為何這個時代的軟體專案，應該採用敏捷開發。

我覺得只需要扼要說明，請一邊參考底下這張圖。

最早期(1960年代)，軟體開發是毫無章法，雜亂無章的情況，迫使技術團隊覺得應該要有一些制度，因此借鏡了傳統的工程營造之類的專案管理概念，一段時間的演進之後，建構了像是CMMI之類的軟體專案管理方式，但後來(最近10年)許多人慢慢發現，似乎並不可行…

不可行的原因出自於幾點:

  1. 傳統的專案管理和工程方法試圖把人當作可替換的資源，但軟體開發並非全然是施工(Implementation)，還有創作的成分(而且非常高)，每一個程式設計師的產能可能天差地遠完全不一樣，把開發人員視為可替換的資源根本是個錯誤的假設。
  2. 傳統計畫導向的開發方法相信，設計(Design)和實施(Implement)可以分離，甚至，設計需要比較高階的人力，而實施只要muscle就好。但敏捷開發認為，設計和實施無法分離，每一個開發動作都同時包含了設計和實施的成分在。
  3. 我們幾乎永遠不可能有確定的需求。因為完全一樣的程式碼(需求)你根本不用重寫，只需要copy一分(或買套裝軟體)就好，所以，每一個軟體專案幾乎肯定都是獨特的。再加上現今市場變化快速，需求的固定幾乎已經不可能。
  4. 從不確定的需求，衍生出，準確的預估幾乎是不可能實現的。因此，軟體開發沒有stick to the plan這回事。(那要怎麼辦呢? 後面再說)

因為上面這幾個與傳統工程之間的核心差異，導致軟體開發用工程方法、SOP、甘特圖來管理、期待他跟其他的工程施工一樣順利，似乎非常的不切實際。

除非你的需求永不變動、除非你每一個開發人員的產能完全相同，除非你有無窮盡的開發人員可以替換，否則，傳統的工程管理方法根本無法進行軟體開發的專案管理。

不知道你是否曾經好奇過，其實我們早已用工程方法(甘特圖、要徑法、CMMI、SOP…等)來管理軟體開發很多很多年，如果，這個方法是錯的，難道從來沒有人懷疑過? 難道從來沒人覺得工程方法怪怪的?

有，但很抱歉，過去，設計出這些管理方法的人，很可能自己根本都不寫程式。就像設計員工管理制度的HR/Manager，本身可能根本不是一般員工，這些制度的受益者/設計者，從來都不是制度的使用者…也因此，身為程式設計師的你，如果夠敏感，很可能早就覺得哪裡怪怪的，但，你無法改變，因為制度的設計者不是你。

一個新方法

然而，敏捷開發法的出現，和過去工程方法誕生的方式完全不同，敏捷開發的概念是由有實務開發經驗的開發人員所設計，這跟過去建構工程方法的管理階層，自己從來沒下來搬過磚塊的狀況有著很大的差別。

敏捷開發法的設計者認為，你不能把程式設計師看做資源，軟體開發的團隊，也根本不是傳統的施工團隊。如果真要比較，軟體開發團隊比較像是一組球隊(team)，團隊中的成員每一個都有自己獨特的角色和任務，人人不可或缺，無法輕易替代。每一個球員的產值也大不相同，高低之間可能相差數十倍，無法相提並論或替換。

這是一個認知上的巨大差異，一旦當你把軟體開發團隊，從傳統工程(例如營造)的施工團隊，轉變成球場上的團隊，你會發現你的思維將會瞬間轉換。你將不再相信傳統的專案管理方法，你帶領團隊的方式也會大不相同。

DevOps/ALM/Agile與軟體專案管理

一旦你用一個全新的眼光看待軟體開發，你對於軟體開發的方式，採用的專案管理工具、做法，都將會跟以前有所不同。

也因此，我們這篇先談敏捷開發，然後接著，我們要來看，在這個思維底下，如何管理軟體專案，如何管理軟體生命週期，如何透過工具來實現DevOps…

如果你要惡補你的敏捷開發概念，請參考底下這本書:
http://www.books.com.tw/products/0010691328

下一篇，我們談時程預估與迭代的概念。

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html

如果需要即時取得更多相關訊息，可按這裡加入FB專頁。若這篇文章對您有所幫助，請幫我們分享出去，謝謝您的支持。

留言

張貼留言

這個網誌中的熱門文章

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中
Read more »

VS Code的字體大小

作者： -
圖片
身為.net developer，這年頭是什麼code都得要會寫的年代。 而雖然我的NB還沒從Windows淪陷為Mac OS，但寫Node.js和Python免不了要用VS Code，這是一種愛的表現。 但歲月不饒人，盡管微臣非常熱於配合，但VS Code預設字體的大小在我還沒錢買大尺寸螢幕的狀況下，實在讓老臣難以適應。當下的第一個反應是什麼? 當然是 Ctrl+滑鼠滾輪往上推…哇靠，沒用。看…這設計…恩，千錯萬錯一定是我的錯。 只好從選單 file –> Preferences –> Settings: 在出來的視窗中，你可以看到 editor.fontsize: 沒錯，改它就行了。改不動? 喔，不好意思，我沒仔細看說明，要copy到右邊是吧，沒問題，copy->paste->modify->Save…搞定。 好簡單啊…連ctrl+(mouse scroll up)都用不到了呢… 咦?這是一篇抱怨文嗎? 沒有，誰說的? 免費的tool我們還有什麼好抱怨的呢…要感恩啦。 啊….對了，如果你還是堅持要使用 Ctrl+滑鼠滾輪，請找關鍵字… "editor.mouseWheelZoom"
Read more »

使用 Dify 建立企業請假機器人

作者： -
圖片
八卦與未來 上個月，前Google執行長Eric Schmidt在史丹福有場演講，媒體關注的是八卦消息(如果你也曾關注，網路上有很多鐵定可以找到)，但我注意到的則是他提到了自己認為接下來 AI(特別是大語言模型) 可能的發展方向，包含: Large Context Window AI Agent Text-to-Action 底下這邊有這一個段落的影片： https://www.youtube.com/watch?v=zl3k1ksFZdY 為何我會關注這部分? 因為上述的三個方向，也是身為開發人員的我，過去這一年，來與LLM打交道後的感想。昨天，我在 twMVC 的研討會分享中，展示了一個其實我過去早做過了N百次的範例，就是企業的請假機器人。(唯一不同的是，這次我幾乎沒有寫任何程式碼) 場景是，員工在家裡生病了，想要透過語音或是app進行請假，你可以看底下這個運行的範例 (git圖檔會循環播放，開始是 『我好像感冒了』)： 用自然語言對談的方式，即可完成請假。 我說過，類似這樣的範例我做過很多次，用 LINE Bot 搭配 C# 做過，用MS Bot Framework 做過，前陣子也用 Semantic Kernel 框架做過，更早期，還沒有AI的時代，我也在EIP和HR系統裡做過。 但我想說的是，這 就是 Text-to-Action 的呈現，也是一個典型的 AI Agent 的例子，它讓我們透過自然語言(可以是語音或文字)，直接命令機器人(Chat Bot、AI 助理、Agent、Assistant …不管你叫它什麼…)幫你完成一件事情(請假、售票、查詢資料、做財務報表、統計圖表、寫程式…etc.)。 這是一直以來人類對電腦最底層的需求與期待。 隨著 LLM 能夠處理和記憶的 Context 愈來愈被放大，AI Agent 所能夠處理的任務就更加的不受限制。 自然語言才是最符合人類直覺的操作 順帶一提，我昨天在研討會中講了一個故事。 有天，你覺得自己需要聘請一位助理，因此上網張貼徵人啟事，沒多久，你找到了一位號稱上知天文、下知地理的高材生，來幫助你更有效率的完成工作。 他什麼都好，唯一的一個小缺點是，你不能直接對這個助理下達指令，你必須用一種只有這個助理看得懂的語法，才能要求這個助理幫你完成特定的工作。這些語法還挺
Read more »

使用Qdrant向量資料庫實作語意相似度比對

作者： -
圖片
什麼是向量資料庫? 在許多的AI實作當中，都有向量資料庫的使用需求。例如RAG(檢索增強生成)、或是資料的相關性比對、相似性搜尋…等，這些應用情境中，我們都會用到向量資料庫。 向量資料庫主要的任務，當然就是存儲和查詢向量數據。被儲存的向量數據通常是高維度的資料，以陣列(集合)的形式呈現。 例如，OpenAI就有提供一組Embedding API，讓我們可以把文字給向量化。你可以透過該 API，把一句話(一段文字)轉換成向量數據，類似底下這樣： OpenAI 的這組 Embedding API，在預設狀況下，會把資料轉成 1536 維度的向量數據，其背後的行為是把文字送給一個訓練好的模型，透過該模型跑出這組向量數據，再回傳給用戶。 然而，把一段文字給向量化的目的是什麼呢? 當我們把文字做了這種轉換後，在 1536 維度的座標空間(向量數據)中，愈相似的文字，透過Embedding API會得到距離愈接近的座標點，藉此，我們得以迅速的判斷兩段文字在語意上的相似性。 而向量資料庫中所謂的查詢功能，主要就是向量的檢索，像是『近鄰搜索（Nearest Neighbor Search）』，當用戶或應用程式提交一個向量查詢時，向量資料庫會幫我們找出資料庫中，與之最相似(接近)的向量座標點。 因此，開發人員只需要透過 Embedding API，把文字轉成向量，再把轉換好的向量座標值，儲存到向量資料庫之中，未來就可以透過向量資料庫來查詢相似(接近)的文字。 關於這個部分，如果讀者有興趣，前陣子有段網路上的影片把多維度向量資料庫的概念介紹的蠻清楚的: https://www.youtube.com/watch?v=W_ZUUDJsUtA https://www.youtube.com/watch?v=ct20Kv8yn0U 為何需要? 向量資料庫最實務上的應用，就是找到類似的特徵值。 例如，當我們把人臉的特徵值以向量資料的形式儲存到向量資料庫中之後，我們就可以透過資料庫本身提供的搜尋功能，快速地尋找出相似的人臉，這也是許多AI應用實現的基礎。 我們底下的程式碼範例，則是找出最接近的問題。(呃…什麼意思?🤔 請往下繼續看) 我們在建立對談機器人時候，常常需要讓機器人回答用戶的問題。這時，我們會讓用戶輸入問句，然後透過 Embedding API
Read more »

使用C#開發LineBot(3) - 使用LineBotSDK發送Line訊息

作者： -
圖片
新版的Line Messaging API，要主動發送訊息給用戶不是很困難，主要是透過Push API，可以參考底下的官方說明 : https://devdocs.line.me/en/#push-message 另外，如果你想申請一個Line Bot，可參考: 關於LineBot (1) - 用c#建立一個LineBot 前陣子說過，我們為了團隊開發方便，做了一個 Nuget Package 以便於讓撰寫C#的開發人員可以方便的進行Line Messaging API的操作。 所以，如果你想要透過該SDK來發送訊息給用戶，可以透過底下的指令: isRock.LineBot.Utility.PushMessage(               UserId, 要傳送的訊息, AccessToken); 別忘了使用前，要先引用linebotSDK這個套件: 當您在.net 4.x的專案中，安裝上述lintbotSDK，即可透過前面提到的指令發送訊息給用戶，但請注意，該用戶必須加你的bot為好友。 你可能在使用時會碰到一個問題，怎麼知道用戶的id呢? 請注意，PushAPI的Line用戶id並非你的line ID，而是一長串項是底下這樣的id: U6OX388eOX3634X2OX2e341OX06b8OX4123 這個ID會在你的用戶跟你的bot交朋友，或是對談的時候，由系統傳送給你所設定的WebHook網址(其本質上是一個asp.net WebAPI或類似的API服務)。你會在Line傳遞給該WebHook URL的封包中的JSON形式資料內獲得。 也就是說，當你的用戶傳訊息給你的Bot，或是與你的Bot做朋友(或封鎖)，你所在你的LineBot後台，所設定的這個WebHook，都會收到這些相關的訊息。其設定位置如下: 訊息內容是以JSON的格式出現。 但是，如果你還不知道怎麼寫一個WebHook，該怎麼辦呢? 寫個WebHook其實很簡單，以asp.net來說，就是寫一個asp.net WebAPI即可。(有空我再說明，但今天比較沒空) (2017更新，WebHook開發方式請參考 這裡 ) 如果你沒空寫，可以先用底下這個工具(注意這個工具 僅限測試使用 ，我們不保證其穩定性與可用性、與資料安全性): http://isbaas.azurewe
Read more »