Development Experience for Team


整理對 Development Experience (DX) 的看法,原文草稿發表於 Facebook


一、海賊王 D 之一族的傳說:定義 Developer or Development

首先是 DX 這個詞 D 的定義,很容易被理解成 Developer Experience (DX),而 Developers 通常指的是 寫 Function / Feature 的人。所以有各式各樣的想法、做法、工具,讓開發人員更順暢的工作、提升產能,像是 工程師喜歡 找了一堆工具來增加產能、或者讓工作更流暢,像是 VSCode 的 Extensions。

  • 註一:寫 Function / Feature 的人 更精準的詞應該叫做 Programmers,而社群的鄉民會用 Coders 這個詞來調侃自己,而外界更普遍的用詞稱他們為 Engineers,但實際上 Engineers 其實包含其他像 QA / Ops 等角色。
  • 註二:關於 Developer vs Engineer 的差異,我個人的定義參閱 “Developer vs. Engineer“。
  • 註三:啥是 Function / Feature 以後再說。。。再歪樓下去我會收不了筆。。。

不過比起 Developer Experience,我覺得 Development Experience 更適當。Development 代表參與這個產品開發的團隊所有成員 (Team),我在 “Software Development Lifecycle“ 一文定義常見的角色有以下四大類:

  1. Planner: PO / PM / UI/UX / SA / Architect / Developer
  2. Executor: SWE / Programmer / Coder
  3. Accepter: STE / QA / Tester / SDET / QE / QoO
  4. LiveKeeper: Ops / Infra / SRE / DevOps / SE / IT / MIS / …
  • 其中 2), 3), 4) 統稱 Engineers。
  • 中文很麻煩,當我寫 工程師 實際上想表達的是 Programmer,而對我來說,大部分的 工程師 都不能算是 開發者
  • Software Engineering at Google 這本書一開始提到 工程 (Engineering) 的定義,我自己的定義有兩個面向:已知規模 (Known Scale)可以擴展的規模 (Scalable)
    1. 已知規模例,如 … 要建立捷運板南線、三峽大壩、台電輸配電工程、蓋 101 大樓 … 等已知的巨觀規模。
    2. 另外一種則是未知規模、但可以擴展成巨觀的能力,稱為可擴展 (Scalable),軟體工程大多就是這種。
    3. 不管是已知規模、還是可擴展的規模,工程都必須具備的關鍵特性:可靠性 (Reliability)。前述兩個定義,都要具備可靠性,才能稱之工程。

這些成員,都是 Development Team 的一員。Programmer 有太多 DX 的方法、工具,但我覺得,整個團隊不是只有 Programmer 才是人,也應該關心一下,開發團隊其他成員的開發體驗。

  1. 大家知道我們的 QA 是怎麼測試的?開始測試前應該具備哪些條件 (先不用談測試左移)?
  2. 大家知道 上線前、中 Ops / DevOps 怎麼處理 Infra / Build / Deploy 的事情?上線後 Ops / SRE 是怎麼處理線上異常與事件?應該怎樣改善這些體驗?
  3. 還有辛苦的 Planner (PO / PM …) 是如何把需求收斂成可執行的規格的?

整個過程 有體驗可言?怎麼改善這個過程的體驗,讓大家開發的協作有更順暢的體驗?

Again, 品質是整個開發過程

DevOps?

歪個樓,大家常聽到的 DevOps 這個 BuzzWords,通常理解的都是狹義的 Development、或者一些文化之類的,也就是前一段提到的 “2), 4)” 的關係。

廣義的 DevOps 的 Dev 也不是單純講 Programmer,而是以公司角度來看的產品開發 (Product Development),而 Ops 比較像是業務與營運單位。這個角度來看,我前面提到的四個角色都屬於 Development Team,而 Operation Team 則是把業務帶進來、讓客戶留下來的管理單位,像是業務、行銷、營運單位 … 等。

類似概念可以看我幾年前分享的演講 “導讀持續交付 2.0 - 談當代軟體交付之虛實融合“,有提到廣義 DevOps 的看法,如下圖:



二、Are You Experienced:是 的體驗 (Experience)

標題引用 傳奇音樂家 Jimi Hendrix 最有名的專輯:Are You Experienced,是音樂史的里程碑,重新定義了如何體驗音樂。AWS 2015 的 Well-Architected Framework 介紹也引用這個概念。

