CSDN：在你的工作生涯中，前期是在創業公司，後來是大公司，有著一套自己的敏捷開發模式，能夠談談在你現在使用的敏捷開發工具或方法？

黃勇：敏捷這個話題大家一直都在談論，也有很多關於敏捷的工具或方法，我個人比較傾向於 Scrum。我理解的敏捷其實是一種思想，Scrum 是對讓這個思想落地的一個參考。也就是說，我們大可不必完全拘泥於 Scrum 定義的規範，只需要參考它並結合自身的條件做適當調整即可。比如說，每日站會這個環節就非常重要，不管是放在每天上午，還是放在每天下午，總之最好要有固定的週期。此外，每次 Sprint（迭代）結束後除了有評審會以外，Scrum Master 不要忘記對本次 Sprint 做一個回顧與總結，哪些是本次迭代中做的好的地方，哪些是做的不好的，再對比上次迭代的的結論，哪些是有改進的，哪些是新的問題。

Scrum 提供了三類角色，分別是：Product Owner（一般由產品經理擔任）、Scrum Master（一般由開發經理擔任）、Scrum Team（包括開發與測試人員），其中，Scrum Master 的角色至關重要，對專案的成敗起決定性作用。

阿里巴巴也在廣泛使用 Scrum 敏捷開發模式，而且整個專案幾十人都可以用 Scrum，只是首先需要將整個團隊拆分成若干小團隊，保證每個小團隊按照 Scrum 進行操作，此外，再將每個小團隊的 Scrum Master 召集在一起，再做一輪 Scrum，這就是所謂的 Scrum of Scrum。過程稍微複雜一點，但可以將敏捷用於更大的團隊規模，並能保證敏捷的效果。

CSDN：你認為Scrum Master 的角色至關重要，對專案的成敗起決定性作用。那敏捷開發中由產品經理擔任Scrum Master會有什麼問題？

黃勇：我個人不太建議由產品經理來擔當Scrum Master，原因如下：

1. Scrum Master 關注的是專案開發視角，而產品經理關注的是產品功能視角，兩者關注的視角是不一樣的。
2. Scrum Master 需要有一定的技術開發功底，需要對開發工作量進行評估，也需要對技術實現進行評審，可能還會有一定的編碼工作，而具有技術功底的產品經理畢竟太少了，即便有的話，可能對技術方面也不會太深入。
3. 需要有一個人，他來對整個產品負責，這個人就是Product Owner，該角色最好由產品經理來擔任。

CSDN：敏捷開發過程中測試團隊的職責和產出是什麼？

黃勇：在敏捷開發過程中，我認為測試團隊的職責有以下幾點：

1. 根據產品需求，定義測試用例。
2. 針對測試用例進行功能測試，並將測試的結果反饋給開發人員。
3. 負責搭建系統執行所需的環境，包括軟體安裝、資料初始化等。

CSDN：除了Scrum，還有XP、CM、FDD、ASD、DSDM等敏捷開發方法，如何去選擇一個合適的敏捷開發工具或者方法呢？

黃勇：敏捷開發方法有很多，不僅僅只有Scrum 一種，其實不妨相互借鑑，再結合自身的特點，定義一套適合自己的敏捷開發方法。例如XP 中所提倡的結對程式設計、持續整合、測試驅動等，這些都是很好的方法，值得借鑑。包括看板也是一個很不錯的工具，可以結合Scrum 來工作。

CSDN：從部落格上，你也研究過「使用看板進行敏捷開發」，能不能分享你的研究成果？

黃勇：敏捷開發工具“看板”,該詞彙來自於島國，當我看到看板的英文時，我真的驚呆了，看板竟然就是 Kanban？！

我們可以結合 Scrum 與 Kanban，讓專案管理更加有效，讓資源分配更加合理，讓績效考核更加公平！

• 對於專案經理而言，最擔心的就是專案進度不可控，不知道每位開發人員具體的工作進度，有了 Kanban 一切都是那麼地清晰。
• 對於開發經理而言，最擔心的就是資源分配不合理，忙的人忙死，閒的人閒死，有了 Kanban 一切都是那麼地自然。
• 對於開發人員而言，最擔心的就是績效考核不公平，“憑什麼我做的比他多，拿的工資卻比他少？不公平啊！”有了 Kanban 一切都是那麼地公平。

可見，專案經理、開發經理、開發人員擁有了 Kanban，也就擁有了和諧與快樂！

那麼 Kanban 到底是什麼呢？我們先來看看這張表格吧：

下面我們來理解一下這個表格吧！

• 這個表格有 5 列：Backlog（原始需求）、Selected（被選中的需求）、Develop（開發階段）、Deploy（部署階段）、Live（上線階段）
• 其中 Develop 階段包括 2 個子階段：Ongoing（進行中）、Done（已完成）
• 包括 3 中角色：產品經理（紅色小人）、開發人員（藍色小人）、部署人員（綠色小人），其實還有專案經理，只是他/她貫穿於始終，所有就沒有畫出來了。

在 Backlog 中放置了許多小卡片，它們在 Kanban 中被稱為 WIP（Work In Process，在製品）。對於產品經理而言，WIP 是需求，而對於開發人員與部署人員而言，WIP 卻是任務。

實際這些 WIP 卡片上都帶有一些文字描述，包括：標題、描述、優先順序等資訊。

需要注意的是，Selected、Develop、Deploy 下方有一個數字，該數字表示此階段中最多可以放置的 WIP 數量。例如，在 Selected 中最多隻能放 2 個 WIP；在 Develop 中（包括它的子階段）最多隻能放置 2 個 WIP。這裡的數字只是一個示例，具體多少可根據團隊實際情況而定。有一個經驗公式可以參考“WIP 上限 = 團隊規模 * 2 - 1”，減 1 表示大家需要協作，例如：4 人的團隊，WIP 上限是 7。

