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 »

使用 Dify API 快速建立一個包含前後文記憶的對談機器人

作者： -
圖片
Dify 這個產品我就暫時先不介紹了，它找到了一個挺好的切入點跨入AI Agent市場。讓不喜歡(或不擅長)寫太多 Code 的開發人員，也可以快速的建立一個具有前後文、記憶的對談機器人。 其實若單就設計 Chat Bot 來談，它本質上和 GPTs 有那麼一點點像，你只需要給一個 system prompt ，再加上一點點的資料上傳做為 RAG 的數據來源，就可以生出一隻有模有樣的對談機器人。 但 GPTs 做出來的 Chat Bot 被綁在 ChatGPT 的 UI 裡面，你不容易把它跟 LINE Bot (LINE 官方帳號) 或其它 UI (例如 MS Teams) 串在一起，而 Dify 呢? 則給你了一個 chat-messages API，讓你能很快的實現這個功能，把你在 Dify 平台上做好的 Chat Bot 轉變成可以正式運行的 LINE Bot 或 其它 Bot。 這也是今天我們要介紹的部分。 建立 Assistant 我們先用 Dify 以底下這個 system prompt 建立了一個請假助理： 發佈後，你可以在Dify 內建的 Web UI 上測試： 你會發現，這個 chat bot 已經有著基本的記憶，然後可以依照 system prompt 完成對談和任務。 不要問我在這邊建立出一個假單有什麼用，正常情況下是要直接讓 chat bot 寫入資料庫(例如 HR 系統，直接完成請假)，只是我們還沒談到這一段，這部分以後再展開來談。 chat-messages API 好，透過上面那樣建立一個對談機器人超容易，且內建就有了記憶和前後文的功能。讓開發人員快樂的不得了。跟使用無腦 GPTs 生成術差不多。然而，如果只能在 Web 上用，不能串接 MS Teams、LINE…等介面，做了也是白搭。 但，Dify 貼心的提供了 API，我們來試試看。先Gen個 API Key： 生成了 API key 之後，你只需要透過底下這樣的 rest api，即可進行呼叫： 你會發現，開發人員只要使用單一的這一個 https://api.dify.ai/v1/chat-messages API 即可進行對談。每次只需要透過 query 輸入用戶說的話，response 中的 answer 則是 LLM (Assist...
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開發方式請參考 這裡 ) 如果你沒空寫，可以先用底下...
Read more »