談完 D 的定義,再來談談體驗 (Experience),我想專注的是 “誰” 的體驗?

關於體驗,大家最常見的就是 User Experience (UX),這個 User 指的是終端使用者 (End User)。最經典了例子就是 開箱,源自於 Apple 產品的體驗感,讓廣大鄉民都可以藉此寫寫廢文、找理由當 Youtuber、無腦下單 … etc。

承接上一段 Development 對象的定義,而對於 Programmer 而言,最常見的開箱就是:

  • 到 GitHub 找到一個 Open Source,透過 Quick Start / Getting Started 快速體驗怎麼用,能否解決問題、或者有炫砲的感受。。。。
  • 這十幾年全世界開發的份圍,體驗就是:一堆花花綠綠的 terminal、emoji、powerline … 等炫砲 …

如果不容易讓人理解怎麼用,就會被跳過去,因為開箱體驗不好。

上述我覺得都是普遍的第一觀感,其實這些也滿重要的,雖然有時候覺得有點膚淺,但確實是會讓人更容易入門。

我覺得真正的開發體驗應該是這種,舉例以下幾種:

  • 第一個是 SpecFlow: 改善橫跨 PO / Programmer / Tester 針對規格的理解,與落地執行測試的方法。有了這個方法與概念,才有後面的工具產生。
  • 第二個是 Containzied (Docker):這個技術的出現,改善了交付的定義,讓所有角色 (四大) 都可以用統一個方法輕易的交付,終結 在我的電腦可以跑,你的電腦不能跑 的交付體驗。

這兩個例子,都是軟體開發劃時代的體驗,我相信還有其他很多概念、方法、技術改善了團隊協作,增加效率。

另外語言層級的改善,像是 .NET6 從 v3.1 ~ v6 的改善,也是個不錯的案例。.NET Developer 如果 .NET 3.1 到 6 一路體驗下來,就可以感受到在 Language 層次的體驗,越來越精簡、越來越多語法糖,啟動 Startup.cs & Program.cs 兩個變成只有一個 Program.cs,更簡單了,更容易理解了。類似的 DX 改善 node.js 生態系的就跑得更前面了。只是直接受惠者只有 Programmer。

以前哪些體驗不好,或者不好入門的工具,像是 vi / git,則是因為本質夠強大,就有人會主動去改善它的體驗。


三、體驗,使用者的體驗

前面定義的四大角色,以及針對體驗的描述都是內在的東西。也就是每個角色,自己在開發過程的體驗如何,都是角色自己的角度出發。

體驗是動詞。

真正的體驗是以客戶的角度,體驗自己的產品,以電商為例:

  1. 應該要去驗自己的產品,像是走完一家店的流程、到後台過商品、從 End User 角度下單、然後客戶角度去後台完成訂單流程
  2. 給客戶前,應該去用自己開發的 API,吃自己的狗食

怎麼落實這種體驗感?什麼時候開始?上 Production 體驗?我的答案是:

Containzied 技術的出現,已經滿足這種體驗的需求。

在上 Production 之前,不管是怎樣的應用程式、怎樣的架構,都要可以在一台電腦裡 (Linux)、用 Container 跑起來,走完所有業務邏輯。

從設計與規劃階段,就要想這件事情,以終為始。還沒出貨之前,就已經完全可以從客戶角度,體驗整個產品。”淺談軟體測試的階段與策略“ 一文最後談到這整個想法與脈絡。

體驗會讓我們產生行動與認同感。除了薪水,這是凝聚員工向心力與認同感最實際的方法。


後記

寫這篇背後是因為:

  1. 資訊發達的時代,太多單一觀點,在決定所有角色的方向,忽略個別角色的角度。
  2. 單一觀點寫出來的東西,在網路流傳,如果那個人又有點名氣,整個世界就是被帶風向
  3. 團隊有好的開發體驗的同時,也要同步提升自我的專業知識

而我是少數經歷 經歷 Software Develpoer (國際外商)、SQA Manager / SDET Lead (IoT 新創)、Operation / Infrastructure Manager (電商新創)、Architect (電商新創) 等角色,而且每個角色都是全職的、經歷從零到一個過程,對於軟體開發體驗的觀點,有別於單一角色的觀點。


延伸閱讀

站內文章



Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