風險，一般來說會是我們預估的，可能會發(fā)生的“問題”。而 問題 ，則是已經出現(xiàn)并且放在你面前的麻煩事。不管你做任何事，做任何項目，風險有可能發(fā)生，也有可能不會發(fā)生，但問題，你一定會遇到。有的問題在成為問題之前不一定會是風險，因為可能你都沒有察覺到它，它就出現(xiàn)了。因此，我們更要關注問題應該如何解決。
在 精益 和 敏捷計劃 中，我們都提到過 持續(xù)改進 這個東西。它本身就被認為是一種解決問題的有效方式。我們的 迭代沖刺 ，都會在結束的時候有 評審 和 回顧 會議。通過這些會議，我們就能夠發(fā)現(xiàn)潛在的問題，這樣就可以解決在沖刺迭代中臨時處理問題的需求。除此之外，這些也是我們保存經驗和教訓的好工具，通過這些經驗教訓的學習記錄，也可以為我們提供了解自己的長處和短處的一個渠道，可以讓我們確保類似的問題不在發(fā)生。
這個詞的意思就是“變得更好”。說白了，就是我們講的 持續(xù)改進 的意思。Kaizen 涉及每一個人、每一環(huán)節(jié)的連續(xù)不斷的改進，從最高的管理部門、管理人員到工人。Kaizen 實際上也是一種生活哲學，它假設我們應當經常改進我們生活的每個方面。
在團隊工作中，我們會關注的是對團隊的鼓勵——正在做這項工作的人——頻繁地實施小的、增量的改進。這種方法其實是基于另一個非常出名的管理學理論 PDCA 循環(huán)。
除了 PDCA 之外，我們在它的邊上還看到了一個敏捷環(huán)。在這兩個環(huán)中，PDCA 代表著開發(fā)任務的維持，而敏捷環(huán)代表著學習與改善。其實每一個迭代，我們都可以看成是在進行著一個 PDCA 和 敏捷環(huán) 的循環(huán)。甚至可以說，敏捷中的迭代概念就是它們倆的一種實踐表現(xiàn)。
每個迭代都有改進的感覺怎么樣？不過在敏捷中，一個迭代進行一次持續(xù)改進還是太慢了，我們更提倡的是每一天都會進行改進，而不是在一個沖刺之后。通過什么呢？每日站會 以及 知識型團隊 的自我學習成長。
敏捷的持續(xù)改進會在很多個層級上進行，比如說編碼層面上的 結對編程 。每日站會 上團隊成員對遇到的問題的陳述。沖刺結束之后的評審、回顧會議等等。它們一起組成了多層級的改進，敏捷就是在這樣的一個框架下，不斷改進優(yōu)化的一個項目管理框架。
價值這個東西真的已經說得夠多了，但是，注意了，在 持續(xù)改進 這里我們依然又再次見到了它。想想吧，上篇文章在風險中我們剛說完，在這里就又見到了。價值，真的是敏捷的核心啊。
價值流程圖（VSM），就是通過優(yōu)化每一個流程中的環(huán)節(jié)，消除浪費，為客戶提供更優(yōu)的價值。它包括如下的步驟：
識別需要分析的產品或服務
創(chuàng)建目前流程的價值流，識別步驟、排序、延遲、信息流
評審找出的流程中的延遲，浪費和約束
為未來流程創(chuàng)建新的價值流，移除和減少延遲、浪費和約束
創(chuàng)建路線圖
規(guī)劃流程進行再次訪問，以持續(xù)優(yōu)化
價值流程圖來源于傳統(tǒng)制造業(yè)，有興趣的同學可以自己查閱相關的資料并嘗試繪制我們自己的敏捷價值流程圖。
接下來我們來看一套問題的解決流程。這個解決問題的流程是一個比較通用的一般流程，適合于大部分問題的解決。
陳述問題。要清楚明白地說明這個問題，有時間、地點、發(fā)生時的環(huán)境情況等，當然是越詳細越好。
分解問題（問題樹）。對于問題來說，有的時候可能會是一個小的原因一步步導致的，也有可能是多種因素共同導致的，嘗試分解這個問題形成一顆問題樹，看出這個問題中各種關聯(lián)的因素。
去掉所有非關鍵問題（漏斗法）。根據(jù)上一步的結果，分析分解出來的因素有哪些確實是和問題無關的。
制訂詳細工作計劃。主要是針對問題的分析工具的選擇，頭腦風暴、決策評估、魚骨圖、德爾菲，或者你覺得對問題分析有幫助的任何工作計劃。
進行關鍵分析。通過上述制定的計劃進行關鍵問題原因的分析。
綜合調查結果，并構建論證。對問題的關鍵因素進行理論驗證，最好有數(shù)據(jù)支撐。
講述來龍去脈：在溝通文件中將數(shù)據(jù)及論證聯(lián)系起來。
經過上述步驟后，我們不僅會對問題的關鍵因素有一個全面的了解，而且在最后也要對問題記錄在冊。可以使用敏捷的一些知識工具進行記錄，解決過的問題對于團隊來說是一個成長進步的重要內容，并且也是項目的寶貴資產。
最后我們再來講講回顧會議。之前我們就說過，回顧會議是分享好的經驗和發(fā)現(xiàn)改進點的地方，也是促進團隊不斷進步的一個非常好的工具。整個迭代會議應該圍繞三個點：
本次迭代有哪些做得好。
本次迭代我們在哪些方面還能做得更好。
我們在下次迭代準備在哪些方面改進？
對于開好一個迭代會議，需要注意的也有兩點建議：
會議氣氛：Team 全員參加，氣氛寬松自由，暢所欲言，頭腦風暴發(fā)現(xiàn)問題，共同分析原因。
關注重點：Team 共同討論優(yōu)先級，將精力放在最需要的地方（只關注幾個改進就夠了）
會議結論要跟蹤閉環(huán)：可以放入迭代的 Backlog 中。
在會議中，我們可以通過頭腦風暴技術來發(fā)現(xiàn)上次迭代聽問題，這是非常好用的一個工具，而對于原因的分析來說，我們可以嘗試使用 力場分析法、5Why法 等，并且使用魚骨圖來進行記錄。在決定下次要做什么改進時，可以使用 SMART 來確定目標。這些，都是回顧會議中非常有用的一些工具。
要記住，回顧會議絕對不是一個討債大會，回顧不是責備，而是針對定性（人的感覺）的和定量的（衡量指標）數(shù)據(jù)，然后利用這些數(shù)據(jù)找到問題的根源，設計對策，并制定行動計劃。
對于項目來說，問題真的是無處不在的。即使是對于我們每個人的工作來說也是一樣的。很多時候，我們就是在自己一次次的解決問題中成長起來的，失敗為成功之母，但是并不是說我們要一直失敗。當我們碰到一個問題的時候，努力找到解決它的方法，而且大部分情況下都是可以成功解決它的，這個時候我們就已經獲得了成長。而失敗則是沒有考慮到的問題或者風險被觸發(fā)了，是帶來嚴重后果影響的問題，解決它們，會收獲更大的成長。但是，你也可能付出更大的代價?？傊W習，通過學習的方式提前接觸問題，了解問題，解決問題，這才是更好的成長之路。
參考文檔：
《某培訓機構教材》
《用戶故事與敏捷方法》
《高效通過PMI-ACP考試（第2版）》
《敏捷項目管理與PMI-ACP應試指南》
