Scrum: 持續整合與軟體架構能力

續叡揚 e 論壇 90 期「如何利用敏捷開發 管理軟體開發的不確定性」，在此期文章中我亦提到我們的雲端服務平均每 1.5 月就有新功能更新，便是透過敏捷開發。

 

另外值得一提的是 Scrum 中沒有特別提到但卻一樣重要的「持續整合」與「軟體架構」能力。為什麼 Waterfall 會那麼流行?一方面是他相當的簡單而直覺，也符合過去的工業革命後的管理模式。另一方面是在傳統的軟體開發上，我們發現如果一直修修改改的，會讓整個系統變得很不穩定，甚至崩潰。過去軟體人常說的你不會要求建築師在一棟已經蓋好的 20 層大樓中再加上一個地下室，但卻時常要求軟體在已經完成後再增加許多的新功能，而該新功能的困難性幾乎要翻掉整個系統，然後讓整個系統岌岌可危。

 

原本我也是這種觀點的支持者，認為軟體其實一點都不軟，所以我們會希望在需求分析的時候就能夠充分掌控所有的需求，然後按照 Waterfall 的邏輯，把所有的需求通盤考量，設計出最好的分析、設計、開發。因為如果沒有花時間找出最佳解，未來的所有變動都將產生非常高的重工，而重工正是造成軟體專案虧損的最大原因之一。

 

所以如果我們沒有找到一個可以讓軟體本身在不斷的改變中，還能保持彈性，不會崩潰，不需要付出超高代價的方法前，Scrum 的短週期的作法其實是不可行的。還好，隨著眾多新的軟體架構發展與自動化測試、持續整合、DevOps、持續交付等等軟體的實務發展，讓軟體真的可以是「軟」的。讓軟體的修改代價不會隨著軟體的大小與軟體發展的時間呈現指數化的成長而崩潰。從我的角度來看，這部份能力的養成其實比執行 Scrum 難多了，也是要運作 Scrum 所不可或缺的基本能力。

 

再回過頭頭來看 Scrum 的設計，還可以發現一個只有當你執行較長的時間後才會發現的重點。那就是「組織文化」的衝擊。有一句話說，如果你執行了 Scrum，但是沒有感受到「組織文化」的衝突，那就表示你執行錯了。在 Schneider Culture Model 中將「組織文化」區分為「協作/控制/競爭/培育」四種。一般來說敏捷開發的執行會讓組織文化朝向「協作/培育」的象限移動。但也容易讓一般人造成一種誤解就是，因為我執行敏捷開發，所以團隊是最大的，任何的介入或控制都是一種錯的行為。

 

喜歡舞蹈的人可能會有一種體會，當你觀賞舞蹈家在台上表演時，可能會有一種無拘無束、行雲流水的暢快與自由感。這樣的自由其實是來自於該舞蹈家在不斷的練習中，對身體的絕對控制後所呈現出來的。我覺得 Scrum 也是如此，它追求團隊的協同與合作，而前提是來自於在制度上的高度控制。

 

例如在會議上的要求，每個週期召開 8 個小時的短衝會議、3 個小時的自省會議、跟每天 15 分鐘的每日站立會議。另外在不同角色的責任切割方面也明確的定義了不同角色的決策權與責任。認為因為使用了 Scrum 就變成什麼事情都會變成集體決策或無法要求，這是對 Scrum 的一種誤解。Scrum 關心的不是只有開發人員，而是顧客與利害關係人。

 

我個人的體會是，因為採用了 Scrum 的模式，讓軟體的開發人員，能夠打破過去將人員區分成不同角色時彼此的衝突，也打破了團隊跟主管的管理方式，更甚而讓原本跟客戶之間的零和有了一種雙贏的可能。也讓平凡如我的軟體開發人員也能有機會發揮自己的專長，做出一些不平凡的產品，幫助更多的老闆能夠服務好他們的客戶，更進而對這個世界創造更多的值。