敏捷專案管理是專案成本管理和專案交付管理的一門管理藝術，為啥這麼說呢？每一個人都會唱歌，但只有唱得好的人才能是歌手，才能是演唱家，而專案管理也恰恰與之相似，看似一件簡單的社體活動，其實複雜多變，過程坎坷，管理容易，管好難。每一個專案，過程就像中國神話西遊記一樣，歷經無數坎坷，只有懷有堅定信念，才能取得真經。

　　慶幸的是，經過前輩的披荊斬棘，無數的歷練，有了當今比較流行的軟體專案管理理論，敏捷專案管理。今天就總結一下敏捷軟體專案管理裡面兩個比較出色的方法論，極限程式設計和Scrum管理。極限程式設計強調可適應性而不是可預測性。極限程式設計認為軟體需求的不斷變化是很自然的現象，是軟體專案開發中不可避免的、也是應該欣然接受的現象。極限程式設計相信，更有能力在專案週期的任何階段去適應變化，將是更加現實更加有效的方法。其最終目的，降低因需求變更而帶來的成本，是軟體專案管理中對成本管理

　　極限程式設計中有五個核心價值：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、尊重（Respect），時刻牢記這五個核心價值，就能很好的完成極限程式設計專案管理。

　　談完了極限程式設計，再談談敏捷Scrum專案管理，在談Scrum之前，先給大家講一個故事：

一天，一隻雞散步時遇見了豬。

雞對豬說：“嗨，我們合夥開個餐廳吧。”

豬說：“好啊，那準備取什麼店名呢？”

雞說：“要不，就叫火腿和雞蛋吧。”

豬直接拒絕了：“那可不行。我要割肉，你只要下蛋。這樣下去，我遲早要完蛋。”

　　開心一樂之後，細細體會，軟體專案管理未嘗不是一場專案中不同角色之間利益平衡的問題。Scrum管理，強調把客戶拉進專案組，成為一個整體，大家都有共同的故事，為了共同的故事，一起努力，當大家的目標一致的時候，專案組整體效率往往會出現意想不到的效果，這就是Scum 專案管理的精髓。

　　Scrum 專案管理，更像一個故事的演繹，專案首先需要劃定三個角色，產品負責人PO（Product Owner），僕人型領導SM（Scrum Master），開發團隊（Team）。PO往往有專案的甲方核心負責人主演，SM由乙方專案領導負責主演。

　　產品負責人PO：他負責在限定期限內擬定可能的最有價值的產品，簡單講，就是提前規劃好需求故事，評價每個需求故事的價值和優先級別。然後通過管理流向團隊的產品待辦事項，該角色維護產品待辦事項列表（Product Backlog），並確保大家都知道故事的內容以及優先順序。該角色比較特殊，可能需要其他人的支援，但只能是一個人。

　　僕人型領導SM：他負責幫助PO理解如何建立和維護產品故事列表（Product Backlog）。確保團隊在Sprint結束時能夠完成故事，他和開發團隊一起發現並實施技術實踐。SM的另一個職責是保障開發團隊前進的障礙已被清除了。這些障礙可能來自團隊的外部，比如缺乏另一個團隊的支援，也可能來自內部，比如PO負責人不知道如何恰當地準備產品待辦事項列表。

　　Scrum專案的角色已定義完成，就開始故事的演繹。PO是導演，他會提前準備Product Story劇本，每次迭代計劃會議都會用到，每個場景都由PO進行管理，PO掌控著Product Backlog，並由他來決定每個Sprint週期需要迭代的Sprint Backlog，Sprint Backlog的開啟和關閉在每個Sprint Planning Meeting迭代會議上討論的，建立和關閉都是由PO決定的，由SM負責監督和督促Sprint Backlog的推進，促成專案組交付物的產出。

　　PO和SM還要定期的組織專案組進行Review Meeting，回顧專案的交付物演示，SM負責專案回顧和交付物演示，也可以由專案組開發自己進行交付物演示。

　　最後要演繹的就是SM每天主持的站會Daily Stand Up Meeting，PO理論上是需要一起參加，但往往只是理論。SM確保Team一定要站著開專案晨會，確保每次會的時間不會太長，快速的溝通專案組上一天遇到的問題和本天的開發計劃，以及需要的專案資源。

　　總結，Scrum專案管理，需要和客戶扭打在一起，將大的任務拆解成可持續交付的小任務，保證專案的持續交付，出現問題可以及時迭代，風險共擔。在Scrum的實踐過程中，Sprint Planning Meeting最好是一週或者兩週開一次，Sprint 任務為每週可以完成的任務。

　　最後推薦Scrum專案管理使用Azure DevOps工具的Azure DevOps Boards這個工具管理，好用、方便、標準模板。