400-888-5228

敏捷的基礎(chǔ)定義雖然很簡單,但是將其運用到工作上,發(fā)現(xiàn)大家對敏捷還是一知半解,甚至是誤解。今天小艾老師為大家整理了一份對敏捷開發(fā)的誤解清單。

誤解一:敏捷對人的要求很高

很多人在嘗試實施敏捷時說:敏捷對人的要求太高了,我們沒有這樣的條件,我們沒有這樣的人,因此我們沒法敏捷。可是,敏捷對人的要求真的那么高么?軟件歸根到底還是一種創(chuàng)造性活動,開發(fā)人員的技術(shù)水平和個人能力對軟件的質(zhì)量還是起著決定性的作用,各種過程與方法只是幫助開發(fā)人員、測試人員等角色能夠更好的合作,從而產(chǎn)生更高的生產(chǎn)力。不管用什么方法,開發(fā)人員的水平永遠(yuǎn)都是一個主要的因素。

從另一個角度來看:過程和方法究竟能幫開發(fā)人員多大忙?對于技術(shù)水平較低的開發(fā)人員,敏捷方法和傳統(tǒng)方法對他的幫助是差不多的,因此看不到顯著的效果,甚至有些時候還有反效果;而隨著開發(fā)人員技術(shù)水平的提高,敏捷方法能夠解開對人的束縛,鼓勵創(chuàng)新,效果也會越來越顯著。

敏捷對人的要求并不高,而且會幫助你培養(yǎng)各種所需的能力,當(dāng)然前提是你處在真正敏捷的環(huán)境中。

誤解二:敏捷沒有文檔,也不做設(shè)計

這個誤解從XP開始就沒有停止過,XP鼓勵“在非到必要且意義重大時不寫文檔”。這里面提到的“必要且意義重大”是一個判斷標(biāo)準(zhǔn),并不是所有的文檔都不寫。例如,用戶手冊是不是“必要且意義重大”?這取決于客戶的要求,如果客戶不需要,那就不用寫,如果客戶需要,就一定要寫;再如,架構(gòu)設(shè)計文檔要不要寫?復(fù)雜要寫,不復(fù)雜不用寫。通常架構(gòu)設(shè)計只需要比較簡單的文檔,對于有些項目,一幅簡單的UML圖就夠了。因此,寫不寫,怎么寫,都要根據(jù)這個文檔到底有多大意義,產(chǎn)出和投入的比例,以及項目的具體情況決定。實際操作時可以讓項目組所有人員表決決定,盡量避免由某一個人(比如lead)來決定。

至于設(shè)計,XP奉行的是持續(xù)設(shè)計,并不是不設(shè)計。這實際上是將設(shè)計工作分?jǐn)偟搅嗣刻斓娜粘9ぷ髦?,不斷的設(shè)計、改善(重構(gòu)),使得設(shè)計一直保持靈活可靠。至于編碼前的預(yù)先設(shè)計,Kent Beck等人確實實行著不做任何預(yù)先設(shè)計的開發(fā)方式,但是對于我們這些“非大師”級開發(fā)人員,必要的預(yù)先設(shè)計還是需要的,只是不要太多,不要太細(xì),要有將來會徹底顛覆的準(zhǔn)備。

誤解三:敏捷好,其他方法不好

有些人一提到敏捷就大呼好,只要是敏捷的實踐就什么都好,而提到CMMI等方法就大呼不好,不管是什么只要沾上邊就哪里都不好,似乎敏捷和其他方法是完全對立的。牛頓說過,我是站在了巨人的肩膀上。敏捷同樣也吸取了其他方法論的優(yōu)點,也是站在了巨人的肩膀上,敏捷依然保持了很多歷史悠久的實踐和原則,只是表現(xiàn)方式不同罷了。

從另一個方面來看,方法本沒有好環(huán),好與壞取決于是否適合解決你的問題。每一種方法都有他_善于解決的問題和_佳的發(fā)揮環(huán)境,在需求穩(wěn)定、軟件復(fù)雜度相對不高的時代,瀑布模型也可以工作的很好,而敏捷恰好適用于變化快風(fēng)險高的項目 - 這恰恰是現(xiàn)在很多項目的共性。

因此選擇一個方法或過程,并不是根據(jù)它是否敏捷,而應(yīng)根據(jù)它是否適合。而要了解一個東西是否適合,還是要嘗試之后才知道,任何沒有經(jīng)過實踐檢驗的東西都不可信。

誤解四:敏捷就是XP(極限編程),就是Scrum

