这两天在挤出时间学习了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的功能应该是独立的。