敏捷開發縱橫談(3)

　　2.站立會議

　　每天早上項目組全體開5-10分鐘會議，所有人站立講話，簡單講述昨天工作概要、今天計劃、需要別人協調或解決的問題。站立的目的就是讓大家言簡意賅，提高會議效率。每天開這個會，是保證大家有足夠的及時的口頭溝通。極限編程認為，口頭溝通才是最有效直接的溝通。

　　在我們的項目中，我也會推行站立會議，但不一定是早上，當然也不一定非要站立，但是會議一定必須是高效的!口頭溝通很有效，但必要的記錄還是應該有的。一些公司推行站立會議，往往是沒有會議記錄的。而我的做法是會議中如果有決定、有代辦工作，我會要求記錄下來?？陬^溝通算然來得直接，但容易理解錯、容易忘記等缺點是避免不了的，應該輔以適當的書面記錄。

　　3.小版本發布

　　分小版本多次發布，最符合客戶的利益，客戶可以先使用部分功能，可以在此基礎上更好地思考后續應該做什么。

　　小版本到底應該有多小呢?國外很多書會建議3個月，不過3個月對于國內的項目來說，太長了!我們經常要在很短的時間內做出一個大系統!

　　我們公司每個版本的發布周期以前大概是一個月，現在已經縮小到2-3周了。

　　4.每周工作40小時

　　加班是我們IT人的家常便飯，極限編程反對加班!那么是不是我們只要工作時間到了，哪怕很多事情沒有做完，就直接下班呢?

　　這條實踐的真正意思是我們應該充分利用好工作的40小時，少做最好不做無用功，少返工。實際上我們很多加班是因為我們做了很多無用功、返工導致的。

　　人的腦袋每天能高速運轉8小時其實已經很了不起了，如果還要加班，那么只能帶來更多的bug，得不償失!不過我們很多公司的老板喜歡看到我們這些打工仔忙，看到我們加班，而不管實際的效果，這真是悲哀啊。

　　極限編程的各條實踐是有關系的，我覺得最基礎的最重要的是測試驅動與自動化測試，這兩條做不能做好，重構、代碼共用等實踐就難以實施。

　　極限編程很多東西很講究靈活，但測試驅動這條是最死的要求最嚴格的，整個靈活的體系其實就是靠這一條來保證質量的。很多公司實踐極限編程時，不能做到測試驅動，就簡單設計，就隨便改代碼，隨便因應需求變化而變動代碼，這些工作都沒有了質量保障的基礎。

　　極限編程我們需要整體來理解各條最佳實踐，并根據實際情況加以調整，為我所用!

　　下面將會稍微簡單一點介紹另外了兩個比較常見的敏捷開發。

　　敏捷開發

　　有一種敏捷開發，就叫敏捷開發。你可以認為這種是“狹義”敏捷開發，而本文標題所說的敏捷開發是泛指所有帶有敏捷特點的開發模式。

　　這種敏捷開發有這樣的特點：

　　1.個體和交互勝過過程和工具。

　　以人為本，注重編程中人的自我特長發揮。

　　2.可以工作的軟件勝過面面具到的文檔。

　　強調軟件開發的產品是軟件，而不是文檔。文檔是為軟件開發服務的，而不是開發的主體。

　　3.客戶合作勝過合同談判。

　　客戶與開發者的關系是協作，不是合約。

　　開發者不是客戶業務的“專家”，也不是為了開發軟件，把開發人員變成客戶業務的專家。

　　要適應客戶的需求，就要通過客戶合作來闡述實際的需求細節。

　　4.響應變化勝過遵循計劃。

　　設計周密是為了最終軟件的質量，但不表明設計比實現更重要。

　　要適應客戶需求的不斷變化，設計也要不斷跟進，所以設計不能是“閉門造車”、“自我良好”。

　　要不斷根據環境的變化，修改自己的設計，指導開發的方向。

　　你可能會感覺到這些特點與極限編程的相似與不同之處，同時你也會感覺到這些特點很多與傳統的重型開發針鋒相對的。

　　RUP

　　統一軟件過程，英文全寫為：Rational Unified Process。

　　下面這兩張圖最能反應RUP的特點：

　　以上兩圖來自互聯網

　　為了方便大家理解，我弄了中英文兩張圖，兩者是一個意思，不過內容組織稍微有點不同，大家注意一下就行了。

　　要精確理解RUP的意思還是有點難度的，簡單談談我對RUP的理解。

　　按照時間順序，項目分為初始(inception)、細化(Elaboration)、構造(Construction)、交付(Transition)四個階段，

　　每個階段會有很多個小迭代。這四個階段其實很難說有明顯界限的，我覺得大家大概了解每個階段的工作內容就可以了。

　　按照工作的性質，項目的工作可以分為以下幾類：

　　商業建模(Business Modeling)

　　需求(Requirements)

　　分析和設計(Analysis & Design)

　　實現(Implementation)

　　測試(Test)

　　部署(Deployment)

　　配置管理與變更管理(Configuration & Change Mgmt)

　　項目管理(Project Management)

　　環境(Environment)

　　以上這些工作，在項目的不同時期工作量分布是不太一樣的，如：商業建模、需求這些工作往往是頭大尾小，分析與設計、實現等是中間大兩頭小，項目管理、環境方面的工作一直都會持續進行。

　　RUP的思想打破了“需求-設計-編碼-測試”這樣的傳統瀑布模式，需求、設計、編碼、測試這些工作其實一直都在進行的，只是不同時間比重不一樣。這個思想是很符合“敏捷”的特點，也和實際情況非常吻合。

　　大家理解這個意思后，我覺得完全可以按照自己公司的實際情況重新定義時間上的階段，也可以自己重新定義項目的各類工作，以及思考各類工作在項目不同時間的工作量分布。

　　關于敏捷開發的流派還有很多，如：自適應軟件開發、水晶方法、實用編程等等，我覺不同流派其實本質還是很類似的，這里就不一一介紹了。

原文轉自：http://www.cnblogs.com/umlonline/archive/2010/03/17/1687760.html