我在瑞典當產品設計師（2）敏捷式開發中設計師的反思

什麼是敏捷式開發（Agile Software Development）？

敏捷開發，顧名思義就是要能夠快速輕鬆地移動。就以軟體開發而言，敏捷要求的是能夠在最短的時間內交付可以使用的產品，並透過重複相同的開發流程，來更新、迭代產品。敏捷開發要求的是「更好」，而非「最好」。

其實敏捷開發對我來說不是一套開發方法，而更是一種心態（Mindset）或是價值觀。其實若比較敏捷開發的流程，跟傳統的瀑布式開發並沒有太大差異：獲得需求、設計、開發、測試、發布、維護/更新。大概就是這樣子的流程，不過敏捷把所有的事情最小化，也讓產品能夠持續不斷的進化。

而為什麼會說敏捷開發更像是價值觀呢，主要是敏捷開發的社群也很重視這個價值觀。畢竟流程可以輕鬆複製，但是「為什麼要這麼做」卻是能影響產品開發最重要的一個因子。

舉例而言，如果一間公司號稱使用敏捷開發，但重視流程與工具更勝於重視個人與互動，那麼這間公司可能就不是真正的在執行敏捷開發，而是一種速度更快，組件化的瀑布式開發。

敏捷團隊長什麼樣子？

最小的團隊組成可以是這樣：產品負責人(Product owner)、Scrum Master、開發團隊（包含設計師與工程師，依據專案不同有所不同）。而Scrum Master這個角色可以是一個完整的人，有的時候也可以由其他人兼職，像我現在的團隊就是團隊成員輪流當Scrum Master。

不過，由於敏捷開發重視的效率與彈性，因此團隊組成並不一定要是一個非常固定的團隊。舉H&M為例，我們雖然有團隊，但是卻有很多功能需要其他專家的支援，這些專家不需要常設於團隊之內，但是卻要能夠依據專案需求靈活的支援各個計畫，以保專案能順利運行。

除此之外，跨團隊、跨部門的溝通也是敏捷開發中非常重要的一環。Spotify的團隊組成是一個很知名的例子。他們每個專案由各個Squad（小隊）組成，小隊裡的成員可能來自不同部門，有不同的主管，但有趣的是他們還有一個稱為Guild（協會）的組織，讓用有共同興趣、想彼此交流技術或想法的人自由組成，促進知識交流。

不同規模的企業如何套用敏捷開發？

回顧我的工作經驗，約有一半的公司會強調自己是敏捷開發，另外一半正在導入敏捷開發。敏捷開發可以說是在1990年、互聯網產品大爆發後就一直被視為圭臬的軟體開發方法。

不過，真的這麼神嗎？！

說老實話，我閒暇之餘與同事或朋友在談論敏捷開發時都覺得多數公司把敏捷跑成小瀑布。主要的原因就像我前面所說的，敏捷開發所強調的價值，並不容易被體現，而多數企業會認為，只要團隊是跑Sprint、有Daily scrum meeting、有Retro meeting，那就是敏捷開發了，但這正落入了「重視流程與工具」的基模裡了。

新創小公司如何跑敏捷

就我過去的經驗，除非公司內有非常熟悉敏捷開發的成員，並且由創辦人或是高階管理人開始推動，整個組織由「文化」上就很敏捷，不然其實是有一定難度的，不過小公司的優勢在於嘗試新開發方法的成本低，而且在還沒建立屬於自己的流程前，多方嘗試也是建立文化的重要步驟。

我所待過的小組織，由於本身「既定規則」就比較少，因此也容易靈活的依據專案內容來決定開發方法。雖然不見得會有專業的敏捷教練、Scrum Master編製在組織、團隊內，但是文化與價值觀上倒是更容易建立起來。主要在於小組織的互動較為輕鬆、也較為有活力，是很適合使用敏捷開發的。

但小組織有一個很關鍵的是創辦人/高階主管的態度，若是該角色認同敏捷的價值，並減少自身干涉產品開發的程度，或是將自己定位成與團隊成員一同開發、彼此意見權重相當的角色，那麼會更容易推動敏捷開發。

大公司如何跑敏捷

大公司就體質上我覺得比小公司更難推動敏捷開發。主要原因在於人數多溝通耗時耗力、進入市場若失敗的成本高，以及各個產品間牽一髮動全身，勢必要遵循計畫，較難回應變化。

