Software Development Lifecycle


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

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

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


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:

站內相關文章:


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

相關文章:


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

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

v1.5 201908

Updated:

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

2018/03: 深談維運

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

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

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


結論

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

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

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

  • 規劃 (Plan):包含以下
    • 市場調查、使用者情境
    • 需求分析管理、使用者體驗 (UX)、使用者介面 (UI)、
    • 技術評估 (PoC, Evalution) 與研究 (Research)、架構設計
    • 成本、風險管控、資源 ….
    • 執行方法,現代流行 敏捷開發
  • 開發 (Development):真的開始執行了,主要就是寫商業邏輯程式,大部分軟體工程師會注意的地方。
    • 主要有四個部分:System Analysis、System Design、Coding、Unit Test,以前習慣簡稱 DCUT,是一個合格的 Developer 必須做好的本職.
    • 注意,不包含 Research,台灣常混在一起稱 RD …
    • 重構程式 (Refactoring):這是必要的途徑
  • 測試 (Test):驗證階段,也就是測試。
  • 維運 (Operation):上線前後的準備工作都是維運,舉凡 System EngineerDevOpsSRE … 都是這裡。這裡最複雜,也是最容易被忽略的,常常會被歸類為成本單位。我把定義有五大 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. 相關文章:
    • Security: 算是另一個維度,是非常重要且一開始也要考慮到的!

口語上的 開發 (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),也就是還在開發驗證中。


延伸閱讀

相關資料


Comments