敏捷是工具
好吧胆屿，我坦白了，我欺騙了大家偶宫。最近我在游說大家辯證地看待“敏捷”非迹，并期待大家和我對“敏捷”的理解到同一水平線上的時候，我曾大放厥詞：“敏捷不是所謂的流程和工具纯趋，它是價值觀”憎兽。但從一定程度上講，價值觀也只是我們用來解決工程問題吵冒，用來約束人思維而創(chuàng)造的工具之一纯命，我也是Google了“價值觀是工具嗎？”這個關(guān)鍵字才學(xué)習到痹栖，哦亿汞，原來還有“工具價值觀”這么一回事。從解決問題的角度來看揪阿，人發(fā)明出來的東西——敏捷疗我，它不是個工具是什么？
但是南捂，請不要暗自竊喜（就像學(xué)生時代指出老師錯誤那樣）吴裤，我曾提到的所有關(guān)于敏捷的理解都是值得各位深思的。而這里溺健，這篇文章麦牺，我想和大家聊聊所有人心底的那個困惑：“請問我們到底怎么才能把那個該死的敏捷按在地上？”不瞞大家說，在此之前我也不知道怎么把我心里的和我那曾親眼所見的我以為是敏捷的東西塞到你們的腦子里枕面，并和大家一起愉快地寫著代碼愿卒，唱著歌就把項目給交付了。
甚至最近在和朋友吃飯聊天的時候潮秘，一位資深的敏捷交付專家都開始懷疑自己所理解的敏捷到底對還是不對琼开，我們所習以為常的所謂的“正道”是不是入錯了片場，我們應(yīng)該怎么抉擇和取舍枕荞？原來在野蠻的交付環(huán)境下我們也會感受到挫敗與力不從心柜候。
復(fù)盤過去這段時間在項目中推行敏捷的經(jīng)歷以及最近翻譯的書《Robust Python》的啟發(fā)之下，我想我可能找到了問題的部分答案（話不能說太滿躏精，畢竟我以為的我以為一定是我以為的嗎渣刷？）。
工具視角
從該瀑布還是該敏捷矗烛，到是該Scrum還是該Kanban辅柴，再到該站會還是該坐會，到該不該Code Review瞭吃，該不該寫用戶故事的AC碌嘀，該不該持續(xù)集成，該不該TDD歪架，該不該加班股冗，該不該。和蚪。止状。我們有太多問題想知道答案了。除了告訴你咨詢師的標準答案“看情況”之外攒霹，我是真的不知道以何作答怯疤。但是我想把“看情況”這個三個字換個說法并稍微解讀一下：明智地權(quán)衡利弊（正是所謂工程問題的本質(zhì)）；
先抽象一下催束，這些問題的“類”是：“某個工具該不該用集峦，怎么用”。不過是個if else（決策）罷了泣崩，每一個決策背后都需要權(quán)衡利弊少梁，我們聽過太多人說敏捷軟件開發(fā)的好處何其多，但成本是多少呢矫付？敏捷轉(zhuǎn)型是需要成本的凯沪，除了支付給咨詢師的錢之外，更大的成本在于：
- 組織層面是否接受买优，說服組織接受它也是要成本的妨马，有時還不菲挺举。。烘跺。
- 一旦組織上決定敏捷轉(zhuǎn)型湘纵，就會產(chǎn)生高昂的初始學(xué)習成本，團隊不會一夜之間就理解并認同敏捷滤淳，也不會馬上就學(xué)會成套的敏捷實踐（這玩意兒有些單獨拿出來做還沒啥用）梧喷，他們需要學(xué)習與實驗，這太昂貴了脖咐，特別是在時間铺敌、金錢、精力都捉襟見肘的上下文中屁擅。
更糟的是偿凭，在一個中型或者大型團隊中，早期需要投入的成本很可能遠勝于獲得的收益派歌。這個問題本質(zhì)上來說是一個先有雞還是先有蛋的問題弯囊。在團隊沒有達到足夠的敏捷成熟度之前，我們能看到的只有成本和越來越緊迫的交付壓力胶果。然而匾嘱，人都是不見兔子不撒鷹的，看不到好處的情況下讓大家接受并實踐敏捷是很困難的稽物。
我們能做什么
從我們過去實踐敏捷的經(jīng)驗來看奄毡，可以嘗試將成本與收益隨時間的變化這樣建模：
成本一開始會很高折欠，但隨著團隊敏捷成熟度的提升會逐漸降低贝或。而收益一開始會很低，但隨著團隊的成熟會越來越高锐秦。在這兩條曲線相遇之前咪奖，我們可能感受不到敏捷實踐的優(yōu)勢。所以為了價值最大化酱床，我們需要盡可能早地達到這個交叉點羊赵。
痛點驅(qū)動變革
軟件系統(tǒng)問題的與傳統(tǒng)工程問題的最大區(qū)別是我們應(yīng)對的是理想化的世界，我們不需要考慮物理世界類似公差這樣的問題扇谣，我們要處理的90%的問題都來自于人昧捷。所以我們說軟件設(shè)計與開發(fā)要“以人為本”。既然是人的問題罐寨，那無非是兵來將擋靡挥，水來土掩。當我們感覺痛的時候鸯绿，就是我們要動的時候跋破，不要痛到麻木簸淀，然后躺平。
產(chǎn)生價值的最好的方法就是減少正在經(jīng)歷的痛苦毒返。我們可以回頭看看自己當前的工作方式中租幕，哪些地方浪費了時間和金錢？哪些東西讓客戶失望拧簸？以及哪些東西讓團隊士氣低落劲绪？好好做回顧，做根因分析盆赤。如果你明確地知道痛點所在珠叔，請嘗試那些大家都說好的敏捷實踐，并試著堅持一段時間弟劲；否則祷安，我建議從正確的Retrospective開始做起：
- 選擇合適的手段
- 保證安全的環(huán)境
- 暴露有用的問題
- 產(chǎn)出可測試的行動計劃
- 投入適當?shù)某杀疽越鉀Q必要問題
- 設(shè)定Action的Owner
找戰(zhàn)略目標
是不是沒有“敏捷”就不能做價值交付？顯然不是兔乞，這也正是敏捷的魅力所在汇鞭，敏捷的價值觀里總是用發(fā)展的眼光看待人和事。除了“敏捷”和“非敏捷”庸追，我們永遠有一個說法叫“在路上”霍骄，當然我們可能永遠都在路上。
人可以走向天堂淡溯，不可以走到天堂读整。走向意味著彼岸的成立，走到豈非彼岸的消失?
——史鐵生
關(guān)鍵節(jié)點與事件
在軟件咨詢服務(wù)領(lǐng)域咱娶，我們通常將軟件開發(fā)稱為“價值交付”米间，一個非常商業(yè)的詞匯。而商業(yè)中通常有一些關(guān)鍵的時間節(jié)點與事件是需要我們重點關(guān)注的膘侮，比如：簽約屈糊、驗收、交貨琼了、交錢逻锐。對應(yīng)到軟件交付的上下文，這些事件就顯得比較關(guān)鍵：需求挖掘與業(yè)務(wù)分析雕薪、確認交付范圍昧诱、軟件驗收、集成與部署所袁。所以盏档，我們應(yīng)該針對具體的事件正確地采用其對應(yīng)的改進方法：設(shè)計思維之于業(yè)務(wù)分析、SPM（Sprint Planning Meeting）之于確認交付范圍纲熏、Sprint Review之于軟件驗收妆丘、CI之于集成與部署锄俄。
混亂與沖突之源
我們看到有些痛苦一直在發(fā)生，從來沒有停止過：客戶反悔了勺拣、開發(fā)和產(chǎn)品經(jīng)理（BA）吵架了奶赠、前后端聯(lián)調(diào)出問題了。放棄美好的幻想吧药有，上述這些一定會發(fā)生毅戈，毋庸置疑。所以你是打算束手就擒還是坐以待斃呢愤惰？哈哈苇经，勇敢一點，接受它們存在的必然性宦言，試著反其道而行之扇单。比如，更頻繁地讓客戶反悔（盡可能短的迭代奠旺，與客戶建立有節(jié)奏的蜘澜，高頻的反饋環(huán)），設(shè)定專門用來給開發(fā)和BA“吵”清楚需求的流程——SPM响疚、用戶故事的Kick Off鄙信，讓前端和后端開發(fā)可以一直吵（重新定義卡Done的標準，讓他們坐在一起一起工作）忿晕，當然能推行全棧文化就更好了装诡。
世界上只有一種真正的英雄主義，那就是在認清生活真相之后依然熱愛它践盼。
——羅曼羅蘭
一勞永逸地解決復(fù)雜問題
我們通常都需要花比較多的時間來解決復(fù)雜問題鸦采。比如：新人的知識傳遞。而可以改進的點在于當我們花時間完成它之后應(yīng)該盡可能讓下一次再做的時候花更少的成本宏侍。所以赖淤，對項目制的團隊而言蜀漆，請像維護代碼那樣維護好新人 On Boarding 的 checklist 谅河，不論是關(guān)于技術(shù)還是業(yè)務(wù)的。
