最近在實踐Scrum，有一些心得。Scrum不是一個技術名詞，而是一種開發流程，確切的說，是敏捷開發（Agile Development）的一種。
通常講，在一個完整的Scrum流程中，會有產品負責人（Product Owner)，流程管理者（Scrum Master），開發團隊（Scrum Team）三個角色。大家各司其職，從一個產品需求列表出發（Product Backlog），細化成每個迭代週期（Sprint），再接著利用每天的站立會議和看板更新每個人的開發進度（通常還有燃盡圖）。
一些講Scrum實踐的書裡，(甚至)會提到用計劃紙牌（Planning Poker）來精確預估研發週期的方式，招式百出。
聽起來很美好對不對？
實際差之千里。
Scrum對於很多初創團隊，都好似Teenage Sex，臆想跟現實判若兩然，做不好實踐，就覺得是完全扯淡，屁用沒有。
事實上，敏捷一定要多實踐，自己實踐得出的經驗才是最牢靠的。我們之所以抱怨敏捷開發沒有解決問題，是因為對它的理解有誤區。
很多人覺得敏捷就是：
-
“想做就做”的態度，避免任何形式的管理、流程和規矩。
-
每日站立會議上，對著空氣唸經，隨便挪一挪看板上的任務
-
一個領導管下屬的噱頭，走個流程而已
看起來日日有產出，實際上鬼才知道這些產品做了有沒有用，這些程式碼堆完意義在哪裡。團隊渾然不知下一步要做什麼，紛紛兩眼看天。
為什麼會這樣？
問題的本質不在於敏捷開發這種流程，而在於團隊本身。
初創團隊永遠是在在極端不確定的情況下，開發新產品或新服務。
這本身就無路可循，無跡可探，沒有圍繞著問題的核心去做產品，是沒有辦法獲得要領的。
所以如果要做好敏捷開發，就必須：
釐清產品訴求，認真完成商業閉環
-
你的產品多大程度上解決使用者的問題，有沒有比現有的方案好10倍
-
你能從產品上賺多少錢，天花板在哪裡
-
使用者會主動推薦你的產品嗎，自然增長引擎在哪裡
-
產品要做到何種規模可以覆蓋團隊開支，你能閉著眼睛算出來嗎
面對現實，解決核心問題
-
你現在手裡做的，是不是在解決使用者真實的產品訴求，還是你自己腦補的產品訴求
-
有什麼方式可以快速解決問題救火上線，而不是等待一週後的新版本
-
面向使用者場景輸出需求，不要過於在意何種格式，Done is better than perfect
落實到人，而不是流程
-
任務最終要拆解到人頭上，圍繞一個人每日工作量/難度來追蹤進度，而不是大鍋煮湯摸魚，要保證進度透明
-
保持同理心和道義，你的介面或者文件寫的爛，是不專業的表現。己所不欲，勿施於人
-
樸素的拆分任務並完成，你的隊友不會把一個簡單任務描述的艱難萬重，你也不會。
自我欺騙是敏捷開發的禁忌。不管你用什麼樣的工具（比如用Geekbot代替每天早上的站立會議），都解決不了自欺欺人。
裝作看板上一直有任務（哪怕是個簡單issue也要拆成好幾個），裝作設計的產品就是使用者想要的，卻根本沒有調研過友商出品的水準，裝作採集的資料有意義，結果根本無法從中得到任何幫助決策的資訊，裝作每天刷微博是在看行業動態，實際上真的就是在刷微博。
遇到這些情況，團隊的負責人必須立刻馬上One One，一個人滑水的最大的問題是讓團隊其他人感到深深的不公。
敏捷開發讓你做到在產品夭折前，留出救命的發育機會，越早推出產品，越早拿到你的Alpha使用者的真實反饋（他們通常對於現階段的產品缺點充分包容，但提出問題時卻毫不含糊），你也就有更多的機會修正軌道。
如果一個軟體開發上線了，最終客戶根本沒去體驗，這樣的上線，算不算上線成功？
Scrum必須迴歸業務本質，才能被善用，否則都是假的。