《敏捷式軟體開發 (Agile Software Development)－原則、模式與實踐》

    想了一下，決定將讀書的曆程通過日期的形式記錄下來，評論部分就放讀書的討論和感想。
2005-06-01:
    這幾天公司項目不緊張，終於可以有時間看看這些好書，我的心情是格外高興的。又一次拿起《敏捷式軟體開發 (Agile Software Development)－原則、模式與實踐》，我的心情是比較激動的，在一年前買了這本書，草草的看了一遍，但不能將裡面的精髓用到實際的工作之中，所以很多部分只是瞭解一，二。一點也不系統，現在工作了，而且公司也給了我空間和時間，於是想好好研讀一下，將學和做結合起來。
    前言部分引用了《人件》中的一句話：“人與人之間的互動是複雜的，並且其效果從來都難以預期，但卻是工作中最為重要的方面”。他強調了人在軟體開發中的重要性。確實，軟體行業和其他行業是有所不同的，是知識密集型的勞動，對員工的技能，素質等要求都是很高的。我們不能將軟體開發人員當作機器，認為軟體開發人員就是流水線上的工人，項目按流程來，各個部分幹好自己的事情就可以了。
    第一章又有一句德國詩人海因裡希·海涅的明言：“教堂尖頂上的風標，即使由鋼鐵製成，如果不懂的順應風勢的藝術，一樣會被暴風立即摧毀”。
    這句話很好的詮釋了軟體如果沒有面對變化的能力，那麼在剛進入市場、甚至還沒有進入市場時就已經失敗了。事實就是這樣的，我們現在經常在網路上，電視上看到IBM的廣告語：隨需應變。如何才能提高軟體的應變能力，如何才能發現軟體的變化方向，這些知識在《敏捷式軟體開發 (Agile Software Development)－原則、模式與實踐》一書中都得到瞭解答。
    敏捷是如何提出的呢？在以前，專家們為了更好的解決軟體開發的困難，制定了軟體開發方法，這些方法是結合原來軟體的失敗得出的解決方案，並把他們抽象成條條框框。並且確實使軟體開發品質提高了，但是專家們麼有想到軟體的變化越來越快，開發人員用原來的方法已經不能解決問題，於是，專家又在原來的方法的基礎上再加上一些條條框框。久而久之，方法越來越龐大，不僅不能很好的解決軟體開發問題，而且還束縛了軟體的開發，使軟體開發延加長。這種情況的嚴重性引起了專家們的注意，因此,他們制定了“敏捷宣言”，內容如下：
個體和互動    勝過    過程和工具
可以工作的軟體     勝過    面面俱到的文檔
客戶合作    勝過     合約談判
響應變化    勝過    遵循計劃

2005-06-02
    今天看了《敏捷式軟體開發 (Agile Software Development)－原則、模式與實踐》的第二章，覺得每次看覺的講的相當不錯，但總覺得裡面的東西過於理想化，幾乎沒有哪個軟體公司是可以完全做到的。但我想大師說的肯定有大師的道理，如果我們有些條件做不到，應該有一些合適的替代方法，但是這些替代方法有的我是想不到的，希望有經驗的程式員給於指點。下面我就把第二章的每一點內容談談自己的想法。
    1：“客戶作為團隊成員”。
    我覺得這一點在中國是很難做到的，大部分客戶都沒有軟體的知識，他們認為只要和開發人員開個會，將需求講清楚，再給一定的時間，軟體自然而然的就完成的。實際情況不是這樣，需要客戶緊密的和開發人員在一起，隨時指出開發人員對項目理解的錯誤，同時通過軟體的慢慢成型，可以更清楚的知道自己想要什麼樣的軟體。但是客戶有自己的工作，而且工作強度也不會小。更有甚者是客戶可能同時需要幾個軟體系統，正在和不同的軟體團隊打交道。我們該如何讓客戶充分的加入到我們的開發隊伍之中呢?我現在沒有想到更好的辦法，但是可以通過加強團隊自己對客戶所在行業的理解程度，來彌補客戶無法加入團隊的不足。現在很多之名的方案提供者之所以可以為各行業提供解決方案，是因為他們擁有一批對各行業業務都十分瞭解的精英。我們公司是做銀行業務的，在準備招標一個項目之前，會請銀行的顧問給我們充分的講解該業務相關的專業知識，我覺得這一點確實做的不錯，在這裡說出來。業希望大家能夠說說自己公司在這方面是如何做的。
    2：“使用者素材”。
    這一點講的是在做需求是只需要做到能夠估算他的程度就夠了。我理解這句話的意思，是說軟體的需求細節在開發過程之中是會隨時改變的，如果在做需求是過分的追求設計，那麼就有可能做無用功，還有可能延誤項目的開發時間。但認為要想做到這一點是很不容易的。這需要豐富的項目經驗，可以知道什麼情況是分析的不足，什麼是過分的分析。但在這一點上我是沒有經驗的，希望大家指點。
    3：“結對程式設計”。
    這一點說了兩個程式員一起編程，一個編碼，一個在方便發表意見並檢查錯誤，隔一段時間互換一下角色，這樣在效率上遠遠大於兩個人單獨使用一台PC編程的效率。並且業會大大降低項目途中開發人員離開的風險。雖然這一點不難理解，但是想讓公司充分接受也是不可能的，公司可能會說：“這個想法確實很好，但現階段公司人手不多，結對相當於又減少了一半的開發人員”。我也沒有什麼經驗，只是在學校的軟體開發組中這樣的做過，覺得效果相當好。很希望得到老闆的支援。
    4：“重構”。
    這一點是我這次看書印象最深的一點，說的是我們的代碼是在軟體開發過程之中不斷更改的，有經驗的程式員應該知道，在項目初期，我們的設計都是簡單，明了的。但隨著項目的進行，代碼在不斷的更改，拷貝。慢慢的代碼就混亂了。那麼這一點告訴我們要週期性整理代碼，使代碼總保持著清晰的結構和風格。在我們每次實現一個功能後，我們應該立即最佳化這部分代碼，在每周進行一次代碼的結構調整，這樣，最後的代碼才是健壯的，易於維護和調試的。
    5：“測試驅動的開發”。
    講的是先寫測試案例，在寫代碼是測試案例通過。但我在其他說上看得並不一定要先寫測試案例，也可以後寫測試案例。測試驅動開發主要的好處就是可以開發出方便測試的代碼，是測試工作簡單、高效。不過想寫出好的測試案例也是學校很深的功底的，這一點不是理解就可以的。
    今天就說這麼多，提了很多問題，希望得到大家的解答   

待續... ...