靈活軟體開發筆記（一）------靈活實踐

靈活開發宣言

談及靈活開發不得不提到靈活開發宣言，主要是四點：

• 個體和互動 勝過 過程和工具
• 可以工作的軟體 勝過 面面俱到的文檔
• 客戶合作 勝過 合同談判

• 響應變化 勝過 遵循計劃

  在《靈活軟體開發：原則、模式與實踐》的第一章中所提到的那句詩：“教堂尖頂上的風标，即使由鋼鐵制成，如果不懂得順應風勢的藝術，一樣會被暴風立即摧毀。”這是由德國詩人海涅所寫的詩，用在軟體開發上也照樣适用。“暴風”就如現在項目所面臨的巨量的需求，而“風标”就如項目的響應能力，如果不能夠做出快速響應，就會被巨量的需求所壓垮。

靈活開發宣言中提到的四點就是針對這種現實需求所提出的更好的軟體開發方法，是順應現代發展的一種必然趨勢。

個體和互動勝過過程和工具

工具就是為了團隊的效率提升而存在的。而一味的追求工具放棄了團隊之間的互動，就是本末倒置的行為。工具應該是在發現它無法适用的時候才去更換它。一切工具都應該先從最簡單的小工具開始，從輕量化開始，而不是重量級工具。工具的增多也大大增加了團隊成員的學習成本。另外，我認為最好的溝通方式就是面對面的溝通，就好比現在的微信，确實是很好的實時通訊工具，但是人的表情，語氣，手勢等都是傳遞不了的，這些在溝通時都會造成誤解。

團隊成員之間的溝通也極其重要，所謂“三個臭皮匠抵得過一個諸葛亮”。一個優秀的團隊成員未必就是一個一流的程式員。良好的溝通，能夠引導團隊集思廣益，積極碰撞出靈感的火花。近來在工作中，也體會很深，一個程式員必定是考慮不全所有的異常情況的，如果能夠多個開發人員同時去思考異常情況，必定會考慮的更全面。

可以工作的軟體勝過面面俱到的文檔

這一點其實是很明顯的。過多的文檔會造成文檔維護起來非常麻煩，不能保證文檔的版本與軟體版本一緻。對于團隊來說，維護一份短小而且主題突出的文檔是至關重要的。就如平時開發過程中，代碼簡潔，注釋短小一樣，文檔也是要做到這一點。

人與人之間的互動是把系統的脈絡圖傳授給他人最快，最有效的方式。代碼是唯一沒有二義性的資訊源，代碼真實表達了它所做的事情。

客戶合作勝過合同談判

成功的項目需要有序，頻繁的客戶回報。在合同中所提出的需求一方面可能會不切實際，一方面可能在開發過程中會發生變化，不能順應市場變化，是以死闆地遵循合同中的計劃，不如靈活多變的在開發過程中進行回報。客戶最好是和開發團隊密切地在一起工作，很多開發中出現的問題能夠快速反映出來，另外開發團隊也能夠清楚驗收測試的細節。另外，客戶和開發團隊之間真誠的合作，也減少了無理的或者不切實際的需求提出。

響應變化勝過遵循計劃

在上一份工作中，我任職于一家銀行，使用的是傳統的開發模式，規定了計劃無論如何都要完成。每次産品經理說“我不管，這星期我就要結果，不管你怎麼實作”，如此死闆的要求必定會造成軟體品質的崩壞，帶來的是大量的修補還有潛在的隐患。

初定計劃時，不能定得太遠，沒人能想到後面會發生什麼，市場環境在不斷變化中，這也會引起需求的變動。

在施行計劃時，也不能死闆地去根據計劃的日期來決定，可能會出現人力的減少，造成項目的延期。

比較好的計劃就是：下兩周做詳細的計劃，下三個月做粗略的計劃，再之後做極為粗糙的計劃。根據距離目前時間點的由近到遠，計劃也逐漸模糊。這才是科學的計劃方式。

将精力放在目前迫切解決的需求上，而且由于僅僅隻是詳細制定幾周的計劃，不會耗費太多的精力，另外也給後續計劃留下靈活改變的空間。