首先很慶幸，能在適合的時間，遇到了這樣一本適合的書。之所以這樣說，是因爲在遇到這本書前，我還是一名單純的程序員，“增刪改查”的業務代碼，佔據了我大多數的時間，本就繁雜的工作，還被一個叫“敏捷”的東西，弄的一團糟。不知道從什麼時候起，似乎搞一個口水話連篇的“早會”，弄一塊不倫不類的“白板”，就開始全世界宣稱，“我們‘敏捷’了”。
老闆們自然開心的不亦樂乎，因爲從此以後，就可以以“敏捷”之名，塞給你更多的工作量，因爲“敏捷”不是要“快”嘛。需求也可以理直氣壯的隨意改變，因爲“敏捷”不是鼓勵“變更”嘛。甚至代碼都不用測試，就想直接上線，因爲“敏捷”不是要“快速交付”嘛。
天生叛逆的我，自然不會相信，難道這就是大行其道的“敏捷”嗎？但是打鐵還須自身硬，於是，我開始看大量的敏捷相關的專業書籍，並且一邊翻書，一邊實踐，在摸索中前行。這其中對我影響最深，幫助最多，最具有啓蒙意義的，當屬《Scrum精髓—敏捷轉型指南》一書。
理論概念部分，書中已經講的非常好了，通俗易懂，這個是基礎，想要做好敏捷，這些都是基本功，我就不再贅述了。下面，我斗膽以“過來人”的角度，談一談再次翻看本書，那些依舊能觸動我的觀點：
1.“全面擁抱Scrum並不意味着組織在實踐Scrum的時候必須得照着某個一刀切、放之四海皆準的公式生搬硬套（前言部分）”
多年後，或許你已經參見過或聽過N多人分享其他公司的敏捷轉型成功的案例，再或者你已經掌握了N多打着敏捷旗號的架構或模型，但是這些都不重要，切記，這些都不是你的，凡是告訴你可以按部就班去做，就可以成功的，都是騙子。都知道“世界上沒有兩片相同的葉子”，同樣，世界上也沒有處境完全相同的團隊，生搬硬套意味着要“削足適履”，最後一定是哀聲載道，以失敗告終。所以，找到適合自己團隊的纔是最重要的，開始在Scrum的大框架下，包容甚至吸納團隊內已適應的方法，即使在你看來，有些不是好的習慣，但是，請相信，在時間的推演過程中，那些“頑疾”會在Scrum框架的一次次“檢視與調整”的循環中，被識別出來，並最終被“改變”。
2.“每日例會不是用來解決問題的……每日例會也不是傳統意義上的狀態會……每日例會主要是一個檢視、同步、適應性定製每日計劃的活動（P30）”
看過太多喋喋不休的早會了，充滿了口水話，也不注重消息的傳遞性，自顧自說，期間還有人交頭接耳開小會，或是某幾個人就一個問題，討論來討論去，顯得自己很有事做，其他人站的生不如死，也聽不懂那幾個在胡說八道些什麼。或是一羣人圍着主管/產品，彙報各自進度，或是對着jira電子屏更新狀態。這樣的早會，意義何在，就是爲了一大早上給大家添堵嗎？如此，你怎麼能不叫大家有牴觸情緒呢？
想開好早會一定要有看板，不然對着空氣瞎說個啥，而且我個人非常鼓勵物理看板，一是，物理看板多了，可以形成“信息輻射中心”，或者“作戰空間”。二是，物理看板很提升士氣，改變風水格局，營造一種攻堅克難的氣勢。三是，早會移動物理看板上的任務卡，可以產生信息拉動的效果，且很有儀式感。再者，如果團隊有人喜歡開小會，可以增加發言授權物，可以是任何東西，只有拿到授權物的人才能發言，且嚴格控制時間盒，產品可以旁聽，但不要打斷和質問進度，主管能不參加最好，把自主權交給團隊。早會只是爲了同步信息，暴露風險，檢視計劃，有任何問題，散會後，相關人單獨討論，不要在早會浪費所有人時間喋喋不休。
3.“在面對不確定性時，不要一廂情願地預測，要用低成本的探索方式來換取相關信息，並綜合利用這些信息給出明智、合理的最終解決方案(P48)假設事先無法制定完美計劃（P284）”
傳統的項目管理方式，都是基於計劃驅動，有計劃，必然要預測，想要計劃準確，必須要精準預測，想要精準預測，就要花費很長時間去胡思亂想。結果呢？在知識量最匱乏的階段，拍腦門造了一堆低質需求，都是一廂情願的“你以爲”。而且還很容易過度設計，花了很大成本實現一堆“不痛不癢”的需求。所以我們要承認，我們沒辦法在認知有限的情況下，作出完美的計劃，要學會利用短週期的迭代，快速試錯，不斷獲取反饋，以增加知識，來調整下一次迭代的交付。
4.“關注閒置工作，而非閒置人員（P59）”
這個理念是最難被上層接受的，因爲傳統的項目管理理念，是把人當作資源來看的，所以，資源出現閒置，意味着浪費，真的是這樣嗎？
第一，每個人的關注的點是有重心的，當你把所有的精力陷入關注人，就變成了一種監控，而人又不直接產生價值，能直接產生價值，決定項目成敗的是那些還沒有被完成的閒置工作，所以，請把重心放回到剩餘的工作上，而不是絞盡腦汁讓人100%連軸轉。
第二，我們要打造的是自組織團隊，既然如此，請選擇相信團隊，基於迭代前的承諾，我們彼此遵守，過程中不打擾。我們要允許在開始階段出現各種反常的狀態，但是，在經歷了幾輪迭代的磨合後，一切不好的現象都會被潛移默化的改變掉。
5.“在使用Scrum時，不是用既定計劃的執行情況衡量進度，也不是看某個特定週期或開發階段的工作有多大的進展，而是用已交付且驗證過的結果來衡量（P63）”
這是一種增量開發的思想，也符合敏捷的原則之一，“可工作的軟件是衡量進度的首要標準”。所以，對比傳統項目管理中的彙報，所謂的“完成80%”意味着什麼呢？意味着剩下的20%工作要花20%時間完成嗎？幾乎沒什麼可能性。意味着已經完成的80%可交付嗎？也是不可能的。所以，在傳統的衡量進度的理念裏，所謂的完成百分之多少，就如同信口雌黃一樣，沒任何說服力。
但是，在敏捷項目裏，如果說完成80%，那一定是，完成了已符合完工定義（DoD）且優先級最高的，可交付使用的那80%。
6.“質量不是測試團隊在最後階段“測”出來的，而是由跨職能的scrum團隊負責並持續內建於每個衝刺中。(P66)”
質量一定不是測試同學測出來的，而且測試同學也不是質量警察的角色，而且整個團隊，大家一起要努力做好的事情。自動化測試一定是敏捷中不可缺少的部分，同時結合TDD（測試驅動開發），不斷識別代碼中的壞味道，然後進行反覆重構，無論對程序員本身基本功的提升，還是對項目整體質量，都是有利無害的，強烈推薦大家試行。
7.“在Scrum中，我們的目標是消除可有可無的繁文縟節（P66）”
無聊的郵件、沒完沒了的日報，週報、各種彙報糟心的PPT、有一點點小事情，就磨磨嘰嘰的開會、即使做的很近，也不會過去面對面溝通一下，而是在各種類似微信羣裏，喋喋不休的嘮叨…….太多的形式主義，太多的沒用的繁文縟節，佔據我們大量的開發時間。在敏捷轉型時，我們一定要在前期的敏捷思維導入中告訴大家，敏捷不玩虛的，一切以實用爲主，短平快的高效解決問題纔是王道。準備好隨處可以見的白板及便利貼，相互溝通時，走過去，邊畫邊講的效果，一定好過你乾巴巴的文字聊天。
8.“衝刺是在時間盒內完成的，持續時間短並且長度一致，衝刺開始後就不能再改變目標，必須達到團隊的完成定義中要求的最終狀態。（P71）”
“敏捷就不管進度了嗎”，錯！我們是有限定的時間盒的，一般現在大多能做到1～2週一個迭代。且這個時間盒的長度一般是固定的，因爲這樣可以給團隊一個節奏感，類似健康的心跳，同時有一種屢戰屢勝的成就感，同時由於時間短，錯誤有限，也有利於我們快速獲取反饋，即使調整方向。
“敏捷就可以隨便變更嗎”，錯！我們也是有規則的，一般一個迭代開始後，那個這個迭代所做的內容，是不會變更的，如果變，請放在下一個迭代中，畢竟我們的迭代週期很短，但是如果真的非常緊急，那麼，沒辦法，我們要切掉某個獨立的功能點，把這個緊急需求放進去，這個時候，就考驗產品的拆分能力了，MVP能做到多小，很見產品同學的功夫。
9.“產品列表是產品開發期間一直存在的‘活文檔’（P96）”
我很喜歡“活文檔”這個概念，我覺得，在敏捷裏，不僅文檔是“活的”，計劃是“活的”，“人”更是活的，而不是生硬的“資源”。當一切都是“活”的，讓就可以適應一切變化，像活水一樣，“兵無常勢，水無常形”。所以，我們要經常對不僅是產品列表，sprint列表等等的一切，定期review，不斷的檢視與調整，這纔是不至於把自己變成一灘絕望的死水，發臭發黴。
10.“傳統的需求收集方法是問用戶，瞭解他們想要什麼。這種方法我從來沒有用爽過。以我的經驗，讓用戶當評論家遠比當作家好(P112)”
這種現象就太普遍了，你問業務/用戶，你想什麼，他們通常會用很多非常空洞且飄渺的詞彙來描述他們的需求，或者說了一堆，最後乾脆來一句，其實我也不是很知道。所以，與其沒完沒了的問他們想要什麼，期待把所有情況都考慮清楚，再去動身開發，恐怕，一切都晚了。一是，用戶描述不清楚；二是，過程中用戶的想法會變。所以，倒不如我們通過頻繁的交付可工作的軟件，來邀請他們使用和感受，請他們當一個評論家，然後通過不斷的收集他們的反饋，來輔助業務/用戶發現他們的真實需求，纔是王道。
11.“估算不是承諾（P145）”
有太多的開發人員，都很忌諱做估算，因爲一旦他們給出了一個時間的概念，即使再三強調，且用了很多“大概”“可能”“差不多”的概念，但是依舊會當成開發人員的承諾，在後期的排期中進行約束和限制。
造成這個結果的直接原因，就是管理者沒腦子，沒有一點邏輯性。估算本身是對一種不確性的進行假設，這沒錯吧？你讓大家對“不確定性”和“假設”作出確定的承諾，不是腦子壞掉了嗎？
也會有人問，那估算還有什麼意義？當然有意義，估算是以現有的認知，對未來的工作以何種邏輯關係進行開展的一種假設。可以推算產品開發的持續時間，同時在估算PBI的時候，還能激發人們思考PBI的細節，讓所有假設都暴漏出來，這種熱議很有價值。
12.“速率是一種計劃工具，也可以作爲團隊診斷指標。它不應該作爲一種績效指標來判斷團隊的生產率。（P160）”
速率是衡量產出的，而不是成果。所以完成一個8個故事點，不一定比完成3個故事點的人，交付了更多的商業價值！可以縱向比較，即診斷一個團隊每次迭代的交付狀態正常與否，但是不要跨團隊比較，沒有任何意義！
13.“一個普遍誤區，測試屬於額外的開銷，減少測試，我們就可以提高速率。現實是減少測試既增加債務又減緩速率。（P171）”
真的聽人說過，有些創業公司爲了所謂的“提高速率”，竟然取消了測試環境，短期內，確實感覺速度變快了，但是隨之而來的，就是更多的線上問題不斷的爆發，而且由於缺乏測試環節，人們的質量意識隨之降低，造成大量的技術債堆積，所以，很快，修復問題的時間越來越長，留給開發新需求的時間越來越少，且技術債過重，後期技術做一個很小的新需求，也很容易“牽一髮動全身”，大大的拖慢了項目的整體速率。
14.“開發團隊（以及整個Scrum團隊）的成員需要具備三個火槍手的態度——“人人爲我，我爲人人”。……團隊成員共同承擔工作的責任，成敗是整個團隊的事情。（P236）”
很多團隊都沒有“團隊”的概念，大家豎井很深，各自負責一個小業務模塊，自己做的又煩燥，別人又無法插手，各自爲政，不是自己的模塊，不聞不問不管。這樣既沒有集體感，又沒有團隊氛圍，最後都是得過且過的開發，最後伺機跑路。由於業務豎井嚴重，對個人依賴度又高，所以核心人員跑路，其他人又難以短期內接手，對項目的損失又很大。
所以要想變革，首要任務就是要打破各種豎井，可以通過輪崗，結對編程等方式，減少項目對單個人的依賴。在思想上，從強調“我”變成爲“我們”，擯棄傳統的考覈單一個人績效的方式，引入團隊績效的概念，大家一起爲項目奮鬥，不分你我，關起門來，大家都是一家人，一榮俱榮，一損俱損。
15.“衝刺回顧：人們在表達意見時必須要有安全感，用不着擔心受罰（P429）”
回顧會是團隊能短暫駐足思考的重要環節，同時也是Scrum框架提供的有助於持續改進的重要因素。但是很多團隊在開回顧會時，總難獲得理想的效果。原因之一，就是沒有營造一個開放且安全的氛圍。不妨引入一些“世界咖啡屋”的方式，採用各種引導技巧，順帶買點零食，領導如非必須可選擇不參加，交給團隊自己完成。同時在會議的開始，制定基本規則，我們“對事不對人”，不要採用責備的口氣來闡述問題，多用“我們”來代替“有的人”等。
16.“有一種無效的，爲團隊建立的“改進計劃”與每個衝刺完成的工作不相干……爲了確保落實改進計劃，不要把二者分開，一定要整合。（P439）”
回顧會被大家視爲形式主義的另一個原因就是，提了一堆問題，然後搞了一個所謂的“改進計劃”，然後就沒有下文了。最後發現，每次開會都是老生常態，翻來覆去都是那些問題，也解決不了，所以，大家本能的覺得回顧會沒有任何用處。面對這種情況，我們不妨想一想，Scrum的哪個工件跟團隊的任務密切相關？沒錯，是sprint衝刺列表。這是開發團隊在每個迭代中真真切切要完成的工作，那麼我們不妨把每次回顧中暴露的問題，能在下一個迭代中改進的，我們把它變成sprint衝刺列表中的一個條目，將兩者合二爲一，這樣，是不是能促使改進項在下一個迭代中被移動呢。
17.“敏捷或Scrum你沒有任何終極狀態。變得更精通Scrum或更敏捷是一個持續的、永無止境的過程，追求的是日益精進。（P444）”
敏捷是不可能一蹴而就的，當然，也不可能有終止的時候。不會說我們拿出一年甚至兩年的時間做敏捷轉型，然後就成功了，就再也不用管了。這是不可能的。因爲敏捷本身就不是一個靜態的框架，裏面充斥着大量的“檢視與調整”的循環，在每次檢視中識別出改進項，並在下一次迭代中調整，自產自銷，更像是一臺“永動機”，生生不息的運作，以趨於完美。
寫在最後：文章寫的比較匆忙，可能會有錯別字，沒時間校正。同時文中的觀點，僅代表我個人的一些思考，若有不當之處，歡迎隨時微信交流。最後良心的向大家推薦一下BoB姜信寶老師翻譯的這本書《Scrum精髓—敏捷轉型指南》，無論你是新手，還是老鳥，都一定會有一些不一樣的收穫！、
