談談XP（2上）：Principle

Feb. 13 10:45~12:15

 

XP列出了14個Principle（原則），數量將近是Value的3倍（XP有五個Value）。藉由這些原則，可以引導出實務做法（Practice）。今天先介紹前4個原則：

• Humanity（人性）：軟體是「人」寫出來的（迷之音：真的嗎？），所有開發方法都不應背離人性考量，否則終將難以持久。要求員工犧牲個人與家庭生活來滿足工作進度，長期來看這是違反人性的作法。把人當成「CPU」來使用，可以在不同專案之間隨意調配，而且希望每顆CPU都可以多工，最好可以「超頻工作」，這也是違反人性。

Kent Beck在書中提到，好的開發人員有以下五項人性面的需求：

• Basic safety（基本安全性）：免於挨餓、受傷。害怕失去工作、低薪、爆肝都違反了這一點需求。
• Accomplishment（成就感）：有機會對團隊、公司、社會貢獻一己之長。做到一半夭折的產品、打死不釋出的軟體、釋出之後沒人用的軟體，都傷害了這一點需求。
• Belonging（歸屬感）：對於身屬於某個團體感到驕傲而且對於團體的目標能有所貢獻。如果公司或團隊一直在破壞環境、製造出產生82億次駭客攻擊事件的APP、申請身分證6個小時才能辦好，搞到「日月無光、人神共怒」，走在路上不敢跟別人說你是哪家公司的員工，就傷害了這一點需求。
• Growth（成長）：可以增長自己的技能與視野。在同一家公司工作10年，回頭一看卻只有一年的工作經驗，然後重複9次；名為開發軟體但做事卻都不動腦筋；一直用相同的方法做事卻期待能出現不同的結果；不願意花錢培訓員工。以上做法，都傷害了開發人員對於自我成長的需求。
• Intimacy（親密性）：和團隊成員可以打成一片，彼此了解彼此的想法。人力派遣、把人當成「resource pool」裏頭可以隨意支配的資源、分工不合作，每個人只專注於自己手邊的工作，傷害了這一點需求。
• Economics（經濟因素）：軟體既然是由人所開發，只要是人就要領錢，有人得為軟體開發的一切活動買單。因此，軟體開發不能忽略經濟因素。如何在有限的資源內做出最好、最合適顧客的產品，也是開發人員需要思考的議題。確定軟體開發活動滿足商業價值、目標、需要，而不是「爽到開發人員，痛苦到客戶」。

從經濟因素引導出敏捷開發所謂的value-driven（價值驅動）做法（請參考〈計畫驅動 vs. 價值驅動〉），以及敏捷合約的pay-per-use，用多少買多少精神。另外像是incremental design（增量設計）或是精實開發所提到的「消除浪費」（請參考〈只有一位開發人員的專案也需要了解如何消除七種浪費〉）也都算是符合經濟原則的實務做法。

• Mutual Benefit（互利）：雖說「吃虧就是占便宜」，但是在正常情況下人都不想吃虧。任何合作關係，如果不是合作的雙方或多方都可以互助互利，則合作關係很難持久。舉個例子，傳統要求開發人員寫一大堆分析、設計文件的作法，得利者主要是公司老闆（因為一直壓榨員工，怕員工跑掉程式沒人看得懂），或客戶（因為付很少錢且時程很趕，怕外包商隨便設計日後無法接手）。開發人員並沒有獲益，反而需要額外花很多功夫來撰寫這些「無用的文件」。XP的做法則是：透過自動化測試幫助今日的開發人員做出正確的設計、幫助日後的開發人員容易維護系統、也幫助客戶可以獲得bug比較少的系統。一舉三得。
• Self-Similarity（自我相似）：大自然的許多設計都具備自我相似性，一旦發現好的設計，便想盡辦法重複使用。相同的原則可適用於軟體開發，例如，XP的開發步驟建議先寫一個失敗的單元測試再寫程式碼想辦法讓單元測試通過。將此規模放大到每一個開發週期，可以為story寫失敗的驗收測試，然後再撰寫程式想辦法讓story通過驗收測試。持續整合也具有自我相似性，在開發人員的規模，整合自己本機端的程式。將程式碼送交到版控系統之後，整合版控系統上（團隊層次）當下片刻的程式。下班之後的每日建構（daily build）整合一日之內團隊所開發程式。每個開發週期所建構的「潛在可釋出產品增量」整合這個開發週期團隊所開發程式。產品釋出之前所做的建構，整合這個釋出版本所包含的程式。

***

以前沒留意，重新整理一次XP的Value、Principle，發現有很多和Scrum、Lean（精實開發）的觀念其實是重疊的啊，只不過不同的人用不同的語言來解釋相同的「特質」罷了。難怪Alexander要說：「Quality Without A Name」啊。

***

友藏內心獨白：雖說Quality Without A Name，結果還是要記一大堆Name。