但大公司的好處是，一旦決定要推動敏捷開發，便能有充沛的資源來輔助開發流程中可能遭遇的困難，或者是提供教育訓練、敏捷教練等等。像是H&M就是我認為資源充沛的公司，但仍然在導入敏捷的過程中力有未逮，而演化成一種Hybrid的開發方法。

舉個例子，由於組織龐大，所以我們非常重視文件，主要是因為文件能讓跨部門、跨時空的成員對同一個計畫有相同的了解。而在彈性上，老實說並不算是非常彈性，主要都是把規劃好的事情做完，儘管中間發現像是「用戶需求與假設不盡相同」這種算是非常關鍵的曲折時，我們也只會把這個議題放進Backlog裡，而非當下調整定義好的Scope，且由於時程通常與整間公司或其他關鍵部門一起規劃，所以這種新增的backlog都會被越排越後，產生很多未來要還的「債」。

因此我認為，組織的大小並不能用來決定什麼樣的開發流程合適，而是更應該考量產品本身的性質以及公司的文化。

設計師的挑戰與反思

任何一個角色在敏捷開發中都是非常重要的，而以我的角度，我認為在敏捷開發的組織內當一個設計師，除了需要具備一定程度的設計能力以外，定義或是Reframe（重新架構）問題的能力也要非常強。

怎麼說呢，由於我們收到的需求不會像傳統的開發模式一樣，有非常詳盡的Product specification 產品規格說明書。收到的需求通常就是一句話，在拿到這樣一句話時我們就要有能力去定義「這句話是什麼意思？」、「背後相關的用戶體驗是什麼？」

而設計師又是整個開發流程中的最前線，往往我們需要同PO一起把User Story定義完整，另外像是訪談用戶、訪談利益關係人、確認產品指標、定義設計範圍、設定研究方法等等，都是在敏捷開發中設計師需要注意的。

舉例而言，在一間有PM的科技公司當設計師，我可能會收到「開發購物車」這樣的需求，並且包含所有購物車內所需要的功能以及對應的API或是技術需求，像是「移除商品」、「更改數量」、「庫存不足」等等。在一份完整的產品規格說明書中甚至會提供各種狀態的定義，設計師便就定義好的行為、狀態去做設計。

而在敏捷開發的環境，身為設計師的你會得到的就是「開發購物車」這句話，剩下的，都要靠你以及你的團隊一起去探索與定義了！

這對設計師來說其實是很有挑戰的，因為此時你要關注的不僅僅只是用戶體驗、或是視覺效果，而是這個產品如何帶來價值，與工程師確認操作流程及各種狀態，並且要能切分、安排代辦項目，讓產品可以以最小可行性（Minimum viable product, MVP）的形式進入市場。而這個MVP要如何定義，更是一大挑戰，我之後會寫一篇文章來介紹如何規劃你的MVP。

我在敏捷團隊中所學到的就是不要等待任何「指令」，甚至要主動去提問、發掘可能的風險或是未被考慮到的事項，並且成為開啟討論的那個人，當設計師成為啟動專案的人時，我們就可以確保用戶體驗永遠不會被犧牲。

結語

我個人不認為敏捷是一個所有企業都適用的開發方法，而且也不能單就企業規模來討論。如我前文所及，敏捷重視的是心態，也因此我認為組織應該先了解自己內部的文化是什麼樣子，平時大家處理問題、溝通方法是什麼樣子，並評估該產品與市場的關係，才來決定這個產品應該使用什麼樣的開發環境。

舉個極端的例子，如果多數員工偏好且仰賴完整的規格書，那麼大PM的瀑布式開發方法其實沒什麼不好，反而可以很有效率。而如果多數員工極富創造力並且開發速度真的很快，那麼敏捷或許更適合你。而如果市場非常競爭並且以消費性產品為主的話，敏捷很適合；但如果產品本身替代性低，週期長，那麼要不要使用敏捷就不是那麼重要了。

而設計師應該要培養自己適應不同開發環境的能力，畢竟我們是要能擔起維護用戶體驗的角色，無論是在規格明確的大瀑布中，還是充滿未知的敏捷開發，設計師都要能有效的定義並解決問題。

感謝你閱讀至此！喜歡我的文章的話請幫我拍手👏和分享📣！有任何合作邀約或是單純想交流出國做設計的心得，也歡迎到我的LinkedIn、臉書或IG找我。
Stella Hsiao | LinkedIn / 
@imsyc | Instagram / Stella Hsiao | FaceBook