敏捷開發(fā)的需求和設(shè)計的疑問

申請免費(fèi)試用、咨詢電話：400-8352-114

　　今天做敏捷開發(fā)和輕量級流程，產(chǎn)生的疑問：項目管理培訓(xùn)

　　敏捷開發(fā)中，PO將需求整理成Product Backlog，，在這之前，是否需要需求分析呢?在我看來，是需要的。需求的準(zhǔn)確無疑一直都是項目后期開發(fā)的根基，即使敏捷，擁抱變化，如果在早期可以將需求更準(zhǔn)確的分析出來，更貼近客戶，后期我們的成本才會更低。所以需求分析是必要的，這點我毫不懷疑。bbs

　　需求分析--》需求規(guī)格說明書(部分界面設(shè)計或原型系統(tǒng))--》客戶評審--》評審簽字通過泛普軟件-建筑工程項目管理系統(tǒng)

　　這一流程在敏捷中沒有區(qū)別pmp

　　區(qū)別是傳統(tǒng)項目管理到此后就進(jìn)入了設(shè)計，而敏捷這里多了一步，要整理成PO的Product Backlog，將需求變成一條條的用戶故事。然后排好優(yōu)先級，根據(jù)項目經(jīng)理事先設(shè)定好的項目計劃，將幾個sprint的工作填滿。bbs

　　到了設(shè)計這一階段了。到底敏捷是否需要如傳統(tǒng)項目的界面設(shè)計、數(shù)據(jù)庫設(shè)計、概要設(shè)計--包括架構(gòu)設(shè)計、接口設(shè)計等。敏捷中或者說XP中的觀念是不需要預(yù)先設(shè)計的，設(shè)計包含在代碼中，這里引入了重構(gòu)等。但是這樣帶來的后果自我感覺是糟糕透頂。沒有統(tǒng)一的設(shè)計，沒有統(tǒng)一的接口，，每個人根據(jù)自己的想法設(shè)計自己的模塊，然后在爭吵中確定大家的接口和邊界。有多少個人就有多少個想法。就可能有n的平方種接口。沒有統(tǒng)一的設(shè)計，當(dāng)然更沒有統(tǒng)一的文檔。接手的人無所適從。泛普軟件-建筑工程項目管理系統(tǒng)

　　所以，思考的結(jié)論是，設(shè)計還是一樣要做，原來怎么做，還是怎么做，一個都不能少。項目管理培訓(xùn)

　　于是到了編碼階段，這里終于可以開始編碼，召開計劃會議，各人領(lǐng)自己喜歡的任務(wù)，按照設(shè)計的思路和方法開始編碼。service

　　這里又涉及到一個編碼共同享有的問題。敏捷中提倡每個人了解多個模塊。我們有兩種產(chǎn)品，一種是開發(fā)型，一種是維護(hù)型。在開發(fā)型中，是否真的需要每個人掌握那么多模塊的開發(fā)呢?開發(fā)階段的產(chǎn)品大多數(shù)是進(jìn)度壓迫型的項目，一個人專心一個模塊是最快速度的開發(fā)方法，，當(dāng)一個產(chǎn)品開發(fā)完成后，維護(hù)并不需要同時一批人維護(hù)的時候，似乎一個人掌握多個模塊的開發(fā)完全沒有必要。這樣看來，計劃會議的集體討論其實也并不是那么重要，，既然抱著相信每個人的職業(yè)道德的信念，不如直接按照優(yōu)先級派發(fā)任務(wù)好了，，頂多要一個高手去幫忙估算一下時間，掌握一下進(jìn)度而已。。項目經(jīng)理博客

　　看來到此為止只有安排優(yōu)先級排序這個理念比較有用一點。項目經(jīng)理博客

　　在維護(hù)型項目中，大的設(shè)計已經(jīng)定下來了，而且人員不會很充裕的情況下，也許敏捷上面的幾個實踐才能更好的實踐吧，，只是優(yōu)先級排序現(xiàn)在看起來又沒那么重要了，，這一維護(hù)期內(nèi)的需要反正都要做完，做完就上線，不需要什么優(yōu)先級了，都做就是了。泛普軟件-建筑工程項目管理系統(tǒng)