軟體開發生命週期 (Software Development Lifecycle, SDLC) 是軟體工程裡很重要的概念，不同的角色 (PM, Developer, Test, Operator) 會有不同看法，從不同方法論 (CMMI、RUP、LEAN、XP、Agile、Scrum、DevOps) 也會有不同階段定義，Google 可以找到很多類似的圖。

類似的東西聽了不少，但是往往講者會因為個人經驗，會偏重在某一方面。像是現在經常提自動化測試，很多都是開發人員在喊，卻鮮少聽到從 QA 端的聲音；經常聽到開發人員在喊 DevOps，但實際現場調查很少 Operator 加入討論，更別提資安相關角色。最有趣的是，我還沒遇過有 PM 懂這些流程的，PMP 那又是另一個世界。

• 同一件事，不同角度的人有全然不同的看法。這篇文章討論 DevOps 也有類似的想法：关于 DevOps ，咱们聊的可能不是一回事
• 關於敏捷軟體開發，我的想法請參閱這篇整理：談談敏談開發的看法

本文記錄我在不同的工作時期的體悟和心得。

2012/12: 從 SQA 角度的流程

這個階段主要考慮從老闆的 需求 到 Developer 和 SQA 的協作，部分的 Release Engineer (潮一點的說法 DevOps Engineer)。考慮 開發 跟 測試 在每個時間點對應的工作，以及協作方式。

這段在 Startup 的過程請參閱這篇的描述：協同合作系統建制與導入 - 以 Redmine 為例。開發流程沒有什麼很潮、很鮮的敏捷開發，而是很傳統的 Waterfull，但是主軸就是要讓大家彈性的做事。

完整 Slide (Updated: 2019/08/03)

最近跟朋友聊到這幾年軟體開發的份圍與方法 敏捷開發 的看法。聊到一些想法與概念，主要的問題還是一樣：

• 不知道有哪一些是重要、不急的事，特別是工程領域，沒看到全貌，說直白的：領域技能不足
• 省略了很多原本該做的事情，忽略基礎工程
• 『用技術不重要，人才是一切』反駁該做的事
• 團隊技能不足，管理水準不夠

讓 敏捷開發 的美意變成一種炫砲的行銷用語。

討論的過程，我提到以前雖然沒有跑很快，但跑得穩，該做的都有做，而且大家都知道：

1. 有哪些要做
2. 每次要做什麼準備
3. 依照狀況，做取捨

我們跑的原則是：

用品質建立數量，由數量產生速度

經過一些觀察之後，發現問題是：

1. 很多人根本不了解『有哪些要做』，不具備該有的專業判斷
2. 然後就想開始做取捨，說這是敏捷。

用下面這張圖解釋這樣的現象：下棋前知道下棋規矩，棋局中要看棋局狀況，才能決定動作。

知道棋局狀況，也就是掌握全貌
然後依據規矩、全貌決策

所以很常見的問題就是，棋局就還沒看清楚，就開始亂下棋了。根本不需要談所謂的佈局、棋局的層次。

這個比喻，是我在內部分享想法時引用的，後來也放在這篇文章中： 證照有無用論？

回到討論中，我想到很多年前的這個簡報。我做的事先把整個制度、流程、組織都釐清、確立了，才開始用工具 (Redmine) 來協助，把制度流程都放到工具裡。這是有先後次序的：

1. 先有制度、流程、組織、紀律等
2. 再來把這些東西，放到工具、系統裡，也就是導入工具

回想當時，我是 1) 先有這張 Software Development Process 的定義與釐清，後來 2) 才有這篇 協同合作系統建制與導入 - 以 Redmine 為例 的導入。整個過程雖然辛苦，但卻是正向的，也就是感覺踏實的。時間越久，效果越明顯。

很多時候的誤區就是：先找了工具，但卻沒有流程 … 整天研究工具，卻不思考自己的流程、組織性問題。

雖然當時我的工作內容是 SQA Manager，但實際上在看的卻是 整個開發團隊 (Development Team) 的角度 (參閱 談當代軟體交付之虛實融合 介紹)。這幾年敏捷常喊打 Waterfall，但實際上經過這幾年的轉折之後，覺得該有的東西還是要有，並不會因為換成敏捷開發、或者看板模式，要做的事情就可以省略。隨著時間越久，那些該做的事情，重要性就越來越高，越來越難做，一開始沒做，越到後面、組織越大、人越多、亂度（熵值）就會以指數上升。

