1XP極限編程
xp體系
Extreme programming （XP極限編程），是由Kent Beck所發展，XP聚焦在軟件開發的最佳實踐，其迭代周期通常比Scrum的沖刺周期短，最短為一周，主要運作機制是讓團隊及客戶高度聚集。XP也是使用用戶故事描述用戶的需求，通常用戶故事會有一系列的Acceptance tests（接收測試）與Acceptance criteria（接收原則）。由客戶定義接收原則及Test cases（測試用例），再由團隊以結對方式編程開發。每一個用戶故事代碼開發由程序員兩兩結對一起工作，一個看大方向，一個編程細節，并定期角色互換，以撰寫符合測試用例的代碼。
季度循環
XP團隊一次計劃一個季度的工作。即XP按照一個季度進行規劃，所以XP團隊每個季度召開會議來進行規劃和反思。開會并反思過去這個季度發生了什么，討論全局問題：公司關注什么，團隊如何融入其中。計劃這個季度的主題（目標），明確其長期目標（主題就是一個總體目標，用來將用戶故事分組組織在一起）。計劃這個季度的代辦列表，為此要與用戶和相關方會面，挑出下一個季度最有價值的用戶故事，可以從這些故事中選擇一些放入到后續的待辦事項列表中。
周循環
即一周迭代，XP使用一周迭代，在這個迭代中團隊要選擇用戶故事，并構建這一周結束時“完成的”可用軟件。每個循環開始時會召開一個會議，在這個會議上將演示可用的軟件，并如下計劃他們打算實現的目標：
1、審查到目前為止的進展，并演示他們上一周的工作成果。
2、與客戶一起選擇這一周的用戶故事。
3、將用戶故事分解為任務。
雖然也可能會分配任務，但是XP團隊自我認領任務為主，周循環是在周二或周三開始。為什么不是在周一開始，因為周一開始周五結束，到周五沒完成，會有加班的想法。其目的就是杜絕加班，所有在周二或周三開始，在下周一或二結束，可以給自己激勵。
松弛（Slack）
團隊創建計劃，會增加松弛，即加入少量可選或不太重要的選項，如果將來進度開始落后，可以選擇去掉這些工作項。例如：團隊可能在周循環中包含“可有可無”的用戶故事。一些團隊只會加入1-2個松弛項，而且松弛項所占時間很少會超過周循環的20%。
xp價值觀
價值觀：勇氣、尊重、溝通、簡單、反饋。
勇氣
xp團隊有勇氣接受挑戰。
xp團隊有勇氣為他們的項目挺身而出。
xp團隊有勇氣丟棄現有的糟糕代碼。
尊重
團隊伙伴相互尊重。
團隊中的每個人都信任彼此能完成任務。
即使不喜歡，也相信和認可對方的選擇。
溝通
xp團隊通過信息發射源，讓他們的工作可視化，透明化。
xp團隊利用滲透式溝通，進行潛移默化。
團隊編程是社交性的，不是孤立的活動。
溝通幫助程序員進入“涌流”，而不是絕對安靜的環境。
反饋
迭代不是等工作全部做完做大型演示，只是做一小塊工作，獲得用戶反饋。用戶會對其需要的東西越來越了解，以便后續不斷調整計劃。
集成代碼，本地代碼如果與團隊其他人文件版本不同，會帶來很大問題，需要經常將你的新代碼與團隊其他人的代碼集成，能得到更早的反饋，集成得越頻繁，發現沖突就越早，解決起來就越容易。
隊友審查，Linus定律（李納斯定律）：“足夠多的眼睛可以讓所有bug無所遁形”。從隊友得到反饋可以幫助你發現你的代碼問題。幫助隊友了解你構建的是什么，以便他們以后處理你的代碼。
單元測試，或自動化測試，確保你構建的代碼能正常工作，單元測試通常與其余代碼一起存儲在文件中。對代碼做一個修改時，會測試失敗，這是你得到的最有價值的反饋。
10分鐘構建，團隊會維護一個自動構建，該自動構建包括編譯代碼、運行自動測試以及創建可部署的包。要確保這個自動構建運行時間不超過10分鐘。這樣能夠了解代碼是否出現問題，及時得到反饋。如果構建能很快運行，團隊中的所有人就會愿意在需要時盡可能多地運行構建。
線框圖（Wireframes），線框圖是快速描繪產品或解決方案的藍圖設計工具。在軟件開發過程中，線框圖可以拿來描繪顯示頁面中不同區塊及連接畫面的信息流方向，進而確認干系人對于最終產品的功能是否同樣的認知。若是認知上有差距，線框圖就成為視覺輔助工具，借由不斷的討論與微調，直到干系人達到共識為止。線框圖是低寫真的模型視覺展現，優點為快速且低成本，可輕易獲得反饋的溝通方式，其機動性很強，可以隨時進行調整。
使用線框圖的目的，就是協助理清干系人心中的Done是長什么樣子、怎樣才算完成？在投入大量精力前，先確認團隊與客戶雙方的認知是相同的。一個好的線框圖特性：
1.議題可以圖示化展示以便討論。
2.可有效溝通雙方想法。
3.可確認認知是否一致。
4.能夠快速取得客戶反饋。
探測（Spike）spike是Risk-based spike的總稱，在Agile觀點里，Spike都是針對風險的探測。通常在一有限的時間盒（Timebox）期間執行，通常是在迭代之前進行工作或實驗，用以獲得特定問題的知識或確認解決方案的可行性。XP提及風險探測可以當作是用戶故事來管理，但需要小心，因為探測并無法提供客戶價值。
若風險探測本身為技術開發的必要條件，則優先做探測（其優先級高于其他的用戶故事，因為要確認是否造成項目的Fast failure（快速失敗））。但是，若有許多技術方案可選擇，其中一個方案有不確定性，需要做探測才能得知是否可行，則我們會選擇不做探測，因為風險探測是不得已的最后手段。
簡單
1、如果一個單元的代碼做的事情太多，就會很復雜，要盡量一個單元的代碼只做一件事，要降低復雜性，最有效的方法之一是把它分解為更小單元。
2、重構現有代碼，代碼無法一次就寫到最好，不斷重構來降低代碼復雜性。
3、好習慣比紀律更有效，要養成以上兩點的良好習慣。
xp實踐
1整個團隊（Whole team）
指所有對xp項目有貢獻的人，坐在同一個辦公室里一起工作。團隊包含：客戶代表、代碼設計師、商業分析師及Quality Analyst（qa品保人員）。xp鼓勵通才，避免專人專用，可以工作論調、Pair programming（結對編程）等作法，以達到資訊分享，避免人才流失影響工作或產生斷層，xp團隊沒有指定的角色。
集中式與分布式團隊（Co-located and Distributed Teams）
集中式或分布式團隊一般是以Physical Location（實際距離）來看，并考量：
1.團隊是否有共同工作區域。所謂共同工作區域指的是團隊每日工作都是在同一專屬空間，又叫War room（作戰室）。
2.團隊的每個成員是否都集中一起（一般10米之內），實際距離所影響的不僅是團隊合作的程度，也會影響信息的分享。敏捷強力推薦集中辦公，可以產生以下途徑提升溝通效能：
主動式途徑Face-to-face communication（面對面溝通）
被動途徑Common open area（共同開發空間）
集中式團隊（Co-located Teams）
敏捷團隊理論的理想狀態，為了發揮最大及最好的溝通效果，團隊應該是集中在一起工作。何謂一起？實際范圍直徑是10米，超過10米則為分布式團隊。好處1面對面的溝通是常態。2文檔的書寫量可以減至最低。
集中式團隊還能提供兩種特別信息分享的模式1.Osmotic communication（滲透式溝通）2.Tacit knowledge convey（隱性知識傳遞）。集中式團隊的挑戰：
1.缺乏個人隱私：敏捷建議Caves（私人洞穴）and common（共同空間）以平衡滿足團隊合作與個人空間的需求。
2.人員數量限制：若是項目的規模大，敏捷建議將團隊分割成子團隊，以維持各團隊的人員數在建議值之內。??
團隊空間是完全開放無隱私的，為了保障個人處理私事（例：接聽私人電話），敏捷方法建議在團隊空間旁邊，開設另一個空間，給予團隊成員處理個人私務使用，這個模式叫做Caves（洞穴） and Common（公共區）。
滲透式溝通，指團隊成員對話中的信息流動，對其他成員來說，就是無意中聽到的信息。集中式團隊讓團隊成員彼此的距離縮小到像是一起辦公一般，成員間相互流動的信息就成為環境背景噪音。當下滲透式溝通發生時，成員間問與答的信息，在幾近零阻隔障礙下，很自然而然在所有成員之間流傳及散播。滲透式溝通就像雷達波一樣，信息傳遞有一定距離限制；成員相距越近，效果越顯著。
2規劃游戲（Planning game）
主要目的是期望將規劃效益最大化。XP包含兩個主要的Planning games：發布規劃及迭代規劃。Release（版本發布），是將新的功能或特性發布至正式環境給用戶，一個項目通常有一道多個Releases。
3小版本發布（small release）
聚焦在Minimum Marketable Features（MMF；最小可售特性）以降低開發復雜度及提升產出價值。XP鼓勵頻繁的小版本發布，發布軟件給客戶使用，讓客戶更密集的參與版本發布活動。在迭代階段，可定期展示進度及提升項目對客戶的Visibility（透明度），Release階段，快速的將可正常運作的軟件給使用群組。
4客戶測試
客戶測試演示了客戶定義的系統功能。客戶測試的好處是，確保有問題時可以隨時獲得客戶的實際反饋。客戶測試是定義項目所需功能的重要部分，客戶描述一個或更多的測試條件并實際測試，確保軟件可正常運行。在XP，客戶主要責任：
1.寫用戶故事。
2.定義用戶故事的Acceptance criteria（接收原則）。
5集體代碼所有權（collective code ownership）
指在XP實踐中，多位開發者同時進行代碼設計與開發，共同修改代碼質量或提升效能。這代表許多人在修改同一份代碼，如此可提升團隊的知識及代碼的透明度。此做法讓更多人看相同的代碼，可產生高水準的質量及更快發現缺點。由于Responsibility（執行責任）和Accountability（負責）都已分擔給團隊，因此團隊成員對代碼都有責任。可以降低開發者離職所產生的沖擊及風險。
6編碼標準（Coding standard）
雖然集體代碼所有權可以讓項目的多位開發者修改同一代碼，但也可能因此造成問題。為了降低風險，XP團隊需要遵循一致的編碼標準，以確保所有的代碼看起來都可以讓團隊中的每一個成員所理解并適時修改。編碼標準包含：檔案命名、函數命名規則、編排方式、括號原則等。在相同組織里的不同團隊，可使用不同的編碼標準。只要在開發前團隊有共同的認知即可。團隊有代碼成敗的共同責任。
7可持續的步調（Sustainable pace）
XP認為項目的高生產力是由團隊在可持續的步調中所達成。雖然長時間的工作可能是必要的。但持續的長時間工作，會導致質量不穩定及成員生產力降低，更可能進一步造成員工生活失衡而離職。可持續的步調是在項目開發過程中保持團隊可接受的一致的工作負載與生產能力，此作法可持續提供最佳的長期價值給客戶。
8隱喻（比喻）Metaphor
XP使用比喻來解說系統設計及分享技術愿景。這些描述可讓不懂技術的干系人易于了解系統如何運作。例：將Server load balancing （服務器負載平衡），比喻為大型超市的多臺收銀機，可有許多人排隊，以避免大排長龍及等待時間過久。可以使用通用或常見的名詞以表達不同的元素。例：Chickens（雞；說話的人）、Pigs（豬；做事情的人）等比喻名詞。
9持續集成（Continuous Integration）
是將不同開發者所撰寫的代碼整合在一起，確保軟件可被匯編及正常運作。XP實施持續集成，開發者通常將代碼放入Code repository（代碼倉庫），每次將新功能整合進系統，整個系統會自動執行所有測試。可能一天執行好幾次。可在更多的代碼或設計不相容之前，將問題浮現在臺面上，即時通知開發者修正，減少bug與產品缺陷。
持續集成-驗證與確認。利用自動化系統（版本控制系統）。將新增或修改的代碼編譯，融入既有的代碼庫。持續集成通常應用在開發者Check in（檢查） 新代碼的時候，后每隔一段非常短的時間自動執行。好處是可以在不同人員撰寫代碼及Check in（檢查）時，降低彼此代碼相容性問題的發生，是一種提供代碼開發者及早發現與解決問題的機制。
持續集成帶來優點如下：
1.提供保護機制，可讓代碼設計人員不畏懼進行編程，系統隨時可以恢復到Last known bug free（最后無缺陷）的狀態，讓開發者可以盡情發揮，不會綁手綁腳。
2.提供立即反饋，指出問題點在哪?讓團隊可以盡早修正，降低變更成本曲線。
3.確保代碼庫保持在最新狀態且經過測試驗證。
4.收斂技術債務，避免在版本（發布）前才手忙腳亂處理代碼缺陷。
缺點如下：
1.需要主機設備以及設定持續集成軟件的時間，這些工作通常在Iteration0（0迭代）的階段完成。
2.需要采購主機服務器的成本，通常是一臺專用主機。
10測試驅動開發（Test-driven development）
測試驅動開發（TDD）是XP方法論的關鍵實踐，確保良好的測試涵蓋范圍，讓問題可以在代碼發展初期及早發現。此做法中，團隊把測試條件先寫好，在寫代碼。當通過測試，則代表代碼編寫正確，此作法可以縮短測試的周期反饋時間。
先把測試用例與測試代碼寫好，在進行代碼編程的循環開發方法。詳細步驟如下：
1.Add tests（撰寫測試），針對開發的產品特性先寫測試代碼。
2.Run tests（執行測試），此時測試結果一定是Fail，因為產品代碼尚未開始撰寫。
3.Write code and run tests （編寫代碼并執行測試），執行所編寫的代碼，直到通過所有測試的檢測為止。
4.Refactor（重構），最后在不更改原有功能的前提下，將通過測試的代碼重構優化。
優點如下：
1.直接面對需求保持單純。
2.提早偵測代碼缺陷。
3.應用多元小型可測試的單位，組成更有彈性的系統。可提前理清功能性問題，進而控制設計的單純性，提高客戶滿意度。
4.執行強化重構的基礎，能夠有效提升產品質量。
TDD強調Red、Green與Clean（紅、綠、凈）的先后順序，以下為重構的判斷標準：在無代碼的情況下，寫下的測試，測試結果為失敗：紅燈。
持續撰寫及修改代碼，一直到通過測試為止：綠色。
此時開發者開始重構優化已通過測試的代碼：凈化。
11重構
Refactoring（重構），是在不改變代碼原有功能的前提下重組代碼，提升現有代碼的質量與運行效率，讓后續代碼設計的新增或變更可更容易實施。重構聚焦于移除不必要的代碼、簡化代碼的復雜度、降低代碼的Coupling（耦合度）及提升Cohesion（內聚度）。
技術債務（technical debt）
又稱為Design debt，是項目團隊為了短期利益，而降低產品質量所造成的質量負擔。技術債務如同貸款一般，越早還債，就越容易解決，越晚處理，問題就像滾雪球越來越大，成本也越高。積累的原因：
1.Making poor design decisions 不良的設計決策
2.Making decisions too quickly 太快做決定
3.Not fixing errors right away 沒有即時修正錯誤
4.Making code changes for the moment rather for moment為解決當下問題而修改代碼
12簡單設計（simple design）
Simple design（簡單設計），XP遵循一個審慎的設計哲學，偏向于“What is the simplest thing that could work？”（什么是最簡單有效而又能運作的產品？）每一個迭代重新檢查增量成品，確保目前的交付產出扔符合簡單設計原則。簡單的設計除了可以有效降低風險之外，也可實現更快速變更的目標，提升開發效率。
敏捷原則第10條就是合乎簡單設計的定義：Simplicity-the art of maximizing the amount of work not done -is essential（簡單是美，如何將不需要的工作項目數量最大化是重要的）針對設計，敏捷方法會問：在能夠運作的前提下，最簡單的產品是長什么樣子？為了要滿足全方位的需求，而打造復雜且多功能的產品特性，不是敏捷認同的設計理念。在簡單設計的原則下，產品設計要定期審視，盡量降低復雜度以確保設計合適。
Complex Design （復雜設計），是指當專注在打造非現今必要特性功能的設計，常會造成以下缺點：
1、增加項目負面風險。
2、增加未來變更的成本花費，且降低產品彈性。
3、增加產品維護與支援的成本花費。
4、減少可用在優先發展特性的資源。
5、產生追加假性功能需求的惡性循環。
研究指出，高達80%的軟件功能極少或根本沒人使用。
13結對編程（Pair programming）
結對編程，XP強調代碼是由兩兩一組的開發者所設計出來的，一個寫代碼，另一個對代碼進行即時審查。這個做法看起來很浪費人力，但是XP提倡，如此做法反而能減少更多開發時間，因為可在長期發現問題，且平時兩人建立知識分享，可以避免當有人離開團隊時所造成的沖擊。在項目執行過程中，配對的開發者，不一定是固定的，也可與其他組別互換人員。
XP極限編程的最佳實踐要求包括以下三點：
1.兩位代碼設計師坐在一起，共用一臺工作站。
2.一個人編寫代碼，另一個人擔任觀察者。觀察者的責任是立即審視剛寫出來的代碼。
3.兩人頻繁的互換角色。
這種一人注意代碼細節，另一個人注意邏輯全貌的方式，需2者功力相當，目的是要立即的檢查并糾正項目產出。
結對編程好處：
1、Better designs 較佳設計
2、fewer defects 較少缺陷
3、More accurate details 細節較正確
4、Real-time code reviews 立即代碼審查
5、Reduced technical debt 減少技術債務
2精益敏捷開發
精益思維
Lean Software Development（LSD；精益軟件開發）是以制造業Lean manufacturing（精益生產）法則延伸而來的，精益體系提倡》ean portfolio management（精益項目組合管理）與精益的七大原則。精益是一種思想，而不是一個方法論，精益項目組合管理的主要精神是：
1、聚焦能夠快速完成的工作，故所挑選的項目越小越好。
2、透過將WIP（在制品，正在制作當中的產品）最優化以消除工作瓶頸，提升開發速度，降低產能的浪費。
TPS思想
自働化（Jidoka）：創建自動化方法，只要檢測到問題就停止生產。在TPS中，流程中的每道工序都有自動化檢查，確保一旦發現問題就在當前位置修正，而不會推到下一個工序。
看板（Kanban）：發出信號的卡片。TPS制造系統中使用看板卡片知識流程中的一個工序已經準備好接受更多庫存。
拉動系統（Pull System）：流程中的每個工序在零部件消耗完時指示上游工序的一個工序需要更多庫存。通過這種方式，可以按最高效的拉動系統，而不會變得不均衡或者需要應急儲備。
根本原因分析（Root cause analysis）：明確導致某種情況發生的“深層”原因。Taiichi Ohno（豐田生產方式的創始人大野耐一）采用5問法，來找出根本原因。
改善（Kaizen）：持續改善。只有當團隊注意到工作流中發生了什么并提出改進建議時，加入改善日常功能的活動才是有意義的。
精益思維工具（查找浪費、價值流程圖、排隊論、拉動系統、選項思維、延遲成本、度量）
排隊論
精益團隊使用排隊論來確保人們不會工作負荷過重，使人們有足夠的時間并且采取正確的方式工作。軟件開發中往往有一些需要優化的隊列，如產品待辦事項列表，往往先進入的任務也是最先完成的。精益思維要求團隊的工作列是共有的，要讓其成為決策流程的中心，幫助團隊更快地交付工作。精益團隊經常使用排隊論嘗試在系統中增加隊列，以均衡系統中的工作流。
拉動系統
團隊使用代辦列表組織所有的工作，開發人員完成了一個任務時在選擇一個新任務，這就是在使用拉動系統。待辦列表不是由用戶、經理或PO向團隊推送任務、特性或請求，而是將請求加入隊列，團隊在拉取需求。拉動系統要求保證一次只處理一個工作，有人空閑下來可以處理新工作時才會把工作拉入流程的下一個階段。如此人們可以盡其所能地完成好他們承擔的各個任務，在強調質量和效率的前提下構建產品。
選項思維
團隊在決定下一個版本要包含哪些特性時，實際上只是確定團隊可以選擇哪些選項，從而為每個發布交付價值，而不是與用戶的承諾。
Scrum團隊不會花時間描述和跟蹤任務之間的依賴關系，實際上，在每日站會上，團隊可以在任務板上自由地增加和去除任務，這些任務是選項，而不是承諾。這些任務沒有截止日期，不會有所謂“落后的”任務導致項目的其余部分錯過最后期限。團隊將工作計劃想象成選項，就能在需要時做出調整，確保他們盡其所能地完成產品工作，而不會過度承諾。
延遲成本
延遲一項任務所付出的成本，高風險任務比低風險任務的延遲成本高，低風險任務即使在規定時間盒內沒有完成也不會有太大影響。團隊需要了解隊列中各個任務的延遲成本以便進行決策。精益團隊會為發布新特性建立交付節奏，并不是承諾按一個特定的時間表交付一組特性，只承諾盡其所能地交付最大的價值。
最小可售特性（Minimum Marketable Feature）
（MMF；最小可售特性）由客戶或PO所定義，是最小產品群組功能，可提供用戶價值。此MMF是已經可讓用戶使用或進入市場銷售。（例如：1投影機要能投影及連接電腦功能，兩個功能若少其一，對用戶是不完整的。故齊全才能讓用戶使用投影機簡報。2手機要能接聽電話及撥打電話。3數字相機要能拍照、預覽照片及匯出照片）
若比較MMF和Backbone（骨干）及Walking skeleton（可行走的骨架）：MMF指產品對客戶有價值。產品上市時，若客戶會買單，就代表達到MMF的需求。骨干是產品必要的元件（一定要有）例車子的引擎、剎車、排氣系統等。Walking skeleton是產品能夠基本運作的元件。例車體、方向盤、剎車、電路及傳動系統等。換句話說，MMF是從客戶的角度來看，而骨干和可行走的骨架是從開發團隊技術角度來看。
最基本可運行產品（Minimum Viable Product）
概念就是：在最精簡的投入下產出的產品，并且能得到反饋的價值是最佳話的。MVP要能夠滿足最基本的功能需求，而且是立即可以使用，完全沒有額外多余的特性。
精益項目管理的優點
1、speed and quality（兼顧速度和質量）
2、Line of sight to business needs（調整與營運需要同步）
3、Minimize work in progress（最小化WIP-在制品）
4、Minimize interruptions（降低干擾及中斷次數）
精益原則
（1）消除浪費
就是相對的增加或提高價值。任何不能夠帶來價值的資源投入，就是浪費。如何消除浪費？
1、See the waste（識別浪費）
2、使用Value stream analysis（價值流分析），可將整個Process flow建立起來后，針對識別的浪費，發展對策使其消除或減輕。
TPS三大浪費來源
1Muda（浪費）：指一切不為顧客創造價值但卻消耗資源的活動，這表示“無價值、無用、閑散、過剩、浪費、廢物、資源浪費等”。
2Mura（不均衡）：指生產運作的不平衡，這表示：“不平均、不規則、不統一、無統一性、不均等”。
3Muri（負荷過重）：指超載的設備或是超負荷的工人，這表示“非理性、不可能、超出某人能力、過于困難、被強制、過量、無節制”。
根據這三類浪費，精益軟件開發衍生出7大浪費。
價值流程圖（Value Stream Mapping）
是一種精益的系統性方法。借由透過圖示化分析目前過程的價值、找出浪費，改善過程效率；如下圖
價值流改善對象可以是特定的產品、服務或是一系統產品的組合，可讓我們改善產品生產力的過程，已提供改進的策略及提高競爭優勢。相同的過程，套用的不同對象時，會有不同的過程循環效率。例：母親帶小孩去買ps5游戲機，30分鐘游說小孩不要過度沉迷，20分鐘挑選，10分鐘結賬。對小孩有意義的只是后面30分鐘，對媽媽則是60分鐘。
（2）強化學習
是在迭代結束前，借由持續不斷地反饋機制，改善下一個迭代的作法。將產品展示給客戶，以強化及修正對產品的認知。以內部的回顧會議來改善過程的效率。最有效的學習是短周期的學習循環，故迭代的回顧會議是典型強化學習的作法。比長期之后發現問題，再學習來得好。
（3）盡可能晚做決策
針對產品方向及未來目標的不確定性，強調任何重大的決策，越晚做決定越佳。信息越晚越明確，越晚做決策，可挑選的決策選項就越少了，確保決策的準確性。可大幅度降低因太早做決策，而造成晚期大量變更所帶來的風險。最晚的決策點是“The last responsible moment（最晚回應時刻）”，在這個時刻之后，就沒有必要再做決定了。
（4）盡肯能快交付
以增量方式提早交付產品，可獲得下列利益：
1、確認開發方向是正確的。
2、提早讓客戶實現產品能夠帶來的價值。
3、提早發現問題并修正。
（5）授權團隊
讓團隊成員自己做工作相關的決策，管理者僅適時領導。采用Pull systems（拉式系統），讓團隊自行挑選該迭代所要完成的工作事項。工作不是由管理者指派，而是由開發團隊成員主要決定。
（6）內建質量
強調產品的質量，應是項目過程中，與客戶建立一致的質量認知與觀念。在開發產品過程中，將質量做出來，并持續的維持質量水準，而不是靠后期的檢查與確認，來發現產品缺陷。借由不同程度持續測試機制，如：持續集成、小版本發布及重構，以確保整個產品的質量。
（7）縱觀全局
看到以下四個方面全貌：
1、在團隊方面，注重團隊整體的表現。
2、中項目方面，同步調整許多項目的目標使之一致。
3、在跨職能團隊方面，強調整體運作的和諧。
4、在對外談談方面，聚焦在創造雙贏局面，像是簽訂雙贏合同。例：Change for free合同，若客戶參與過程的開發，則可讓客戶在迭代之間，免費調整優先級。
看板體系
看板（Kanban Board）
Kanban在日文代表看板、布告欄的意思。版本來自Toyota制造系統，其概念是設計一個生產管理系統，將零件的倉儲水準控制在最低點，當需要的時候才以Just in time （JIT；即時產生）的方式拉動生產。應用看板可形成Pull-driven flow（拉動向導）機制，即在有需要的時候才開始生產，避免囤積多余產出的風險。（例：大量產出才發現缺陷，需返工數量太多）Kanban的三個簡單原則：
1、Make work visible（讓工作視覺化）
2、Limit WIP（限制進行中的工作）
3、Help the work flow（促進工作順暢進行）
Kanban將項目的工作狀態，貼在明顯的信息發射源，以逐步完善目前工作排程，當做是項目績效的主要測量工具。Kanban是屬于Low-tech、High-touch（低科技高感觸）工具，可使團隊共同規劃及維護項目的狀態。
看板可明顯看出WIP的任務量有多少，可有效限制WIP的數量，這也可以當作是Agile項目的控制界限。限制WIP的數量是為了最佳化工作流量，使工作不塞車，而非將資源（人員）的使用率最大化。為確保Cycle time（循環時間，周期時間）的最小化，團隊通常會在看板上的用戶故事卡片寫上開始日期及結束日期。看板與任務版最大差異在于看板上的用戶故事或任務在每一次迭代都不重新清零。
在制品限制（WIP Limited）
WIP是Work in progress，指過程中工作，代表已經開始執行但尚未完成的工作。太多的WIP會有以下問題：
1、綁死資源，但看不到價值的產出。
2、會隱藏工作瓶頸（想象只有1項進行中的工作，若做不出來，是很容易看出瓶頸？若同時有10項工作進行中，則不容易看出哪項工作造成瓶頸）
3、若此時出現變更，大量正在進行中的工作會變成沒有必要的工作，而且需要返工。
看板的核心實踐步驟
1、可視化工作流：為當前使用的流程圖創建一個示意圖。
2、限制WIP：觀察工作項在系統中如何流動，并嘗試限制每個步驟中的工作項數，直到工作能均衡流動。
3、管理流動：度量交付時間，查看哪些WIP限制使得向客戶交付特性的時間最短。試著保持穩定的交付速度。
4、顯示化流程策略：找出知道團隊做決策的未成文規則，并記錄這些規則。
5、實現反饋回路：對流程中的每個步驟，建立一個檢查來確保流程是可行的。度量交付時間和周期時間，確保流程沒有減慢。
6、協作式改進：分享你收集的所有度量結果，并鼓勵團隊提出建議繼續進行試驗。
周期時間【循環時間】（Cycle Time）
是指要花多久的時間把特定的事情完成。如：一個用戶故事從團隊開始進行開發，直到完成普通的測試，稱為循環時間。
Project cycle time（項目循環時間）是指項目所有工作的循環時間平均值，而不是所有工作的循環時間總和。
Worker in progress（WIP；過程中工作）是指任務已經開始執行，但是未完成測試驗收的狀況。WIP與循環時間息息相關。
團隊在單位時間內完成的工作量叫做Througput（生產率）和循環時間及WIP三者之間的關系為，WIP/Througput = Cycle time
例如工廠生產率為1000組/天，WIP為2000組故意循環時間=WIP/Througput=2000/1000=2天
敏捷項目與傳統項目最大的不同在于敏捷手法強調最佳化WIP，就能降低循環時間,并以追尋最佳循環時間為目標。
交付時間【交付周期】（Lead Time）
交付時間是指從客戶下單到接受產品所需的時間。在軟件開發領域，則只從客戶提出需求到需求上線所需的時間。應用看板管理方法，測量項目進度方法是使用，交付時間而非速度，其項目績效聚焦于降低交付時間，而不是增加團隊的速度。
交付時間（Lead time）和周期時間（Cycle time）不同。交付時間站在用戶觀點，即從形成用戶故事，到用戶故事實際上線所需的時間。周期時間站在開發者觀點，即開始開發用戶故事到完成用戶故事所需的時間。
積累流圖（Cumulative Flow Diagrams）
累積流圖（CFD）可用以追蹤及預測項目進度，協助找出項目的問題。
循環時間【周期時間】是工作或產品的制作時間（完成時間-開始時間）
可以使用Goldratt’s Theory of Constrains（TOC；限制理論）找出工作的瓶頸限制。如下圖
當某一工作的WIP越來越寬，下面那一層即為工作瓶頸，為避免過程限制，盡量不要專人專職，而是一人多功相互支援。
團隊工作協議（Team Working Agreements）
又稱為Ground rules（基本規則）是一種團隊的項目運作規則。由團隊共同提案、共同討論、共同決議，作為日后共同遵守的工作原則，是團隊運作更有效率及效能。團隊工作協議可與每個迭代結束前的回顧會議時修正。團隊工作協議通常貼在信息發射員讓團隊都可以看到。
團隊章程（Team Charter）
敏捷項目需要有章程，團隊組建也需要有章程。將團隊組建產出的共識給予書面化，可賦予團隊良好的心理建設。團隊章程由團隊共同討論以下項目：
1、Core Values （核心價值）
2、Strengths （團隊優勢）
3、Logistics（后期支援）
4、Team Working Agreements（團隊工作協議）
