Bye-bye Scrum!申請“敏捷項目經理”職位的人注意啦

全文共2751字,預計學習時長

8分鐘

Bye-bye Scrum!申請“敏捷項目經理”職位的人注意啦


如今,項目管理知識體系(PMBOK)與敏捷宣言(Agile Manifesto)基本原則直接衝突。


項目管理協會是一個有50年曆史的機構,致力於項目、程序、項目組合管理的研究。在他們的官網上,你能找到該組織的宗旨“…讓我們為您服務,來推動項目管理專業世界化。”


該組織也是項目管理知識體系的作者,這本書可以說是項目管理的聖經。說真的,這玩意兒有756頁!


由於該組織在項目管理上的權威性,他們同時也提供8種不同的資質證明。其中一種證明就是敏捷管理專業人士資格認證(PMI-ACP),而這個認證也是這篇垃圾,我是說這篇文章的主題。


我有一堆很亮眼的證書。除了CSM、CSPO和CSP1外,我還有PMP和PMI-ACP證書。


1:都為Scrum認證體系。


我並不反對PMI作為項目管理行業的權威和推動者。該組織為項目、程序、組合經理提供了大量的重要信息,他們的資格認證項目在測試相關技能和經驗要求方面做得非常好。不得不說,PMI非常非常擅長他們的工作。


PMI進入敏捷領域的理由是錯誤的


Bye-bye Scrum!申請“敏捷項目經理”職位的人注意啦


這就是為了錢。純粹且簡單。PMI看到了敏捷框架的發展前景,尤其是Scrum,於是他們就想進來分一杯羹。更多的認證,更多的訓練,更多的會員,這些都意味著更多的錢。


Scrum中項目經理角色的缺失也引起了PMI的關注。如果沒有項目經理的角色,那麼項目管理專業人士資格認證(PMP)將做些什麼呢?PMP面臨的收入流風險是巨大的。


根據PMI 2018年度報告,世界範圍內,他們在會費、資質認證和書籍銷售上創造了2.39億美金的年營收。該報告還宣稱PMBOK已經發行了600多萬份。但由於PMP是他們的主打產品,PMI應該感到擔憂。


PMI-ACP :一隻獨角獸出生了


先確定一下,我們對此都能達成共識,那就是Scrum沒有項目管理人。這個脫胎於PMI-ACP認證的“敏捷項目管理人”是一個獨角獸。


在應用Scrum的組織中,傳統項目管理的職能分散在ScrumMaster、產品負責人和開發團隊上。一些傳統的項目管理函數已經不再需要了。


在試圖過渡到敏捷框架的組織中,敏捷項目經理只會導致混亂和衝突。沒有人十分清楚各自的職責是什麼。


Bye-bye Scrum!申請“敏捷項目經理”職位的人注意啦

該PMI-ACP包括許多敏捷方法,如Scrum、看板、Lean、極限編程(XP)和測試驅動開發(TDD.)因此,你的項目可能會幫助你體驗更多的功能。


贊!這才是該有的認證。


真的。我說真的,一次考試,就能夠獲得對五種不同的敏捷框架紮實的理解?說再多的就沒意思了。


如果這還不能讓你流下敏捷的淚水,那麼看看PMP和PMI-ACP的要求:


Bye-bye Scrum!申請“敏捷項目經理”職位的人注意啦


申請考試的條件


我有三個Scrum證書,參加過正式的課堂培訓,參加過多天的Scrum或者敏捷會議,花了無數時間學習Scrum。我是領導團隊的一員,負責把瀑布模型成功地過渡到Scrum。我在軟件產品開發方面有20年的經驗,在真實的Scrum環境中有10年的經驗。我還有很多東西要學。畢竟,我是一個Scrum新手。


Scrum需要經驗豐富的專業人士。Scrum主管和產品負責人不是由沒有經驗的高中畢業生擔任的入門級角色。


獲得PMI-ACP認證的條件明顯表明了,即使是PMI也沒有認真對待這一資質。PMI-ACP是對市場需求突然轉變的錯誤反應。


PMI和Scrum之間的功能性衝突


項目管理原則和Scrum之間的衝突遠遠超出了過程、角色和語義。PMI所教導和傳播的原則明確地破壞了使Scrum有效的原則。如今,橫跨這兩個領域的藩籬導致了許多組織中應用Scrum的失敗。


Bye-bye Scrum!申請“敏捷項目經理”職位的人注意啦

PMI項目管理階段


讓我們看看前兩個階段,能發現哪些衝突。


1構想 & 啟蒙


PMI風格的項目管理第一步是創建項目章程。通常,項目的執行發起人會對該文檔進行實體或數字簽名。這是一個已經執行的合同,目的是在項目的第一天鎖定目標。


衝突: 這違反了敏捷宣言四個價值觀中的兩個:


客戶合作優於合同談判。


僅僅是簽署項目章程的心理就立即使項目利益相關者和項目執行團隊之間產生了分歧。是我們對抗他們。


按照計劃對變化做出反應。


請記住,許多項目會持續數月甚至數年。認為項目任務在此期間不會發生變化,是幼稚和不負責任的。特別是在軟件產品領域,及時對競爭對手和新技術做出反應是至關重要的。


2定義 & 計劃


或者,正如我所說的“如何從一開始就讓你的團隊對失敗有準備”。請注意“軟件開發”名稱中的詞彙。發展是對新事物的創造,它本質上是探索性的。


衝突:提前要求完整的項目定義違反了Scrum經驗過程控制的原則。它無視對變化做出反應的價值,這也可能違反確立可持續發展步伐的原則。團隊將不可避免地落後於計劃,並在項目的最後一個月被要求奉獻出他們的夜晚和週末來“趕上”進度。


要求開發團隊預估他們從未做過的事情的工作量是沒有意義的。此外,這項工作的時間安排:沒有一行代碼是編寫的,但開發人員應該理解項目的每一個細微差別,並準確地估算它。迭代開發的好處就永遠不會被認識到。


我可以繼續列舉第三、第四和第五階段的問題,但你明白我的意思。傳統項目管理方法的一開始就抹殺了Scrum團隊賴以建立的基礎。你怎麼可能在這樣的情況下繼續前進並期待成功呢?


項目管理辦公室(PMO)如何融入一個敏捷組織裡?


我真的希望我有一個很好的答案。但我沒有。我經常在想,有一個Scrum管理組織(SMO)是不是一個更好的選擇。雖然我不喜歡這個名字(也有“服務管理組織”之意),但我確實喜歡在公司內部單獨一個組織來宣傳Scrum,以及《敏捷宣言》中的價值觀和原則綱要,確保提供適當的培訓,並幫助完善Scrum方案的執行。


理想情況下,PMI和Scrum權威組織應該聯合起來,以支持而不是衝突的精神,弄清楚這兩個機構如何能夠結合起來。我認為兩者都有生存空間。


Bye-bye Scrum!申請“敏捷項目經理”職位的人注意啦


無論如何,當前PMI-ACP認證和“敏捷項目經理”的激增,將Scrum團隊的未來發展置於可怕的道路上。我們能做的最好的事情就是教育公司領導人關於PMBOK、Scrum實踐和敏捷宣言之間的關鍵區別。


此外,對於那些正在招聘或正在申請“敏捷項目經理”職位的人來說,要當心了。


Bye-bye Scrum!申請“敏捷項目經理”職位的人注意啦

我們一起分享AI學習與發展的乾貨


分享到:


相關文章: