今天在看架構相關的文章時突然看到一段，和敏捷有關。所以也就想起了自己現在參與的項目中的敏捷概念。
我們一直在強調敏捷，但怎麼個敏捷法呢？項目週期不斷的縮短，中間兩次迭代，CR不定期的出現，即使在版本即將發佈的最後幾天，此前可是經過四輪的SDV啊。
另外還特別遵循了敏捷方法中的站立會議，但我不知道是否起到了敏捷的作用，原本是想將過去一天的工作與問題進行總結，並對新一天的工作做合適的安排，但到最後，這個會議卻顯得很無用，每天每人一句話，甚至一半人的那句話別人都聽不清楚，不知道這樣一個團隊是在做着什麼樣的配合與協作。而領導者呢，對於整個項目的週期與計劃並不很強調，導致大家心裏根本沒有一個對整個項目週期的清晰輪廓。
此前開發此項目時（此項目從南京轉移到深圳開發，此前項目指的是在南京開發時的那一時期）對於敏捷中的一些方法比如結對編程使用的很好，代碼質量得到一定保證，同時無論需求，測試用例，編碼這些重要的過程組內除了結對人要要進行檢視外，組內所有手中有時間的成員都要進行檢視，並填寫檢視表單，然後組織大家開評審會議，爭取把項目問題最早的暴露並把風險降到最低。但現在這些做到的很少。當然這一段時間屬於項目交接期，所以會出現很多問題，但我在想是不是正是因爲這樣，管理者才應該將那些好的實踐方法引用到項目中來，讓整個項目更加高效的交接。
而更重要的一部分——持續集成也沒有得很好的運用。華爲對於持續集成工具已經做的很好，光版本從我看到的就換了三次。但對於現在這個項目卻沒有真正的運用起來，反而還不如以前。而現在項目的交付去責任更重，因爲多了一個現網局點。
也進行了大半年的敏捷實踐，現列出我認爲的好的實踐 ：
1、站立會議。 此會議不是例行，我個人認會不是每天都需要，如果沒有確實的需要而舉行，感覺真的很空洞。此會議多數應該由領導者以特定議題發起，且時間不需要固定。如果組內成員有想法需要與大家共同討論同樣也可以發起。
2、測試驅動開發。 此方法也是一個重要和很好的實踐。在未進行代碼開發之前將可能和必須出現的場景進行預料，寫出測試用例，以方便代碼完成後對基本的邏輯和特性進行有效驗證。但我發現有很多人不願意去執行此步，即使是在使用自動化測試工具的時代。
3、結對編程。 有一次和同事聊開發，他問我們是不是在搞敏捷，我說是，他說：敏捷就是耗盡一個人所有精力的開發方式。這句有點太過，人的精力是有限的，如果所有精力都用在今天了，那明天誰爲我們來開發。但他這種說法和我以前自認爲的敏捷實踐中的結對編程有點像。既然是結對，那應該是這樣的，兩人對於從需求開始就要對要做的事以及對此前做的事都達成共識，然後一臺電腦，兩把椅子，一人執筆，一人緊跟。如果一人對於思路的實現遇到了問題則另一個人可以很快的接手過來，將此前已商討過的實現方式進行下去，或修改前者錯誤，或直接走下去。兩人都在一種編碼的興奮狀態。這樣纔會高效的，真正的達到一種結對。當然這個實現過程並不需要兩個人都進行編碼，也可以只一人執筆，但對於遇到的問題（或者是在此興奮過程中又想到什麼此前沒有考慮到的問題）兩個人應該可以馬上進行討論然後修改和確定新的實現方案。
4、文檔檢視和評審。 這裏的文檔包括規格，需求，測試（方案）用例，以及代碼，另外相關的VDD等。此檢視所有成員都應該參與到其中，而領導者更應該是此中的重中之重，他對規格和現場（局方）需要的方案和特性應該最熟悉，所以他需要對規格，需求提出最有效的檢視意見，對於代碼則應該所有成員都去保證邏輯正確，結對人保證所有細小的地方都沒有忽略檢視。而檢視完成後的重要一步對是組織評審，此評審必不可少，要讓問題提出人與問題解決人都要明確提出的問題是否正確和必須，所以必須當堂對質。當然這些所有的問題不一定要等到評審上才解決，此前任何時刻都可以將發現的問題與問題負責人進行溝通，確定問題的存在性。這一過程包括對代碼的一些特殊的問題檢視，通常都會按統一要求進行checkstyle檢查，還要進行findbugs的檢查。
5、每日構建。 對於現在的敏捷開發來說，寫個ant腳本加入到ICP中進行每日構建是必須的事，否則對於整個系統的完整和正確，還有項目的風險都無法預估。而項目的一些checkstyle與findbugs的問題將會遺留到第二天。這可不是一個好消息，因爲它的存在意味着你們此前做的檢視都被忽略了。而日後這些問題必將積重難返，你必將爲當初的軟弱而後悔。
6、總結會議。 這個會議必不可少，通常在一個版本快結束時進行。你會說我每天都在忙着開會，把我的文檔編寫的代碼編寫的時間都擠沒了。你錯了，在IT行業的會議中應該所有會議都簡可能的簡短和有效，如果你們的會議不是這樣，那應該向組織者提出建議了。此前的會議都是必要的，現的會議是爲了將來更好的將項目開發組織好，讓項目中的每個人都參與到項目的管理中來。所以這個會議，與會者都要拿出一個自己對此版本開發中有需要改進的或是好的實踐的例子來，當然，多多益善。這樣整個團隊纔會有凝聚力，更重要的是這樣才能不斷的發現問題，現將這些問題規避在進入下一個版本之前。
目前，對於敏捷項目的心得就是這些，而如果你們開發的項目有一個好的系統架構，那會更加有利。因爲敏捷本身就要求對所開發的代碼要將各自設計模式運用起來，真正體會到代碼之美麗。