中式太極敏捷與西式敏捷的區別

太極敏捷與 XP 在對軟體工程本質的認識和哲學觀上存在著明顯的差異。根據太極敏捷的辯證法則和極限法則，我們認為 XP 有點偏激，極限和極端既是它的優點也是它的缺點。

TDD、CI 和 PP 是 Kent Beck 先生及其同事們發明的 XP 最知名的（也是爭議最大的）三個核心做法。針對這三種做法，太極敏捷提出的替代解決方案是 UDD（使用者目標驅動的開發，User-Goal Driven Development）、AI（Adaptive Integration，自適應整合）和 PoD（Pairing on Demand，按需結對）。

UDD

TDD（Test Driven Development）有一個別稱叫 Test-First Programming，要求開發的第一步是根據需求，必須先寫單元測試程式，然後再寫實現程式讓測試通過（符合需求）。

我們認為，一概而論，簡單要求所有型別的敏捷專案開發都必須從寫單元測試程式開始，顯然有點僵化。對於很多種類的軟體開發，以及有經驗的中高階程式設計師來說，必須先寫單元測試這一要求其實有點過度，是不必要的。有經驗的程式設計師完全可以自主選擇是否編寫單元測試，以及何時編寫單元測試。

測試驅動主要可以分為兩種：UTDD（即經典的 TDD）和 ATDD（Acceptance Test Driven Development）。系統開發也有不同的型別，比如應用系統開發和軟體框架開發。

軟體框架開發，主要是為了重用，有很多對外公開的 Class 和 Interface，顯然有必要對每一個公開的類和介面都進行單元測試。針對可重用框架、共享庫（library）等 API 的開發，從編寫單元測試開始，是相當高效和合理的。

對於常見的應用系統的開發，焦點不在 API 的單元測試上，而在整個系統的邊界上。即便寫在再多的單元測試，也無法驗證整體系統的正確性和質量。這時盲目地採用 TDD 就可能造成主次不分、浪費精力，從編寫系統測試或驗收測試程式開始開發，顯然更為合理。

系統測試從哪裡來？來自系統需求。系統需求從哪裡來？來自使用者目標。

太極 UDD 方法提倡根據使用者目標，編寫軟體需求，根據軟體需求，編寫系統（驗收）測試。根據開發系統和專案的不同型別，有選擇地採用 UTDD 或 ATDD。

AI（不是人工智慧）

從軟體工程的歷史發展來看，上世紀九十年代經微軟公司倡導而流行的每日構建（DB，Daily Build）技術可以說是持續整合（CI）技術的“祖宗”。

CI 要求我們縮短 build/integration 的間隔時間，一天之內持續不斷地、連續進行系統的整合和測試，這當然是一種保證系統質量和穩定性很好的做法，是我們應該長期努力追求的目標，但在實際工作中，CI 對於微型、小型專案和系統是相當有效的，對於大中型系統和專案，CI 會有 scale up 的問題。總體上，我們認為 CI 有點理想化，也有點極限。太極觀點認為，要取得質量和效率的平衡，並非只有採用 CI 這樣一種極限、固定的做法不可。

DB 也是一種敏捷做法。我估計，恐怕國內還有一大半的軟體開發團隊連 DB 還沒做到吧，談 CI 有點超前了。在實踐中，我們建議本土團隊先從微軟公司 15 年前已經做到的每日構建、每日整合做起，收到實際成效後，再談 CI。

太極敏捷主張的是 AI（Adaptive Integration），整合的時機、間隔應該是自適應、可調節的。是否採用分支、合併的開發方式，也應該根據專案的實際情況進行選擇。

PoD

相比 PP 要求所有的程式程式碼都必須由兩個人結對在一臺電腦上完成編寫和測試，太極敏捷認為 PoD（按需結對）的做法可能更加靈活，也更加實用。


...