對于敏捷前面談的很多，其核心仍然是短周期迭代交付，可視化，自適應調整，開放式及時溝通，所有的敏捷實踐基本都是圍繞這些核心展開，如果再要對敏捷的核心抽象就是迭代+自適應。

　　周末和我一個師兄聊天，覺得在原公司實施敏捷后確實帶來了很多的變化。原來可能大家都說很忙，確實是否真的很忙不清楚，原來一個任務來了來安排不下去，原來客戶要的東西遲遲交付不了，或者是交付后就陷入到持續的變更。實施敏捷后這些問題都得到了一定的程度的改善，這么好的東西怎么原來沒有引入進來，在cmmi上浪費了這么多的時間。

　　其實我個人理解原來的過程改進和cmmi一點都沒有浪費時間，就像原來我們經常說瀑布都做不好如何去做好RUP軟件過程？基本的cmmi過程都做不好如何去做好敏捷？做任何事情我們都必須經歷的階段是簡單-》復雜->簡單的過程，只有經歷過了復雜你才知道如何來簡化，如何來吸取精華去除糟粕。CMMI里面確實很多過程都比較重，但是很多的核心過程思想必須要有，只是用更加敏捷的方法來實現這些思想。

　　公司實施敏捷，開始使用user story card，這是很好的，但是我們要注意到product backlog和sprintbacklog絕對不僅僅是user story。很多人任務敏捷拋棄了文檔，而實際上敏捷只是濃縮了文檔，backlog中有userstory，有詳細的業務場景描述，有優先級，有規模和工作量估計，有類型，有如何演示，如何實現，如何測試等各種內容。這些內容可以看到一直從需求覆蓋到設計和實現和測試。這可以說是敏捷里面最重要的一份文檔，而且這份文檔是完全可以結構化的文檔，結構化的條目就是userstory，用戶故事是最開始的最小粒度單元，關于用戶故事的需求，設計和測試所有內容都在這里，體現方式最簡單就是excel，這個東西太好了，你這樣做你發現原來cmmi需求管理中要做的需求追蹤沒必要了，這個excel文檔本身就實現了需求追蹤。單獨的測試用例文檔好像也沒有必要了，需求文檔也不要了，而且需求比原來的描述方式更好，體現了業務場景站在用戶視角，沒必要還要像原來搞個用戶需求文檔+軟件需求文檔，項目管理的復雜文檔也可以不要了，就在這里估算安排人員，確定時間。所以可以看到濃縮的都是精華。

　　再回過頭看來，架構到哪里去了？backlog里面能否體現架構的核心內容？我個人的答案是不能的，仍然沿用《人月神話》里面觀點的話，架構需要保證高度的概念完整性，否則談不上架構。backlog里面的如何實現好像體現了部分架構的內容，讓我們感覺架構也是可以迭代的，漸進式的，這個觀點沒有錯，但是這個只能算做是低層級的概要設計，高層的架構還是沒有。所以我原來一直強調了一個思路，對于變更型和增量版本型的項目特別適合用scrum，而對于全新的項目根據適合RUP的思路，體現用例驅動和架構為核心，在迭代版本規劃出來后再考慮敏捷的思路。

　　在崗位細分后，軟件開發里面分出了獨立的需求分析師和架構設計師崗位，大家可以回想下原來沒有細分前，這兩個崗位其實和合并為一個的，即原來的系統分析員。這其實是實施敏捷后我們需要做的一個回歸，重新會產生類似系統分析員角色，系統分析員負責需求和高層架構。低層的一些架構下沉到sprintbacklog的每一個迭代里面來做。高層架構做的內容包括全局用例分析，全局數據視圖，集成視圖和接口交付，其控制的邊界在于這些內容是否跨越了多個迭代版本，這好比一個數據實體設計，如果是在某一個迭代版本內部體內循環則不一定要在高層架構設計，但是如何是涉及到多個迭代版本使用則需要在高層架構識別和設計。對于全新的產品研發，高層架構不穩定，直接導致不斷迭代加入進來的內容結構混亂，這個問題必須要重視和考慮。

　　很多時候我們都在想，我現在新研發一個產品，原來公司類似的一個產品已經用過這個架構了，或者說公司已經有相應的技術平臺，所以架構工作沒有必要了。注意我們通常說的產品平臺或技術平臺，SSH框架等都是框架，是架構中非功能性架構的內容。而實際根據產品需求或用戶需求過來，考慮的子系統，模塊組件規劃等是功能性架構的內容，不要以為有了平臺或框架就沒有架構的內容了。

　　通過前面分析，敏捷下架構能否迭代的問題就比較清楚了。對于不屬于高層架構的內容是可以迭代的，到了每一個迭代版本中再來做架構，對于高層架構的內容一般不能迭代以保證設計的概念完整性。對于高層架構本身，整個設計和方案思路是不能迭代的，但是實現過程本身是可以迭代的，如同一個接口，設計必須體現做，這個做了接口本身的實現可以和其它功能模塊的開發并行。