寫在前面

6月27日，我在ThoughtWorks PM社區(qū)上做了一個直播分享——項目管理標(biāo)準(zhǔn)化。

在這次分享中，我從項目團隊的視角出發(fā)，歸納了在項目管理中我們通常遇到的三類問題：

團隊目標(biāo)不一致

團隊成員不熟悉

信息發(fā)布不順暢

作為項目經(jīng)理的我們，不斷地經(jīng)歷一個又一個的項目，一次次地面對相同的問題。如果我們不從中總結(jié)和提煉，我們就會反復(fù)地徘徊在豐滿的理想和骨感的現(xiàn)實中。

敏捷思想和敏捷實踐，為我們提供了一種解決方法，幫助我們解決在項目交付過程中遇到的具體問題。下面我將詳細(xì)介紹我在本次分享中所談到的敏捷實踐，作為我直播分享的一個補充。

正文：

敏捷的項目管理——追求最大價值的成功

當(dāng)我們提到敏捷的項目管理，我們就不能不先說說瀑布式開發(fā)和迭代式開發(fā)的區(qū)別。

大家都知道瀑布式開發(fā)的特點是大批次、緩慢流動，每一階段追求工作完整，但因其缺乏并行迭代的概念，面對變化的響應(yīng)必然很慢。而迭代式開發(fā)則恰恰彌補了這個弱點。在迭代式開發(fā)過程中，整個開發(fā)工作被組織為一系列短小的、固定長度（在ThoughtWorks通常是2周）的小項目，我們將其稱為一系列的“迭代”。每一次迭代都包括了需求定義、需求分析、設(shè)計、代碼實現(xiàn)與測試。

采用這種方法，開發(fā)工作可以在需求被完整地確定前啟動，并在每次迭代中都可以完成系統(tǒng)的一部分功能的開發(fā)工作，再通過客戶的反饋來細(xì)化需求，并開始新一輪的迭代。

ThoughtWorks的敏捷開發(fā)通過逐步細(xì)化、迭代前進的方式，分階段地將需求予以實現(xiàn)。比如說，我們先從整體功能規(guī)劃中定位出一小部分核心功能，打造能基本運轉(zhuǎn)、對用戶有價值的最小可用產(chǎn)品（Minimum Viable Product，MVP），然后迅速迭代開發(fā)，聽取用戶反饋，及時調(diào)整功能規(guī)劃。

上周日我參加了一個培訓(xùn)，其中一位同事談到了西游記團隊和敏捷團隊的聯(lián)系，他認(rèn)為唐僧師徒是敏捷中的全功能團隊：團隊有共同的目標(biāo)——取到真經(jīng)；他們歷經(jīng)了九九八十一難，好比九九八十一個迭代，每個迭代的打怪都是一次交付；在不斷迭代的過程中，這個團隊不斷地收集反饋、持續(xù)改進，一步步地完成了最后的目標(biāo)。取到了真經(jīng)，意味著完成了項目的交付，同時在這個過程中，團隊能力得到了提升。這是一個美妙的結(jié)果。

項目成果的交付&團隊能力的提升，這是在項目管理中，項目經(jīng)理最希望達(dá)成的目標(biāo)。

傳統(tǒng)項目管理的定義是：“在有限資源限定的條件下，實現(xiàn)或超過設(shè)定的需求和期望”。一句話概括了傳統(tǒng)項目管理的鐵三角：需求是范圍，資源包括時間和成本。

那么這個定義是正確的嗎？

大家都看過電影《泰坦尼克號》，如果我們套用上面這個“范圍、時間和成本”定義的框架，《泰坦尼克號》會被判斷是一個失敗的項目。為什么呢？這部電影拍攝過程多次延期，預(yù)算也超出很多，無論從成本和時間來看，這都是一個失敗的項目?？墒俏覀兌贾?，《泰坦尼克號》直到現(xiàn)在仍然是一個難以超越的票房神話。

