作為有證上崗的Scrum Master，我負責任地說，考了這個證只代表你學了相關課程，但是並不保證你能真的實施敏捷，同樣，就算你沒有這個證，你也完全可以把敏捷做好。

而且，獲得這個證真心不便宜，如果不是能公款報銷，建議大家就不要去考了，如果你真的很想學，那有個省錢的方法，看我的Live《實話實說「敏捷「軟體開發流程》吧，比考個證便宜多了:-)

不過，無論是考證還是看Live，都只能是知識，不是實踐，並不能直接幫助一個企業成功實施敏捷。今天，我要講的是更直接、更容易執行、更適閤中國國情的敏捷實現方法，避免軟體開發團隊「葉公好龍」，讓他們直接乾脆沒有退路地擁抱敏捷的乾貨。

歸結起來，就是三點：

1. 管好你的需求；
2. 使用統一的工具；
3. 可視化！可視化！可視化！

接下來聽我一個一個細細道來。

管好你的需求

敏捷開發流程最容易在哪個緩解出問題？

肯定不是開發人員。至今為止，我見過開發人員對敏捷流程有抱怨的，但是，還真沒見過敏捷流程毀在開發人員手上的，因為開發人員往往飽受項目管理混亂之苦，而且開發人員頭腦比較理性有邏輯，都清楚敏捷流程是能幫助自己的。

我所見過最容易出問題的地方，在於需求管理，把敏捷搞亂的，往往是提需求的一方，在Scrum流程中，叫做PO（Product Owner），從職位上說，往往就是產品經理。相信我，全世界的產品經理都有一個特點——主意改得快，朝三暮四，早上提的需求，晚上一拍腦袋就改了。更要命的是，很多企業在進行敏捷流程培訓的時候，沒有叫上這些提需求的人，或者叫了他們但是他們不來。

「學習敏捷？你們做開發的搞一搞就好了，我還要開會，就這樣。」

「敏捷培訓？我就不用去了吧，敏捷不就是隨機應變嘛，需求改了你們就快速反應，我們已經敏捷了。」

「你們搞敏捷？好啊，以後改需求就更方便了，呵呵……」

我相信你肯定也聽過產品經理說過類似上面的話，這是一個可悲的事實，很多企業的敏捷開發過程只能在開發人員中推廣，移到產品經理層面，就容易碰壁。需求是功能的源頭，如果需求不能處理好，那就全完了。

所以，第一個關鍵：管理好你的需求。

怎麼管理好需求？

一句話：讓他們寫下來！

首先我們要明確一點，敏捷並不是沒有文檔，《敏捷宣言》裏說「運行的代碼高於完備的文檔」（Working software over comprehensive documentation），但是可沒說要消滅文檔，文檔依然是軟體工程的重要工具，一定要把需求落實下來，你可以用文字，你可以畫圖，你可以直接給一個競品的功能介紹鏈接，但是不能撂下一句話就要求開發人員開工。

唉，說句可能不大中聽的話，人性吶，也就是賤，如果讓他說一句話就算是提完了需求，他也不會有多上心，所以需求細節往往也是考慮不周；但是，你要求他費點勁寫成文檔，而且白紙黑字留他的名，他也怕寫爛了丟臉，寫的時候考慮問題也會全面一些，最後需求的質量也會提高。

最好的方法，是讓需求文檔和開發的代碼一樣，都要有完整的歷史記錄，能夠追溯到何時什麼人做了什麼修改，這樣可以追責到每一次需求變更。

這就引出下一個話題，需要一個統一的工具來管理敏捷流程。

使用統一的工具

敏捷流程其實並不強求使用什麼工具，你要是玩得好，用白板和小貼紙也能管理得井井有條，不過，現在我們面臨的現實不是沒那麼專家嘛，畢竟不是誰都像我一樣有那個證:-)

最現實的方法，就是使用統一的工具。現在工具選擇太多，反而讓人無所適從，比如代碼控制用github，文檔用wiki，然後任務管理又用JIRA，使用的工具多起來之後，就不方便管理了，新人加入進來學習曲線也陡峭，某些成員也會對工具挑三揀四，所以，使用統一工具是最直接最有效的方法，讓產品經理和開發人員、測試人員都在一個工具上協同合作，避免了流程不暢，更重要的是，真的讓所有人都感覺是在一個團隊中工作。

工具選對，事半功倍。

我們以碼雲（不是那個有錢的那個馬雲，是「碼雲」）為例，來介紹一個實現敏捷開發的工具必不可少的功能：

• 任務管理
• 文檔管理
• 代碼庫管理

首先，你需要一個可以管理任務的功能，項目管理的一個主要內容就是分解和分派任務嘛。

在碼雲中，除了開發者的「任務」，還有兩種特殊任務：「需求」和「缺陷」（也就是bug）。這就把把產品經理（負責需求）、測試人員（負責開bug）和開發人員（執行開發任務和fix bug）放在了同一戰線，而且，每個任務都有狀態標示，產品經理不把需求寫清楚並且被確認，開發人員是不會認可開工的，大家要做的事在一個視圖中呈現，互相監督互相激勵。

然後，你還需要文檔管理。

