敏捷開發方法背後的哲學原來是避免浪費
我最近一直在思考，為什麼敏捷開發這麼流行，難道是傳說中的銀彈嗎？為什麼《敏捷革命》這本書要將敏捷稱之為一種革命？為什麼作者那麼鄙視瀑布式開發方法和甘特圖？經過反覆閱讀《敏捷革命》這本書，我發現敏捷開發方法背後的哲學原來是避免浪費，我將從以下9個方面簡要討論一下敏捷方法是如何避免浪費的，希望讀者再補充1個，幫我湊個整數。
-
敏捷方法最強大的地方，是通過迭代式增量開發的節奏，定期給客戶展示真實的產品，從而及時收到真實的反饋。傳統的軟體開發方法的迭代週期比較長，一般是按照幾個月前的需求文件編寫程式碼，並且需求分析多多少少都會有點偏差，最終交付到使用者手上的功能可能已經不是使用者想要的了，程式設計師們辛辛苦苦開發出來的東西沒有人願意用，這是一種極大的浪費。
-
對於專案管理來講，專案經理要保證每個專案成員都清楚地知道自己要做什麼事情，以及每件事情完成的標準是什麼，SCRUM看板就是一個很好地工具。每個專案成員都會在SCRUM看板上認領自己的任務，這相當於專案成員做出的承諾，這樣就避免了員工由於工作目標不明確而造成的混亂（我曾經待過一個團隊，大家都不知道自己這個月要幹什麼，這對企業來講是一種很大的浪費）。另外，看板傳遞的另外一個訊號是資訊透明，任何人都可以通過看板看出來團隊的每個人正在做什麼，進度怎麼樣，這促進了資訊的流動，防止有些團隊的成員甚至團隊負責人利用資訊的不對稱來維護自己權威。
-
每日站會上，每個人要回答三個問題，我昨天做了什麼、我今天計劃做什麼、我遇到了哪些障礙。這個機制有助於及時暴露問題，SCRUM master的一個重要的職責就是調動資源為團隊掃清障礙，避免由於障礙導致專案卡殼，卡殼的話，有些人只能乾等著，什麼都做不了。
-
SCRUM master除了要為團隊掃清障礙以外，還要保護團隊成員不受外界干擾。對團隊成員來講，同時做多件事情會大大降低效率，是一種很大的浪費，SCRUM master要及時叫停與本次迭代沒有關係的事情，避免團隊成員因為處理其他雜事而出現上下文切換的浪費。
-
每項任務最好一次做完，所以要明確每項任務完成的標準。如果很多工只做到了一半，就像一個工廠的倉庫裡堆滿了半成品，賣也賣不出去，又佔用了大量的成本，這也是一種浪費。每個使用者故事都應該是完整的，可以解決使用者的某個問題，因此一個使用者故事完成後是可以交付的。
-
與一次性把事情做完相比，另一個非常重要的事情是最好一次性把事情做對，修復bug或返工是一件充滿了壞味道的事情，不僅可能會打亂已有的開發節奏，造成過多的上下文切換，而且，重複的返工和遍地的bug甚至會影響團隊的士氣。敏捷是一種迭代式開發的方法，配合持續整合和持續交付的基礎設施，能夠通過自動化的手段更好的在釋出前發現問題。
-
在任何一款軟體上，80%的價值來自20%的功能，有些不重要的功能反而會佔用大量的工時。產品負責人要不斷地找出最有價值的那20%的功能，並列入到團隊的待辦清單中，確定好優先順序。
-
敏捷團隊要具備徹底完成一項任務所需的全部技能，並且成員之間還要具備相互backup的能力。這個就類似特種部隊的小分隊，俗稱老A，每個人除了自己的專長以外，還需要具備比較綜合的能力。對應到開發團隊，就是全棧工程師。試想一下你們的團隊想要啟動一個專案，需要先去產品團隊借一個產品經理，再去前端團隊拉一個前端工程師才能啟動專案，但產品經理可能不具備你們專案所需的行業知識，前端工程師只能協助你們兩週，兩週以後就去忙別的事情去了，以後再想改需求就要另外排期了，那麼這樣的專案註定充滿了低效的溝通和失敗的風險，這也是一種浪費。
-
敏捷方法主張由開發人員來評估每一個迭代能夠完成多少工作量，反對在一個迭代週期內臨時加入任務，導致任務量過大而加班。更直接地講，敏捷方法不主張加班，因為加班容易造成人的疲勞，人在疲勞狀態下犯錯的概率大大增加，而修復這些錯誤所需要的時間甚至會遠遠大於加班的時間。儘管加班在當時看來會有立竿見影的效果，但是把眼光放長遠的話，疲勞加班其實是一種得不償失的、具有後遺症的浪費行為。
最後，我想聊一下產品負責人這個角色，我目前的角色就更像是產品負責人。產品負責人要花很多時間和使用者溝通，聽取使用者的想法，然後根據使用者的反饋制定出團隊的下一步待辦清單，並排好優先順序。產品負責人除了需要具備產品設計的專業知識以外，還需要具備以下四個特點：
產品負責人要具備相關領域的專業知識和行業背景，餐飲行業的產品經理要懂餐飲，能源行業的產品經理要懂能源，運維領域的產品經理要懂運維，只有具備了這些，才能懂使用者，懂使用者的痛點，懂產品的價值。
產品負責人必須具備自主決策權，才能帶領團隊做出自己認為有價值的功能，才能不過多地受到行政干預，或者外部壓力的干預。
產品負責人必須有足夠的時間與團隊成員接觸，向團隊成員解釋清楚需要做什麼以及為什麼要這麼做。產品與研發在考慮問題時的出發點不一樣，思維方式也不一樣，比較容易產生爭執和矛盾，網上關於這方面的段子也比較多，但雙方必須意識到，產品負責人需要依靠研發來實現自己的想法，否則PRD永遠是PRD，無法變成可以執行的軟體送到使用者的手上，研發則需要依靠產品來實現自己的價值，否則無論你編寫出多麼優雅的程式碼，無法產生商業價值。所以，產品與研發要充分融合，讓對方覺得值得信賴、言行一致、易於溝通。
產品負責人必須為價值負責。產品負責人要設計出能夠解決使用者問題的產品，並通過產品為公司實現商業價值。
本文首發在我的個人公眾號老朱的讀書隨想，如果感興趣的話，歡迎關注我哦。