答疑：Scrum和PMP，該學哪個？Scrum和Kanban，該學哪個？

問題

有朋友向我咨詢關于認證。他們問:"Scrum和PMP，該學哪個？Scrum和Kanban，該學哪個？” 我這樣回答：“你的業務環境是怎樣的？你需要解決什麼問題？你希望在什麼方面有所改善？一把鑰匙開一把鎖。業務環境不同，需要解決的問題不同，需要采用的方法也不同。”

軟體開發活動包括從創新型産品開發到現有産品維護和支援等各種工作，我們逐個分析。

分析

創新型産品

創新型産品開發的業務環境是不可預測性大于可預測性。例如，産品需求不明确，能夠明确的通常隻是産品的願景，一個大概的方向和藍圖。産品具體要有哪些特性，不同的人有不同的想法，很難說的清。在産品開發的過程中，客戶需求又存在很多變數，很難說的準。客戶滿意的産品到底是個什麼樣子？等到産品開發完成了，客戶真正滿意了，我們才能知道，"哦，原來客戶想要的産品就是這個樣子！”

開發令客戶滿意的産品，不能靠碰運氣，恰好猜中客戶的需求，就像中大彩一樣，是及其理想的情況，也是及其少見的情況。我們需要解決的問題是，如何才能持續的獲得到客戶對于産品的實際體驗，讓客戶理想的産品的模樣逐漸浮現出來。是以我們需要采用疊代開發的方法，每個疊代産出可以工作的軟體，讓客戶體驗我們的産品，給我們提出回報意見。像做科學實驗一樣，我們首先假設客戶喜歡某些産品特性，去探索一下。然後通過讓客戶體驗，去感覺客戶喜歡哪些産路特性，不喜歡哪些産品特性。最後根據這些感覺及時調整方向。就這樣重複"探索一感覺一調整"的循環，摸着石頭過河，走一步看一步，收集越來越詳實的客戶回報，進而開發出令客戶滿意的産品。Scrum就是這樣一種開發方法，特别适合作為開發創新型産品的開發方法。

現有産品維護和支援

現有産品維護工作包括修複缺陷，為客戶添加一些定制化的小特性，也許還要優化軟體性能。這樣的業務環境，需求是明确的、具體的，不需要"探索一感覺一調整"這麼麻煩。這種業務環境，Scrum可以用，但不是最優的解決方案。缺陷什麼時候被發現，客戶什麼時候要求添加新特性，這些都在事前難以預料，産品用着用着，發現了缺陷，就報告到開發團隊這邊了。使用者靈機一動，說我想添加一個這樣的特性，就要求開發團隊添加。是以從維護和支援邀請到來的時間上來看，不可預測性大于可預測性。

我們需要解決的問題是，怎樣用最低的成本，提供最優質的維護和支援服務。所謂最優質的維護和支援，包括但不限于，優先級方面，重要客戶的重要服務邀請，要優先響應；時間方面，缺陷修複的快，客戶要求響應的快。然而，在不增加成本的情況下，人少事多，怎麼才能保證優先級，提高響應速度呢？我們需要做到至少2點：首先，工作流程可視化。有多少個邀請，哪些優先級最高，要能夠一眼看的見。一個支援邀請在哪個環節堵住了，我們很快就可以發現，采取措施解決它，進而保證它可以很快被完成。第二，控制進行中的任務的數量，讓開發團隊可以專注于響應優先級高的任務。一個人同時承擔多個任務，在多個任務中間切換，會造成很大的精力上的浪費。開發者也分不清并行的任務中，哪個是重點，同時做多個任務，哪個也做不完。第三，持續優化現有的工作流程。這就像一個管道，如果我們把維護人力比作管道口徑，把傳遞給客戶的價值比作出水量，那麼如果不能增加口徑，又想獲得更高的出水量，我們要想辦法加快水流的速度。看闆就是這樣一種像管道一樣的靈活開發方法，特别适合用于産品維護和支援。

跟風産品

所為跟風産品，就是國外有個什麼新軟體，國内照抄。競争對手有個什麼新産品，自己照抄。這樣的業務環境，可預測性高。具體的說，産品需求在開發初期就能明确，産品開發的技術可以借鑒别人的，在開發過程中，需求變更比較少，大部分事情是确定的，那麼瀑布是最簡單實用的方法。PMP對傳統軟體管理方法講的很透徹，學瀑布的話，從PMP開始最好。

總結

PMP講到的項目管理方法也是通用的原則，當然近來PMP-ACP 也出現了。我就是先學的PMP，然後學Scrum，再學Kanban。管理的基本原則是相通的。這就好像一個公園有東、南、西 、北四個門，從哪裡入門都可以，重要的是在公園裡漫步，欣賞風景的過程。無論學什麼，最後都要落實到“學以緻用”。

回到開頭的問題。Scrum和PMP，該學哪個？Scrum和Kanban，該學哪個？你現在明白了，業務環境不同，需要解決的問題不同，需要采用的方法也不同。Scrum和Kanban，哪個更好？Scrum是個循環，适合用于創新型産品開發；看闆是個管道，适合用于産品維護和支援。一個環兒，一個管兒，各有各的好。

本文作者書山有伴，由ShineScrum捷行編輯