這是鼎叔的第六十五篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本公衆号《靈活測試轉型》，星标收藏，大量原創思考文章陸續推出。
繼續聊聊著名的靈活研發架構：極限程式設計。
極限程式設計（Extreme Programming，XP）是由Kent Beck在1996年提出的一種軟工工程方法學。XP作為最富有成效的方法學之一，相對于傳統工程方法，更強調可适應性而不是可預測性。軟體需求的不斷變化是難以避免的，主動适應變化才是更加現實，更加具有競争力的态度。
對極限程式設計理論的了解
XP是一種軟體開發風格，專注于程式設計技術，清晰溝通還有團隊協作的實踐。XP是始終讓客戶驅動系統的内容，由團隊驅動開發的過程，其工作範式是保持清醒，适應變化。
XP緻力于解決靈活軟體開發中的所有風險，包括延遲、取消、系統惡化，高缺陷率，業務誤解，需求變更，人員流動等。
XP要求你抛棄舊的低效技術和習慣，按照你對團隊共同目标做出的貢獻來評價自己。
極限程式設計的價值觀和核心實踐
XP的基礎價值觀是加強交流、從簡單做起、尋求回報和勇于實事求是。它采用近似螺旋式的輕量級開發方法，把複雜開發過程分解為一個個相對比較簡單的小周期，幫助客戶清楚地了解開發進度和待解決的問題，并及時調整。
XP要求遵循的13條核心實踐是：團隊協作（Whole Team）、規劃遊戲（the Planning Game）、結對程式設計（Pair Programming）、測試驅動開發（Testing-Driven Development），重構（Refactoring）、簡單設計（Simple Design）、代碼集體所有權（Collective Code Ownership）、持續內建（Continuous Integration）、客戶測試（Customer Test）、小型釋出（Small Release）、40小時工作制（40-hour Week）、編碼規範（Code Standard）和系統隐喻（System Metaphor）。如圖2-2所示。
XP推崇開放式的工作環境，把客戶卷入開發隊伍之中，強調頻繁測試不斷整合的價值，希望盡早傳遞簡單産品給使用者以獲得回報。XP方法比較适合小團隊的開發實踐。
價值觀是普适的，實踐是基于場景的，那連接配接兩者的橋梁則是原則。
XP的原則
一 人性化，在開發中應滿足一些人性的需求。軟體是由人來開發的，非人性化的管理過程會付出高昂的代價，比如導緻人員更替的成本，失去創新的機會。優秀的開發者需要基本的安全感，成就感，歸屬感，親切感和成長。
XP中的限制工作時間就是為了給非工作場合的人性化需求挪出時間，進而提高工作時間内的個人貢獻。總是犧牲個人需求來滿足團隊需求也是不可取的，偉大的團隊在建立互相信任的關系時，讓每個成員可以更加自我。
二 經濟學。經濟學上影響開發的兩個方面是金錢的時間價值（今天的一塊錢比明天的一塊錢更加值錢），團隊和系統的可選擇價值（能适應未來變化的系統更有價值），必須有人為是以這些買單，不在沒有把握的地方投資。
XP實踐應讓所有成員和客戶都獲益，才算是成功的，比如代碼重構，優化命名和自動化測試。
三 改進工作，而不是等待完美。“最好”是“足夠好”的敵人，軟體開發的卓越是通過改進達到的。
四 多樣性。想法越多，機會越多。關鍵的困難問題能用幾種不同的方法解決。
五 檢討。不要試圖掩蓋錯誤，檢討後緊跟行動。
六 流。通過參與軟體開發的所有活動來傳遞有價值軟體的穩定流，這個流是連續的，通過頻繁部署較小的增量來實作。
七 機遇。有意識地學會把問題變成機遇。
八 失敗。當你不知道怎麼做的時候，冒一點風險失敗可能是通向成功的最短道路。
九 品質。項目不會因為接受低品質而加快速度，要求高品質通常導緻更快的傳遞，并且讓工程師感到自豪。
十 責任。責任不能被指派，隻能被心甘情願的接受，同時還要接受相應的實踐，責任和權力需要同時承擔。
讀者可以參閱Kent Beck和Cynthia Andres的《解析極限程式設計——擁抱變化》
下面我們從測試角度談談有哪些主要的啟發。
測試啟發
一、将業務代表或使用者代表卷入到各類測試活動中，越早越好。
充分利用有代表性的客戶，幫助我們明确需求的品質要求及優先級，參與早期版本驗收測試（尤其是MVP版本，即最小可行産品的版本），盡快回報能代表使用者聲音的品質問題。
通過積極的交流，讓客戶代表非常清楚開發的進度、風險、待解決的品質問題以及背後的困難；同時開發團隊也能及時響應商業變化，避免投資浪費。
二、共享代碼所有權。
有些團隊是比較抵觸測試人員獲得代碼權限，甚至以安全為理由拒絕權限申請。我傾向于支援專職測試人員獲得和開發同等的代碼權限，至少是閱讀和本地編譯權限，便于測試人員進行代碼了解，精準測試，嘗試定位問題等技能。測試人員有機會和開發在同等的資訊源上進行技術對話，甚至直接針對代碼品質進行規範檢查。
測試人員可以推動團隊使用單一代碼庫，對臨時分支生命周期進行度量，推動盡快關閉。
三、可持續的工作投入。
即不要長時間加班（工作時間超過40小時/周）。據我觀察，一些加班嚴重的團隊效率并不高，加班必要性不強，而每天真正高效的工作時間遠遠低于8小時，很多時間都被浪費或者拖延掉了。管理者也常陷入隻看工時不看效率的低水準管理模式。
可持續的穩定工作時間，才能形成穩定的疊代會議節奏，和準确的工作量估算。團隊處于比較松弛的疊代狀态是持久健康的，這遠比高承諾低傳遞要好。
在國家明令打擊996的今天，企業管理者隻能寄希望于法定工作時間内的穩定效率。
是以，如果出現大量加班現象，管理者和客戶可以一起确定加班的原因，及時采取緩解措施，進行項目進度和資源的調整。
四、開放的工作空間。
最好15秒内能識别團隊的資訊工作空間。所有人在一個開放的空間辦公（可以有一些小隔間做私人溝通用途），牆上有大白闆貼有各種重要的提醒卡片，列出團隊共同的目标和願景，随時可以在白闆上進行塗寫讨論，甚至可以一起在休息間吃茶點交流。
成員需要團隊感，而不是碎片人的感覺。
五、測試驅動開發TDD。
詳細解讀文章參考本公衆号上一篇：聊聊測試驅動開發
XP将單元測試結合到它獨特的螺旋式增量型開發過程中，鼓勵開發人員先寫驗收測試通過的代碼，再不斷補充和重構代碼内容，降低備援代碼，并努力保證測試代碼的通過。這些測試代碼就形成保障品質内建的安全網，同時確定了開發設計從簡單開始演進，盡可能避免備援設計。
對于測試人員，學習TDD的代碼可以更好的了解開發人員的設計過程，以及單元測試的完成品質，同時可以把相關測試代碼高頻率地用于回歸測試。多用單元測試替代目前的系統測試，在降低備援的同時，還能提升根源分析的能力。
對于架構師，應習慣利用測試代替規格說明和解釋，并對系統治而分之。
六、結對程式設計對品質有什麼好處。
結對程式設計是XP實踐中争議最大的一點，實施效果參差不齊。由于個人隐私空間被打破，第一次嘗試結對程式設計的開發者通常不太适應，需要管理者加以推動。而且長時間結對很難保障，每天的結對時間通常建議控制在4小時以内。
從個人産出效率來說，結對程式設計并沒有明顯的優勢，開始時甚至是下降的（因為同時要占用兩個開發人員），随着配合越來越默契，結對程式設計的效率會提升。
但是從設計品質和代碼品質角度來評估，結對程式設計效益明顯，因為一個人員在主導編碼時，另一個人會對他的設計思路、代碼規範、測試品質做評估，及時指出了大部分的初級問題。同理，我們也鼓勵測試人員和開發人員一起實踐結對程式設計。
七、泰勒科學管理主義和TPS(豐田産品生産方法)
泰勒主義，把品質從工程中分離出來使得品質部門更像懲罰而不是建設性的。而TPS是把品質融入到工程每個角色和每個環節，強調控制在制品的最大數量，中間零件承載了上遊是否穩定工作的資訊。
為什麼項目中本應該親密合作的兩個角色團隊會産生對立？
我認為是，部分團隊采用了靈活原則中對自己有利的部分，而忽視了靈活的其他重要價值觀，溝通，one team，角色互補
部分團隊沒有學習靈活，而是泰勒主義的中間人，沒有定期停下來審視和集體改進，建設上下遊的尊重融合。
八、疊代計劃和估算
使用者故事的計劃就像購買貨物，價格就是估值，預算就是時間，盡量晚做出基于最佳資訊的決定，降低品質并不會減少工作量。
大團隊要縮小，就要學會把大問題轉化為小問題，進而可維護，可追溯。為了提高團隊的瓶頸吞吐率，嘗試把限制轉移到團隊以外(這需要主管的認可)，把推模式變為拉模式。
軟體設計品質則依賴核心人員的本能，思考，經驗。
九 合同。和客戶簽訂可協商範圍的合同，甚至嘗試按次付費（有利于與客戶的快速回報），關注初次産生收益的周期，盡快對外呈現出産品優點。客戶隻為系統現在或将來功能制品付費，其他都是浪費。
有價值的項目文檔應在開發完成後盡快完成，不能為了文檔增加基本的開發周期。
十 最佳的面試方法：先讓候選人和團隊工作一天吧。