Member-only story
推進式系統 vs 拉取式系統
一切無關好壞
最近一個月的時間忙著寫side project，一直無法抽出時間好好寫篇文章整理一下讀書心得，自從上次寫了一篇有關Kanban的文章後，我便開始整理一些應用案例，想比較一下在不同行為框架下面，對組織及個人成長造成的優缺點為何，其實眾多管理框架/方法本身都沒有對錯，起初都各自適當的情境與之搭配，並產生良好的效果，才因此被認同並廣泛轉移到不同領域。
像是一般常被Scrum拿出來比較的Waterfall作法，我就認為後者其實放在建築設計的領域中算是滿合宜的，甚至比Scrum好，因為建築和軟體開發在本質上有很大的不同(雖然兩者時常被拿來做類比)，前者在設計圖確認下來的那一刻起，團隊唯一的目標就是按圖施工，把預想的模樣構造出來即可。但軟體開發由於牽涉到市場需求變動，不容易像建築一樣一體成型，反而以小步快跑的開發方式逐次檢查與調整，較能打造出用戶預想中的產品及服務。
相反的如果你拿Scrum導入建築開發，或將Waterfall應用在軟體開發，時常會引來團隊的怨懟，工具本身是中性的，只是場景和它本身的特性不匹配，以至於效果差強人意。
退一步思考，先拋棄Scrum、Kanban、Waterfall、Scrumban、Lean等等的名詞和相關方法，不如先從商業系統本質逆向拆解它葫蘆裡賣的是什麼藥，並加以分類，後續再依據情境作典範轉移，比較不容易變成請鬼開藥單。
推進式/拉取式系統的分野
前面講那麼多的廢話，終於可以進入正題XD，繼先前比較過迭代式系統 vs 流動式系統，今天我想再從任務獲取的角度探討這兩個名詞，什麼是推進式系統(Push System)?以及什麼是拉取式系統(Pull System)?這兩者跟一般我們探討的敏捷方法又有什麼關聯? 先來張圖，聞一下!
- 推進式系統 (Push System)
看圖說故事，當專案或產品的產出是透過預測 (意即並非有了解市場或用戶的需要) 來決定時，我們便將這樣的過程視為推進式系統 (Push System)。就像上圖一樣，當研發工作一結束，則立即將成果遞延到下一個生產階段，再接著做行銷，這種階段任務完成就立刻往下階段傳送的過程，即推進(Push)，階段任務結束即可視為推進訊號，但最後是否符合市場的要求則是未知數。
傳統的Waterfall軟體開發方式就充滿這樣的味道，雖然OOAD (Object-Oriented Analysis and Design)…
