l

2014年2月18日 星期二

談談XP(2中):Principle

Feb. 13 13:40~15:11

image

 

今天繼續介紹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層地獄裡面輪迴,無法轉世投胎挑眉質疑

***

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

沒有留言:

張貼留言