本文作者將以自己所在公司的項目經(jīng)歷為例，講述公司日常交付項目中主要使用的敏捷實踐是如何幫助團隊實現(xiàn)最大價值的。雖然文章內(nèi)容對象是以項目經(jīng)理展開敘述，但項目管理中的敏捷實踐值得我們產(chǎn)品經(jīng)理去學習。enjoy~

作為項目經(jīng)理，我們經(jīng)歷了不同的項目，卻總是受限于相似的困局。比如以下三個典型難題：

• 團隊目標不一致
• 團隊成員不熟悉
• 信息發(fā)布不流暢

倘若我們?nèi)斡蓡栴}存在，而不在每次項目中進行總結(jié)和提煉，就會反復的徘徊于豐滿理想與骨感現(xiàn)實當中。

敏捷思想和實踐能夠為我們提供一種可能性，幫助我們解決在項目交付過程中遇到的具體難題。

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

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

（圖片來自：http://t.cn/R9IjtIs）

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

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

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

我曾在一次培訓中聽到同事談到敏捷團隊與西游團隊的相似性，他認為唐僧師徒可以被看作敏捷中的全功能團隊：團隊有共同的目標——取到真經(jīng)；他們歷經(jīng)了九九八十一難，好比九九八十一個迭代，每次打怪成功都是完成了一次交付；在不斷迭代的過程中，這個團隊不斷地收集反饋、持續(xù)改進，一步步地完成了最后的目標。取到了真經(jīng)，意味著完成了項目的交付，同時使得團隊能力得到質(zhì)的提升。這是一個美妙的結(jié)果。

項目成果的交付和團隊能力的提升，這是項目經(jīng)理在項目管理中最希望達成的目標。 傳統(tǒng)項目管理的定義是：“在有限資源限定的條件下，實現(xiàn)或超過設定的需求和期望”。一句話概括了傳統(tǒng)項目管理的鐵三角：需求是范圍，資源包括時間和成本。

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

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

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

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

下文將以我所在公司的項目經(jīng)歷為例，講述公司日常交付項目中主要使用的敏捷實踐是如何幫助團隊實現(xiàn)最大價值的。

用戶故事

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

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

• 角色：誰要使用這個功能；
• 活動：需要完成什么樣的功能；
• 商業(yè)價值：為什么需要這個功能，這個功能帶來什么價值。

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

作為一個<某種類型的用戶角色>，我要<達成某些目的>，只有這樣我才能夠獲取<商業(yè)價值>。

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

估算和迭代計劃

估算(Estimation)：團隊在動手開發(fā)一個用戶故事功能之前，應當對實現(xiàn)這個用戶故事所需要的工作量有清晰的認識。如Martin Fowler所說，”Estimation is valuable when helps you make a significant decision”。只有當團隊對達成一個目標的工作量以及完成它之后的“收益”有明確的認知， 才能做出明智的決定。

當團隊在為工作排定優(yōu)先級、制定迭代計劃時，業(yè)務分析師需要知道每個用戶故事的成本，團隊成員需要知道每個用戶故事的價值。有很多種估算用戶故事工作量的方法，其中一種就是把完成這個用戶故事所需要的點數(shù)（根據(jù)用戶故事的復雜度估算）寫到對應的故事卡上。估算可以幫助團隊以不同的方式，對實現(xiàn)即將開始的用戶故事、未來的架構(gòu)方向和代碼庫的設計，有更好的理解。一個迭代能完成多少個點數(shù)是能估算出來的。也可以使用一些工具統(tǒng)計出過去每個迭代所完成的點數(shù)，比如燃盡圖。

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

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

迭代會議和功能演示

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

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

• 下一個迭代的用戶故事；
• 對下一個迭代的期望和計劃；
• 風險的評估和總結(jié)。

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

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

站會和用戶故事開卡

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

• 昨天完成的工作；
• 今天計劃做的工作；
• 面臨什么阻礙，需要什么幫助；
• 自己手頭用戶故事的進展，是否存在技術風險。

