幾年之前我還是個野生程序員的時候，對“敏捷”這個詞是有些抗拒的。那時候，要麼是沒有想法、懶得去理會，要麼就是主觀上拒絕：
肯定又是些無所事事的人弄出來的無聊概念，幫他們自己刷存在感的東西！
敏捷，就是那些諮詢公司弄出來給別人洗腦的嘛，那些理念太空，根本無法落地！
那些一大堆概念都是些什麼鬼？條條框框太多了，運作起來太麻煩了！
不用敏捷，我們現在不也挺好的嗎？敏捷跟我有什麼關係？
但後來我卻選擇加入了 ThoughtWorks，這個傳說中的敏捷大本營，一方面因為很多出名的書都是 ThoughtWorks 的人出的，另一方面也想親入虎穴一探究竟。而如今，歷經敏捷項目的洗禮，我已經成為專職的一線諮詢師，為眾多大型企業提供敏捷轉型過程中的技術指導。
他們
在一些朋友看來，我自從換了工作，就開始在群裡轉發一些敏捷相關的文章，發表一些感言。在轉發這些內容的時候，我經常用到的敘事口吻是“他們”。
他們的代碼真的寫了好多測試。
有時候要開一整天的會，我真不知道他們是怎麼撐下來的！
感覺跟著他們一起做測試驅動開發好像沒那麼難。
這段時間裡，我讓自己成為一個“警惕的觀察者”。不管是主觀上的警覺，還是故意在外人面前將自己打造成這樣的一個形象。深怕在我還沒有覺察到的時候就已經被敏捷洗腦了；同時也希望在曾經的好友面前以儘量理性、中立和客觀（理中客）的形象示人：不過，這不妨礙在他們看來，我已經被洗腦了。
後來我瞭解到，這如同學習新知識過程“守破離”中“守”的階段。“守”的過程既是獲取新認知的過程，也是與過去的認知做比較和更新的過程。觀察現象——對比質疑——私下學習——撥開疑雲，大體就是這樣的不段重複，在不斷了解新實踐的過程中，也同步去認識它、理解它。
漸漸地，一系列疑問得以解答，使得最終我接納了敏捷開發思想，並認為它是適用於現代開發團隊中的工作方法。
疑問
在過去我呆過的團隊中，一直有兩個無法解答的問題。那時作為技術經理，我經常被別人問到的問題，也是我自己無法用經驗回答的問題。
- 做完這個功能，你估計需要多少時間？
- 為什麼大家在辦公室顯得很安靜、氣氛有點壓抑？
在成功學的洗腦課程中，有一句被強調最多的話：“失敗一定有原因，而成功一定有方法！”那麼，我們過去回答不了的上面這些問題，以及由它們導致的管理上的難題，其根本原因又是什麼呢？獲得管理上成功的方法又是什麼呢？我帶著這兩個問題離開了之前深度參與的創業項目。與朋友分享了要探索新徵程的想法之後，他真誠地邀請我加入他的創意，並希望由我來帶領團隊一起續寫新的故事。我猛然間發現，其實雖然之前在團隊裡擔任所謂技術經理的職位，但我真正給團隊帶來的幫助似乎更多的只是一個有經驗的工程師給新手的指導。那時候，第三個疑問產生了：
- 如何去做好一個團隊帶頭人？應該安排團隊成員每天做什麼？
這些疑問不得到解答，我就如同掉下井底的青蛙，雖然能聽見外面世界的聲音，卻只能看到井口大小的世界。
答疑
加入新團隊後不久，這些疑問就完全得到了解答。第一個要實現的需求就是一個“明星”功能，集成第三方系統的調查問卷。團隊很快組織了需求計劃會議，並細緻地過了一遍第一期要完成的目標，實現這個目標要包含的業務範圍，而具體又包含哪些步驟（用戶故事）。
- 目標：發出問卷鏈接，並將數據收回來。
- 範圍：選取模板、發送鏈接、收回數據、發送提醒郵件
- 步驟：
1. 管理員在外部系統中創建好模板（不需要開發）
- 用戶可在 XX 頁面中使用選項來選擇問卷模板（系統自動將外部系統中的模板名字同步到本地系統）
- 用戶可在 YY 頁面中使用鏈接發送調查表單，客戶收到包含鏈接的郵件
- 系統自動將外部系統中收到的數據同步到本地系統中以供使用
- 如果沒收到提交數據，系統自動在7天后自動發出提醒郵件，客戶再收到一封包含鏈接的郵件
接著開發人員和測試人員對還不夠詳盡的細節提出問題，討論獲得一致，一起對各個步驟大致估計所需時間。每個用戶故事並不確定由誰來做，而是大家一起就其中的細節進行討論，並就所需時間形成一致：有的人說需要 3 天，有的人覺得 2 天就夠了。他們會敘述自己的想法，並最終達成共識。
這項活動，以及之後的迭代過程中，基於這個會議的開發過程解答了我第一個疑問。
他們有一個角色叫 BA，會寫一個個的用戶故事來描述需求，一兩天就可以完成一個故事。明確的前提條件和驗收標準（從哪裡開始做，做到哪裡為止），讓開發工作變得有節奏感，需求不清楚的時候隨時就這個需求的範圍進行討論。
相比於拿別的產品做個演示，甩一句“就照這個做”，然後就天天催進度、做出來之後又說不對勁的產品經理，有一個專門負責業務、隨時可以叫過來討論的 BA 讓開發人員感到倍感輕鬆。
江湖上傳言說敏捷不需要文檔，原來是謬誤。敏捷並沒有說不需要文檔，只是說認為團隊成員之間的溝通協作比詳盡的文檔更重要。所以，用戶故事仍然是會包含必要的描述內容的。要寫清楚為什麼要做這項功能，以及驗收標準等。
團隊一起估計時間的過程，不光可以消除特定人估計時的無助感，更重要的是它讓所有人都瞭解用戶故事的細節，在後續開發中誰都可以參與開發。
相對較小的用戶故事，估計起來要比一整個功能（比如對整個調查問卷功能進行估計）估計起來靠譜得多。即使有特定的用戶故事估計不準確，其影響範圍也是可控的。
把所有故事的估計時間相加，即為整個功能所需要花費的時間。
估計只是幫助做計劃的一種方法，在後續開發過程中，如果發現比當初估計的要複雜，或者簡單，需要與 BA、PM 等角色一起更新這個估計值，從而幫助團隊及時完善一開始制定的迭代計劃（如果必要，可以加入一些，或者減去一些，或者修改一些）。
這樣，我發現開發團隊的時間原來是需要管理的，而管理時間這件事其實也需要花些心思才能做好。這時候，如果你問我某項功能需要多久做好？我會告訴你，讓我來拆分一下功能，粗略估計就成為了可能。
而後面的其他疑問也很快得到了解答。關於團隊氣氛，如果一個團隊裡每個成員都在悶頭做自己的工作，獨自面對自己的交付壓力和技術挑戰，成員之間互相幫不上忙，他們的氣氛一定不會太好。而如果所有人通力配合工作在相同的功能上，一起理解消化業務，一起解決技術問題，共同做技術決策，並分擔解決缺陷（BUG）的責任和壓力，那麼團隊的氣氛怎麼會不好呢？
最後一個問題，關於團隊。
團隊裡大家的角色是如何分配的，規模又應該多大？團隊之間應該如何配合？這就不難回答了。典型的業務功能團隊，以及後來出現的微服務團隊，都很好的詮釋了團隊結構和規模問題。有一個論述產品設計和組織結構關係的康威定律，值得我們深入思考。團隊帶頭人？我突然反應過來，一定要有這個角色麼？如果大家都能很好地運作了，那其實這個所謂帶頭人的作用是很淡化的，這也就是所謂的自組織團隊了。如果一定要一個帶頭人，那他的職責一定是確保這樣一種自組織的機制在團隊中持續地運作下去。
所以，我被洗腦了嗎？
也許你可以這樣認為。
作者我現在是接受了敏捷思想的，其中還有一些工具和方法，我還在持續學習過程中。不過，“洗腦”這個詞本身其實具有一定的預設立場，它是那些質疑者的說法。
那麼，重新回到問題本身。敏捷是什麼呢？它會將人們洗腦嗎？
敏捷不是什麼宗教，它只是一種生產軟件的思路，一種倡議。它倡議，通過加強團隊成員間的交流協作，儘快交付高質量、有價值的軟件，讓團隊以良好的響應性來擁抱軟件的變化。為了符合這種思路，它一般又會有一些典型的實踐方式。我們可以說哪些實踐是由敏捷方法所推薦的，因此是“敏捷的”；而哪些實踐是不推薦的，因此是“不夠敏捷的”。但不會說哪種是好的，哪種是不好的。
比如，敏捷的：
- 自主提交代碼，儘早集成
- 自動化一切，包括環境初始化
- 代碼由團隊共享，隨時重構和優化
不敏捷的：
- 逐次代碼提交都需要他人審查並批准的管控
- 手動部署生產環境
- 不讓他人修改自己編寫的代碼
但這些“不敏捷”的條目，基於團隊具體情況，可能實際操作起來更可行，就可以根據目前的階段去施行，並向著更敏捷的方向去持續改進。類似地還有，敏捷不會說團隊一定要開站會，站會一定要在早上開等等……相反，如果要求團隊一定要做某件事，其實它與敏捷思想是背道而弛的。我們應該遵循敏捷理念去對實踐進行改良，以適應團隊實際情況。
事實上，“敏捷”一詞來源於英語 Agile，這一英文詞彙也類似於中文中的形容詞“敏捷”一詞，其適應性相當廣泛。人們往往用它來形容業務的靈活性，思路的開放性等。因此對於敏捷來說，並不存在什麼洗腦不洗腦的說法。它只是一種風格，一種態度。只要你運用這種思路和風格去讓團隊協作越來越好，開發出來的軟件的質量越來越好，那就是敏捷的。敏捷中典型的具體實踐方法有 Scrum)、XP 和 Lean 等。此外，近年被廣為談論的 DevOps，也已經成為了敏捷軟件方法的典型實踐。
文／ThoughtWorks陳計節
閱讀更多 ThoughtWorks 的文章
