傳統開發流程

這是所有想要進入軟體產業的人最常問的問題之一，公司的開發流程是怎樣的呢？

不管我們搜尋還是聽公司的前輩介紹，我們大概都會聽到這樣的流程：

1. PM 規劃需求
2. 設計師設計設計稿
3. 前端工程師實作設計稿
4. QA 測試
5. 上線

詳盡一些的可能會再細分成各個節點，例如下圖

但如果你有一些工作經驗都知道，實際情況，這個流程並不是這樣的，而是這樣的，如下圖:

不管是 PM、設計師、工程師、測試、都會陷入一個溝通循環中，這個循環會發生很多溝通問題，例如：

1. PM 規劃需求，設計師沒有考慮到前端的實作問題，導致前端無法實作，或是前端實作的方式和設計師的想法不同。
2. 設計師因為需求的變更，導致設計稿的變更，但是前端已經實作了，導致前端需要重寫。
3. 每一次迭代都和上一次的迭代有差異，導致前端需要重寫。
4. 前端實作的方式和設計師的想法不同，導致設計師需要重寫設計稿。
5. 驗收標準不明確，導致每個節點無法溝通，產出和預期不同。
6. 這樣的流程並無法優化
7. 浪費大量的時間再溝通上

站在組織的立場，最後一句話的威力是相當驚人的，當然出現問題了，自然就會有人跳出來解決，於是我們導入了其他開發方法，例如敏捷。

敏捷開發

敏捷開發是一種軟體開發的方法論，它強調的是「快速回饋」，而不是「快速交付」，這是敏捷開發和傳統開發的最大差異。

白話一點說，就是當我們在開發一個產品的時候，我們很需要馬上就知道市場對這項產品或功能的反應，依照這個反應，我們可以馬上做出調整，而不是等到產品開發完成後，才發現市場不需要這個產品或功能。

所以在開發流程上，做出了一些細微的改變，為了延續前面的例子，我們可以將流程改成這樣，如下圖
（下圖可能不是標準的敏捷開發的示意圖，因為可能不會有設計師或測試這些角色）：

如果團隊中的成員都是資深的工程師，這樣的流程是可以運作的，但是如果團隊中有新人，或是沒有經驗的人，這樣的流程就會有問題，例如：

1. 新人不知道如何實作，導致無法實作。
2. 無法判斷所需資源和預估風險。
3. 技術能力無法進行快迭代
4. 在資訊量不完整的情況下，無法做出正確的決策。

到最後，又是陷入不斷回頭修改和討論的流程。

不是方法的問題

在某種程度上，敏捷開發指出了關鍵性的問題和修改，也就是將大家的專注力放在解決問題上，而且資訊都是透明的，加速了溝通的速度。

在這種情況下，工程師能依照資訊和判斷做出「適當」的開發範圍，並依照這個範圍做出「適當」的開發時間，這樣的流程是可以運作的。

但問題就在於，這一切都必須依賴在一個 可靠且懂得規劃和設計的工程師，如果沒有這樣的工程師，這樣的流程就會失敗，反而會不斷累積技術債，累積的速度跟 Sprint 一樣快。

因為在追求結果和效率的同時，我們忽略了一個重要的問題，那就是「如何讓團隊中的每個人都能做出適當的決策」。

要做到這一點，以目前來看，就只能靠大家的「自動自發」了？

如果一個管理方法，對於人的依賴性很強，那麼其組織的運作就存在很大的管理風險，所以這也是另外一個原因我們需要規劃出另外一個方法來治理團隊。