一、敏捷已死，有事燒紙

21世紀剛過一年，17位在軟體開發各領域有所建樹的大師匯聚在在美國猶他州，發表了似乎每個聚會都要發表的宣言（《敏捷軟體開發宣言》），併成立了Agile 聯盟，時間過去了十幾年，現如今當初的17個人裡有很多人都認為敏捷已死，let it go。敏捷似乎在21世紀初軟體開發還在野蠻發展，不存在標準化的年代裡滿足了開發者對於軟體開發的所有幻想，是當時人心中幻想的輕量級、高效開發方法，但是隨著軟體開發的逐漸成熟和軟體從業者水平的逐漸提升，新任的開發者發現不需要那些太過於錯綜複雜的“神聖的方法論、奇怪的術語、神聖的工具和一堆詭異的行為”就能夠在互相協作中達到高質量的交付，而敏捷的踐行者本身也在逐漸遭遇自身的問題，比如敏捷開發模式的標準化、規模化敏捷和商業模式變化

關於敏捷是如何從一套先進的輕量級開發思想，轉變成各大諮詢公司蜂擁而至爭相吹捧的大而全的框架的，筆者未曾親歷敏捷由盛及衰的輝煌十數年，敏捷領軍者ThoughtWorks目前正在所倡導的標準化和規模化，筆者也算親歷其中，本文中所說的敏捷，只是我定義的“適用於小規模團隊（特別是軟體諮詢和交付團隊）的能夠指導團隊提高交付質量的價值觀及一系列最佳實踐”，在後續的分析中就能看到，這種情況下的敏捷其實是最能發揮其強大優勢和力量的場景，經歷了一圈榮辱是非，敏捷迴歸原本使用場景，恰好我還有機會能夠經歷感悟。

二、敏捷到底是什麼

老生常談的話題，敏捷到底是什麼，這一次沒有層次高超直達商業價值高度的高階諮詢師，僅僅是從一名完成交付任務的諮詢側開發，與一個也在學習和應用敏捷，但是卻是在自建功能團隊實踐敏捷的團隊工作經歷對比，給出敏捷的一個基本概念的解釋。

敏捷其實從根本上來說，就是一套有利於迅速澄清和交付使用者的需求的方法論，從根本上來說敏捷注重四個價值，較之於過程和工具，更注重人及其相互作用的價值。較之於無所不及的各類文件，更注重可執行的軟體的價值。較之於合同談判，更注重與客戶合作的價值。較之於按計劃行事，更注重響應需求變化的價值。整體上來看，這就是一套十分適合於軟體外包和交付的思維，這也是敏捷能夠在ThoughtWorks得到實踐的重要原因。

敏捷主張最重要的三點是簡單設計、擁抱變化和快速反饋，強調在專案開始時於客戶溝通和澄清（Align或者拉通，隨意叫）需求（一般以Inception為方式），並以快速迭代的方式持續小規模交付客戶關注的價值，從幾周到幾個月，時間尺度越短越好，在開發中提倡使用簡單化、可持續的技術開發，並通過重構方法逐漸迭代直至完成，在工作中可以隨時接收和相應變化。聽起來對於客戶來說十分友好了，一個在專案開始時能夠充分理解客戶需求、專案中間能夠響應客戶變化、開發過程中可以每天於客戶面對面開短會（站會）回報專案進度的開發團隊，幾乎可以說是完美了。

而對於一名開發者的角色而言，這些是敏捷獨有的開發流程：

2.1 Inception

為了能夠在專案啟動前充分收集客戶的痛點和需求，一般專案以Inception開頭，一般需要BA夥同資深開發與客戶窩在小房間裡開長長的會從各個角度對客戶進行採訪和提問，涵蓋產品所涉及的各個角色，充分收集需求。在這個過程中對於開發的要求是能夠根據客戶的需求快速進行需求的甄別和可行性的估計，有些團隊也會要求Inception結束時能夠給客戶勾勒出一個產品藍圖，並給出產品大概的開發時間，交由客戶決策是否立項。

2.2 Iteration 0

Iteration 0是整個開發過程的起點，這個迭代主要做的工作就是搭建開發所需要的CI和CD環境，配置打包工具和程式碼審查工具，配置各種賬號的許可權和招募開發人員進入組中，算是整個迭代的起點。ThoughtWorks內部採用鬆散而扁平的社群模式組織人員，雖然開發都由人事（People）評判業績表現，但是理論上開發可以自由選擇在各個專案甚至各個角色之間轉換，因此Iteration 0一般是普通開發進組的正確時間。

2.3 Epic Story/User Story

由專屬客戶業務分析師（BA）或者替代其的技術領導（TL）與客戶溝通之後收集到的客戶的需求被分為史詩故事和使用者故事，史詩故事會拆分成為使用者故事，每個需求都被稱為一個卡，卡是開發工作的最小單位，而每張卡建立起來之後需要所有開發一起對卡所需要消耗的時間進行估算（Estimation），所有人一起估算也是為了保證估卡的公平性。卡按照性質也分為需求卡（正常綠色）、故障卡（紅色）和技術卡（黃色），其中技術卡主要是指重構、CI/CD等不屬於客戶需求，但是屬於支撐開發或者提高開發效率的卡，這種卡也是算在客戶的付費時間中的。