我說過，敏捷並不是不要文檔，無論是產品經理還是開發人員都需要寫文檔，我們不是不要文檔，我們要的是更加高效的文檔管理。都已經2019年了，就不要再拿Word來寫文檔了！拿Word寫的文檔，放在自己電腦的文件目錄裏，拷來拷去，很難實現版本控制，最後追溯哪個功能哪個時候修改的，幾乎做不到，所以，你的需求需要和代碼一樣也要有版本控制。

碼雲中可以直接編寫文檔，在任務中可以直接用Markdown格式編輯文檔，可以添加圖片，可以做必要的格式，非常方便。

也可以增加獨立的文檔，在任務中可以用鏈接直接引用文檔，這裡要說一下，你在文檔中輸入中文，碼雲可以自動生成英文URL，比如我輸入「怎麼纔是真的敏捷」，對應文檔專屬地址中的路徑部分自動翻譯成how_to_be_really_agile。

無論哪一種開發流程，制定發布週期都是必須要做的，在Scrum流程中稱為Sprint，每個Sprint都應該有一個明確目標，在Sprint開始之前，就要把實現這個目標的任務定義清楚，然後Sprint開始之後所有成員就向這個目標邁進，在一個Sprint內不要操太多心今後Sprint的事，以為計劃趕不上變化，將來的事情誰能預料？排除幹擾，把握住當下這個Sprint纔是要緊的。

在碼雲中，「里程碑」這個概念可以對應Sprint，也可以對應任何一種其他更大的發布週期，因為怎麼稱呼不重要，重要的是包含這些元素：

• 什麼時候開始？
• 什麼時候結束？
• 最終交付的產品代碼在哪裡？
• 負責人是誰？

最後，敏捷實踐的產出還是產品代碼，所以歸根結底還是要落實到代碼上。

碼雲中當然也有代碼的管理，提供了完整的git代碼庫管理功能，每一個PR可以和需求關聯。

這樣，從需求和文檔，一直到代碼，一個工具可以全部搞定。

團隊中每一個成員，只要進入碼雲，每天要做的什麼任務，每週有什麼任務，都很清楚，一目瞭然。

不過，如果工具只是讓每個成員只坐在自己的電腦面前對著任務表工作，那也就失去了敏捷的本質，敏捷需要團隊成員如果只是盯著自己的一畝三分地，直到出大事才開會解決，那不叫敏捷，敏捷需要隨時把握項目的健康狀況，這就需要說下一個問題——可視化。

可視化！可視化！可視化！

問：「我們的項目進行得怎麼樣？」

答：「很好。」

問：「什麼叫做很好？」

答：「開發任務進展了40%了。」

問：「40%？為什麼才進展了40%就算很好，為什麼不是達到80%纔算很好？」

答：「因為……我們才開始2天啊。」

問：「那你覺得多少天才能達到80%？」

答：「……」

上面這段對話是想說明，即使是語言大師，也無法用語言精確描述一個項目的進展，因為軟體項目的複雜程度，本身就不是三言兩語就能講清楚的。

不過，一圖勝千言，無論多複雜的項目，都可以用可視化的方法一眼看清楚狀況。敏捷流程中，有兩樣東西是每天團隊都要在一起看的。

• 任務看板
• 燃盡圖(Burndown Chart)

任務看板分為幾列，最基本要包含「待辦的」、「進行中」和「已完成」這幾列，如果流程更細可以有「已驗收」列，在界面上可以一目瞭然地看到哪些任務還沒開始，哪些任務還在進行中，哪些任務已經搞定了。

嚴格來說，敏捷流程並沒有寫「周報」這項活動，寫太多報告就不敏捷了，但是，實際中領導還是想要有一個更詳盡的周總結，在這個問題上，我們還是要面對現實，不要追求純粹的敏捷。實際上，碼雲就有這樣非常適應中國國情的功能，把任務看板從「看板模式」切換成「列表模式」，很讓變就可以篩選「本週任務」，這周的任務一幕瞭然，更妙的是，還有「導出」功能，誰要是不想看網頁工具，那就導出Excel給他看。有這樣的工具輔助，既滿足了領導的需求，又節省了開發者的時間，真是爽得不要不要的！

不過，要說把脈項目進度，還需要看燃盡圖，燃盡圖是一個橫坐標代表時間的X-Y坐標系，縱坐標代表任務量，圖中會有兩條線，一條是最理想情況下的任務完成曲線，還有一條是實際任務完成進度的曲線，如果實際曲線低於理想曲線，那就說明工期朝前，如果實際曲線高於理想曲線，就說明工期延後，非常清楚。

碼雲中還提供了任務分佈餅形圖，算是錦上添花，可以更加直觀看到當前任務狀態的分佈。

有了這些可視化工具，團隊任何一個人在任何一個時間，都可以對當前項目進展有一個直觀認識，開放透明，這纔是敏捷。

你還害怕解釋不清楚項目進度嗎？

問：「我們的項目進行得怎麼樣？」

答：「請看我們的燃盡圖。」

完畢。

總結

敏捷口號在業界已經喊了這麼多年了，道理該說的差不多大家也都知道了，之所以無法按照敏捷執行，在我看來，就是差工具這一步。

項目管理說到底就是管理任務和人力，不要再糾結在ppt上的敏捷教程了，直接用工具來實施敏捷項目管理，你值得擁有。

工欲善其事必先利其器，希望大家找到最合適自己團隊的工具，推薦使用和大富豪馬雲同名的「碼雲」，享受敏捷，利用敏捷，做一個快樂幸福的職業人。

推薦閱讀：