XP 和Scrum只是眾多敏捷方法中的兩種,還有很多其他的敏捷方法。龍生九子各個不同,敏捷的這些方法看起來差別也是很大的,可是他們之所以被稱為敏捷方法,就是因為他們背后的理念和原則都是相同的,這個原則就是《敏捷宣言》。學(xué)習(xí)敏捷不僅僅要學(xué)習(xí)實踐,還要理解實踐后的原則,不僅要理解怎么做,還要理解為什么這么做,以及什么時候不要這么做。

即使將XP或Scrum完全的應(yīng)用的你的項目中,也未見得就能成功,適合別人的東西未必就適合你。敏捷的這些實踐和方法給了我們一個起點,但_不是終點,_適合你的方式還要由你自己在實際工作中探索和尋找。

誤解五:敏捷很好,我要制定標(biāo)準(zhǔn),所有項目都要這個標(biāo)準(zhǔn)

沒有哪兩個項目是一樣的,客戶是不一樣的,人員是不一樣的,需求是不一樣的,甚至沒有什么可能是一樣的。不一樣的環(huán)境和問題,用同樣的方法解決,是不可能解決的好的。方法是為人服務(wù)的,應(yīng)該為項目團(tuán)隊找到_適合他們的方法,而不是先確定方法,再讓團(tuán)隊適應(yīng)這個方法。因此也不存在適合所有項目的統(tǒng)一的方法。任何企圖統(tǒng)一所有項目過程的方法都是不正確的。

同時,對于同一個團(tuán)隊,隨著項目的進(jìn)行,對需求理解的深入,對技術(shù)理解的深入,一開始適合項目的過程和方法也會漸漸的不適合。這時候也需要團(tuán)隊對過程進(jìn)行及時的調(diào)整,_項目的質(zhì)量和效率。敏捷是動態(tài)的,而非靜止不變的,因為這個世界本身就是變化的,在變化的世界使用不變的方法,是不現(xiàn)實的。銀彈從來就沒有過,在有限的將來也不會存在。

發(fā)表回復(fù)

您的電子郵箱地址不會被公開。 必填項已用*標(biāo)注

  • 2024-11-28 20:00
    智能財務(wù)運營的未來視角:RPA與AI技術(shù)的融合應(yīng)用
  • 2024-11-29 14:00
    周五課堂:如何帶團(tuán)隊?靠什么服眾?那些無處不在的“軟技能”
  • 2024-12-04 20:00
    職場故事:PMP與BA的協(xié)同與本地化策略
  • 2024-12-05 20:00
    職場故事:策劃崗如何快速學(xué)習(xí)新領(lǐng)域新知識?Get新技能√
  • 2024-12-10 20:00
    數(shù)字化轉(zhuǎn)型與TOGAF:不謀全局者,不足謀一隅,數(shù)字化轉(zhuǎn)型的“頂層設(shè)計”
  • 2024-12-12 20:00
    神秘莫測:密碼學(xué)和加密解密
  • 2024-12-17 20:00
    財務(wù)運營智能化與數(shù)據(jù)驅(qū)動:商業(yè)智能(BI)系統(tǒng)的實施與運用
  • 2024-12-19 20:00
    職場故事:項目管理的藝術(shù)與日常
  • 2024-12-25 20:00
    案例分析:深入探討商業(yè)分析工具的實際應(yīng)用
  • 2024-12-26 20:00
    存量數(shù)據(jù)“由亂到治”:如何解決已有數(shù)據(jù)的數(shù)據(jù)質(zhì)量問題?
  • 更多直播講座
    小艾老師還在安排中…
查看全部 >

掃碼一鍵預(yù)約全部

查看更多 > 查看更多 >

數(shù)字化轉(zhuǎn)型8大核心認(rèn)證

  1. PMP項目管理認(rèn)證

    艾威最近一期班: 針對2025年03月考試
  2. CBAP業(yè)務(wù)分析認(rèn)證

    艾威最近一期班·開課時間: 2025-01-18
  3. CBPP流程管理認(rèn)證

    艾威最近一期班·開課時間: 2025-03-15
  4. ITIL4 IT管理認(rèn)證

    艾威最近一期班·開課時間: 2025-01-18
  5. TOGAF企業(yè)架構(gòu)認(rèn)證

    艾威最近一期班·開課時間: 2025-01-18
  6. CDMP數(shù)據(jù)管理認(rèn)證

    艾威最近一期班·開課時間: 2025-02-22
  7. CISA信息安全審計師認(rèn)證

    艾威最近一期班·開課時間: 2025-03-02
  8. CISSP信息安全專家認(rèn)證

    艾威最近一期班·開課時間: 2025-02-15
近期課程安排