我的敏捷歷程 —— 兼評《敏捷整潔之道 – 回歸本源》

• 2020 年 8 月 15 日
• 筆記

我個人最早接觸敏捷是在上大學時，在《程式設計師》雜誌上看到一本書——《解析極限編程》——的推介。當時我只是「幼稚」的從字面意思去理解：極限編程就是一種新式的編程方法（其實這麼說也沒錯，對了一半）。

工作後，非常幸運，所在團隊的 leader 對敏捷開發推崇備至。在技術層面，單元測試、結對編程是我們在工作中最常採用的兩項敏捷實踐，在項目管理層面，我們並沒有採用任何敏捷實踐（我有點記不清了）。過了一段時間，團隊 leader 在某次技術大會上接觸到了 Scrum 且被成功洗腦（他原話 😁）。之後，我們團隊就走上了實踐 Scrum 的康庄大道。Product backlog、Sprint、站立會議、燃盡圖、計劃撲克、演示會議、回顧會議 被我們「玩」的風生水起。我有幸被 Leader 指定為 Scrum Master，但不幸的是，我對 Scrum Master 的理解太膚淺，導致自己最後變成了「站立會議 Master」😂。這個階段的敏捷實踐加深了我對敏捷開發的認知，變成了敏捷開發的堅定擁躉。

之後，我進入第二家公司，試圖將敏捷開發的理念帶入團隊。但，無果。

而後，我進入第三家公司，並成為一個小型團隊的 Leader。推進團隊敏捷轉型便成了水到渠成之事。在團隊內，我主要的推動實踐是 Scrum，而想要推行 Scrum ，必然對技術團隊的合作方——QA 團隊、PM 團隊——有影響，那……就拉他們一起轉型，當時真是以無所畏懼的心態「強推」 Scrum。結果是，我們做的不錯！整個節奏理順並運行起來之後，我們只要按照節拍來進行就好，到了某個時間節點該做什麼都按照 Scrum 框架的設定來進行，有了一點點自組織團隊的味道。當時，在我的腦袋裡有一個極端的念頭：只有敏捷才是項目管理的唯一正確方法。
現在，我逐步放棄了「唯敏捷正確」的觀點。我觀察在傳統瀑布模式下，團隊成員依然可以很快速的開發和交付。

我反思自己這些年的敏捷經歷，得出一個小小的結論：沒有敏捷技術內核的敏捷過程，只是一種表象的敏捷。這句話怎麼理解？簡單說 Scrum + XP 才是完整的敏捷，只推進 Scrum，而不採用諸如 TDD、持續集成、結對編程等技術實踐，敏捷會慢慢陷入一種僵化狀態——會有大量的技術相關的 Story，可能還會有大的技術重構——這些其實嚴格意義上講，都是不應該出現的。
最近讀到的一本書，其主旨與我上述的想法不謀而合（其實是我自己領悟的太晚，這本該就是敏捷的本意😂）。

《Clean Agile – Back to Basics》中文名為《敏捷整潔之道 – 回歸本源》，從本書的命名上就可看出這是 Bob 大叔 Clean 系列的新作品（這個系列的其他幾本書我也讀過），書中提到的敏捷的價值觀、方法論大多我都耳熟能詳，有些甚至爛熟於心。但還是不乏振聾發聵之聲，記錄如下。

第一點，敏捷的定位。書中寫道：敏捷是幫助小型軟體團隊管理小型項目的一個小型行為準則。並且，作者對大型組織中的敏捷持完全否定的態度：根本沒有所謂的大規模敏捷。對於大型團隊，作者建議先將其拆分為小團隊，之後在小團隊上應用敏捷，最後再用業已成熟的方式把這些小團隊組織起來就可以完成大規模敏捷。干大事靠的不是大團隊，而是靠若干解決小問題的小團隊之間的協作。

第二，生命之環 Circle of Life 。生命之環由外、中、內三層環構成，描述了完整的敏捷本質及核心。外層環展示了面向業務的實踐，實際上相當於 Scrum 流程。這些實踐為軟體開發團隊與業務溝通的方式以及業務和開發團隊管理項目的原則提供了框架。這些實踐包括：計劃遊戲 Planning Game、小步發布 Small Release、驗收測試 Acceptance Tests、完整團隊 Whole Team；中層環是面向團隊的實踐，這些實踐提供了開發團隊在團隊內進行溝通和管理的框架和原則。這些實踐包括：可持續節奏 Sustainable Pace 、 程式碼集體所有 Collective Ownership 、 持續集成 Continuous Integration 、 隱喻 Metaphor；內層環是技術實踐，用以指導和約束程式設計師，來確保得到最高的技術品質。這些實踐包括：結對 Pairing 、 簡單設計 Simple Design 、 重構 Refactoring 、 測試驅動開發 Test Driven Development ; 在作者眼中，生命之環所代表的的極限編程就是敏捷本質核心的原型，也是最好的代表。生命之環也與我在前面提到的自己的經驗總結是一致的。

第三，關於交付日期。作者寫道：交付日期的選擇都是出於重要的商業理由，交付日期一旦選定就將被凍結，談判交付日期沒有意義。在這點上，我個人是受到一些啟發的：實際工作中，技術團隊很討厭 PM 給出需求後「順手」敲定一個所謂的「上線日期」，研發同學會對這個日期做出強烈反應，會感受到被冒犯，因為這個上線日期可能會極大的壓縮研發同學的開發時間，導致時間過緊、壓力過大、加班嚴重、身體疲勞等等一系列問題。所以，除非老闆高壓，通常上線日期是根據整個研發周期來確定的。作者對鎖定交付日期的肯定態度給我一點啟發：如果 PM 提出的上線日期是有商業理由的，是有業務價值的，那這個日期是可以進行討論甚至可以鎖定的。

第四，項目管理鐵十字。軟體項目的基本原理由品質、速度、成本、完成四要素來構成，在實際工作中，只能同時滿足任意3個元素，沒辦法4個元素全要。優秀的項目經理理解這 4 個屬性是共同作用的且會推動一個項目變得足夠高品質、快速、低成本，盡量按需完成。

其實，雖然我司市值在中國互聯網在前三名內，但在我司肉眼可見的範圍內，大範圍採用敏捷實踐的團隊少之又少。但站會會議、單元測試、重構、持續集成等技術，已突破敏捷的範疇作為單獨的技術實踐被很多團隊採用。我相信，會有更多敏捷實踐逐步被採納，而最終，所有的開發團隊都將是敏捷團隊。

原文發表於公眾號：技術心流 FollowFlow