敏捷開發之初識

#敏捷開發#使用者故事可以用3C表示，分別是Card(卡片)、Conversation(對話)和Confirmation(確認)。卡片上是故事的文字描述，然而需求細節通過對話擷取，對話所確認的需求在卡片上記錄。注意：卡片代表客戶/使用者的需求而不是記錄需求。開發人員的溝通對象是客戶團隊（測試人員，產品經理，實際使用者等等）

#敏捷開發#編寫優秀的使用者故事，關注的六個特徵：獨立性（Independent）、可討論（Negotiable）、對使用者或客戶有價值性（Valuable to Purchasers or Users）、可估計性（Estimatable）、小（Small）和可測試性（Testable）。

#敏捷開發#編寫使用者故事時，開發人員協助編寫，並和客戶團隊交流。客戶團隊負責編寫，並和開發人員溝通。當開發人員被問及實現故事的的技術或者架構資訊時，應該從使用者的角度回答，而不是技術術語回答。

#敏捷開發##使用者角色建模#明確項目中有哪些使用者，並且整合使用者，提煉使用者， 把使用者虛擬出人物，並且把虛擬人物的描述寫在紙上，掛在牆壁上，供團隊瞭解。

#敏捷開發#收集故事，故事夠用就行，不必面面俱到。收集故事的過程，就是“拖網撈魚”的過程。不同大小的網捕獲不同大小的需。

敏捷開發#漁網不能捕獲所有的魚，所以不能捕獲所有的需求，捕獲的魚也可能是死魚或廢物，無效需求使需求膨脹。第一遍，用大網撈大需求，形成對軟體的整體感覺，中網捕獲中等需求，暫時不用顧忌小需求。

#敏捷開發#收集故事，最好的方式就是使用者訪談，面對面和使用者溝通，通過開放式，與背景無關的提問擷取有用的需求。例如：“可以告訴我你想怎麼樣搜尋酒店的？”勝過 “你要通過地區來搜尋酒店嗎？”

#敏捷開發#項目開發中，一般沒有真實的使用者，所以有使用者代理程式這樣的角色，領域專家擔當使用者代理程式角色可能導致複雜性。

#敏捷開發#使用者故事驗收測試，兩部流程，第一步將測試要點寫在卡片的背面，如果需求有更新，有新的測試點，更新卡片背面、第二步測試人員將測試點變成全面的測試，測試通過，可以表明故事已正確和完整的實現。

#敏捷開發#使用者故事驗收測試，測試點是在寫代碼之前有客戶團隊寫好。測試的目的是找到缺陷，而不是為了覆蓋率。

#敏捷開發#估算故事點，故事點是故事的複雜度，工作量的相對估算。整個團隊來估算故事，而不是一個人。一般一個故事點為理想個人日的工作或者是理想結對日的工作。開發人員，估算時，要考慮到故事需做的所有事情，全盤考慮測試代碼，客戶溝通，協助測試人員或驗收測試等，估算時儘可能對故事瞭解詳細。

#敏捷開發#反覆項目計劃會議，1、根據優先順序討論故事，2、開發人員分解故事，3、根據分解的人物估算大小並且確認。

#敏捷開發#SrumMaster的權力來自團隊，只負責流程相關的，不能超出流程的範圍。類似健身教練和運動員的關係。

#敏捷開發#測試驅動開發，重構，集體所有權，持續整合，結對程式設計等技術實踐提高團隊的綜合能力。

#敏捷開發#每個迭代潛在可交付的軟體，可以提前並鼓勵反饋進度，需要時可儘早發布。潛在可交付意味著測試過，意味著整合已做好，並不意味著功能完整性。

#敏捷開發#產品負責人需要給團隊提供兩樣東西：願景和邊界。願景：產品的願景，產品的獨特性，與競爭者的不同，或者對手在做什麼。邊界：產品開發時間，速度等等。