Scrum

最近在實踐Scrum，有一些心得。Scrum不是一個技術名詞，而是一種開發流程，確切的說，是敏捷開發（Agile Development）的一種。

一般講，在一個完整的Scrum流程中，會有產品負責人（Product Owner)，流程管理者（Scrum Master），開發團隊（Scrum Team）三個角色。你們各司其職，從一個產品需求列表出發（Product Backlog），細化成每一個迭代週期（Sprint），再接着利用天天的站立會議和看板更新每一個人的開發進度（一般還有燃盡圖）。

一些講Scrum實踐的書裏，(甚至)會提到用計劃紙牌（Planning Poker）來精確預估研發週期的方式，招式百出。

聽起來很美好對不對？

實際差之千里。

Scrum對於不少初創團隊，都好似Teenage Sex，臆想跟現實判若兩然，作很差實踐，就以爲是徹底扯淡，屁用沒有。

事實上，敏捷必定要多實踐，本身實踐得出的經驗纔是最牢靠的。咱們之因此抱怨敏捷開發沒有解決問題，是由於對它的理解有誤區。

不少人以爲敏捷就是：

1. 「想作就作」的態度，避免任何形式的管理、流程和規矩。

2. 每日站立會議上，對着空氣唸經，隨便挪一挪看板上的任務

3. 一個領導管下屬的噱頭，走個流程而已

看起來日日有產出，實際上鬼才知道這些產品作了有沒有用，這些代碼堆完意義在哪裏。團隊渾然不知下一步要作什麼，紛紛兩眼看天。

爲何會這樣？

問題的本質不在於敏捷開發這種流程，而在於團隊自己。

初創團隊永遠是在在極端不肯定的狀況下，開發新產品或新服務。

這自己就無路可循，無跡可探，沒有圍繞着問題的核心去作產品，是沒有辦法得到要領的。

因此若是要作好敏捷開發，就必須：

釐清產品訴求，認真完成商業閉環

• 你的產品多大程度上解決用戶的問題，有沒有比現有的方案好10倍

• 你能從產品上賺多少錢，天花板在哪裏

• 用戶會主動推薦你的產品嗎，天然增加引擎在哪裏

• 產品要作到何種規模能夠覆蓋團隊開支，你能閉着眼睛算出來嗎

面對現實，解決核心問題

• 你如今手裏作的，是否是在解決用戶真實的產品訴求，仍是你本身腦補的產品訴求

• 有什麼方式能夠快速解決問題救火上線，而不是等待一週後的新版本

• 面向用戶場景輸出需求，不要過於在乎何種格式，Done is better than perfect

落實到人，而不是流程

• 任務最終要拆解到人頭上，圍繞一我的每日工做量/難度來追蹤進度，而不是大鍋煮湯摸魚，要保證進度透明

• 保持同理心和道義，你的接口或者文檔寫的爛，是不專業的表現。己所不欲，勿施於人

• 樸素的拆分任務並完成，你的隊友不會把一個簡單任務描述的艱難萬重，你也不會。

自我欺騙是敏捷開發的禁忌。無論你用什麼樣的工具（好比用Geekbot代替天天早上的站立會議），都解決不了自欺欺人。

裝做看板上一直有任務（哪怕是個簡單issue也要拆成好幾個），裝做設計的產品就是用戶想要的，卻根本沒有調研過友商出品的水準，裝做採集的數據有意義，結果根本沒法從中獲得任何幫助決策的信息，裝做天天刷微博是在看行業動態，實際上真的就是在刷微博。

遇到這些狀況，團隊的負責人必須馬上立刻One One，一我的滑水的最大的問題是讓團隊其餘人感到深深的不公。

敏捷開發讓你作到在產品夭折前，留出救命的發育機會，越早推出產品，越早拿到你的Alpha用戶的真實反饋（他們一般對於現階段的產品缺點充分包容，但提出問題時卻絕不含糊），你也就有更多的機會修正軌道。

若是一個軟件開發上線了，最終客戶根本沒去體驗，這樣的上線，算不算上線成功？

Scrum必須迴歸業務本質，才能被善用，不然都是假的。