<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          敏捷與傳統:項目管理的加減法

          • 發布:軟件測試培訓
          • 來源:軟件測試教程
          • 時間:2017-08-08 15:16

          引子

          很多從事敏捷的項目經理心中可能都有個問號:“《項目管理知識體系指南》在敏捷中中到底扮演什么角色?”《項目管理知識體系指南》(以下稱《PMBOK指南》是被廣泛認可的、關于項目管理的方法和實踐的知識來源。其最新版本嚴謹地地說明了該如何使用該指南,原文如下:

          “《PMBOK指南》提供了管理項目的指導。它定義了項目管理及相關的概念,描述了項目管理生命周期及相關的流程……作為一個基礎的參考,《PMBOK指南》既不是完整的,也不是包羅萬象的。該標準更多的是指導性的而不是具體的方法。每個人都可以用不同的方法和工具來應用這個框架。”

          《PMBOK指南》介紹的大多數方法都是通用的,適用于所有項目(敏捷或者傳統的),但《PMBOK指南》畢竟還是來源于傳統的計劃驅動的開發模式,而且一般來說,人們也是在這個語境下理解它的。如果要將其應用在敏捷項目中,可能需要更多的解釋。

          關于敏捷的原理與《PMBOK指南》中的方法和流程有何關聯性。現實中,人們采用互相鄙視、非此即彼割裂地方式來看待二者。這些看法使得對敏捷與PMBOK地誤解雪上加霜。

          例如對于《PMBOK指南》的誤解:

          1)過多的文檔工作。

          2)一堆檢查表格。

          3) 繁重的流程。

          4) 你被流程管理而不是你管理流程。

          同時,與之恰恰相反的人們對于敏捷的誤解:

          1) 完全拋棄流程。

          2)無序的,失控的。

          3)不適用于復雜項目。

          4) 不專業

          這些大部分都是誤解。然而在這些誤解背后,也存在一定的真實性。形成這些誤解的原因有以下幾個。

          1.失敗的實施與錯誤的方法:仗打不好怪兵書不好

          我們必須區分將PMBOK背后的原理及方法同它們在現實中的具體實施區分開。有時候,由于某些具體實施不成功,導致人們認為方法本身是錯誤的。在很多情況下,問題發生在實施上而不是方法本身。不管是傳統方法還是敏捷方法都有此類情況,由于實施不成功而被冠以惡名。

          在有些時候,傳統方法由于過多的文檔工作、繁重的體系控制,而不能靈活地根據業務環境選擇適當的文檔工作水平和控制度而被人詬病。其實在傳統方法中并沒限制通過適當的方法來減少文檔量及控制度。

          而敏捷方法被人指責的原因則是另一個極端,因為有時候人們會過快地進入項目執行階段而只做了很少的甚至一點都沒做項目前期計劃。同樣地,在敏捷方法中也沒限制人們自己決定做多少前期計劃是合理的。

          上述兩種情況,問題都發生在具體的實施上而不是方法本身,然而有時候人們將其歸咎于方法。PMBOK中的原理同傳統方法有很強的關聯,在很多時候,這些原理的具體實施并不盡如人意。

          2.指導性方法與規定性方法:無套路V.S.有套路

          敏捷原理和PMBOK基于兩種完全不同的理念。敏捷方法一般來說只提供非常簡單的、價值導向的原理,而不做出具體規定,留了很大的空間給具體實施人員來決定在特定的環境下如何應用。它希望實施人員在其上根據實際情況增加新的內容。整個方法體系的設計都是非常靈活及自適應的。

          “敏捷項目管理中重要的一點就是,方法都是指導性的而非規定性的。規定性的方法試圖規定團隊應做的每件事情。這種方式使人迷失其中。人們要從一堆方法中進行選擇而又缺少指導,這導致想要為某個具體項目剔除無關的方法困難重重。

          一組指導性的方法是一個系統的最小集合。它不規定項目團隊要做的事情,但是它定義了那些有價值的、基本適用于所有項目的方法。

          從一組最小的方法集開始,然后審慎地根據需要用“加法”增加其他的方法,同從全面的方法集出發之后用“減法”將其減少到一組適用的方法相比,被證明是更加有效的。敏捷不會用幾千頁的文檔來規定開發上需要的每件事情……“

          相反地,很多傳統的以計劃驅動的方法采用“減法”。PMBOK就是一個例子,你需要將其裁剪,只使用你的特定項目中需要的內容。它的問題在于過度規定做什么,而敏捷方法的問題在于過度不規定做什么。PMBOK第5 版差不多有500 頁。PMBOK的原意非常清楚,它提供了一組工具,你可以將這些工具作為參考,按照你的理解使用它們。然而PMBOK的寫法,很容易讓人將其看做權威性的和規定性的文件,雖然這并不是它的本意。

          “敏捷方法制定文檔強調最精簡化。遺憾的是,大部分傳統方法都受累于”減法”方法。這些傳統方法都是由專家制定的,他們希望這些方法可以為使用者提供所有的可預見的情況下的指導。所以專家們制定了非常全面的方法,并在不重要的和不復雜的項目上做”減法”。這些專家理解如何做”減法”,并經常為其他人提供指導和案例。

          遺憾的是,大多數開發人員、用戶和項目經理并不具備足夠的專業知識和自信心,他們希望看到所有的計劃、規范和標準,他們覺得這樣比較安全。非專業人士無法根據需要選擇合適的方法而是在項目上直接使用所有規定的方法。非專業人士很少閱讀不斷更新的資料,而是錯誤地認為他們使用了最佳實踐方法來保證項目的可預測性和可控性。不用說,制定方法的專家會非常失望,因為他們的方法被按照字面的意思錯誤地使用。

          敏捷方法如Scrum被批評太過虛無,在一些重要的領域不夠具體,尤其是在一些高層次的項目管理方法上面。另外,PMBOK和其他的傳統方法被批評規定性太強。最理想的方法介于兩者之間,西方人喜歡把矛盾的問題分開看,東方人喜歡對立統一的看問題,其實敏捷的至高境界應該是中庸之道,則其兩端而用其中。

          3.人性價值導向與流程導向:為項目選擇流程而不是相反

          另一個很大的區別是人性價值導向和流程導向的區別。PMBOK沒有深度挖掘項目管理中的人性成分,而敏捷方法則直接談到了項目人員管理中的人性成分。

          PMBOK第9章和第13張談到了“項目人力資源管理”與“干系人管理”。這些題目應該更多地依賴原理性理解和反復實踐才能靈活掌握,尤其是要善于反思才能做好,而不是采用一些按部就班的流程就能做好“人力資源管理”和“干系人管理”。

          PMBOK第5 版附錄 X“人際交往技巧”。而在敏捷方法中,這個主題是整個方法體系中的一個有機組成部分,而不只是作為附錄加入的。

          當然,一個優秀的項目經理懂得如何管理項目人員。盡管PMBOK并沒有任何具體的介紹,但是敏捷原理更加深入,在敏捷宣言中將其明確為價值之一。

          “依靠自我激勵的團隊完成項目。為他們提供需要的環境和支持,信任他們可以完成工作。“

          兩種方法的區別在于:

          PMBOK指南的出發點是以流程導向的,后來開始在流程導向中融入了以人為導向的思想,但依然還是以流程為主而以人為輔的

          敏捷則從一開始就強調以人為本,敏捷宣言中的四大價值之一就是“個體和互動高于流程和工具”。

          這兩種方法已經日益融合,但這兩種思想體系要真正地融為一體尚需時日。

          敏捷方法在過去的16年間成熟度大大提升,也越來越多地認識到在以人為本的基礎上也需要增加以流程為導向的內容。

          PMBOK指南已經逐步開始豐富項目管理中軟件的部分及更多對人的關注(在PMBOK指南第6版本中新加入了敏捷的應用指導,就是很好的例子)

          4.強調前期計劃和控制與對變化的及時響應

          控制與適應決定于項目的不確定性和復雜度

          另一個PMBOK指南的方法同敏捷方法間的重大區別就是,PMBOK指南一直以來都強調前期計劃及控制,自然而然地會注重對項目范疇的管理和控制。雖然PMBOK指南中明顯地說明對計劃和控制的注重,但這確實是人們對于PMBOK指南的一種常見解讀。在敏捷項目中對項目范疇的控制并非至關重要,敏捷方法持有一種開放的心態,鼓勵和歡迎在項目過程中來自相關人員的各種變化。這在思維方式上大相徑庭。

          當業務需求非常不確定,隨著項目進展很有可能發生變化,要想真的控制改變只是一種妄想。即便是計劃非常完善的項目,可能開始時看起來一切盡在控制,而后期變化非常頻繁而導致所謂的控制變成了虛幻的表象。在這種情況下,試圖獲得高控制性是徒勞的,而真正需要的則是控制和靈活之間的一種平衡,既有根據計劃的一定的控制,又保持足夠的靈活性以應對項目過程中業務需求的變化。

          我們必須仔細思考如何實現這樣的平衡,而要獲得這樣的平衡必然要做些權衡。比如說,要想成功獲得業務上的效果,就要在整個開發過程中采用更加協作的方法,允許在開發過程中提出更多的業務上的需求,而這可能會影響對項目的預測,以及對于成本和時間的控制,這種權衡應該是完全可以接受的。PMBOK指南中沒有任何地方說不可以做這樣的妥協,當然其中也沒有特別鼓勵去做這樣的權衡。

          而在另一個極端,敏捷方法則鼓勵項目團隊盡早地進入執行階段,不要做過多的前期計劃,而這則帶來另外的一些問題:

          由于前期計劃很少,開始時對于預算和時間的估計非常不可靠,這可能帶來意外的“驚喜”。

          由于在敏捷方法中,經常采用增量和迭代的方法來開發,沒有在前期做好架構設計的工作,而是隨著項目進展不斷完善的,這可能導致大量的重構工作。

          在很多情況下,項目失敗并不是由方法本身導致的,而是由錯誤的實施而導致的。不管敏捷方法還是非敏捷方法,從來都沒有任何理由阻止我們根據具體的業務情況及項目本身的風險和復雜度來選擇和制定好的方法。

          比如說,敏捷方法同樣可以包括:

          通過適當的前期計劃來獲得一定精確度的成本和時間估計,并隨著項目進展不斷地完善它。然而,有些比較極端的敏捷的擁護者則認為對于敏捷項目而言,計劃及成本和時間管理已經完全不需要了。

          在前期做適當的架構設計并隨著項目進展不斷修改和完善架構。

          結束語

          從表面上看,PMBOK指南同敏捷的方法和實踐是水火不相容的。如何能將兩者融合起來并不是顯而易見的,但兩者卻是相互之間非常好的補充。要將兩者很好地結合起來需要花費一些時間。而理解這兩種方法論,并根據項目的具體情況準確判斷并將兩者結合起來,則依賴每個項目經理在管理具體的項目時去實現。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:提高軟件測試效率的方法有哪些?
          下一篇:軟件測試如何提交一個有質量的bug?
          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>