如何當好敏捷項目的經(jīng)理
Michele Sliger是《軟件項目經(jīng)理的敏捷之路》一書的編者和顧問，本文總結了她對如何做好敏捷項目經(jīng)理的一些觀點和建議。
每個敏捷項目都有項目經(jīng)理嗎？
Michele Sliger認為，這個問題要看具體情況。Scrum開發(fā)有Scrum Master，這算不算項目經(jīng)理呢？XP開發(fā)有XP教練，這算不算PM呢？在Michele做過顧問的大型企業(yè)中，雖然這些企業(yè)大都選擇使用XP、 Scrum或是精益敏捷開發(fā)方法，但他們的人事簿上都有PM一職。職位還是“項目經(jīng)理”，只是作用可能并不一樣。
敏捷項目經(jīng)理的職能與以前有何不同？
Michele Sliger認為，敏捷項目經(jīng)理的職能與以前的定義完全不同。傳統(tǒng)意義上的項目經(jīng)理只是一個在項目失敗的時候承擔責任的人。因為要承擔責任，所以他們通常傾向于使用命令加控制的領導方式。在敏捷開發(fā)中，需要的是一個教練、指導、引領者，不是在微觀上進行操控，告訴團隊的每個人應該干什么，而是要讓團隊明白我們需要什么，避免走上歧路。
PMI（美國項目管理協(xié)會）說，90%的項目管理工作是交流與溝通。對于敏捷項目管理來說，同樣是這樣。這項工作的主要內容就是作為團隊成員的交流媒介，幫助他們達到共識，與企業(yè)協(xié)商讓他們明白企業(yè)動向將對團隊產(chǎn)生怎樣的影響。他們的作用就是協(xié)助、交流、引導，就像是那種一對一的領導方式。雖然不是要一直從商業(yè)的角度來考慮，不過PM還是需要時時通知開發(fā)人員項目當前的狀態(tài)?？梢哉fPM幾乎就是開發(fā)過程的監(jiān)督人。
敏捷項目經(jīng)理需要注意自己的領導方式。如果他們以前使用的是命令與控制的方式，那么必須做出改變?，F(xiàn)在的首要任務是如何幫助自己的團隊。但是，即使團隊開始有組織地、高效率地運作起來，也并不意味著PM的工作已經(jīng)結束，他們仍然需要幫助公司采納敏捷這種方式。相對于以前協(xié)助團隊的工作而言，也就是轉向更有戰(zhàn)略意義的工作，比如把精力放在如何幫助公司向敏捷進行調整上。
敏捷項目經(jīng)理還必須對項目成敗負責嗎？
Michele Sliger指出，Ken Schwaber曾經(jīng)說過，在Scrum開發(fā)中唯一負責的是產(chǎn)品負責人（product owner），而不是項目經(jīng)理。產(chǎn)品負責人是對產(chǎn)品有著決定權。我們可以把責任想像成三元組：產(chǎn)品負責人管理產(chǎn)品的功能需求，開發(fā)團隊開發(fā)實現(xiàn)，而 Scrum Master/敏捷項目經(jīng)理負責幫助團隊完成任務并避免受到外界干擾。PM要保護團隊，想辦法滿足團隊需求、為團隊爭取預算以及其它類似工作。
項目經(jīng)理是否必須擁有PMP資格認證并遵循PMBOK體系（項目管理知識體系指南）呢？
Michele Sliger認為，現(xiàn)在的項目經(jīng)理甚至都沒有正確地使用瀑布模型。我們在每個新過程所做的都是取出20%，了解它，然后完成。PMBOK也是如此。許多人沒有注意到，PMBOK并不是單單指向軟件項目管理，它是針對所有的項目管理。PMBOK上的內容都是已被普遍認可的優(yōu)秀實踐，我們要做的只是仔細閱讀并把它們作為必須實行的。PMBOK是一本指南。如果把它看做是必須做的，那么你就會圍繞它建立起一個像瀑布模型的框架，然后會發(fā)現(xiàn)大家都在用瀑布模型。而常見的誤解是，你必須建立瀑布模型來保持與PMBOK的一致，這種做法恰好顛倒了主次。
那么PMBOK和敏捷實踐之間有哪些相似之處和不同之處呢？
Michele Sliger認為，PMBOK中的一個要點就是漸進細化（progressive elaboration），而這正是敏捷需求定義的意義所在。漸進細化是從較高的層次上分析需求，在準備開始的時候才進行細節(jié)方面的工作。PMBOK還有一個要點是使用滾動計劃——計劃到一個點、進行幾個迭代周期、回顧并做下一個計劃。這與傳統(tǒng)的、在項目開始時就做好計劃是不同的。
最主要的不同點是敏捷方法不會使用PMBOK中的所有實踐。我們只是使用其中的一部分，比如滾動計劃。另一個不同點是敏捷方法不做正式的項目文件，而 PMBOK則建議做正式的項目文件，雖然這一定并不做要求。另外，PMBOK強調要做大量的分析，而敏捷方法則不提倡。
敏捷項目經(jīng)理使用傳統(tǒng)的PM工具嗎？
Michele Sliger表示，她已經(jīng)有十年時間沒有碰過甘特圖了。這種東西是為那些不使用迭代方法的長期項目準備的。敏捷開發(fā)所使用的應該是那些更能滿足迭代開發(fā)要求的工具。這些工具不會像甘特圖那樣，認為一個項目可以一次性完成90%的內容。Michele使用的是時間計劃圖（burndown chart）——要么徹底完成，要么就是失敗。通過時間計劃圖，可以更準確地估計完成項目所需的時間。這種計劃圖能夠比較清晰地展示當前的狀態(tài)。
如果團隊比較分散，則還需要一些工具以及相關的支持設施。由于工作進展很快，所以需要如Skype、IM等的共享軟件，或是XPlanner等工具幫助進行敏捷項目管理。所有的敏捷PM工具都應該有以下基本特征：有存放待辦任務的地方，有表示迭代的地方，可以表示正在開發(fā)中的功能、測試結果以及測試本身。
在向敏捷PM轉型過程中有哪些可避免的常見誤區(qū)呢？
Michele Sliger表示，千萬不要把轉型簡單地看作使用工具的改變。別以為你放下甘特圖拿起時間計劃圖來就嗖地一下完成了敏捷轉換。敏捷是一種理念，它是價值驅動而不是計劃驅動的。你必須理解這種范式。經(jīng)常有人犯各種各樣的錯誤。不管大型公司還是小型公司，他們都以為敏捷是一種新的方法，這種方法有特殊的規(guī)則，因此要使用特定的工具。這種想法不會讓你的團隊變成敏捷團隊——它只會讓你變成一個使用敏捷工具的瀑布團隊。
【編輯推薦】
