敏捷開發之初識

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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