由此可知，左圖的“傳統(tǒng)項目管理鐵三角”概念忽略了“價值”這一重要因素。右圖的“敏捷項目管理鐵三角”強調(diào)，團隊?wèi)?yīng)得到來自市場的真實反饋，以此來幫助敏捷團隊持續(xù)不斷地、盡早地交付有價值的軟件。

在追求價值交付過程中，我們越來越多的發(fā)現(xiàn)敏捷項目管理中至關(guān)重要的一環(huán)——人，也就是我們的團隊。價值是人創(chuàng)造的，是為人服務(wù)的，很多敏捷實踐都圍繞人展開。我們試圖找到一種通用的方法來最大限度地發(fā)揮人的能量。未來社會最有價值的人，是以創(chuàng)造力、洞察力、對客戶的感知力為核心特征的，我們相信這樣的團隊能創(chuàng)造最大的價值。

用戶故事

用戶故事(User Story)是敏捷開發(fā)的基礎(chǔ)，它從用戶的角度來描述用戶希望得到的功能。軟件開發(fā)是為了實現(xiàn)產(chǎn)品的商業(yè)價值，滿足用戶需求。只要需求足夠明確，所有人都了解需求的具體內(nèi)容是什么，團隊就能簡單有效地把需求轉(zhuǎn)化成可實現(xiàn)、可測試、能夠發(fā)布的代碼。為了實現(xiàn)這個目標(biāo)， 需要找到一種方法描述需求，讓所有的人都能對任務(wù)的范圍有一個共同的認(rèn)知。這樣團隊對任務(wù)完成會有一個共同的定義，不會出現(xiàn)“你做的不是我所要求的”、 “我忘了告訴你這個需求”等類似的問題。

因此就出現(xiàn)了用戶故事， 它描述了產(chǎn)品需求及商業(yè)價值，同時定義了一系列Acceptance Criteria(AC)。只有團隊完成的工作符合這一系列的AC時， 才真正完成了這個用戶故事。一個用戶故事通常包括三個要素：

角色：誰要使用這個功能。

活動：需要完成什么樣的功能。

商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值。

每個用戶故事可以有不同的展現(xiàn)形式，以下是其中一種：

作為一個<某種類型的用戶角色>

我要<達(dá)成某些目的>

只有這樣我才能夠獲取<商業(yè)價值>

所以只要將用戶故事確認(rèn)下來，那么這個用戶故事所要實現(xiàn)的功能、需求范圍、完成這個用戶故事所需要的工作量也就隨之確認(rèn)了。之后開發(fā)人員所要做的就是根據(jù)這個用戶故事的內(nèi)容進行開發(fā)，只有當(dāng)所有AC被覆蓋到，測試人員完成測試，發(fā)現(xiàn)所有功能是可測試的、可運行的，這個用戶故事就算完成了。

估算和迭代計劃

估算(Estimation)：團隊在動手開發(fā)一個用戶故事功能之前，應(yīng)當(dāng)對實現(xiàn)這個用戶故事所需要的工作量有清晰的認(rèn)識。如Martin Fowler所說，"Estimation is valuable when helps you make a significant decision"。只有當(dāng)團隊對達(dá)成一個目標(biāo)的工作量以及完成它之后的“收益”有了一個明確的認(rèn)知， 才能做出明智的決定。當(dāng)團隊在為工作排定優(yōu)先級、制定迭代計劃時，業(yè)務(wù)分析師需要知道每個用戶故事的成本，團隊成員需要知道每個用戶故事的價值。有很多種估算用戶故事工作量的方法，其中一種就是把完成這個用戶故事所需要的點數(shù)（根據(jù)用戶故事的復(fù)雜度估算）寫到這個故事卡上。估算可以幫助團隊以不同的方式，對實現(xiàn)即將開始的用戶故事、未來的架構(gòu)方向和代碼庫的設(shè)計，有更好的理解。一個迭代所能完成多少個點數(shù)是能估算出來的。也可以使用一些工具統(tǒng)計出過去每個迭代所完成的點數(shù)，比如燃盡圖。

