今天做敏捷開發(fā)和輕量級流程，產(chǎn)生的疑問：
敏捷開發(fā)中，PO將需求整理成Product Backlog，，在這之前，是否需要需求分析呢？在我看來，是需要的。需求的準(zhǔn)確無疑一直都是項(xiàng)目后期開發(fā)的根基，即使敏捷，擁抱變化，如果在早期可以將需求更準(zhǔn)確的分析出來，更貼近客戶，后期我們的成本才會更低。所以需求分析是必要的，這點(diǎn)我毫不懷疑。
需求分析--》需求規(guī)格說明書（部分界面設(shè)計(jì)或原型系統(tǒng)）--》客戶評審--》評審簽字通過
這一流程在敏捷中沒有區(qū)別
區(qū)別是傳統(tǒng)項(xiàng)目管理到此后就進(jìn)入了設(shè)計(jì)，而敏捷這里多了一步，要整理成PO的Product Backlog，將需求變成一條條的用戶故事。然后排好優(yōu)先級，根據(jù)項(xiàng)目經(jīng)理事先設(shè)定好的項(xiàng)目計(jì)劃，將幾個sprint的工作填滿。
到了設(shè)計(jì)這一階段了。到底敏捷是否需要如傳統(tǒng)項(xiàng)目的界面設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、概要設(shè)計(jì)--包括架構(gòu)設(shè)計(jì)、接口設(shè)計(jì)等。敏捷中或者說XP中的觀念是不需要預(yù)先設(shè)計(jì)的，設(shè)計(jì)包含在代碼中，這里引入了重構(gòu)等。但是這樣帶來的后果自我感覺是糟糕透頂。沒有統(tǒng)一的設(shè)計(jì)，沒有統(tǒng)一的接口，，每個人根據(jù)自己的想法設(shè)計(jì)自己的模塊，然后在爭吵中確定大家的接口和邊界。有多少個人就有多少個想法。就可能有n的平方種接口。沒有統(tǒng)一的設(shè)計(jì)，當(dāng)然更沒有統(tǒng)一的文檔。接手的人無所適從。
所以，思考的結(jié)論是，設(shè)計(jì)還是一樣要做，原來怎么做，還是怎么做，一個都不能少。
于是到了編碼階段，這里終于可以開始編碼，召開計(jì)劃會議，各人領(lǐng)自己喜歡的任務(wù)，按照設(shè)計(jì)的思路和方法開始編碼。
這里又涉及到一個編碼共同享有的問題。敏捷中提倡每個人了解多個模塊。我們有兩種產(chǎn)品，一種是開發(fā)型，一種是維護(hù)型。在開發(fā)型中，是否真的需要每個人掌握那么多模塊的開發(fā)呢？開發(fā)階段的產(chǎn)品大多數(shù)是進(jìn)度壓迫型的項(xiàng)目，一個人專心一個模塊是最快速度的開發(fā)方法，，當(dāng)一個產(chǎn)品開發(fā)完成后，維護(hù)并不需要同時一批人維護(hù)的時候，似乎一個人掌握多個模塊的開發(fā)完全沒有必要。這樣看來，計(jì)劃會議的集體討論其實(shí)也并不是那么重要，，既然抱著相信每個人的職業(yè)道德的信念，不如直接按照優(yōu)先級派發(fā)任務(wù)好了，，頂多要一個高手去幫忙估算一下時間，掌握一下進(jìn)度而已。。
看來到此為止只有安排優(yōu)先級排序這個理念比較有用一點(diǎn)。
在維護(hù)型項(xiàng)目中，大的設(shè)計(jì)已經(jīng)定下來了，而且人員不會很充裕的情況下，也許敏捷上面的幾個實(shí)踐才能更好的實(shí)踐吧，，只是優(yōu)先級排序現(xiàn)在看起來又沒那么重要了，，這一維護(hù)期內(nèi)的需要反正都要做完，做完就上線，不需要什么優(yōu)先級了，都做就是了。
文章來源：中國項(xiàng)目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
