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