既然是快速的會議，站會的時間就不宜過長，10分鐘左右為佳。建議團隊成員站著開會，因為研究表明，當人們坐著開會的時候，會議的時間會被無形中拉長。

這里有一些實踐原則：

• 團隊成員都要參加站會，輪流主持，誰遲到了都不等——儀式感很重要。
• 站會的時候，每位團隊成員圍繞故事卡進行更新。介紹一種有意思的實踐——使用Token(也就是使用一個實物作為”令牌”，準備發(fā)言的人首先取得”令牌”，發(fā)言完成后將“令牌”傳給下一個人。令牌要醒目，可以是毛絨玩具，也可以是一頂帽子)。

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

代碼審查和回顧

代碼審查（Code Review） 開發(fā)團隊在完成每天代碼之后，會聚在一起評審當天的代碼，這樣做有幾個好處：

• 團隊經(jīng)過一天高強度的思考與編碼，適當?shù)赝Ｏ聛恚纯雌渌藢懙拇a，同時將自己的代碼講解出來，往往能獲得一些意外的靈感，或許能解決自己面臨的阻礙；
• 互相了解設計思路，獲得更好的建議和進行思路重構(gòu)，提高代碼質(zhì)量；
• 及早發(fā)現(xiàn)潛在缺陷，降低事故成本：如果這個時候發(fā)現(xiàn)代碼的壞味道和一些需要改進的地方，代碼審查結(jié)束后可以花少量時間作出更改；
• 促進團隊內(nèi)部的知識共享。

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

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

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

最大程度的可視化

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

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

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

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

可視化帶來的好處是：

• 日常工作透明，將迭代過程中所有的故事卡可視化出來，團隊成員可以隨時知道當前需要完成的工作以及將要完成的工作。由于人對視覺反應更靈敏，可視化的故事墻能立刻聚焦團隊的注意力。
• 將迭代過程中遇到的問題暴露出來，可以促進團隊成員在工作中一起積極討論解決方案。
• 團隊也可以根據(jù)現(xiàn)在的進度以及遇到的問題，了解需要哪些幫助，更好的分配資源，減少開發(fā)進度被滯后的風險。

溝通計劃

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

在ThoughtWorks有一個非常有名的活動叫Inception。Inception是啟動軟件設計和交付項目的方法，通過集中式、互動式的設計工作坊，幫助客戶在最短時間內(nèi)對項目范圍達成一致，快速進入項目交付。而Inception的一個產(chǎn)出就是溝通計劃(Communication Plan)。比如在這個溝通計劃中會討論：以什么頻率、什么形式作項目的更新，比如說每周五以周報的形式作一些主要信息的更新；站會和迭代會議什么時候召開，需要邀請哪些人，比如說業(yè)務負責人，技術負責人等等。

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

寫在最后

回到文章開頭的部分，我認為可以將敏捷實踐和解決方案做如下對應：

團隊目標不一致

• 用電子墻和物理墻展示用戶故事、需求全景圖、項目進度燃盡圖；
• 通過迭代會議和功能演示會議對齊迭代計劃，項目進度、識別項目風險。

團隊成員不熟悉

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

信息發(fā)布不順暢

• 共享信息，制定溝通計劃；
• 最大程度的可視化。

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

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

• 守：最初階段須遵從老師教誨，認真練習基礎，達到熟練的境界
• 破：基礎熟練后，試著突破原有規(guī)范讓自己得到更高層次的進化
• 離：在更高層次得到新的認識并總結(jié)，自創(chuàng)新招數(shù)、另辟新境界

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

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

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

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

作者：萬學凡，ThoughtWorks咨詢師，資深項目經(jīng)理，擁有豐富的項目管理經(jīng)驗和行業(yè)經(jīng)驗，現(xiàn)任武漢分公司負責人。業(yè)余喜歡登山和讀書。

本文由 @ThoughtWorks （微信公眾號：“思特沃克”） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。