這兩天在擠出時間學習了Scrum資料有很大的感悟，說來慚愧使用快半年的Scrum開發方式竟沒好好找個資料看看，借這個機會對以前的工作有個總結！
1、sprint backlog只描述用戶功能（用戶功能以User Story形式展現），每個user story下面可以分多個task。
2、每個user story儘量在一個sprint中完成，如果不能則分解。
3、一個Sprint完成的條件是不但完成產品功能的開發，而且測試工作也要完成。
4、一個Sprint不應該是現在的一週時間，應該是一個月或半個月爲好（因爲現在一期、二期是以一個月爲期限）。
5、一個Sprint結束後要有一個Sprint評審會，在會上先演示demo（demo是在sprint成功預期）再演示系統功能（實際完成情況），這種方式也是對團隊成員的一種約束和鞭策。
6、每個User Story 都必須是所有的代碼都完成，所有的代碼都做過Unit Test，並且都提交到代碼服務器上，經過測試，才能稱作‘Done’。
7、做Sprint計劃的時候不能光圖完成得快，還應該把方方面面的問題都考慮到。
8、在做Sprint計劃時不能有任何理由把團隊拋棄，要讓團隊人員參與。
9、Sprint 回顧會議通常是最容易被忽略的。然而Sprint回顧會議其實是非常有用的，它是整個Scrum開發框架中第二重要的事件（最重要的是Sprint 計劃會議），因爲它是讓Scrum 團隊成長和進步的最好的機會。
10、不要隱瞞團隊的技術實力，否則很難做切合實際的計劃和評估。在制定計劃是要將項目的不足提出來做爲制定計劃的依據。
11、Wiki來管理項目文檔是一個方法。
12、在Scrum 中，產品要完成的功能清單叫做產品Backlog。每一個Backlog項通常也叫Story，是由User Story來描述的，一個Story 是由一個完整的User Story
來描述的。有時候，一個比較複雜的Story 也可以分解若干個成更小的Story。Task 是任務，在具體實現每個Story 的時候都要將其分解成具體的任務，
比如編碼、測試、調研、代碼評審等，這些都是Task。
13、需求理解不應在Backlog中體現。應該在sprint計劃制定前就有所瞭解，這是做Sprint計劃的前提。然後在做具體task時對需求進行豐富理解。
14、代碼評審在敏捷開發中還是比較重要的。
15、制定task計劃完成時間的方法：團隊每個人都同時給出一個時間，將懸殊的時間拋棄掉。讓每個人都講出設定這個時間的原因後再次給出計劃時間，以此類推直到一致或相近爲止。但總的sprint時間點是不變的。
16、在Sprint進行中有很多突發事情（與本Sprint相關的）或有一些遺漏的task可以隨時補充到Backlog中。而這些task的佔用時間應該在計劃制定是預留出。
17、單元測試不管在敏捷開發還是其他開發方式中都是不可缺少的。
18、敏捷開發是不提倡加班的，但在可以預計的情況下，如果加班能夠完成剩餘的工作量，不加班則有困難的時候，可以酌情考慮。長期加班是萬萬不可取的。
19、結對編程對於團隊成員間技能的互相學習很有幫助，這樣可以最快提升團隊水平。結對編程不一定要兩個人做同一個工作，可以做相近的工作。這種狀態有點導師學生的味道（在當前要解決的問題上得角度）
使用ECF 的全稱是Eclipse Communication Framework個人覺得不太實用（片面感覺可以先研究下，也可以用它做代碼評審）。
20、擴充16點問題，當碰到諸如安裝軟件環境、服務器等工作，說他們與項目多少還是有些關係的。如果用時較短可以不增加User Story，反之要增加一個User Story。
21、Sprint計劃時間制定好後不能隨意改變。
22、在敏捷開發中面對面的溝通是最有效的方式。在一個異地開發項目的初期，核心人員進行面對面的接觸是非常有必要的。
23、個人績效問題：似乎沒什麼特別的地方，可以以團隊的分數作爲平均分，然後再給每個團隊成員評分。
24、如果有條件可以上客戶參加敏捷開發中來，及時瞭解客戶的意圖。（對這條的認識還只停留在教條上，自身還沒用什麼體會和感悟）
25、找到一個Sprint 回顧的工具（Team Pulse Survey），羅列了Scrum團隊應該做哪些工作並給出打分。看的我信心倍受打擊感覺要求太高。
26、測試人員要融入整個Sprint中去，Sprint結束的同事測試也完成。可以在研發人員開發後一個功能後（這裏的完成是功能實現、單元測試完成）測試人員直接進入。小的bug不必寫入bug庫可以由開發人員直接改；大的、複雜的、不能及時修正的bug要寫入bug庫。
27、User Story制定公式：作爲<某個角色>，我可以<做什麼>，以完成<什麼目的>例如：作爲一個病人，我可以預約一個醫生，讓他給我看病。User Story是用戶的角度寫的爲用戶提供價值的功能。不能出現技術問題。User Story的功能應該是獨立的。