概覽
自序
精益原則要求:
企業(yè)要將具有最大商業(yè)價值作為軟件開發(fā)的方向
團隊擁有自己的系統(tǒng)并持續(xù)不斷的改進系統(tǒng)
管理層培訓并支持團隊工作
認可高品質的工作
目標將管理層和個人結合一起，達到“全局優(yōu)化”
整個企業(yè)：整合企業(yè)、團隊和個人以最佳狀態(tài)合作
整個產品研發(fā)過程：不只是包括開發(fā)谒府，也包括維護和集成
全部時間：不只是包括當前命锄，也包括將來衣洁。我們需要為得到可持續(xù)的投資收益率而工作
引言
兩種方式看待敏捷：
敏捷是一套價值觀和信仰體系屎鳍，實踐者需要判定該如何應用敏捷
敏捷是一套實踐理論焙矛，實踐者需要證明敏捷具有良好的效果
實踐者通常結合兩者痪枫，信任敏捷宣言指令并運用Scrum或極限編程作為他們工作的基本原則，但這種工作方式會面臨雙重挑戰(zhàn)凛辣，一個來自敏捷的根源抱既、一個來自敏捷實踐本身缺乏理論基礎
原則和范式：
原則是一種綜合的基本法則、學說或假設
范式是假設扁誓、價值觀防泵、信念和實踐的組合蚀之，定義了如何評估現(xiàn)實狀況，如何看待實際形勢捷泞。它是一種世界觀足删，描述了真理的特性
需要務實的方法去論證范式，并批判過程锁右、團結協(xié)作
瀑布模型的核心理念：
敏捷的核心理念：
Scrum?一種最受歡迎的敏捷方法失受，基于精益原則產生，但軟件行業(yè)對于精益的了解并不廣泛咏瑟，開發(fā)團隊會因此失去精益可以提供的有潛力的開發(fā)指南拂到。
精益的核心理念：
精益提供了這樣一種管理范式：在合作的基礎上，通過重視團隊工作的過程-?該過程必須是使團隊能夠順利完成任務的最好過程-?來管理團隊码泞。通過這種管理兄旬，過程不再是強加于團隊的東西，而是被團隊靈活應用余寥、使他們工作更有價值和更令人愉快的東西
精益管理范式結合了概念领铐、工具和實踐，提供給雙方（管理者和開發(fā)人員）一種合作方式去提高管理的可視性宋舷、管理的方向和團隊的生產力
本書也吸收了部分來自非精益的實踐原則绪撵，但這些非精益的實踐原則在其他方面是與精益的中心原則“全局優(yōu)化”保持一致
第一部分?拓寬視野
與實施執(zhí)行階段相比，許多項目實際上是在啟動階段耗費了更長的時間祝蝠；因此音诈，縮短啟動階段的時間是縮短產品上市時間的一個關鍵：
選擇正確的開發(fā)產品或增值產品，最大限度的提高投資回報绎狭，是團隊高效工作
從全局著眼改艇，從項目的具體工作著手
為軟件開發(fā)或軟件增強功能部署開發(fā)人員
第一章?精益軟件開發(fā)-?敏捷開發(fā)者指南
精益
豐田公司在汽車生產和汽車研發(fā)時所使用的豐田生產方法的名稱
精益應用于組織的多個層級
業(yè)務部門：
不斷優(yōu)化和分解企業(yè)的增值需求
管理業(yè)務需求組合
發(fā)布計劃
管理部門：
公司跨職能團隊提供端對端交付增值任務的功能
管理價值流團隊
幫助消除障礙
交付團隊：
每天都在一起工作，并交付經(jīng)過全面測試和集成的代碼
學會如何交付業(yè)務增量需求
精通驗收測試驅動開發(fā)和重構
精益思想的快速回顧
多數(shù)錯誤源于系統(tǒng)本身坟岔，因此必須對開發(fā)的系統(tǒng)加以改進
為了改進系統(tǒng)，必須尊重員工
過早開始會造成浪費摔桦。只在需要的時候完成需要做的事情社付，這就是所謂的”準時制“或JIT（Just?in?time）
精益思想通過消除開發(fā)過程中的延誤來縮短產品的上市時間，使用JIT方法做事情比讓大家一致忙碌更加重要
- 查找錯誤的根源
當錯誤產生時邻耕，我們一般傾向于批評責任人鸥咖，實際問題的根源是這些人的合作方式問題
敏捷致力于提出好的方法去提供信息溝通的過程，同時不斷減少錯誤的數(shù)量
改善溝通是敏捷的主要目標兄世，但敏捷實踐往往只強調了局部層面的溝通：團隊內的溝通啼辣、團隊間的溝通、團隊與客戶的溝通
敏捷實踐沒有提供貫穿整個企業(yè)的御滩、溝通上級與下級的價值流
精益實踐鸥拧，重視端到端溝通的價值党远，提供了人人參與產品開發(fā)的環(huán)境，促使公司中不同層面的溝通更加頻繁富弦，強調了持續(xù)改進沟娱、全局優(yōu)化、盡早交付與頻繁交付
精益思想有助于消除由于浪費導致的延誤
- 尊重人
尊重管理層和員工腕柜，在過程中允許靈活性济似、持續(xù)的改進過程、吸引和留住高素質員工
將復雜程度和返工工作量最小化
- 消除浪費與推遲決策
在適當?shù)臅r間”最后負責人的時刻“做出決定：太早是你不能獲得所需的足夠信息盏缤；太晚會使你承擔更高成本的風險
在需求與分析階段推遲決策
敏捷方法指導我們去分析客戶最重視的需求來處理軟件開發(fā)項目砰蠢，同時注意系統(tǒng)架構風險，哪些需求被忽略將會造成系統(tǒng)出現(xiàn)問題唉铜，如果有台舱，這也是必須要注意的需求
在設計和編程階段推遲決策
當需要處理客戶模糊需求是，有兩種方法：只關注最簡單的需求幻枉，不去處理任何將來的需求熬甫；預計未來可能發(fā)生什么需求胰挑，為這些需求存在可能性的需求創(chuàng)建系統(tǒng)接口
還有一種替代方法稱為”浮現(xiàn)式設計“瞻颂，設計具體表現(xiàn)在3個方面：
利用設計模式過程的思想，創(chuàng)建靈活多變的應用程序體系結構
設計模式要實現(xiàn)的功能僅限制為當前的功能
編寫代碼之前編寫自動化驗收和單元測試，既提高了思維過程，又創(chuàng)建了測試工具
- 利用迭代開發(fā)最小化復雜程度與返工工作量
代碼復雜的兩大原因：編寫多余的代碼湃望、編寫緊密耦合的代碼
迭代有助于發(fā)現(xiàn)客戶的真正需求，防止開發(fā)無用的需求
浮現(xiàn)式設計能用”使用中的代碼“去解耦”使用過的代碼“术幔，而不必增加開發(fā)過程中不必要的復雜性
- 創(chuàng)建知識
敏捷過程泛源，分階段做需求調研没龙，只要發(fā)現(xiàn)客戶的需求，就去創(chuàng)建這部分需求，快速地交付有價值的軟件
產品開發(fā)3過程：發(fā)現(xiàn)客戶需求、知道如何開發(fā)產品、開發(fā)產品
- 快速交付與頻繁交付
延誤代表了浪費道伟，消除延誤將實現(xiàn)更快交付部逮，重點是為客戶增加價值
當快速交付的好處便得顯而易見時，以可持續(xù)方式去消除延誤就成了一種必須
- 品質為先
劣質代碼和難以理解的代碼也會造成時間浪費
- 全局優(yōu)化
精益思想來自一種規(guī)母凳拢化生產的狀態(tài)教届，一大轉變是放棄了優(yōu)化每個步驟的理念买置，更加重視提升生產過程中的效率城舞，即從生產周期開始到結束去優(yōu)化整個價值流
優(yōu)化每個步驟的問題在于脱柱，在每個步驟都有可能產生大量的庫存（部分完成的工作）椅邓，精益思想證明板壮，單件流（即重視制造一件完整的產品）是一種比集中制造其所有組件更快透葛、更有效的方法
快速-靈活-機動
- 重視時間
精益更重視縮短從提出概念到交付有價值的軟件的整個過程的時間，而非如何利用資源
精益角度靶草，如果我們堅持持續(xù)的改進過程，專注于更快的生產速度，那么制造成本就會降下來，以更少的錯誤和浪費獲得更高的產品質量；但實際工作方法通常只注重降低成本
軟件開發(fā)中的延誤：
需求被提出到被證實正確，所花費的時間
代碼被編寫到被測試，所花費的時間
開發(fā)人員詢問業(yè)務問題到得到解答拌蜘，所花費的時間
- 準時制（JIT）的反思
在每個階段真正需要之前烤芦，才去做分析、設計、編碼和測試等具體工作事甜，有助于找到阻礙項目過程的原因
價值流圖
價值流是一組為客戶增加價值的活動陪蜻，從最初需求開始到價值的交付為止
價值流圖包括畫出價值流的過程圖形邻悬，并利用這些圖形來尋找浪費
價值流圖的重點是改進從開始到結束的全部過程所花費的時間，同時項目在未來也要保持一定的速度（不能以未來發(fā)展為代價而走捷徑）
價值流圖好處之一在于清楚的顯示全局的狀況
運用價值流圖獲知造成問題的根本原因
例：”現(xiàn)狀“價值流圖
價值流分析著眼于大局，重視客戶反饋坟漱，實施”將要“價值流圖
精益超越敏捷
精益為敏捷實踐在新的情況下的應用提供了指南
把重點放在開發(fā)時間上而非資源利用上
要重視全局優(yōu)化觅捆，而不是試圖讓每個步驟都盡可能高效
敏捷通常只關注項目庸论、團隊、軟件趋观，缺乏遠見；精益引領我們超越敏捷，關注整個企業(yè)，研究如何選擇增值產品，以及如何在公司結構下組織團隊工作
敏捷方法通常無法為這種情況提供幫助：系統(tǒng)缺乏良好結構而開發(fā)團隊又必須為該系統(tǒng)工作
總結
精益為軟件開發(fā)提供7項原則
尊重人、消除浪費、推遲決策、創(chuàng)建知識屋匕、快速交付进泼、品質為先洋措、全局優(yōu)化
根本目標
快速-靈活-機動
把開發(fā)過程看做一個繁忙的生產流水線，凡慢下來流水線就導致浪費，浪費包括延誤、錯誤渔工、誤解、等待資源，通過消除過程中的障礙，改進過程
為改進延誤與浪費，價值流是圖是一個重要的工具，用于分析過程
第二章?敏捷的商業(yè)案例
敏捷的益處
敏捷將通過一列方式，使企業(yè)和團隊受益：
快速提升商業(yè)價值
幫助客戶明確需求
促進基于知識的產品開發(fā)和更好的項目管理
激勵團隊和允許早起的失斀堋（從失敗中學習）
重視以產品為中心的研發(fā)
提高團隊效率
- 快速提升商業(yè)價值
投資回報：客戶越早開始使用產品赦颇，企業(yè)就越早收回投資
提高客戶滿意度：客戶也愿意更早獲得新的功能或改進的功能髓窜，使他們能更快的將產品投入使用
市場定位：維護或提升市場競爭力的最佳方式程拭，先于競爭對手推出有價值的產品功能，使產品看起來更新穎，具有滿足客戶需求的能力
低風險：快速響應，縮短客戶的反饋通道，盡早發(fā)現(xiàn)項目中的問題齿诉，及時修正產品或放棄產品，以減少企業(yè)的損失
更大的利潤空間：更快收回投資成本、更快的發(fā)布產品唤锉，通過增量交付更小的版本晒衩，進一步降低成本
功能越早發(fā)布意味著每個人能夠越早獲得價值：利潤、市場滲透脑豹、效用
- 幫助客戶明確需求
基于客戶所知道的那部分需求來啟動系統(tǒng)開發(fā)拌牲，從客戶的反饋中獲得更清晰的需求土居，然后在重復這一過程
盡可能少的去開發(fā)不必要的功能，更重要的是能開發(fā)出一套相對簡單的系統(tǒng)
- 促進基于知識的產品開發(fā)和更好的項目管理
沒有進入項目測試階段之前擦耀，不會知道代碼質量究竟如何棉圈，通常會帶來項目時間延后
短期計劃周期
敏捷的神話之一是不用做計劃，實際上需要不斷的做項目計劃分瘾，以較小增量或更多的人做計劃
發(fā)布計劃、迭代計劃吁系、每日計劃德召，利用15%的時間做計劃
為已知的事件做計劃整體上比未知的時間做計劃容易得多
測試改進開發(fā)過程及產品質量
一個精益原則：精益求精白魂、不斷提高
強烈推薦測試驅動開發(fā)任務的完成，為縮短開發(fā)并修復缺陷的周期時間氏捞，在開發(fā)過程早期就要開始做測試工作
無懼計劃
精益-敏捷項目中碧聪，總有一種緊迫感，因為項目周期短液茎，所有要與客戶保持緊密聯(lián)系一確保項目能夠按截止日期完成
激勵團隊和允許早期的失敵炎恕（從失敗中學習）
早期發(fā)現(xiàn)問題，進行調整捆等，避免浪費
重視以產品為中心的開發(fā)
沒有從產品的分步發(fā)布中獲得收益滞造，在產品發(fā)布之前，必須完成全部生產過程的研發(fā)（這種情況并不少見）
客戶能提供完美而清晰的需求（幾乎不會發(fā)生）
管理層相信開發(fā)團隊會開發(fā)出所需的產品栋烤，雖然該項目沒有通過迭代進行控制（有時發(fā)生）
開發(fā)團隊需要完成理解敏捷方法谒养，沒有學習曲線
提高團隊效率
精益方法，從開始新項目前明郭，先結束當前的項目并交付給最終用戶
更快的開發(fā)當前項目买窟，降低對關鍵人力資源的競爭，僅此一點就能提升團隊的效率
總結
敏捷給團隊和企業(yè)的六大益處：
快速提升商業(yè)價值
幫助客戶明確需求
促進基于知識的產品開發(fā)和更好的項目管理
激勵團隊和允許”早期的失敗“（從失敗中學習）
重視以產品為中心的開發(fā)
提高團隊效率
第三章?大局觀
以達到企業(yè)級敏捷為目標
團隊敏捷是必要的薯定，但遠遠不夠始绍。企業(yè)級敏捷使企業(yè)能夠比競爭對手以更快的速度為客戶提供質量更高的產品和服務
企業(yè)需要應對外部的競爭、需要更好的了解市場话侄、需要了解自身的缺點亏推、需要掌握不斷變化的技術、還需要了解任何可能對企業(yè)產生不利或積極影響的事情
達到企業(yè)級敏捷
企業(yè)級敏捷要求查看一個企業(yè)完整的價值流（交付軟件解決方案的流程）
企業(yè)級敏捷清楚的表明了（通過市場機會年堆、競爭威脅或業(yè)務需求來觸發(fā)）貫穿產品部署和使用整個生命周期吞杭，致力于縮短項目周期時間，并消除在此過程中產生的浪費和延誤
大多數(shù)敏捷專家主要關注團隊本身或團隊內部流程变丧，主要精力在項目級別和團隊面臨的挑戰(zhàn)上
技術方法芽狗，如設計模式和TDD會幫助團隊完成開發(fā)工作
Scrum和其他敏捷方法使團隊比以前更加有效，但同時也需要更多的指導以解決整個公司內部多團隊協(xié)同的工作問題
精益思想就提供了所需的方法和指導痒蓬，應對整個價值流面臨的問題和挑戰(zhàn)
如何為組織創(chuàng)造真正的價值
為了改進軟件開發(fā)方法，必須解決幾個重要領域的問題：
確定將要開發(fā)或升級的軟件產品一定是對公司的盈虧底線影響最大的產品
企業(yè)資源與升級產品（項目）要相互匹配
管理項目是以最高質量和最快的速度去開發(fā)產品增強功能
組織軟件開發(fā)團隊谊却，使其以最有效的方式協(xié)同工作
使用適當?shù)能浖こ谭椒ㄈ嶂纾摲椒寄苤С猪椖抗芾恚帜艽_保項目的長期可行性炎辨，并維持較低的開發(fā)成本
營造學習氛圍捕透，使過程不斷改進
- 確定價值
什么樣的產品將給企業(yè)帶來最大的商業(yè)價值
什么時候企業(yè)或客戶可以開始使用他們
從業(yè)務驅動觀點來看，而不是從軟件開發(fā)角度（我們的技術人員能做什么）
- 管理組織的資源
理想情況下，同一個人應該為一種產品工作乙嘀，并貫穿整個生命周期
許多項目進行中末购，對資源的爭奪太過激烈，以至于項目計劃制定要基于資源的可用性或政治影響力虎谢，而不是基于可提供的商業(yè)價值
極端情況下盟榴，項目團隊根本不存在，幾個人臨時湊一起婴噩，同時還會為其他項目工作
會導致很多問題：
人員被分配多多個項目擎场，工作效率下降
我們要求項目準時啟動和停止，以便人力資源在需要時被調用几莽；項目不斷的中止迅办、重新啟動，在加上信息等待章蚣，造成了生產力的巨大損失
受資源限制站欺，真正的關鍵項目無法加速完成
管理項目：
一旦開始產品開發(fā)，并分配好資源纤垂，必須要有效的管理項目本身
使用適當?shù)能浖こ谭椒ǎ?/b>
運用設計模式作出有品質的軟件設計和運用自動化前置測試是兩種需要開發(fā)團隊理解和應用的必不可少的基本方法
只重視開發(fā)團隊的開發(fā)速度其實是不夠的磺送，必須看到產品在全局中的作用-?在整個價值流中的作用
總結
從非敏捷開發(fā)到敏捷軟件產品開發(fā)的轉型坎弯，并不是孤立完成的纤怒。是在更大范圍內-?企業(yè)層面的靈活運用
企業(yè)級敏捷需要著眼于整個組織的價值流攒驰，從最初的概念開始魏身，到客戶可以使用該產品為止
第四章?精益組合管理
項目面臨的挑戰(zhàn)
改進產品開發(fā)方法的過程中格侯，軟件開發(fā)是項目面臨的一半挑戰(zhàn)
另一半挑戰(zhàn)來自要甄選出最重要的產品去開發(fā)
這種甄選的方法被稱為”項目組合管理“
項目組合
- 項目組合管理
項目組合管理包括一個有規(guī)劃的項目生命周期啸罢，組織使用項目生命周期來確定最大投資收益率的來源柒室，然后定義計劃去實現(xiàn)它
用戶提出的需求越多履磨，項目組合管理的規(guī)模就越大
項目組合越大蛉抓，就越難管理，進而導致更多的延誤
- 我們能使用批處理需求分析出現(xiàn)的延誤嗎
當分批處理需求時剃诅，先發(fā)布一個批次中最重要的需求巷送，然后發(fā)布批次中次重要的需求，以此類推矛辕，直至批次最后一個重要需求被發(fā)布出去
- 我們能通過增加發(fā)布來避免出現(xiàn)的延誤嗎
增加產品的發(fā)布頻率加速了構想和交付產品的時間
這種方法的好處是為企業(yè)提供了一份可預測系統(tǒng)實現(xiàn)的時間表笑跛，展示了快速交付產品的軌跡
如果構想到交付之前的時間過長，就表明了延遲聊品，作者認為這種想法已經(jīng)過時
精益組合管理
解決上述問題
目標：采用”快速-靈活-機動“的工作方式飞蹂，同時選擇的項目將給企業(yè)帶來更大的商業(yè)價值
精益思想通過首先交付系統(tǒng)中最重要的功能，盡量減少項目中在制品庫存
通過建立反饋機制和側重價值而非注重提前計劃一切事務的老方法翻屈，去關注軟件開發(fā)中的風險
- 精益組合管理有效的原因
允許干系人和客戶去定義和排列功能的優(yōu)先級陈哑，為企業(yè)帶來最高的投資收益率
精益組合管理方法是基于結果的驗證方法
精益思想認為，集中思想提交產品最重要的功能，最大限度的提高團隊工作效率（通過消除任務的切換和等候時間）和效果（工作產品的最重要部分）
-?確定計劃發(fā)布
精益同敏捷惊窖，建議不去關注太超前的迭代計劃刽宪，但需要早起做出的決定仍需盡早做出
不然會導致失敗，隨著對需求越來越多的理解界酒，知識也被納入了未來的增值規(guī)劃中
未來的功能可以在迭代中提前被解構圣拄，作為計劃發(fā)布功能的概念來表達，建立學習型組織毁欣，帶來了在可預見的能力層面的功能描述的評估
- 使用增量交付現(xiàn)在系統(tǒng)
企業(yè)通過分階段開發(fā)庇谆、商業(yè)價值驅動，實現(xiàn)系統(tǒng)的增量交付
增量交付還使企業(yè)能應對市場變化署辉，抓住在轉換項目過程中出現(xiàn)的商業(yè)機會
精益組合管理的益處
-?速度與質量
確定最小的可市場化的功能族铆，更快速的交付有價值的軟件
把價值交付和軟件質量視為一種可持續(xù)的行為，并通過短周期信息的反饋回路不斷改進
-?業(yè)務需求的視野
將功能和功能描述松散的映射一起哭尝，為描述項目愿景的業(yè)務解決方案或一個典型的項目章程
創(chuàng)建一個可視的圖形哥攘，業(yè)務功能被列出來，用于排列優(yōu)先級和衡量技術上需要付出的努力（這些工作必須被不斷的權衡）
-?最小在制品數(shù)量
確保團隊的工作總是聚焦在最高優(yōu)先級的產品
關鍵資源在較小的任務塊中更易于管理材鹦，這些資源是整個團隊必須共享的資源
如果工作任務較小逝淹，可以將減緩對珍貴資源的爭奪，使系統(tǒng)顛簸成本最小化
-?最大限度地減少中斷
工作在小塊任務中桶唐，中斷也更容易處理
可以讓項目經(jīng)理的緊迫任務等到團隊做完目前的小塊工作后再去完成
規(guī)避了迫使團隊不得不處理多任務的風險
精益組合管理方法
精益項目組合管理的基本方法是從業(yè)務功能的分類開始
需要跨職能栅葡、不斷整合的敏捷團隊在團隊能力的基礎上找出優(yōu)先排列的工作任務
取得所有項目的所有業(yè)務功能后，可以制定產品開發(fā)計劃
更短的計劃周期
考慮不同階段的時間尤泽，并縮短每個階段的時間：
等到計劃的平均時間
計劃花費的平均時間
完成花費的平均時間
評估和跟蹤進度
傳統(tǒng)的項目組合管理通常是針對計劃而不是針對創(chuàng)造的價值來跟蹤項目進度欣簇，有可能項目前期是綠燈狀態(tài)，后期就突然變成了紅燈
精益思想坯约，最優(yōu)價值的狀態(tài)指標是可工作的軟件熊咽，構建規(guī)模較小、功能完整的功能件簡化了持續(xù)集成的原則
避免了長期的集成周期循環(huán)和隱性障礙闹丐，是防止浪費的方式
通過建立業(yè)務功能的精益組合横殴，集中劃分優(yōu)先級，清楚的看到商業(yè)價值與成本
團隊指導如何為企業(yè)估算準確的項目支出卿拴，以確定最佳價值
評估使用像素點衫仑，由項目組合中功能百分比來確定
總結
精益生產方法管理項目產品組合優(yōu)勢：
精益組合的特征使業(yè)務人員和技術人員可以查看項目的投資收益率和所面臨的技術風險
使規(guī)劃人員可以分屏編入預算工作的經(jīng)配比，并建立最佳工作方式
使項目工作量可被準確的估算堕花，并順利進入大型敏捷機構中
使企業(yè)能夠簽發(fā)一種可預測的版本計劃文狱，確立以業(yè)務為指導的交付技術解決方案的方式
讓企業(yè)注重正確的工程實踐，企業(yè)級敏捷便會實現(xiàn)缘挽，從而促進企業(yè)變革如贷，加快產品上市時間陷虎，為企業(yè)帶來競爭優(yōu)勢
精益的本質是“快速-?靈活-?機動”
能夠通過生產流水線獲得更高的價值，選取最小的可市場的功能
確保正在工作著的任務是我們能構建的最小功能杠袱，提高了工作效率尚猿、更迅速完成工作、降低工作進程楣富、限制產能凿掂、消除延誤及避免系統(tǒng)顛簸
提高工作效率，提高了產品質量并降低了項目成本
第二部分?精益項目管理
管理是把事情做正確纹蝴，領導是做正確的事情庄萎。-?彼得.德魯克
一個獲得充分授權的組織應該是這樣的：它的員工要具備知識、技能和工作熱情塘安，并且有機會通過個人的成功引領集體的成功糠涛。-?斯蒂芬.科維
超越Scrum
兩種方法幫助團隊超越Scrum：Scrum#（嵌入精益思想中的Scrum）和看板工程（直接針對工作流）
-?學習一種新方法
要想成為領域中的專家，需要再已經(jīng)形成的知識的基礎上兼犯，不斷的添加新原則和新做法
這種更新可能成為某些固有方法路的負擔忍捡，如果沒有強大的技術支持，這些更新會讓我們不知所措
精益-?敏捷的思維方法可以提供一些適當?shù)母轮改锨星⑹惯@種知識的更新沒有為項目成員帶來沉重的負擔
敏捷的思維方法解決了在特定情況（環(huán)境）下出現(xiàn)的新問題和新做法
-?定義一種方法而不被其限制
過程曾僅被用于微觀管理團隊或被認為過于松散而對組織無用
團隊會反對過程或是被剛性要求的過程嚇倒砸脊，但缺乏過程也會使團隊成員誤入歧途
精益-敏捷是通過尋找一種能夠支持開發(fā)團隊良好運作的過程，來平衡過程或過程不足的極端情況
精益思想假定大多數(shù)錯誤都來自系統(tǒng)本身纬霞，為解決這些問題凌埂，關鍵要理解開發(fā)團隊的工作方式，團隊成員必須理解他們循序的過程诗芜，開發(fā)團隊自己負責項目過程
當過程支配行動瞳抓，而這種行動不適合實際情況時，開發(fā)團隊就必須修改（完善）過程
-?定義過程
通過一下幾項來平衡過程：
原則適用于所有的環(huán)境伏恐，而具體實踐只在某些情況下適用
學習新知識時孩哑，人需要花時間去轉變蟹瘾，也需要一定的速度來學習
當開發(fā)團隊掌握了新的知識之后蓝撇，就需要對過程定義進行更新袱蜡，團隊成員應該幫助客戶進步，讓它們能夠從初學者逐漸變?yōu)閷＜?/p>
我們希望一個模型秤掌，可以讓團隊輕松上手，然后熟練掌握后又能進一步擴展開來鹰霍，納入更多的知識模型
不給新手過多負擔闻鉴，不給經(jīng)驗豐富的人太多約束
-?原則和實踐為專業(yè)化打開了大門
用精益-敏捷方法建立一個用于從事軟件開發(fā)的模型，它將結合基本原則茂洒、初期實踐和思想過程孟岛，供團隊用來擴大它們的知識面，并可將學習到的他人的經(jīng)驗教學納入其中
-?知道你在哪里
學習新概念之前，應當糾正之前所學知識的謬誤
稍后探討行業(yè)中對Scrum錯誤的理解
-?Scrum是一種框架
Scrum是構建有效敏捷開發(fā)過程的一種框架渠羞，基于一種概念斤贰，即軟件開發(fā)必須通過響應開發(fā)過程中收到的反饋來控制
反饋頻率越高對開發(fā)過程越有效
沒有放之四海皆準的方法，因為每個團隊和他們的工作領域次询、遇到的問題都不盡相同
必須學會學習荧恍，還必須擯棄觀念上存在的條條框框
-?對Scrum的誤解、不正確的觀點和Scrum的局限性
Scrum新手的認知誤區(qū)：
項目開展首次工作時沒有做計劃
（一些前期計劃是必要的屯吊，第六章會詳細說明）
Scrum中沒有文檔
（Scrum不會直接去解決這個問題送巡，Scrum建議除非具有商業(yè)價值，否則不需要創(chuàng)建文檔盒卸，這樣消除了許多類型的文檔骗爆，文檔只存在于當這些文檔對客戶有益當?shù)那闆r下，不要為了寫文檔而寫文檔）
Scrum中沒有架構
（Scrum不會直接去解決這個問題蔽介，Scrum更多的是關于如何管理團隊而不是定義團隊應該做的工作）
作者認為不正確的Scrum觀念：
Scrum的成功在很大程度上是因為由項目成員來定義如何做項目
團隊要遠離管理層
（第十一章提供了讓管理層和項目成員一起工作的方法摘投；精益知道管理層去支持項目團隊，當團隊創(chuàng)建自己的工作過程時屉佳，管理層為團隊提供方向性指南
當團隊僅僅局限于關注它們重視的問題時谷朝，管理層的存在就是一種必須
管理層是團隊在項目改進過程中的合作伙伴）
產品是由產品開發(fā)人員靠拍腦袋想出來的
（產品牽頭人引導開發(fā)人員去客戶的真正需求）
當決定要開發(fā)何種產品時，即可從素材開始啟動產品開發(fā)武花，發(fā)布計劃就是選擇發(fā)布的素材的過程
（發(fā)布計劃就是選擇要發(fā)布的素材的過程）
團隊應該由通才組成
（極端片面圆凰，團隊真正需要的是，能夠以很短的時間組織起所需要的技能去完成工作体箕，可共享的知識越多越好）
檢查和修改是足夠的
（檢查與修改是良好的专钉、必要的，但這種行為并不足夠累铅，除非它明確改進了團隊工作的過程
必須要向他人學習或總結過往的經(jīng)驗跃须，更好的模型是計劃-執(zhí)行-檢查 PDCA，團隊應該考慮重新學習遺忘掉的知識）
克服Scrum的局限性：
自組織團隊能夠超越其他團隊改進軟件開發(fā)的流程
（團隊應該被自組織而不應該自我向導娃兽，持續(xù)改進的過程可以通過團隊與管理層之間關系的改善獲得加速）
每次迭代都需要向客戶提供價值
（迭代需求并不總是為客戶利益服務菇民，當需要學習一些系統(tǒng)知識時，也可以通過迭代進行
不構建過度需求投储，會增加浪費第练，同時也要保持一種全局觀）
切勿超越目前的迭代計劃
可以使用Scrum-ofScrums協(xié)調不同產品團隊間的工作關系
可以在無需自動驗收測試或單元測試前置的前提下使用Scrum
（在最初創(chuàng)建Scrum時，是有著兩項的玛荞，但為了大眾更容易的掌握Scrum娇掏，這兩項實踐被刪除了，其實很必須）
精益思想提供了必要的基礎
- 將Scrum#-Scrum嵌入精益思想中
Scrum#?注入了精益思想的Scrum
-?引入看板軟件工程
看板軟件工程將更多的關注直接放到工作流的方法
看板基于下列觀點：
軟件開發(fā)有關創(chuàng)建和管理知識
軟件開發(fā)過程可以用隊列和控制回路及相應的管理來描述
通過系統(tǒng)的信息流有一定的代表性
看板與常用的敏捷方法不同之處在于：
軟件開發(fā)團隊中排隊的隊列很少
軟件開發(fā)團隊的中斷是盡快完成功能開發(fā)勋眯，但沒有時間箱的制約
從形成概念到產出消費品婴梧，在真哥哥價值流的過程中下梢，看板讓人一目了然，理想情況塞蹭，客戶啟動價值流孽江，產品經(jīng)理和團隊一起緊密合作，利用看板在過程中對在制品的數(shù)量加以限制
-?管理看板團隊的工作
基于精益思想的看板方法將管理層包含在內浮还，管理層可以參與團隊工作的執(zhí)行和跟蹤
累計流程圖（CFD竟坛，Cumulative?Flow?Diagram），描述了看板在系統(tǒng)中的整個流動過程钧舌，提供了一個衡量工作流程的重要步驟
寬線顯示了流動中的障礙或阻塞担汤，細線表明了在制品太少（有時也被稱為”氣泡“）
看板兼具以下兩個工作流：
基于隊列和可控制的回路來定義的工作流
在工作流的每個步驟中通過限制在制品數(shù)量來管理工作流
團隊不斷學習加快了工作過程的改進，原因如下：
看板減少了評估每個素材時的恐懼感洼冻，這對某些團隊來說是一種風險崭歧，恐懼總是妨礙學習
看板明確一個團隊過程而非一個個人過程，突出的是團隊的表現(xiàn)而非個人的表現(xiàn)撞牢，可以減少遇到困難時的恐懼感
看板注重的是工作流過程如何被改進率碾，而非責備某個個人
看板能夠反映具體措施的實施情況，在開始時利用看板去反應具體的問題相比去反映那些更抽象或更個人的問題更容易
一個開放透明的過程使用管理者能夠參與其中屋彪，并有機會去改進這一過程
選擇方法
總結
Scrum#所宰，將Scrum嵌入精益思想
Kanban，基于精益思想畜挥，通過直接管理在制品的價值流來改善產品的流通
第六章?迭代0：準備第一次迭代
為迭代1做準備
瀑布型項目仔粥，缺點是在項目開始前耗費了太多的精力去做準備工作
敏捷型項目，許多項目失敗卻是由于事先沒有做好充分的準備
綜合兩種的優(yōu)點蟹但，在項目開始時做好充分準備去有效的啟動項目躯泰，使項目能遞增的進行開發(fā)和交付，但也不要做太多準備华糖，成為額外的負擔
-?設置產品
產品牽頭人要能清晰的描述企業(yè)的愿景麦向，讓團隊明白企業(yè)的需求
在執(zhí)行迭代前，要實現(xiàn)建立和評估精益組合及發(fā)布計劃并使其可視化
分解和評估高層次計劃客叉，創(chuàng)建足夠的素材并分解到任務當中诵竭，結構應該能夠支持前瞻性
但并不需要過多的關注未來的任務，團隊過多的關注未來的任務或風險時會帶來很多不必要的分析工作并開發(fā)出很多不必要的功能
-?組建團隊
精益表示兼搏，把工作限制在團隊的能力范圍之內卵慰，是讓工作流有效運轉的基本法則
在迭代0期間確立并組建團隊，在精益-敏捷方法中分配已定義的角色：
管理每日站立會議與可視化控件（產品組合向族、路線圖呵燕、發(fā)布計劃棠绘、迭代待辦事項）
如何管理項目障礙
如何確保項目開放件相、透明（在制品再扭、障礙和狀態(tài)）
創(chuàng)建測試計劃：
包括單元測試、功能性測試夜矗、系統(tǒng)驗收測試、用戶驗收測試
詳細說明”完成“的定義：
素材階段，團隊需要標準化工作氓润，詳細說明”完成“的定義
應該有一份簡單的文檔用以描述團隊優(yōu)先將素材文檔必須達到的可視化的質量步驟憨募，包括所有相應文檔的更新、可交付設計的更新对扶、編碼檢查区赵、架構復審和產品牽頭人的最終驗收
- 構建環(huán)境
迭代0盡可能的完成環(huán)境的構建準備工作：安裝、配置和開發(fā)環(huán)境組建的校驗浪南，包括IDEs笼才、可視化控件、測試工具和缺陷跟蹤應用系統(tǒng)
迭代0期間络凿，有專門團隊負責執(zhí)行技術支持（缺陷修復）工作骡送，對構建測試環(huán)境也有幫助
-?搭建架構
為了設置開發(fā)標準，必須對依賴關系及其風險絮记、架構目標文檔做出高層次的定義
這些定義需要企業(yè)高層復查和簽字摔踱，第十三章會進一步討論
迭代0清單
總結：
迭代0是團隊的一個設置階段，為了啟動迭代1和更多迭代計劃而做的前期準備工作
迭代0的時間長短取決于團隊和項目的需求
準備好：產品怨愤、團隊派敷、環(huán)境、架構憔四，組建團隊
第七章?精益-?敏捷發(fā)布計劃
發(fā)布更改計劃
-?評估過程
過程包括以下幾方面：
過程定義的程度膀息，即過程多大程度上被定義
可預測的程度，或者輸出的隨機性
反饋的程度了赵，或者過程使用的反饋數(shù)量
過程定義的程度：
在確定的過程中潜支，輸出100%通過輸入來決定；在隨機過程中柿汛，輸出是一種隨機變量冗酿，會有不同值，以不同概率產生
明確定義的系統(tǒng)產出的輸出范圍是一個處于確定性與隨機性之間的一個閉聯(lián)集
可預測的程度：
將系統(tǒng)輸出看成隨機的络断、可變的裁替，會比將結果標識為可預測的或不可預測的更加有用
輸出分為3種形式：完全不可預測、宏觀可預測貌笨、微觀可預測
反饋的程度：
這一變量應該被添加到可預測程度和過程定義程度中
反饋可能是達到目的地最有效的方式弱判，但決定如何及何時使用反饋，是經(jīng)濟學問題
透明度和持續(xù)的規(guī)劃：
第四章把產品組合起來作為一個透明的焦點锥惋，企業(yè)可以按順序發(fā)布最小可市場化功能
發(fā)布計劃是一種可持續(xù)性的行為昌腰，對一份產品愿景進行不斷分解开伏，同時重視對企業(yè)有較高優(yōu)先級（價值）功能的計劃
發(fā)布計劃始于產品牽頭人提供愿景，產品牽頭人為客戶與企業(yè)決定價值優(yōu)先次序
項目的預訂日期的確定取決于團隊開發(fā)速度的評估結果如何
為了有效的執(zhí)行精益-敏捷發(fā)布計劃遭商，開發(fā)組織必須具有創(chuàng)建可視化控件（持續(xù)改進）的能力和決定開發(fā)速度的能力（開發(fā)每個迭代的素材點）
-?發(fā)布和提高
理想情況，每次迭代直接發(fā)布產品給客戶
實際情況劫流，可能因為集成先進行內部發(fā)布巫玻，或發(fā)布代碼給客戶去獲得客戶的反饋
為這些不是真正意義的發(fā)布，杜撰了一個詞”拔高“
發(fā)布計劃會議示例
通常步驟：
1?定義功能
2?排列功能優(yōu)先級
3?使用最小可市場化特性分解功能
4?評估功能的價值
5?評估開發(fā)功能的成本
6?細化功能祠汇，重復該行為仍秤，知道使這項功能具備合理的清晰度和高層級的商業(yè)價值
7?按照日期或范圍創(chuàng)建發(fā)布計劃
通過適當方法可以幫助團隊重視和規(guī)避風險：
工作在最重要的功能上
防止在最重要的功能完成之前去開發(fā)次重要的功能
最小化在制品的數(shù)量
8?計劃拔高
一類拔高計劃是查看里程碑，讓軟件優(yōu)于真實發(fā)布的計劃完成開發(fā)
沒有為拔高設置的規(guī)則可很，理想的情況是跨所有開發(fā)平臺去做集成徒扶，但由于存在不同的平臺、不同的操作系統(tǒng)根穷、不同的基礎客戶等姜骡，所以集成并不總是能完成
然而，拔高計劃有助于我們針對大型屿良、系統(tǒng)工作的一部分圈澈，研究最好的方式去獲得反饋
會議動力：
1?為客戶增加價值
2?迅速進入市場
特別說明
-?評估和風險
風險是附著在錯誤的評估上的，最糟糕的情況是評估到最后反而成了項目的障礙
重要的不是預測素材開發(fā)的優(yōu)先級別尘惧，而是預測素材發(fā)布的先后次序康栈，避免錯誤交付日期
-?帕累托定律與帕金森定律
精益軟件開發(fā)與帕累托定律相似之處在于：80%的價值來自于20%的工作，20%的功能提供給客戶80%的價值
帕金森定律：工作會不斷擴展喷橙，直至所有的時間被用完啥么；如果沒有時間箱沒有設置結束日期，就會如此
當多個產品經(jīng)理競爭團隊資源時贰逾，應用帕金森定律就特別危險悬荣，A經(jīng)理重視團隊的每件事情、B經(jīng)理只關心什么時候A團隊能來做他的工作
可以通過讓團隊在最短時間內遵循帕累托定律來中和帕金森定律的影響
總結
一個組織對可視化發(fā)布計劃的維護以持續(xù)且有效的速度來驅動的疙剑，組織擁有一個有競爭力的武器-?關鍵戰(zhàn)略和戰(zhàn)術氯迂，對商業(yè)化價值的最大化進行不斷的分析
交付組織積極參與發(fā)布計劃的活動，并通過評估來實現(xiàn)企業(yè)級敏捷
第八章?企業(yè)團隊的可視化控件和信息發(fā)射器
“不能衡量就無法提高”
“沒有清楚的認知言缤，就無法真正的改進”-?艾倫.沙絡維
“過程不可視就無法工作”-?蓋伊.比弗
可視化控件和信息發(fā)射器
Scrum環(huán)境中以下幾個方面使用信息發(fā)射器：
產品愿景
產品需求列表/發(fā)布計劃
迭代列表
向下燃燒圖與向上燃燒圖
障礙列表
可視化控件包括以下幾方面：
信息傳遞可視化
真實反映（或者至少部分反映）團隊正在使用的過程
描述工作過程的情況
用于控制工作過程
任何人均可查看
可視化控件和信息發(fā)射器嚼蚀，只是不同稱呼，相同目標管挟，精益思想中轿曙，“可視化控件”具有更多含義
除了能向所關心項目進展的人分享信息之外，也能反映管理層要參與項目進度的意圖
當存在問題阻礙團隊進程時，可視化控件會邀請管理層協(xié)助檢查
在團隊需要被干預的關鍵時刻导帝，方便管理層能及時叫停并做出調整策略
可視化控件增加了可能性-?管理層可以實際干預過程來增加價值
精益-敏捷可視化控件
可視化控件存在于項目的所有層面：業(yè)務層察藐、管理層、團隊層
應該有助于讓業(yè)務人員認識到價值是如何被創(chuàng)建的舟扎，并協(xié)助管理層和團隊成員去高效開發(fā)軟件
可視化控件的細節(jié)：
1 產品愿景
2 產品需求列表、發(fā)布計劃悴务、精益組合管理
優(yōu)先級從左到右
3 迭代列表-單一團隊睹限、多個團隊
遵循推遲承諾和準時制原則
單團隊
多團隊
精益-敏捷中，通過價值流向企業(yè)交付最大價值讯檐，在此基礎上待完成的工作將被拉入進來
產品開發(fā)階段整個過程包括3個階段：發(fā)現(xiàn)羡疗、定義、構建
建立清晰的可視通路
4 素材點向上向下燃燒圖
5 商業(yè)價值交付表
6 障礙列表
包含字段：
輸入列表中的日期
障礙描述
障礙嚴重等級（障礙的影響是什么）
障礙會影響誰
采取的清楚障礙行動
用可視化控件管理依賴關系
好的可視化控件
特征：
需要極少的時間去學習使用這種工具
能夠為團隊指明接下來將要做些什么工作
能夠為管理層指明團隊正在如何做工作和正在做什么工作
總結
可視化控件是管理精益-敏捷軟件開發(fā)工作中的一個關鍵組建
提供了一種低成本方法别洪，讓團隊能夠看清楚所在的為止
讓管理層和客戶能夠看清開發(fā)工作的進度叨恨，向項目各個參與方提供項目的狀態(tài)信息
能夠讓大家一起合作，解決團隊面臨的任何問題挖垛，以獲得最高價值痒钝，將具有最高質量的產品推出市場
為團隊和管理層提供了一種合作技巧，在獲得正確結果的前提下痢毒，有助于管理層監(jiān)控團隊的進度
管理層用可視化控件送矩、對團隊的支持和方向性指導代替了命令和控制
本文只是描述了一些基本使用控件，可以視項目需要增刪合適的可視化控件
第九章?精益-敏捷軟件開發(fā)中的QA角色
質量保證（Quality?Assurance哪替，QA）指有計劃的栋荸、系統(tǒng)的生產過程留搔，為產品符合預期目的的實用性提供保障
質量控制（Quality?Control螟蝙，QC）確保產品或服務被設計和生產出來故响，滿足或超越客戶需求的做法
QA應該為防止缺陷負責熙卡，而不僅僅是發(fā)現(xiàn)缺陷捞烟，為達到這個目地塞栅，QA應該被移至開發(fā)周期之前鸣奔，有助于團隊避免大量的溝通錯誤虱痕，這些溝通錯誤會帶來延遲身冀、缺陷和浪費
在開發(fā)每個素材之前靠汁，團隊與客戶應該關注“如何得知工作已經(jīng)完成？”闽铐，理想情況應該在編寫代碼之前進行測試蝶怔，并且確保以最小的浪費來生產高品質代碼
第十章?成為敏捷企業(yè)
持續(xù)改進不是說你要把事情做得多好-那只是工作的一部分。持續(xù)改進是移走那些妨礙你工作的事務兄墅，那些降低工作效率的事務踢星。這就是持續(xù)改進的真諦所在
想去何處
目的地：
確定市場需求
快速響應市場變化
為市場開發(fā)軟件-?高品質且重視交付最高價值的功能
開發(fā)的產品（內部與外部）要有長久的生命力、易于擴展和容易維護
做以下事情：
確認和定義開發(fā)最小可市場化功能
管理開發(fā)組織隙咸，使生產力最大化和迭代循環(huán)時間最小化沐悦，并且在此過程中開發(fā)出高品質軟件
確保團隊遵守精益原則成洗，在約束因素范圍內盡其最大的努力
雇用具有最高水平工程實踐技能的團隊（有能力開發(fā)出高品質的軟件，包括測試驅動開發(fā)和設計模式）
采用持續(xù)改進過程的做法藏否，變成一個學習型組織
企業(yè)驅動軟件開發(fā)：
上述行為是基于業(yè)務驅動的組織所需要的瓶殃，但還不足以讓團隊變得敏捷，企業(yè)還必須組織和領導團隊為客戶增加最大價值
如何到達
企業(yè)轉型期普遍存在的問題：
團隊沒有很好的形成
團隊成員不在一起辦公
年度周期計劃導致項目需要更長的時間去完成
大批需求雜亂無章的堆放在一起
項目經(jīng)理和項目發(fā)起人爭奪資源副签，而不是一起合作以實現(xiàn)投入收益最大化
自動化驗收測試沒有完成
在項目結尾才完成集成
代碼質量依賴于程序員的個人能力
沒有積極地尋找和消除問題的根源
過程的持續(xù)改進沒有實施或沒有價值
平衡調整片
改變大型輪船的過程非常困難遥椿，以個人力量去改變社會是一件困難的事情
一個平衡調整片就像一個個微舵，當移動船舵時淆储，平衡調整片會創(chuàng)造一個低壓區(qū)冠场，使舵能夠很容易的轉動
平衡調整片可以讓船員話很少的力氣就能轉動一艘巨型船只
如果要改變這個世界的話，必須尋找人生的平衡調整片本砰，用微小的理想產生巨大的影響
轉型時期的指南
考慮三個問題：
最容易清除的痛點是什么
轉型過程中的文化態(tài)度是什么
轉型過程中的尺度是什么
要點：
剛開始時計劃做太多工作反而產生不良后果碴裙，即使所做的工作都有價值
人們經(jīng)歷轉型，通常懷有某種程度的恐懼
人們始終要明白的是他們的工作范圍
給轉變做轉型工作的團隊再去增加關鍵性工作点额，可以導致人們放棄轉型
我們應該尋找“平衡調整片”去協(xié)助平衡過渡舔株，“摘低處的果實”，低付出还棱、高回報
從何處開始
-?產品公司
生產產品供個人或其他公司使用督笆，擁有定義良好的開發(fā)團隊，但團隊成員通常會同時參與多個項目
從最常見的地方入手以提高團隊效率：如通過實施Scrum或看板
構建敏捷團隊诱贿、改進選擇產品增強功能的方式娃肿、計劃管理者合作一起挑選最小可市場化功能
轉型方法通常以團隊為基礎，使用精益思想做指導珠十，從頭開始工作
- IT?公司
降低運作項目的數(shù)量和定義良好的工作團隊是一套組合行為料扰，必須同時進行，以避免造成其他（Scrum）團隊獲得成功的同時焙蹭，（非Scrum）團隊遭遇挫敗
重點關注對客戶有價值的功能
-?IT-產品公司
向其他公司出售服務
年度項目預算計劃在這類機構具有很強生命力晒杈，學會如何構建更小的項目是關鍵
在開始的時候對計劃管理者加以適當?shù)呐嘤?/p>
明確定義可能的最小可市場化功能、然后對最小可市場化功能按照投資收益率進行排序
各個團隊工作在同樣最小可市場化的功能中孔厉，從共同產品需求列表中將最小可市場化功能拉出來開發(fā)
跨職能團隊的創(chuàng)造力將帶來生產力的立即提升并帶來即時收益拯钻，這種收益可以超過并抵消轉型本身帶來的混亂
持續(xù)過程改進的重要性
精益并不是關于專注企業(yè)轉型的方法，而是一個讓企業(yè)學習轉型的過程
但是為了轉型而轉型的目標是不對的撰豺，轉型的目地是提高生產力和投資收益率
團隊需要研究如何改進過程并改善與其他團隊的依賴關系
管理層需要不斷的尋找一種方法去減少迭代循環(huán)的時間并提高產品質量
團隊要學會去發(fā)現(xiàn)并改進過程粪般，找到組織結構中的障礙，以便進行修正
總結
公司如何轉型取決于所處的位置和需要克服的挑戰(zhàn)
在已經(jīng)存在的架構中污桦，以它們的能力從業(yè)務需要的角度去推動開發(fā)亩歹，有助于到達轉型的目地
第十一章?精益-?敏捷開發(fā)中管理者的角色
“管理是把事情做對，而領導是做對的事情”-彼得.德魯克
"你必須管理系統(tǒng)，因為系統(tǒng)本身不能對自己進行管理"-?W.愛德華茲.戴明
精益-敏捷管理
精益-敏捷重視價值流的管理和對人員的領導
構建環(huán)境
敏捷開發(fā)團隊是一個完整且具有超強生產力的團隊小作，需要有一個有利于成長的環(huán)境亭姥、健康的團隊活力和良好的團隊行為
需要一位具有良好視角、專注力與深刻理解需求的領導者
精益-敏捷中顾稀，管理者有兩個重要的職責：
設定結果或團隊預計要達成的目標
協(xié)助工作人員改進過程并安排工作區(qū)达罗，以方便團隊完成工作
精益-敏捷兼顧管理的辦法
泰勒主義，一種趨向于指揮和控制風格的管理方法
當風險增加時静秆，采用指揮和控制的管理方法（Command-and-Control）會讓人覺得比較安全
精益思想提供了一種替代方法：對實現(xiàn)目標的工作和方法授權粮揉，但仍需要團隊成員對結果負責
運用多種方法和工具將團隊面臨的調整可視化，運用這些方法和工具來解決項目問題
同時需要管理者注意诡宗，不要提供解決問題的方法，只是引導團隊击儡，防止團隊掉入問題的深淵塔沃，避免浪費
在團隊內部創(chuàng)建知識
精益-敏捷管理者必須再組織內部構建知識，并清楚的知道通過自己的方式催促團隊工作將會產生不利的影響阳谍，短期蛀柴、低效的戰(zhàn)術違背了在價值流中優(yōu)化工作的原則
精益-敏捷領導力應該在短期效率最大化的技能基礎上防止管理者按照邏輯去推動工作分配
敏捷開發(fā)管理者要注意創(chuàng)建“教與學”的文化氛圍，但違反了主流的戰(zhàn)略管理思想：充分利用有技能的專家矫夯，分解任務并分配任務鸽疾，是個人以最大效率完成工作
尋找根本原因
尋找根本原因，對癥下藥训貌，確保解決方案能增加價值
精益思想指導我們我們首先查看價值流制肮，并分配人員不斷的去消除任何不增加價值的行為，從構思到產品交付使用的整個過程
敏捷軟件開發(fā)不是無政府狀態(tài)
可行的精益-敏捷轉型戰(zhàn)略是一個自上而下的領導過程和自下而上的實施過程
精益管理為我們設置了愿景和成果递沪，同時培訓團隊并完善組織架構
缺乏管理等于缺少成功
Scrum的目的是讓組織中的問題變得開放豺鼻、透明，向組織提供了查看項目過程的工具款慨，但不是修正問題的工具
精益-敏捷方法所信奉的管理層參與的原則儒飒，為解決許多標準敏捷方法不能解決的問題提出了深刻的見解
管理者必須看到，團隊是如何被他們制定的那些制度所影響檩奠，使他們能夠做出必要的改進
用精益思想提高管理
正常人的真實反應-?在關鍵時刻用熟悉的桩了、過去的行為方式解決問題
管理者能有當前的成就，就是因為在關鍵時刻能夠比其他人更具有處理危機的能力
管理者的其中一項任務埠戳，就是要教會被管理者的員工井誉，充分授權給員工，使他們能夠實現(xiàn)目標整胃；項目進展順利的時候送悔，大多數(shù)管理者都能做到這些，但當關鍵時刻來臨時，管理者很容易會跳出來欠啤，又采用管用的方式來解決問題
這造成了微觀管理荚藻，并抑制了團隊學習和設計解決方案的積極性
精益思想為管理者提供了一種方法去監(jiān)控團隊是否達到了所需求的結果并指導團隊最終達到目的
總結
精益思想旨在幫助企業(yè)最大限度的完成高品質、高附加值的工作
利用精益和業(yè)務驅動原則將工作按照收益率大小排列洁段，無論按照利潤应狱、銷售額、客戶重要性或其他因素祠丝，均由產品牽頭人來決定
克制住“讓員工保持忙碌”的沖動
排隊理論的知識體系有助于提升針對優(yōu)先級更改時跨職能團隊快速重組的能力
第十二章 產品協(xié)調小組
讓團隊協(xié)同工作
- Scrum-of-Scrums?
來自不同團隊的成員定期召開會議疾呻，以促進合作、交流和分享需求
適用于管理一個具有共同目標的大型團隊写半，不適合管理幾個具有不同目標的小型團隊
人的本性是先感興趣自己的同事正在做的事情燎斩，其次是部門，再次是分公司蟋恬，最后才到總公司
Scrum-of-Scrums 方法與這一本性相反铸鹰，它假設來自松散團隊的各個成員跨過所有團隊為企業(yè)創(chuàng)建一個更大的藍圖，所有成員以這個藍圖為共同目標
- 協(xié)調小組面臨的挑戰(zhàn)
多個團隊合作可能出現(xiàn)的問題：
整個團隊的進度
需要多個團隊來實現(xiàn)需求
團隊之間的技術依賴
多個團隊使用通用組件
需要一個團隊修改代碼去協(xié)助另一個團隊的工作
團隊的共享代碼
一個團隊擁有另一個團隊所需的知識
產品協(xié)調小組
導致團隊不能協(xié)同合作的根本原因：
視野過于狹窄悔捶，僅僅關注自身的需求铃慷；如果要想實現(xiàn)協(xié)同合作，那么團隊需要改變從自身利益出發(fā)的視角
需要一個協(xié)作的架構蜕该，把基本的關注點放在企業(yè)的視角上
標出涉及團隊問題的素材犁柜，并排列出開發(fā)的先后次序，它能把素材分配到最合適完成素材開發(fā)的團隊堂淡，成這個協(xié)作架構為“產品協(xié)調小組”馋缅，團隊的另一個產品牽頭人
產品協(xié)調小組與Scrum-of-Scrums之間有很多相似和不同，協(xié)調小組工作重點是站在更高的角度-“全局優(yōu)化”绢淀，是一個真正意義上的團隊股囊，由來自不同團隊中的成員組成的，為了達到一個共同的目標而團結在一起
Scrum-of-Scrums是一個大局觀的前提下更啄，將團隊的問題交給團隊自己去解決
- 產品協(xié)調小組指南
由固定成員和輪值成員組織
固定成員：對于保持一致性和確保團隊目標被理解是有用的
輪值成員：幫助產品協(xié)調小組不偏離開發(fā)團隊的需求稚疹，識別需求
計劃成員：來自開發(fā)團隊和在迭代計劃階段參與產品協(xié)調小組的成員
- 目標
實現(xiàn)企業(yè)價值最大化
確定和協(xié)調如何讓開發(fā)團隊在技術上發(fā)揮最大的協(xié)同合作作用，特別是要找出通用組件祭务，避免冗余開發(fā)内狗，協(xié)助浮現(xiàn)式設計
驗證拔高的計劃
- 提供指導
為團隊提供良好的個性化指導
可以作為團隊實踐的基礎，也可成為知識管理或分享的方法
總結
團隊間協(xié)同合作時遇到的挑戰(zhàn)义锥，自身利益是根本原因：團隊應該（適度地）關注當前的需求和工作任務
產品協(xié)調小組柳沙，要擁有特有的企業(yè)視角和充分授權去關注團隊的問題，是跨團隊協(xié)調問題的產品牽頭人
功能和Scrum-of-Scrums 類似拌倍，但目的各不相同
第十三章 精益-敏捷中的軟件架構和設計角色
避免過度或過少設計
只開發(fā)在此刻需要的功能赂鲤，當有新問題產生時噪径，系統(tǒng)可以快速升級-來做開發(fā)
為了解決這個問題，需要開發(fā)人員做到一下幾個方面：
快速編寫代碼
修改代碼但不會破壞代碼
能夠安全修改代碼
為改變而設計
有的開發(fā)人員只關注解決手頭上的任務数初，而不是尋找一個綜合的解決方案找爱，當給開發(fā)人員時間去思考的時候，他們又會過度開發(fā)泡孩，以解決可能出現(xiàn)的問題
解決問題的關鍵在于车摄，要意識到在開始階段是不太可能做出正確決定的，必須編寫可以改變的代碼以滿足變化的需求仑鸥，但你還不可能知道需求將如何變化
編寫高質量的代碼使系統(tǒng)具備可更改的特性是解決問題的關鍵吮播，同時要做全面的驗收測試，使系統(tǒng)能夠安全的升級更新眼俊；另外還需要管理層支持并鼓勵開發(fā)團隊去完成這些工作
適度準備意狠，敏捷鼓勵不過度設計，剛好夠用疮胖，平衡
《設計模式解析：從一個全新的視角描述面向對象設計》
軟件開發(fā)中的設計角色
設計能夠讓代碼的更改變得簡單环戈，將改變對系統(tǒng)帶來的影響最小化
通過：組合解耦（隔離）、封裝和防止冗余達到
軟件架構的目的不是盡可能多定義每項功能获列，而是妥善處理好功能之間的關聯(lián)關系
遵循“準時制設計”原則谷市，防止因為預測而過度設計
軟件開發(fā)設計中的管理角色
管理層大多數(shù)情況下都會支持開發(fā)團隊蛔垢，同時提供開發(fā)愿景
所謂支持击孩，是指在不給團隊過多壓力的前提下，協(xié)助團隊了解什么需要團隊做的工作鹏漆、特別是什么時間應該開始構建自動化測試
但管理層并不是安靜的接受開發(fā)人員想要做的任何事情巩梢，需要作出對開發(fā)工作的成本判斷
同時相信開發(fā)人員作出的關于構建軟件質量的判斷
總結
軟件設計的目的不是設計一個滿足所有需求的軟件框架
只是定義主要概念之間的關聯(lián)關系
當出現(xiàn)新的需求或新的變更時，讓系統(tǒng)作出的修改對系統(tǒng)本身的影響有限
第十四章 認識精益
“名字有什么重要的艺玲？玫瑰如果不叫玫瑰括蝠，但它依然會芳香如故”- 威廉姆.莎士比亞
豐田：首個偉大的精益實例
W.愛德華.戴明，偉大的質量改進體系的先驅者
豐田的生產方式（Toyotal Production System饭聚，TPS）就是基于戴明的想法而構建出來的
TPS 的根本就是要絕對的消除浪費忌警，支持這套系統(tǒng)的兩個支柱是：
準時制
自動化，或者說以人為本的自動化
準時制秒梳，指在生產運行過程中法绵，必須在需要的時候按需要的量生產需要的產品
自動化要求過程平穩(wěn)運行，當過程遇到問題酪碘，不能只是簡單的解決問題朋譬，而要找出問題的根源所在
在戴明原理的基礎上，豐田的生產方式新理論由3部分構成：如下圖
精益重視用戶價值兴垦，但其真正的含義要依賴具體情況而定
重點是向客戶交付如客戶所期望的（產品）價值徙赢，不必在開發(fā)之初就明確客戶的需求字柠，重點是學習和改進你對客戶需求的理解
如豐田產品開發(fā)系統(tǒng)中常常會提及的一種做法是“多方案同步進行的開發(fā)工程”（Set-Based Concurrent Engineering，SBCE）狡赐，一種降低風險的做法
精益的三個主體
精益“科學”（拉動原則窑业、限制原理、流動性）
精益管理（管理層和開發(fā)團隊一起工作）
精益知識管理工作（如何學習阴汇、指導和保持知識的生命力）
- 精益科學
準時制
使用原理：
少量隊列和批量型號
限制在制品數(shù)量
少許法則（循環(huán)時間=在制品數(shù)量/產能，利特爾法則）
拉動管理
實際選項
- 精益管理
強調管理者對團隊績效應承擔責任
遠離事無巨細的微觀管理搀庶，管理者教團隊去執(zhí)行一種新的過程拐纱，包括團隊需要遵循的具體工作流出
管理者是領導者、教練和培訓師
他們不是“公仆式的領導者”哥倔，而是以一種積極的方式去幫助團隊秸架，去引導
精益是一門已經(jīng)構建好的科學體系，管理者提供一個機會去幫助員工學習這門科學咆蒿，并將這門科學應用到事件中去
- 精益知識管理工作
包含一下內容：
A3s（由豐田公司開創(chuàng)的改善工具东抹，采用一頁紙格式解決問題的方法。通常用結構化方法把問題沃测、分析缭黔、改正措施、以及執(zhí)行計劃囊括在一張A3紙上蒂破，格式圖形化目視化馏谨，以取代冗長的書面報告，讓報告者可以用五分鐘清楚傳達信息附迷。）
Kaizens持續(xù)改進
工作后的檢查和回顧
5Why分析法
價值流映射
來自精益-敏捷教練們的深刻見解
一次只關注一個項目
啟動較少的項目
縮短批處理時間
尋找缺陷產生的根本原因
知道你在哪里：最小化可發(fā)布的功能
生產力及質量
跨職能團隊
精益宣言：快速-靈活-機動
優(yōu)化整個價值流
短隊列惧互、消除浪費（優(yōu)先級、準時制喇伯、尋找根本原因）
下一步：獲得更多的方法
www.netobjectives.com/lasd
用戶興趣小組?
http://tech.groups.yahoo.com/group/learnagile
http://tech.groups.yahoo.com/group/leandevelopment
閱讀書籍
其他資源
www.netobjectives.com/resources 咨詢服務
總結
精益-敏捷軟件開發(fā)是用比從前更低的浪費和成本稻据，快速艾猜、優(yōu)質的開發(fā)軟件的方法
精益原則結合了科學、管理和知識管理工作
我們形成的終點并不是精益捻悯，這是一個持續(xù)的過程匆赃，持續(xù)改進意味著總是在尋求更好的轉變
精益助力高效、快速的開發(fā)出最重要的功能組件秋度，為客戶增加價值并降低成本
附錄A：團隊評估游戲
撲克牌+改良版斐波那契數(shù)列
附錄B：精益-敏捷軟件的開發(fā)模型
精益思想的基礎
以精益生產為基礎的基本體系炸庞，大多來自愛德華.戴明作出的貢獻
1 多數(shù)錯誤是系統(tǒng)性的
2 人們的本性是好的，都想把工作做好（以人為本）
3 當企業(yè)為客戶提供了最大價值時荚斯，企業(yè)也實現(xiàn)了自身利益的最大化
精益生產帶來了實現(xiàn)精益的可能性埠居，通過員工的努力工作查牌，結合管理者的指導與引領來實現(xiàn)持續(xù)的過程改進
- 觀點
精益思想是戴明的知識體系與豐田所推崇的準時制的完美結合
1 看看時間，已經(jīng)沒多少資源可用了
2 使開發(fā)過程快速滥壕、靈活纸颜、機動
3 增加過程可見性
4 消除浪費的最佳方式是不開發(fā)不需要的功能
5 過程就是變革的基礎
6 把過程的阻礙當作浪費看待
- 原則
原則（法律）
1 縮短周期時間，減少浪費并提升質量
2 當下面時段中耗費了過多時間時绎橘，會產生浪費和獲得低品質的產品
當需要信息的時候和當你獲得信息的時候
當你發(fā)生錯誤的時候和當你發(fā)現(xiàn)錯誤的時候
3 決策過早增加了浪費的風險
4 超額的在制品數(shù)量增加了風險和浪費
5 對流程的阻礙造成了浪費
6 并行項目數(shù)量增加而沒有增加可為項目工作的資源胁孙，延長了項目的時間長度
7 參與多個項目，降低了人員的效率
8 大批量生產造成浪費
9 任務切換產生的系統(tǒng)顛簸會造成浪費
10 忽視風險會造成浪費
11 快速交付有價值的軟件可以提高投資收益率
原則（指南）
1 全局優(yōu)化
注意從概念到產品開發(fā)完成整個過程中縮短循環(huán)時間
不能花費總體的周期循環(huán)時間去做局部的改進
2 消除浪費
分配的工作要限制在能力范圍之內
消除人員或信息等待過程中產生的延遲
消除從發(fā)生錯誤到錯誤被檢測出來這個過程中的延遲
重視消除產生錯誤的根源
找到方法称鳞，消除阻礙團隊進程的事物
使團隊在一個時間段內只開發(fā)一個項目
3 構建知識
查看系統(tǒng)錯誤
遵循科學的方法找到改進過程的方法
挑選最重要的事情去工作
盡可能的定義出可行的工作流涮较，將其作為變更的基準，這能夠帶來管理的可見行
4 品質構建
質量問題經(jīng)常造成工作流上的延遲冈止，消除這類延遲可以改進產品質量狂票、提升交付速度、降低成本
5 推遲委托
在適當?shù)臅r候作出決策
如果可能是決策可逆
6 快速交付
開發(fā)具有最小可市場化功能的產品增值功能
遵循指南，通過移除延遲來“消除浪費”
7 尊重員工
讓具有豐富知識的員工常常感到挫敗的事情是，提出的解決方案常常無人理會
通過改善管理系統(tǒng)去構建企業(yè)文化
制定過程持續(xù)改進的目標计呈，員工將朝著這個目標去完成工作
- 態(tài)度
我們的態(tài)度是我們持有的信仰體系所產生的結果，會影響對所有事物的看法
1 管理者是最重要的掂器，為團隊設置目標，并允許團隊以自己的方式去籌劃該如何實現(xiàn)目標
2 要設定在盡可能短的時間里交付盡可能多的價值的目標
3 通過消除浪費移除延遲俱箱，提升產品品質和降低成本
4 要改正錯誤国瓮，不要讓錯誤從你手邊溜走，或者至少要把錯誤標識出來匠楚，待開發(fā)后期再去探尋產生錯誤的根本原因
- 知識
1 知識是經(jīng)驗教訓的積累
2 如果測試和修復循環(huán)計劃占用的時間很長巍膘，前期就不會有足夠的時間做前置測試
3 只重視優(yōu)化組件而不關注全局的目標會造成浪費
4 重視降低成本往往會帶來低劣的產品質量厂财，并需要話費更長的項目時間
5 只重視產品質量又可能造成項目需要更長的研發(fā)時間芋簿，從而交付給用戶更低的價值
6 通過消除延遲來提升開發(fā)速度將縮短交付時間、提升品質璃饱、降低開發(fā)成本
7 實際的開發(fā)人員比管理者對系統(tǒng)有更大的認知能力
8 在制品通過表示系統(tǒng)經(jīng)歷過很多系統(tǒng)顛簸与斤，在顛簸過程中的產物
- 實踐
要有效的發(fā)揮實踐的作用必須根據(jù)不同的環(huán)境運用不同的實踐，確保運用的實踐和環(huán)境兼容
運用原則指導實踐在不熟悉的領域內的運用是一種創(chuàng)建新實踐的好方法
1 運動價值流圖找到延誤
2 運用可視化控件管理項目
3 分階段開發(fā)項目
4 持續(xù)的改進過程
5 將測試行為移到開發(fā)過程之前進行
6 挑選風險最小的素材進行開發(fā)（最大的風險就是開發(fā)不需要的功能）
7 使用最小可市場化功能來制定發(fā)布周期計劃
8 跨職能團隊完成一個項目后在轉入另一個項目
9 進入“工作現(xiàn)場”（就是進入正在開發(fā)軟件的工作之中）
只是一個開始
上述展示的模型只是一個開始荚恶，當將精益展開學習撩穿，模型將得到進一步的拓展
《產品開發(fā)流程的原則：第二代精益產品開發(fā)》
介紹了175條精益產品開發(fā)的原則，并按領域對原則進行了劃分
- 經(jīng)濟上的考慮谒撼、排隊隊列食寡、變化性、批次型號廓潜、在制品約束抵皱、流程控制善榛、快速反饋、授權
《管理設計工場》
www.netobjectvies.com/lasd
敏捷項目管理圖書
《有效的項目管理- 面向傳統(tǒng)呻畸、敏捷移盆、極限項目》
《精益-敏捷項目管理：實現(xiàn)企業(yè)級敏捷》
《敏捷回顧-讓團隊從優(yōu)秀到卓越》
《項目管理敏捷方法》
《敏捷項目管理決策：平衡控制和敏捷性》
《敏捷職業(yè)發(fā)展：IBM的經(jīng)驗與方法》
《指導敏捷團隊》
上面四本有，下面三本暫沒有
