敏捷項目管理誤區(qū)
與敏捷軟件開發(fā)一樣，敏捷項目是在叫做迭代的小型部門中完成的。每個迭代都由項目團隊審查和評判;從迭代的評判中獲得的信息用于決定項目的下一個步驟。那么敏捷項目管理誤區(qū)有哪些呢?一起來看看!
一：敏捷對人的要求很高
很多人在嘗試實施敏捷時說：敏捷對人的要求太高了，我們沒有這樣的條件，我們沒有這樣的人，因此我們沒法敏捷�？墒牵艚輰θ说囊笳娴哪敲锤呙�?
軟件歸根到底還是一種創(chuàng)造性活動，開發(fā)人員的技術(shù)水平和個人能力對軟件的質(zhì)量還是起著決定性的作用，各種過程與方法只是幫助開發(fā)人員、測試人員等角色能夠更好的合作，從而產(chǎn)生更高的生產(chǎn)力。不管用什么方法，開發(fā)人員的水平永遠都是一個主要的因素。
從另一個角度來看：過程和方法究竟能幫開發(fā)人員多大忙?對于技術(shù)水平較低的開發(fā)人員，敏捷方法和傳統(tǒng)方法對他的幫助是差不多的，因此看不到顯著的效果，甚至有些時候還有反效果;而隨著開發(fā)人員技術(shù)水平的提高，敏捷方法能夠解開對人的束縛，鼓勵創(chuàng)新，效果也會越來越顯著。
敏捷對人的要求并不高，而且會幫助你培養(yǎng)各種所需的能力，當然前提是你處在真正敏捷的環(huán)境中。
二：敏捷沒有文檔，也不做設(shè)計
這個從XP開始就沒有停止過，XP鼓勵“在非到必要且意義重大時不寫文檔”。這里面提到的“必要且意義重大”是一個判斷標準，并不是所有的文檔都不寫。例如，用戶手冊是不是“必要且意義重大”?這取決于客戶的要求，如果客戶不需要，那就不用寫,如果客戶需要，就一定要寫;再如，架構(gòu)設(shè)計文檔要不要寫?復(fù)雜要寫，不復(fù)雜不用寫。通常架構(gòu)設(shè)計只需要比較簡單的文檔，對于有些項目，一幅簡單的UML圖就夠了。因此，寫不寫，怎么寫，都要根據(jù)這個文檔到底有多大意義，產(chǎn)出和投入的比例，以及項目的具體情況決定。實際操作時可以讓項目組所有人員表決決定，盡量避免由某一個人(比如lead)來決定。
至于設(shè)計，XP奉行的是持續(xù)設(shè)計，并不是不設(shè)計。這實際上是將設(shè)計工作分攤到了每天的日常工作中，不斷的設(shè)計、改善(重構(gòu))，使得設(shè)計一直保持靈活可靠。至于編碼前的預(yù)先設(shè)計，Kent Beck等人確實實行著不做任何預(yù)先設(shè)計的開發(fā)方式，但是對于我們這些“非大師”級開發(fā)人員，必要的預(yù)先設(shè)計還是需要的，只是不要太多，不要太細，要有將來會徹底顛覆的準備。
三：敏捷好，其他方法不好
有些人一提到敏捷就大呼好，只要是敏捷的實踐就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上邊就哪里都不好，似乎敏捷和其他方法是完全對立的。牛頓說過，我是站在了巨人的肩膀上。敏捷同樣也吸取了其他方法論的優(yōu)點，也是站在了巨人的肩膀上，敏捷依然保持了很多歷史悠久的`實踐和原則，只是表現(xiàn)方式不同罷了。
從另一個方面來看，方法本沒有好環(huán)，好與壞取決于是否適合解決你的問題。每一種方法都有他最善于解決的問題和最佳的發(fā)揮環(huán)境，在需求穩(wěn)定、軟件復(fù)雜度相對不高的時代，瀑布模型也可以工作的很好，而敏捷恰好適用于變化快風險高的項目 - 這恰恰是現(xiàn)在很多項目的共性。
因此選擇一個方法或過程，并不是根據(jù)它是否敏捷，而應(yīng)根據(jù)它是否適合。而要了解一個東西是否適合，還是要嘗試之后才知道，任何沒有經(jīng)過實踐檢驗的東西都不可信。
四：敏捷就是XP，就是Scrum
XP和Scrum只是眾多敏捷方法中的兩種，還有很多其他的敏捷方法。龍生九子各個不同，敏捷的這些方法看起來差別也是很大的，可是他們之所以被稱為敏捷方法，就是因為他們背后的理念和原則都是相同的，這個原則就是《敏捷宣言》。學習敏捷不僅僅要學習實踐，還要理解實踐后的原則，不僅要理解怎么做，還要理解為什么這么做，以及什么時候不要這么做。
即使將XP或Scrum完全的應(yīng)用的你的項目中，也未見得就能成功，適合別人的東西未必就適合你。敏捷的這些實踐和方法給了我們一個起點，但絕對不是終點，最適合你的方式還要由你自己在實際工作中探索和尋找。
五：敏捷很好，因此我要制定標準，所有項目都要遵循著個標準
沒有哪兩個項目是一樣的，客戶是不一樣的，人員是不一樣的，需求是不一樣的，甚至沒有什么可能是一樣的。不一樣的環(huán)境和問題，用同樣的方法解決，是不可能解決的好的。方法是為人服務(wù)的，應(yīng)該為項目團隊找到最適合他們的方法，而不是先確定方法，再讓團隊適應(yīng)這個方法。因此也不存在適合所有項目的統(tǒng)一的方法。任何企圖統(tǒng)一所有項目過程的方法都是不正確的。
同時，對于同一個團隊，隨著項目的進行，對需求理解的深入，對技術(shù)理解的深入，一開始適合項目的過程和方法也會漸漸的不適合。這時候也需要團隊對過程進行及時的調(diào)整，保證項目的質(zhì)量和效率。敏捷是動態(tài)的，而非靜止不變的，因為這個世界本身就是變化的，在變化的世界使用不變的方法，是不現(xiàn)實的。銀彈從來就沒有過，在有限的將來也不會存在。
【敏捷項目管理誤區(qū)】相關(guān)文章：