經過一些考慮與 Review，把當時 (2012/12) 的簡報，移除敏感資訊之後，釋出完整的 slide：

站內相關文章：

• 協同合作系統建制與導入 - 以 Redmine 為例
• 淺談軟體測試的階段與策略
• Software QA 的職能條件
• 輕鬆聊系統測試 (SVT) 的三兩事
• 談談敏談開發的看法

2016/01: 從開發者角度的流程

這張圖比較聚焦在開發者的角度，同時也包含上線後的議題處理。開發重點沿用 IBM 的 DCUT，也就是 Design, Coding, and Unit Test，我只是做了一些調整。

圖中 Suggestion 是我很常用的 Feedback 方法，也就是開發過程中，大家透過建議的方式，Feedback 給團隊、或者是 PM，讓開發過程溝通更好，產品自然而然就會好。

2016/06: 系統維運角度

以 系統維運和管理 (System Operation and Administration) 角度出發，與各個單位，包含決策單位、管理單位、開發單位 … 等在各個時間應該要面對的任務。

這張的角度比較偏向 IT 與公司營運出發了，少了很多軟體開發，但是基本精神依舊是那四個：

1. Plan
2. Execution
3. Acceptoance
4. Operation

後來針對 Operation 的想法都整理在這個分享：Serverless All-Star - Ops as Code using Serverless

相關文章：

• 再談啥是維運？
• What is Ops？
• What is Monitoring?
• Monitoring vs Observability
• 怎樣的 CI/CD 才夠 Quality?

2016/06: 從整個軟體開發團隊，看見全貌

最終，我還是覺得要聚焦在整個開發團隊的 視野，每個區塊，都有期對應的職責，甚至是組織。

Updated:

• 2019/08, v1.5
• 2016/06, v1.0

2018/03: 深談維運

這張圖是針對 維運 的想法，圖中表達了 人、事 的維度，人包含職場上各種常見角色的分佈，事則是具體執行的工作內容。

圖上面灰底、橘底代表兩個面向：節流、開源

完整的 Slide 整理在：Serverless All-Star - Ops as Code using Serverless

2022/09/17: 談 Development Experience for Team

Development Experience for Team 一文整理開發週期對於各種角色的定義，呼應本文的想法，重新定義名稱如下：

1. Planner: PO / PM / UI/UX / SA / Architect / Developer
2. Executor: SWE / Developer / Programmer / Coder
3. Accepter: STE / QA / Tester / SDET / QE / QoO
4. LiveKeeper: Ops / Infra / SRE / DevOps / SE / IT / MIS / …

結論

而這些圖也不是存粹的時間導向，應該是要平行的，齊步跑的，也就是開案，這些單位就要一起同步，而不是接力賽，如下圖：

一路走來，我一直在嘗試調整 視野，期望能夠從不同角度，看得更清楚。而最後整理出來的結論：軟體開發要知道有哪一些角色會參與，然後應該什麼時間點知會相關的人，這是 PM / PO / Boss / 管理階層 的責任。

對我來說，一個成熟的軟體開發至少、至少、至少要有這四個面向：

• 規劃 (Plan)：包含以下
  • 市場調查、使用者情境
  • 需求分析管理、使用者體驗 (UX)、使用者介面 (UI)、
  • 技術評估 (PoC, Evalution) 與研究 (Research)、架構設計
  • 成本、風險管控、資源 ….
  • 執行方法，現代流行 敏捷開發
• 開發 (Development)：真的開始執行了，主要就是寫商業邏輯程式，大部分軟體工程師會注意的地方。
  • 主要有四個部分：System Analysis、System Design、Coding、Unit Test，以前習慣簡稱 DCUT，是一個合格的 Developer 必須做好的本職.
  • 注意，不包含 Research，台灣常混在一起稱 RD …
  • 重構程式 (Refactoring)：這是必要的途徑
