談談XP（2下）：Principle

Feb. 13 15:47~17:40

 

今天介紹剩下的5個XP原則：

• Redundancy（冗餘）：這個字經常在「容錯設計」中看到，容錯系統透過冗餘來容忍系統中的缺陷（fault），使得缺陷被引發之後系統仍然可以繼續正常運作。軟體開發是一種很複雜的活動，很多環節都可能會出錯，因此不能依靠「銀子彈（特效藥）」來解決所有的問題，只能透過多種不同的方法讓系統處於一個可以接受的健康狀態。例如，XP對付bug的實務做法，就有pair programming、continuous integration、sitting together、real customer involvement、daily deployment這麼多種，這就反映了冗餘原則。
• Failure（失敗）：失敗不是不好的結果嗎，為什麼XP會把失敗列為15個原則之一？仔細回想每個人成長的的過程，其實都有過從失敗中學習的經驗。學走路和騎腳踏車，幾乎每個人都有跌倒的經驗，應該沒有父母要求小孩子學走路或學騎自行車「不准」跌倒吧？學說話也是，小朋友不害怕失敗，所以只要有適當的環境可以很快學會一種語言。大人就不一樣，好面子，怕丟臉、出糗，不敢開口，就不容易學會新的語言。

失敗是一個選項，也是一種學習的過程，更是面對變化與未知最好的武器，也是獲得回饋的一種手段。個人與團隊想要變得更敏捷，就要不害怕失敗、失敗趁早、從失敗中學習。

• Quality（品質）：關於品質有一個很重要的慣念以及常見的迷思：「犧牲品質可以增加開發速度」，這是錯誤的觀念。專案不會因為接受低品質的軟體而進行得比較快，也不會因為要求高品質而進行得比較慢。要求高品質的軟體通常會導致較快的產品交付，反之則導致延後且不可預期的交付時程（這個觀念Bob大叔在《Clean Code》也有提到）。

如果光談到速度與成本，品質好像只是個與「經濟」相關的因素，但品質與人性也有關。如果一直開發出被客戶罵到臭頭的軟體，開發人員的士氣一定非常低落。虧欠太多「技術債」的產品，也沒人想接手開發，甚至想要逃離負責的開發團隊。

既然品質不可妥協，而開發時程與成本（主要是人力）在XP裡面基本上是固定的因素，所以XP選擇了調整範圍（scope）。基本上Scrum也是採取相同策略，把時程、成本固定，而讓交付範圍（產品功能的多寡）保持彈性。

追求高品質是一個過程，如果你知道如何達到高品質，但現況的限制讓你無法立即施實所有改善品質的策略，可以在考量現況的情況下儘量提供高品質的產品，日後再安排時間來提升品質。例如，明天就要交貨但臨時發現bug。你知道一個完美的解法，但需要花三天的時間，緩不濟急。怎麼辦？先想一個quick-and-dirty的解法讓明天系統可以上線，之後再來償還「技術債」。

• Baby Steps（小步驟）：改變都是痛苦的，一次變動太多可能會越改越糟糕，引發改變的理想過於遠大但時間和資源卻過於不足。按部就班的小步驟改變比較容易控制，就算失敗要重來付出的代價與風險也相對較低。這個原則和Alexander所說的「piecemeal growth（逐步成長）」是相同的道理。

「小步驟」原則在XP中處處可見，TDD的步驟就是典型的例子，寫一個會失敗的測試案例，然後用最簡單的方式實作程式碼讓測試案例通過，功能完成之後再套用重構（另外一種小步驟改善技巧）來改進設計品質。

「小步驟」也呼應「改善」、「Flow」與「失敗」這些原則，和「精實開發」的「小批量多樣化生產」也有異曲同工之妙。

• Accepted Responsibility（承擔責任）：責任不是被指派或是硬塞到開發人員身上，而是必須要每個人自己去接受與承擔（突然想到〈QBQ之正面思考〉這一篇文章）。在XP裡面，做事的人負責估算時間，開發story的人也同時負責設計、實作、測試它。

Scrum也有類似的作法反映這個原則，像是PO、ScrumMaster、Team的責任分擔，還有組織「自我管理團隊」。

***

友藏內心獨白：XP的14個原則比青年守則還要多2條。