這裡需要提到的是，一張卡估算出來的時間是按照開發全速無打斷無切換的情況完成的，而最終這張卡交付的時間可能與估點時間不同，實際時間和估點時間的比率正是ThoughtWorks等諮詢公司對於程式設計師自身成長的認可和鼓勵，畢竟從理論上講估點時間是所有開發共同估算的合理時間，開發有權利在完成客戶需求的同時得到自身的提升，這點上後面有關自建團隊和外包團隊的區別也會提到。

2.4 Estimation/Kick Off/Desk Check/Sign Off

開發做卡的全過程，分為Estimation，Kick Off，Desk Check和Sign Off四個過程，Estimation階段確定卡的時間，Kick Off階段開發把卡所包含的內容和風險複述給BA和QA，確保開發已經完全明白了任務的上下文，而Desk Check和Sign Off則確保開發做完之後展示給客戶的功能（經過BA和QA確認過眼神）就是客戶想要的功能。整個功能這種獨特的儀式感，其實也是敏捷之所以被詬病的原因之一。

一張卡的所有過程可以通過需求牆追蹤，而建卡和卡每個階段的更新也是開發需要做的極其富有儀式感的事情。

2.5 Retrospection

迭代回顧會是敏捷的另一個“富有儀式感”的儀式，每個迭代完成後團隊所有成員總結上一週期的工作得失、發掘問題改進措施，進而推進團隊下一週期的工作質量。這是很多業界大佬也都嗤之以鼻的儀式，但是這個回顧的最高指導原則，其實第一次讀的時候有些感動，也恰巧代表了敏捷對於開發的含義吧：“無論我們發現了什麼，考慮到當時的已知情況、個人的技術水平和能力、可用的資源，以及手上的狀況，我們理解並堅信：每個人對自己的工作都已全力以赴。”

2.6 CI/CD

CI/CD，即持續整合/持續交付也是敏捷所倡導的能夠提高響應速度和迭代速度的“神聖工具”，從程式碼編寫完畢到生產環境的一系列自動化流程確保了開發提交程式碼之後能夠以最快的速度上線，這讓開發的工作能以最快的速度讓開發成果展現在使用者面前。

三、敏捷尊重勞動價值和勞動者，不適用於自激勵的風險型團隊

作為一名開發，體驗敏捷最大的感受是，敏捷其實從根本思想上來說是一種尊重程式設計師勞動價值和自身發展的思想，有些時候甚至會懷疑這種尊重是不是來自於開發人員自身的孤芳自賞而暗自警醒，遺憾的是這種思想並不適合於當前國內勞資市場的大環境，不適用於很多公司的很多場景。

敏捷倡導的交付流程，與正常交付流程相比獨特的環節是需求估算，這種需求所需工作量的大概估算的本意是幫助需求者（一般是產品經理或者客戶）衡量該需求是否是真正值得的，同時也便於需求者按照工作的輕重緩急為程式設計師安排工作效率，這其中恰恰體現了軟體開發的思維價值。

在承認了軟體開發是一種腦力勞動的結晶的同時，敏捷也在天然給使用者灌輸一種思維，那就是軟體開發者的工作是有價值的，按照人/天的方式計算的工資赤裸裸的體現這一點，想要完成和交付某個需求就必須要付出若干人天的等待和費用。與此同時在很多敏捷的真實實踐專案中，由於敏捷方法對於開發者的要求較高（別忘了還有結對程式設計這種燒錢的工作方式），很多情況下一些比較有人文關懷和科技視野的公司會在公司內部構建一種學習和進步的思維模式，內嵌在高質量完成客戶需求這樣的價值之中，並在潛移默化中勸服使用者：“軟體開發人員多花費時間學習和提升自己，正是為了能夠給客戶交付質量更高的程式碼”。這種思維模式認為軟體開發人員在完成客戶需求的同時，也應當在個人的能力方面有所提升，這也是敏捷所附帶給程式設計師的蜜糖。

但是實際上很多公司組建的自有的研發團隊已經使用月固定工資的方式買斷了團隊成員的月工作時間，用年終獎和晉升機制的方式約定了可預見範圍內的人員穩定，而一般執行穩定的公司並不存在短期僱傭一幫程式設計師幹一票就散夥的思想，軟體開發人員從被僱傭開始就被認為將是長期工作在團隊中的，在這種情況下軟體開發並不需要細緻到天級別的工作量估算，敏捷顯得又些累贅而又形式化。