只要整個團隊都一起參與進來共同協(xié)作，估算本身也可以變成一種很有意義的活動。它有助于團隊增進理解，并保證團隊每個人都對要交付的需求范圍和價值達(dá)成共識。讓評估變得更有趣的是，通常不采用簡單連續(xù)的數(shù)列，比如1，2，3，4，5等——而是采用一種近似菲波拉契數(shù)列的形式，像1，2，3，5，8，13等（就如《達(dá)芬奇密碼》里面看到的），這樣當(dāng)數(shù)字越大、相鄰數(shù)之間的間隔也越大，使得團隊更容易區(qū)分哪個故事更小、哪個更大。

在做迭代計劃(Iteration Planning)時，團隊需要從客戶價值維度和技術(shù)風(fēng)險的角度來排定優(yōu)先級。下圖中是常用的工具之一——需求優(yōu)先級矩陣。

迭代會議和功能演示

敏捷宣言里面有一條：客戶協(xié)作優(yōu)于合同談判。在敏捷團隊中有一個角色叫做業(yè)務(wù)分析師，業(yè)務(wù)分析師(BA)的核心職責(zé)是確保業(yè)務(wù)需求的清晰和透明，保證開發(fā)團隊對業(yè)務(wù)有足夠的理解，并將這些待完成的用戶故事按照優(yōu)先級排列出來，以任務(wù)卡的方式來驅(qū)動團隊的開發(fā)。

迭代會議(IPM)通常發(fā)生在每個迭代的第一天，團隊成員一起制定迭代計劃。這個會議由BA主持，大家一起同步幾個方面的內(nèi)容：

下一個迭代的用戶故事;

對下一個迭代的期望和計劃;

風(fēng)險的評估和總結(jié)。

不同的人對需求的理解是不同的，所有團隊成員都要明確用戶故事所有相關(guān)內(nèi)容、所要實現(xiàn)的功能、滿足哪些條件用戶故事才算完成。迭代會議的主要產(chǎn)出是下一個迭代中需要完成的用戶故事，這些用戶故事即為下一個迭代所要完成的主要目標(biāo)。

功能演示(Showcase)是敏捷開發(fā)流程中的又一個實踐，通常發(fā)生在每個迭代的最后一天，目的是演示可工作的軟件。團隊把一個迭代中開發(fā)好的功能給相關(guān)人員演示，并收集反饋，以便在下一個迭代中可以對變化作出快速響應(yīng)。

站會和用戶故事開卡

簡單地說，站會(Standup)是團隊在一起快速地開一個會(通常在物理墻前)，成員逐個更新自己的狀態(tài)。更新包含以下幾個方面：

昨天完成的工作；

今天計劃做的工作；

面臨什么阻礙，需要什么幫助；

自己手頭用戶故事的進展，是否存在技術(shù)風(fēng)險。

既然是快速的會議，站會的時間就不宜過長，10分鐘左右為佳。建議團隊成員站著開會，因為研究表明，當(dāng)人們坐著開會的時候，會議的時間會被無形中拉長——會議的重要目的是讓每個人在自己以及同事面前作出承諾，這個承諾是團隊之間的承諾。

這里有一些實踐原則：

團隊成員都要參加站會，輪流主持，誰遲到了都不等——儀式感很重要。

站會的時候，每位團隊成員的更新都是圍繞故事卡來進行。介紹一種有意思的實踐——使用Token(也就是使用一個實物作為”令牌”，準(zhǔn)備發(fā)言的人首先取得”令牌”，發(fā)言完成后將”令牌”傳給下一個人。令牌要醒目，可以是毛絨玩具，也可以是一頂帽子)。

用戶故事開卡(Story kick-off)：在每個用戶故事開發(fā)之前，要確保BA、DEV和QA對用戶故事理解一致。這個溝通活動通常由DEV講解這個用戶故事要完成的功能及AC，一旦發(fā)現(xiàn)任何疏漏，BA會及時補充。DEV有任何疑惑也需及時提出來，當(dāng)場確認(rèn)，使這些功能得以正確實現(xiàn)。在后續(xù)開發(fā)中如果碰到任何疑惑，也應(yīng)及時找BA了解清楚。QA會嚴(yán)格按照AC來驗收用戶故事。

代碼審查和回顧

