談談XP（2中）：Principle

Feb. 13 13:40~15:11

 

今天繼續介紹XP的第5~9個原則：

• Improvement（改善）：改善是一個通往「完美（perfect）」的過程，在軟體開發領域，「完美」是動詞，不是形容詞。世間不存在「完美的開發流程」、「完美的設計」、「完美的公司」、「完美的團隊」、以及「完美的客戶」，但我們可以努力「完善（改善）」我們的「開發流程」、「設計」、「公司」、「團隊」、以及「客戶」。改善並不是等待一切就緒才開始行動，而是儘快找到一個開始點，然後立即開始改善行動。這個觀念類似Scrum所說的「inspect and adopt（檢驗與調適）」，請參考〈捨我其誰之我不知道要做多久〉與〈專案需求一直變動要如何開始第一個Sprint之做就對了〉。
• Diversity（多樣性）：多樣性不只對生物界很重要，對軟體開發也很重要。開發團隊成員如果每個人都很類似，雖然相處下來可能會很容易，沒什麼重大衝突，但卻可能無法形成高效團隊。大家都知道「近親繁殖」會產生有缺陷的後代，團隊同樣需要不同技能、背景、經驗、看法的成員。雖然可能會因為多樣性產生衝突（conflict），但應該把這種衝突看成是改善機會而不是當作問題。XP的Whole Team實務做法反映了多樣性這個原則，Scrum的cross-functional team（跨職能團隊）也反映這個原則。XP和Scrum的各種規劃會議也反映了多樣性，此外Scrum的retrospective meeting（自省會議）可以用來解決多樣性團隊可能引發的衝突（迷之音：這是在介紹XP還是Scrum啊…）。
• Reflection（反思）：有人說：「什麼是笨？笨就是用相同的做法，卻期待有產生不同的結果。」古人云：「吾日三省吾身」，好的團隊也要經常反省做事的方法，以謀求改善之道。XP的pair programming（結隊編程）與continuous integration（持續整合）就是一種呼應反思原則的實務做法。Scrum的retrospective meeting當然更是一種反思活動。

光是反思而沒有行動也是白搭，因此XP的反思一定伴隨著行動。Pair programming同時具備反思（code review）以及修正（revise），持續整合也是具備檢查與修正（當發生broken build要及時修復）。Scrum的retrospective meeting也有人建議要針對討論改善項目列出行動方案。

節錄自網路。

• Flow（流、流動、流暢）：讓軟體開發所有的活動同時持續地穩定流動（迷之音：怎麼有種精實開發的fu）。為了要達到「貨（工作項目）暢其流」的目的，不能像傳統開發方法把工作項目切割得太大塊（big chunk），例如12~24個月才釋出軟體，或是花三個月做需求分析，再花三個月做架構設計。XP的Weekly Cycle、Continuous Integration、Daily Deployment等實務做法都反映了Flow這個原則。
• Opportunity（機會）：古人云：「聞過則喜」，如果能夠抱持著把問題視為改善機會的心態，則團隊將會變得很不同。如何把問題變成機會？例如，沒辦法為產品做出長期規劃！沒關係，把產品開發拆成幾個釋出版本，先規劃第一個釋出版本。開發人員寫出的程式bug太多！沒關係，試著用結隊編程。有時候你沒辦法選擇自己、團隊、公司、或客戶，現況就是現況。現況並不完美，好的流程或是開發方法可以把問題暴露出來。將問題視為機會，才有可能跳脫18層地獄。不想面對問題，只想逃避，永遠還是在這18層地獄裡面輪迴，無法轉世投胎。

***

友藏內心獨白：止於至善。