• 測試 (Test)：驗證階段，也就是測試。
  • 第一張圖點出一個重點，測試的工作不是測試才開始，而是專案一開始就要開始進入。
  • 測試 (Test) 和品保 (QA) 是不樣的概念。
  • 測試的方法與策略參閱 淺談軟體測試的階段與策略
  • 測試的職能參閱 Software QA 的職能條件 的深度介紹。
  • 自動化測試是熱門話題，但 自動化 倚賴相當程度的工程能力與素養， 軟體自動化測試常見的問題 一文是個人切身的經歷分享，Designing Test Architecture and Framework 則是整理過去設計測試架構的想法。
• 維運 (Operation)：上線前後的準備工作都是維運，舉凡 System Engineer、DevOps、SRE … 都是這裡。這裡最複雜，也是最容易被忽略的，常常會被歸類為成本單位。我把定義有五大 Stages
  • Provisioning: 環境建置、配置 … Orchestration, Infra as Code. 更多參閱: Resource Provisioning and DevOps
  • Deployment: Build, Packing, Deploy, Rollback
  • Observability: Observability and Monitoring, Loggin, Alert, Dashboard
  • Maintain: Backup, Recovery, Security, Permission, Cost … (不知道算啥就丟這裡)
  • Pipeline: 串接上述工作的工作 (有點繞舌)。像是 Jenkins 這種工具，可以 Build / Compile，但也可以用來串接 CI/CD 的 Jobs. 相關文章：
    • Artifacts Management
    • 怎樣的 CI/CD 才夠 Quality?
  • Security: 算是另一個維度，是非常重要且一開始也要考慮到的！
    • 更多參閱 AWS Well-Architected

口語上的 開發 (Development) 有幾層含義，底下是一般組織裡的常見開發結構：

• 開發 = 寫商業邏輯 Code 的工程師 (狹義的開發)
• 開發 = 開發 + 測試 + 維運 (DevOps 的概念)
• 開發 = 產品 + 開發 + 測試 (企業角度)
  更多參見： 心得：持續交付 2.0

P.E.A.G

我把上述提到的四個概念：Plan、Execution、Acceptoance、Operation 再一次 抽象化 後得到以下：：

1. 規劃 (Plan): 商業、業務、資源、成本、時程、架構、PoC、User Story …
2. 執行 (Execution): 像是軟體開發的 Design, Coding, Unit Test、解一個 Bug
3. 接受 (Acceptance): 確認執行的結果是否符合 Verification Point, 像是驗收、測試
4. 現場 (Go Live): 接受之後，就是把產品放到現場，維運 (Operation) 是一般的說法。現場要觀察 (Observability) 與收集回饋 (Feedback)、做現場的 應變管理

這四個面向姑且稱為 P.E.A.G.，可以運用在各式各樣的領域，像是 軟體工程、IT 維運管理、測試、生產導入 NPI … 等。

我把這四個抽象的階段，應用在 看板導入

網路上有很多類似的圖，像是 google DevOps, SDLC，都會有很多圖。但是往往都太複雜，或者太偏想某一個角度。像是 DevOps 的流程很容易偏向 Dev or Ops 的角度、PM 或系統分析角度會很偏開發，而完全忽略 Test、Operation、Security。。。

因為太複雜，不好溝通，所以我一概用四個階段來作為整個的流程與生命週期。

我常常會這樣比喻：產品交到客戶手上之後，叫做維運階段，產品是從這個時候開始活起來，才開始有故事。在產品還沒交付 (Delivery) 到客戶手上之前，但是已經可以賣了，叫做部署 (Deployment / Shipment / Packing)。但是在產品出工廠之前都是 在製品 (WIP, Work in Process)，也就是還在開發驗證中。

延伸閱讀

• 需求管理
• 淺談軟體測試的階段與策略
• AWS Certified SysOps Administrator - Associate 準備心得
• Monitoring vs Observability
• 協同合作系統建制與導入 - 以 Redmine 為例
• Software QA 的職能條件
• 人生的視野
• Resource Provisioning and DevOps
• 看板導入 - 軟體開發與維運
• 談談敏談開發的看法
• Serverless All-Star - Ops as Code using Serverless
• Artifacts Management
• 心得：持續交付 2.0
• 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
• Development Experience for Team

相關資料

• AWS Well-Architected
• 每个架构师都应该研究下康威定律
• AgileTesting Framework
• 关于 DevOps ，咱们聊的可能不是一回事