代碼審查(Code Review) 開發(fā)團隊在完成每天代碼之后，會聚在一起評審當(dāng)天的代碼，這樣做有幾個好處：團隊經(jīng)過一天的高強度的思考與編碼，適當(dāng)?shù)赝Ｏ聛?，看看其他人寫的代碼，同時將自己的代碼講解出來，往往能意外地獲得一些靈感，或許能解決自己面臨的阻礙。

互相了解設(shè)計思路，更好的建議和思路重構(gòu)，提高代碼質(zhì)量；

及早發(fā)現(xiàn)潛在缺陷，降低事故成本：如果這個時候發(fā)現(xiàn)代碼的壞味道，和一些需要改進的地方，代碼審查結(jié)束后可以花少量時間作出更改；

促進團隊內(nèi)部知識共享。

回顧(Retrospective)：回顧會議的目的是通過新的溝通形式喚起大家對團隊的集體意識，指出團隊或個人在一段時間內(nèi)的不足并列出對應(yīng)的行動。持續(xù)而有效的回顧和反饋，可以保證團隊關(guān)心生產(chǎn)力和效率，了解團隊自身的不足和問題，這將成為團隊持續(xù)改進的起點。

回顧的關(guān)注點也多種多樣，除了“項目開發(fā)”之外，還可以關(guān)注“敏捷成熟度”、“團隊角色和職責(zé)”、“人員技能提升”等。在堅持回顧的同時，需要做的還有保證回顧的有效性。應(yīng)根據(jù)團隊建設(shè)目標(biāo)的發(fā)展變化，不斷調(diào)整回顧的關(guān)注點和形式，確?；仡櫮軌蛴嗅槍π缘匕l(fā)現(xiàn)團隊的缺陷并轉(zhuǎn)化為實踐。長期有效的回顧和正確的回顧產(chǎn)出，還能夠不斷提升團隊內(nèi)部的安全感和信任度。

回顧的形式和方法非常多，最常見的是“Well & Less Well”。

最大程度的可視化

看板源于精益生產(chǎn)實踐，敏捷將其背后的可視化管理理念借鑒過來，形成了具有自己獨特風(fēng)格的可視化管理工具。

在敏捷項目里，掛在墻上的“人人可見的大圖表”是一種普遍的實踐，它被用來共享項目的狀態(tài)并將之可視化。比如表示項目狀態(tài)的物理墻，這樣的物理墻通常包括三個元素：時間、任務(wù)和團隊。

除了表示項目狀態(tài)，項目團隊還會可視化其他的元素，比如團隊?wèi)?yīng)堅持的規(guī)則、項目上的經(jīng)驗分享以及項目的里程碑。

在ThoughtWorks這樣的扁平組織里面，存在著虛擬團隊和項目團隊。一般來說，通過有關(guān)聯(lián)的團隊和個人之間相互協(xié)商，可以識別出未來一段時間里各自的活動，以及相應(yīng)的、對成功的衡量方式，然后將其可視化出來，每段時間再回顧和調(diào)整一次。有了這樣的可視化，團隊會更加容易對齊目標(biāo)，并不斷培養(yǎng)和加深責(zé)任感。

可視化帶來的好處是：

日常工作透明，將迭代過程中所有的故事卡可視化出來，團隊成員可以隨時知道當(dāng)前需要完成的工作以及將要完成的工作。由于人對視覺反映很靈敏，可視化的故事墻能立刻聚焦團隊的注意力。

將迭代過程中遇到的問題暴露出來，可以幫助團隊成員在工作中一起積極討論解決方案。

團隊也可以根據(jù)現(xiàn)在的進度以及遇到的問題，了解需要哪些幫助，更好的分配資源，減少開發(fā)進度被滯后的風(fēng)險。

溝通計劃

敏捷里面的自組織團隊其實是敏捷的結(jié)果，而不是先決條件。實施敏捷的過程也是打造自組織團隊的過程。每個團隊成員在面對做什么、怎么做的問題時，也會以自組織的方式去解決。在每一天，團隊中的每一個人都要與團隊中的其他人保持協(xié)調(diào)。為了保持同步，我們會創(chuàng)造基于敏捷實踐的溝通機會，這個也是實施敏捷的過程之一。