因此對於很多公司來說，敏捷的落地最後會缺少很多內容，往往公司會吸收敏捷的一些有利於提升工作效率的實踐，而選擇性得忽略一些敏捷核心優質的思想和文化，從而導致敏捷不倫不類，軟體開發人員疲於奔命趕進度以“快速迭代”，管理者每天聽取下級彙報然後講話動輒三五十分鐘也稱為“站會”等等，本文這裡無意探討自建團隊與外包團隊的優劣，之所以舉這個例子也只是為了說明敏捷其實更適合於沒有狂熱的進度追求和自激勵的開發團隊，更適用於一個有著技術追求和可持續發展方式的技術團隊。

四、敏捷是一種自上而下實行的管理制度，而不是可以憑藉共識達成的氛圍

敏捷方法從根本上來說是一種可以用來管理團隊的制度，哪怕踐行者採用的是扁平的組織架構組織小而精的全功能團隊，但是扁平化依然是對於老的管理模式的破壞。

敏捷要求的快速迭代最適合的團隊規模是6到10人小團隊，這個團隊往往是一個全功能團隊，BA/QA/Dev/UX在內的各個角色都要有，或者要身兼數職，這在對團隊成員提出較高的要求的同時，也挑戰了傳統的團隊管理方式。前面提到的敏捷之所以對於開發是蜜糖正是因為敏捷保護了開發的時間，確保一個完成交付任務的開發人員能夠以正常的節奏和心力完成工作，同時能夠保留屬於一個腦力勞動者的個人時光，用於個人提升和生活。

敏捷雖然是一種包含了站會、迭代迴歸會和Kick Off/Sign Off在內的多種儀式感組合起來的方法論，它所具備的優勢，依然是一種需要自上而下實行的管理制度，而不是一個經過粗略介紹進入團隊就能根據共識達成的輕鬆的團隊文化氛圍。當然這裡並不是說敏捷所形成的文化氛圍不輕鬆或者沉悶，恰恰相反這種文化氛圍相當具有張力和感染力，成型的敏捷制度能夠很寬鬆得容納團隊成員的差異，並能夠極大得激發團隊成員的創造力和活力——這一點很容易被管理者注意到，認為敏捷是一劑腎上腺素，實施之後團隊就能鬥志昂揚，殊不知敏捷的時間並非易事。

敏捷盛行的這些年裡可以看到的是很多公司的很多團隊去嘗試了敏捷制度，比如和筆者上份工作類似的自有團隊，在等級森嚴、上下級分明的團隊中實施敏捷，在敏捷文化核心的平等和價值之上人為添加了制度和階級等無關緊要卻有利於維持團隊存在感的東西，並無異於敏捷的自有氣氛蔓延。僅僅憑藉Dev的共識而構建起的溝通和協作的氣氛能夠在Dev層面降低溝通成本、倡導自主學習，但是僅僅在某個環節的孤立敏捷（從實踐上來看最沒有階層Gap的Dev往往最容易實現這種孤立的小團體敏捷）並不能突破其他層面的限制，比如說從BA層面的相應變化和識別價值，從PM層面的生命週期管理和風險控制，這些往往都沒有得到較好的提升，因此敏捷實施只是形而上學而已。

五、全棧工程師：開發的死衚衕和伊甸園

敏捷之下各個角色如何自處？作為一名也在經歷個人選擇的Dev的角度，我曾不止一次思考。

可以說在敏捷的整個流程中開發Dev作為軟體價值的核心締造者，本來就是敏捷規則中最關鍵的部分，哪怕是在敏捷中Dev和BA/QA/PM這樣的角色合作似乎分薄了其光環色彩，但是敏捷也最大化得提升了Dev角色的人生體驗。可以看到的是對於開發來說敏捷更期望的是開發都能是全棧工程師。

全棧工程師是幾年前比較火的概念，顧名思義就是能夠在軟體開發的各個階段都能打能抗的工程師，起初概念只是包括網站前端和後端，後來隨著DevOps的一陣春風，全棧工程師也附帶了基本的Ops技能。全棧工程師似乎成為了開發眼中一個理想的角色，能夠適應任何工作的需求獲得敏捷體系的認可。成為這樣的工程師似乎是一件十分有安全感的事情。

但是實際上也有一種聲音，那就是全棧工程師是萬金油，成為全棧也是一條死衚衕，成為一個行行都會的人，似乎就成為了一個行行都不精的人。在工作中也能夠看到，從開發的角度來說，敏捷所提倡的開發是一種能夠迅速實現客戶價值的開發，在開發中常常借用的手段並非如同自建核心團隊一樣深刻鑽研一個記憶體池、一個函式呼叫，花費多個迭代解決一個優化需求等等，敏捷開發似乎總是在拼接API或呼叫現有服務湊成一套能用的軟體，恰恰如同敏捷宣言中所說的“工作的軟體”的概念。在這種工作模式下的開發似乎很難積累技術的深度，和系統級的深入特性，畢竟缺乏了數年對於一個產品的精雕細琢似乎很難深入細節。

但是實際上從開發來說，開發從全棧工程師，或者從更廣的維度，以交付價值為核心的開發工作，更可貴的收穫應該是能夠迅速響應變化的技術棧，不斷保持學習的人生態度，這怕是全棧的蜜糖所在。