也許有人會提出，為什麼沒有 Test 階段？—— 這個可以有，這裡只是一個示例而已，你不妨自行加上去。

對於多個專案而言，可以在這張表格中新增更多的泳道（行），每一行相當於一個專案，所有的專案進度清晰明瞭。

好！繼續我們的 Kanban，有意思的事情即將發生！

產品經理挑選了 2 個 WIP 到 Selected 中，此時，由開發經理決定該任務的技術難度，並由專案經理將任務分配到指定的開發人員，也可將同一個任務分配給兩個人，讓他們去結對程式設計。

開發人員（架構師與程式設計師）可對 Selected 中的需求進行工作量評估，可採用投票的方式進行，最終給出一個合理的評估值，整個估算過程，專案經理無需參與，主要是開發人員共同完成。

開發經理可以對任務設定一個“分值”，這個分值可直接影響到後續的績效考核，所以對大家來說，這個分值是公開可見的，誰做的多，誰做得少，一目了 然。當然，開發人員也可以主動承擔具有更具挑戰的任務（為了鍛鍊自己，也為了多拿點錢），但任務分配的決定權始終在專案經理手中。

現在假設 A、B 兩個任務已經分別被不同的開發人員處理了，那麼這些任務就應該移動到 Ongoing 中，同時，產品經理可以從 Backlog 中挑選出 2 個優先順序較高的需求到 Selected 中。這樣就保證 Selected 與 Develop 都達到了 WIP 的上限。

有人已經把 A 做完了，那麼 A 就可以移動到 Done 中了。隨後，部署人員就可以開始幹活了。

部署人員就可以將 A 從 Done 中移動到 Deploy 中，表示部署人員正在做這件事情。同時，做完了 A 任務的開發人員可以再做其它新任務，只需從 Selected 中移動到 Ongoing 中，移動這件事情不是開發人員隨意操作的，而是有專案經理負責的。產品經理髮現 Selected 中只有一個 D，就可以考慮放入一些新的需求了。

此時，部署人員遇到了問題，發現 A 部署的時候總是報錯，跑不起來了。同時，其他開發人員也完成了 B 任務。

完成了 B 任務的開發人員本來是可以做新需求的，但專案經理髮現 Develop 中只能放 2 個任務，所以肯定是後面的階段出現了問題，導致整個流程受阻了。專案經理可以靈活排程人力資源，集中火力解決現在所遇到的問題。

所以專案經理不得不放棄新的任務，去讓開發人員去幫助部署人員來解決問題。此時，其他的開發人員還在進行 C 任務。

部署的問題還沒來得及解決，此時 C 任務也完成了，同時，產品經理也放入了新的 K 需求，確保 Selected 這個水池是裝滿水的。

整個部署問題看起來比較搞人，所有的開發人員全都上陣了，集中更多人的智慧，解決這個棘手的問題。此時，產品經理不能放入更多的需求，由於此時 Selected 已經滿額了。其實，開發人員面對太多的需求時，往往都會倍感壓力，身心憔悴。

看來這個部署問題，確實夠折騰的，連產品經理都過來了湊熱鬧了。但他或許不懂技術，但多個人多個頭腦吧，正所謂“當局者迷，旁觀者清”，最終經過大家的努力，肯定會攻克這座碉堡！

幾天之後，Kanban 流程依舊是穩定的，大家分工協作，人力資源合理利用。大家是一個團隊，目標就是把專案做好，不會因為自己的事情做完了就閒置了。

我們不妨將這張表格貼到牆上去吧！讓每個員工都可以看到，讓過路的老闆們也可以看到我們的辛苦努力，這確實是一種非常好的專案管理方法！

CSDN：一個成功的專案，離不開每個人的努力，能夠分享下你曾經的專案管理經驗？

黃勇：給大家提出以下 10 點建議及其目標：

1. Sprint 第一天，需要將目標定義清楚，並讓團隊所有人都知道「確保建立一致的目標並使之明確」；
2. 若出現需求變更，則優先排到下次迭代，特殊情況需特殊處理「確保本次迭代可以按時完工」；
3. Scrum Master 將迭代中的需求分解為任務，每個任務只能有一個任務負責人，且不超過一個人天「確保每日任務可評估」；
4. 讓 Product Owner 直接與相關開發人員確定需求，Scrum Master 需一同參與「確保需求與實現不會發生偏差」；
5. 每日定時站會，時長不超過 15 分鐘，規模不要太大「確保任務完成情況與計劃保持一致」；
6. 每日進行一次程式碼評審，由 Scrum Master 負責，並在次日將評審結果通知給相關開發人員「確保程式碼質量不要下降」；
7. 各個團隊的 Scrum Master 保持每日溝通一次，時間不要超過 15 分鐘「確保專案管理不會出現風險」；
8. 每次迭代結束，讓大家稍微放鬆一下，可提供一些團隊活動，比如聚餐「確保團隊能夠更加凝聚」；
9. Scrum Master 需要給團隊一些承諾，比如專案獎金或特殊福利等「確保團隊更加有激情」；
10. 對於情緒異常的員工，Scrum Master 需及時與其溝通「確保不要讓一個人的情緒影響整個團隊」；

此外，作為專案管理者，需要不斷在團隊中加強以下 6 點文化：

1. 方向一致
2. 當面溝通
3. 全情投入
4. 充分信任
5. 說到做到