在ThoughtWorks有一個非常有名的活動叫Inception。Inception是啟動軟件設(shè)計和交付項目的方法，通過集中式、互動式的設(shè)計工作坊，幫助客戶在最短時間內(nèi)達(dá)成對項目范圍的一致，快速進入項目交付。而Inception的一個產(chǎn)出就是溝通計劃(Communication Plan)。比如在這個溝通計劃中會討論：

以什么頻率、什么形式作項目的更新，比如說每周五以周報的形式作一些關(guān)鍵信息的更新。

站會和迭代會議什么時候召開，需要邀請那些人，比如說業(yè)務(wù)負(fù)責(zé)人，技術(shù)負(fù)責(zé)人等等。

以下內(nèi)容都會在溝通計劃中定義清楚:

寫在最后

回到文章開頭所提出的三個問題，在這次的直播分享中，我是這樣將敏捷實踐和解決方案對應(yīng)起來的：

團隊目標(biāo)不一致

用電子墻和物理墻展示用戶故事、需求全景圖、項目進度燃盡圖；

通過迭代會議和功能演示會議對齊迭代計劃，項目進度、識別項目風(fēng)險。

團隊成員不熟悉

基于敏捷實踐，創(chuàng)造更多的溝通機會，比如回顧會議、代碼審查和站立會議。通過不斷地創(chuàng)造這樣的溝通機會讓團隊成員更加默契。

信息發(fā)布不順暢

共享信息，制定溝通計劃；

最大程度的可視化。

文中提到了很多類型的敏捷實踐，這些實踐需要貫穿到團隊的日?；顒又腥ィ掷m(xù)的實施和改進。行為心理學(xué)研究認(rèn)為：21天以上的重復(fù)就會形成習(xí)慣。任何一個動作，重復(fù)21天就會變成習(xí)慣性的動作；任何一種想法，重復(fù)21天、或者重復(fù)驗證21次，就會變成習(xí)慣性的思維方式；任何一種信念或者一種有益的實踐，經(jīng)過團隊持續(xù)驗證，它一定會成為團隊的信念和實踐。

劍道中有這樣一個心訣：守、破、離。

守：最初階段須遵從老師教誨，認(rèn)真練習(xí)基礎(chǔ)，達(dá)到熟練的境界

破：基礎(chǔ)熟練后，試著突破原有規(guī)范讓自己得到更高層次的進化

離：在更高層次得到新的認(rèn)識并總結(jié)，自創(chuàng)新招數(shù)、另辟新境界

項目管理者中的大多數(shù)人都處于“守”的階段：他們學(xué)習(xí)、吸收了前人的項目管理經(jīng)驗，帶領(lǐng)自己的團隊有序地開展項目交付工作；但是他們經(jīng)常困惑于某些在管理中反復(fù)出現(xiàn)的問題，苦于找不到有效的解決方法，不得不在新的項目中重復(fù)之前的困惑；

有的項目管理者已經(jīng)達(dá)到了“破”的層次：他們能夠以全局優(yōu)化的角度去總結(jié)自身項目管理的經(jīng)驗，并通過學(xué)習(xí)、分享及各種交流平臺去開闊眼界、拓寬思路，借鑒或改良項目管理的方式方法，使之更適用于團隊；

而所有項目管理者的最高目標(biāo)則是“離”：隨著項目經(jīng)驗的不斷積累，他們對管理的思考日漸加深，對項目管理有了新的、更高層次的、屬于自己的獨特認(rèn)知，并將其應(yīng)用在實踐中，獨辟蹊徑，使整個項目管理思路煥然一新。

希望越來越多的項目管理者能夠達(dá)到更高的階段。這是我們在項目管理中不變的追求。

閱讀：項目管理中的敏捷實踐

本文作者萬學(xué)凡，ThoughtWorks首席咨詢師，武漢。作者保留本文一切權(quán)利，未經(jīng)許可請勿轉(zhuǎn)載。