补充自己的学习记录：
1. Scrum Team通常为5-9个成员
2. Team 组建：理论上不是指派人员而是大家自己自愿加入。。。这个是理想！
3. Back log 不是分派出去的而是开发人员自己认领的。
4. Task 不要太大，2、3天最理想，太大导致风险加大。
5. Sprint review：演示成果时所有人都要参加，到达team中每个成员都知道其他人在做什么。
6. 如果review中发现功能不对或是有遗漏的功能如何处理？接着正常进行，错误或遗漏的功能放到backlog或是下个sprint中处理，不要打断打乱现有的节奏。
7. 如何标记功能完成：全组人-master-Product Owner都review。
8. 估算：每个人都做单功能估算，可以体验出不同人不同的观点和认识理解，如果差生大的分歧则说明对功能理解有问题，需要product owner再确认，再细化问题或功能点。
9. Scrum与实际的问题和矛盾：
Team保护自己的sprint不可被外人干扰保护自己的节奏，Owner可以向backlog中增加内容。
Scrum理论上是组员自己做自己测，但实际中是有QA测试的，如果挤出时间给QA做测试那么开发的时间就短了，利用自动化测试来完善，可这只是传说。。。
10. 每个sprint结束后都将有一个成品完成展示给owner.
1. Scrum Team通常为5-9个成员
2. Team 组建：理论上不是指派人员而是大家自己自愿加入。。。这个是理想！
3. Back log 不是分派出去的而是开发人员自己认领的。
4. Task 不要太大，2、3天最理想，太大导致风险加大。
5. Sprint review：演示成果时所有人都要参加，到达team中每个成员都知道其他人在做什么。
6. 如果review中发现功能不对或是有遗漏的功能如何处理？接着正常进行，错误或遗漏的功能放到backlog或是下个sprint中处理，不要打断打乱现有的节奏。
7. 如何标记功能完成：全组人-master-Product Owner都review。
8. 估算：每个人都做单功能估算，可以体验出不同人不同的观点和认识理解，如果差生大的分歧则说明对功能理解有问题，需要product owner再确认，再细化问题或功能点。
9. Scrum与实际的问题和矛盾：
Team保护自己的sprint不可被外人干扰保护自己的节奏，Owner可以向backlog中增加内容。
Scrum理论上是组员自己做自己测，但实际中是有QA测试的，如果挤出时间给QA做测试那么开发的时间就短了，利用自动化测试来完善，可这只是传说。。。
10. 每个sprint结束后都将有一个成品完成展示给owner.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12476590/viewspace-687966/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/12476590/viewspace-687966/
扫一扫
914
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
