讀硝煙中的scrum和xp，臨時記錄一下，剛剛有點體會...，有時間好好整理整理。
迭代要完成可交付的工作片段
短交付週期=短反饋=在錯誤方向上花的時間更少=學習和改進的速度更快
backlog :功能、故事、用戶想要的東西
說明，優先級（重要性）、估算、測試規範、（產品backlog停留在業務層次上，關注業務目標）
sprint（sprint計劃會議（決定哪些故事應該在這個sprint中完成、時間、重要性） 三週 確定sprint目標（業務術語而非技術術語，讓團隊以外的人能夠理解））
product backlog ---> sprint backlog
處理就處理到自認爲已經很完善，而不要暫時先這樣吧的累積，不能再質量上讓步!
把事情完全做完，達到可以交付的狀態（小，是無所謂的），事情只做了一半，他的價值就是0!!!(敏捷、精益要求)
少構建些功能，然後把他們都弄穩定點是合算的
無休止的sprint計劃會議：1.人們認爲他花不了多長時間2.。。。實際上他們會的！
把故事拆分成任務：故事是可以交付的東西，任務工作內容而非可交付物
用戶管理-->新增、編輯用戶，查詢用戶 這是故事拆分爲更小故事
查詢用戶--->理清需求，write test case,實現查詢結果列表，實現查詢form，集成測試、重構 這是故事拆分爲任務
故事拆分爲任務會發現一些導致時間估算增加的工作，最後得出的sprint計劃更接近現實，這樣拆分給每日例會效率帶來提高(sprint計劃會議中就應該做這件事，如果時間允許的話)
幾乎每個故事的第一個任務都是“；編寫一個失敗的測試”，而最後一個任務是重構（提高代碼可讀性、消除重複）!!!
技術故事：或者叫做非功能性條目，需要完成，但又不屬於可交付物的東西，跟任何故事都沒有直接關聯，（故事應該是業務相關、業務語言描述）
sprint回顧 改進的最佳時機（哪些是好的，哪些應該更好，應該怎樣改善，時間估算比較的話問題出在哪，應該怎麼改進），目的是在下個sprint中怎樣才能做的更好
也可帶有部分技術交流
scrum注重的管理和組織實踐，而XP關注的是實際的編程實踐
scrum: backlog sprint計劃會議 sprint backlog sprint回顧、每日例會
XP : 段週期迭代、小步前進、快速發佈，結對編程、測試驅動、持續集成、每日例會、可發佈物強於規範的文檔 ...
永遠，永遠，永遠不要在沒有記錄堆棧跟蹤信息或是重新拋出異常的情況下捕獲異常（保證別丟失堆棧信息）
加班工作在軟件開發中會降低生產率
