•客戶、管理者、開發緊密工作在一起。
•客戶–指定義產品特性並排列特性優先順序的人或團體。
–同一公司的業務分析師、質量保證專家、市場專家；使用者團體的代表；支付開發費用的人。
–都是能和團隊一起工作的成員。
•客戶或能代替客戶的人最好和開發在同乙個房間工作。
•了解需求只要做到能估算的程度就夠了。
•必須知道存在很多細節及細節分類，但不必知道特定細節。
•看到新系統的問世是關注需求的最好時刻。
•和客戶反覆討論獲取需求細節，但不記錄細節，只記錄一些有共識的言語在卡片上用來提醒這次交談，並作相應的需求評估。估算是基於在和客戶交談時得到的對細節的理解進行的。
•客戶根據故事優先順序及估算代價來安排時間。
•迭代計畫
–每次迭代2周。
–迭代是一次小交付，可能會被加入到產品中，也可能不會
–迭代由一組使用者估算組成，這些故事是客戶根據開發人員確定的預算選出來的
–迭代開始，客戶就同意不再改變故事的定義和優先順序
–開發人員將故事分解成任務並按優先順序開發
•發布計畫
–3個月（6個迭代）的工作量一次大的交付，加入產品中
–發布計畫是可變的。客戶可以隨時改變發布內容，但盡量不要更改一次迭代
•記錄使用者故事的細節，描述每個特性的細節
•在使用者故事實現之前或同時編寫
•可自動、反覆執行
•成為真正的需求文件
•故事的所有驗收測試通過，故事才算開發完成。
•一旦乙個測試通過，就不允許其再次失敗
•系統不能工作的狀態不允許超過幾小時
•單元測試驗證了系統中小的組成單元的正確性，是白盒測試
•驗收測試是用來驗證系統滿足客戶需求的黑盒測試
•驗收測試由不了解系統內部機制的人編寫。如客戶、業務分析師、測試、質量保證。
•驗收測試能自動執行，通常使用一種特定的規格描述語言編寫，這種語言比較適合非技術人員閱讀和使用。
•驗收測試是真正的需求文件
•驗收測試使系統在架構層面解耦
•促使作出優良的架構決策
•在未作任何設計和未寫任何**時，寫驗收測試
•基於意圖程式設計，即按想象的樣子去編寫
•fitnesse
•單元測試和驗收測試是可執行的需求文件
•**由結對的人在同一工作站完成
•乙個寫**、乙個觀察並發現錯誤和改進的地方
•頻繁互換角色
•結對的搭檔要經常輪換
•極大促進知識在團隊的傳播
•tdd三定律
–在寫產品**前，先寫單元測試
–一旦在寫的單元測試不通過或編譯失敗，就停止寫
–一旦單元測試通過，就停止寫產品**
•先寫乙個失敗的單元測試，再寫**使其通過
•編寫測試**和業務**之間的更迭在幾分鐘
•測試**循序漸進的對**編寫進行指導
•有利於重構
•為提高可測性，有利於解除各模組的耦合
•保證行為正確，放心修改**
•從呼叫者角度去觀察將開發的**，開發的介面更易於呼叫（使用）
•提高可測性
•測試是api使用手冊
•任何人可以簽出任意模組進行修改
•不對某一特定模組負責，需要參與各個不同方面的工作
•不會被限制在自己的專業領域
•每天進行多次構建
•所有測試都通過才算完成簽入
•需要合併**和解決衝突
•軟體專案是馬拉松長跑
•有意識到保持穩定、適中的速度
•不允許加班（發布前例外）
•開放的房間
•兩把椅子
•狀態圖、任務明細表、uml
•嗡嗡聲
•了解對方工作狀態
•激勵討論
•在充滿積極討論的屋子裡工作，工作效率不會降低反而會成倍提高
•確定專案持續時間、花費成本
•客戶發現特性->分解成使用者故事
•開發用「點數」估算
•開發估算初始速度->幾個迭代後獲得平均速度
•速度–已經實現的故事的估算之後
–跟蹤速度是最為重要的管理手段之一
•當開發速度變得準確時，可調整發布計畫
•迭代週期1-2周
•使用者故事的實現順序由開發決定
•迭代開始後，客戶不能改變迭代期內的故事
•即使沒有實現所有的故事，迭代也要在指定的日期結束
•計算本次迭代的速度，用於下一次迭代
•開發將故事分解成任務，乙個任務在4-16小時能完成
•迭代到一半時，應有半數故事已完成
•迭代要完成的是故事，不是任務
•速度圖
•餘量圖
•這2圖是所有敏捷方法的真正實質所在
•盡可能簡單、有表達力
•僅關注本次迭代中的使用者故事
•不斷變遷系統設計，使之達到最優
•xp團隊的系統可能不從基礎設施開始，先以最簡單的方式實現第乙個使用者故事，但迫切需要時才引入資料庫、中介軟體等基礎設施
•考慮能夠工作的最簡單的事情
–能使用檔案，不使用db
–能使用socket，不使用orb、ws
–能不用多執行緒就不用
•你不需要它
–只有在有證據，或者有十分明顯的跡象表明現在引入這些基礎設施比繼續等待更加合算時，才引入
•消除重複
–不能容忍重複**
–使用函式、基類、抽象、模板方法
•是一些小改造，改進系統結構
•改造後跑單元測試
•持續進行，每隔乙個小時或半個小時就要去做的
•軟體模組的三項職責
–能完成所需的功能
–能應對變化
–能使閱讀者易理解
•隱喻是系統的全域性檢視，是系統的願景
•歸結為乙個名字系統，提供系統組成元素的詞彙表
•給某個模組命名、打比方
•tdd與設計
–tdd——自上而下的測試優先設計
–關注具有實際行為的物件（上），而不是僅僅儲存資料的物件（下）
–•與tdd相關的兩種程式設計方式
–基於意圖的程式設計
–基於巧合的程式設計
讀書筆記 AgilePPP XP實踐
客戶 管理者 開發緊密工作在一起。客戶 指定義產品特性並排列特性優先順序的人或團體。同一公司的業務分析師 質量保證專家 市場專家 使用者團體的代表 支付開發費用的人。都是能和團隊一起工作的成員。客戶或能代替客戶的人最好和開發在同乙個房間工作。了解需求只要做到能估算的程度就夠了。必須知道存在很多細節及...
mysql運維 讀書筆記 Mysql 讀書筆記
mysql儲存時間有兩種型別 datetime和timestamp。分別說一下兩者的區別。datetime，以8位元組儲存時間，理論上可以從0000年儲存到9999年。並且沒有時區的概念，它儲存的就是乙個時間點的概念。timestamp和datetime最主要的不同就是，它是以4個位元組儲存，由19...
讀書筆記2013 2 Linux核心設計與實現A
讀書筆記2013 2 linux核心設計與實現a 這本書不是想linux原始碼剖析那樣一行行分析linux源 的書，而是從linux歷史，linux哲學，linux設計原理和原則，計算機硬體相關知識，編譯安裝核心實戰等多方面多角度講述和linux相關的方方面面。從中學到的更多的不單核心的源 而是li...