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

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

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

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

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

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

　　很多時(shí)候我們都在想，我現(xiàn)在新研發(fā)一個(gè)產(chǎn)品，原來公司類似的一個(gè)產(chǎn)品已經(jīng)用過這個(gè)架構(gòu)了，或者說公司已經(jīng)有相應(yīng)的技術(shù)平臺(tái)，所以架構(gòu)工作沒有必要了。注意我們通常說的產(chǎn)品平臺(tái)或技術(shù)平臺(tái)，SSH框架等都是框架，是架構(gòu)中非功能性架構(gòu)的內(nèi)容。而實(shí)際根據(jù)產(chǎn)品需求或用戶需求過來，考慮的子系統(tǒng)，模塊組件規(guī)劃等是功能性架構(gòu)的內(nèi)容，不要以為有了平臺(tái)或框架就沒有架構(gòu)的內(nèi)容了。

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

it知識(shí)庫：再談敏捷和架構(gòu)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。