Sprint回顾
让我们一次比一次做得更好。
1.回顾组织
主题：“我们怎样才能在下个sprint中做的更好？”
时间：设定为1至2个小时。
参与者：整个团队。
场所：能够在不受干扰的情况下讨论。
秘书：指定某人当秘书，筹备、记录、整理。
2.回顾流程
- sprint总结：
- sprint backlog（图）
- ：这次我们做（done)的是设计用户登录界面、注册界面、查询功能、链接数据库等，我们成功地把todo变成了done，首先不管我们结果如何，不管我们的付出是否与收获成正比，但我们做到了我们的目标的一部分，相信在我们的共同努力下，我们会用我们的团结‘、信任与合理的分配把我们的TO DO变成DONE。我们将积极，有效，在保证质量的前提下，尽快完成书籍网站的修改。定期对网站进行备份，维护和内容的更新并在，找现漏洞及不足之处，及时进行修改与完善，使网站的功能尽快完善，并一直努力不懈来实现我们的功能
- 轮流发言：
- 卓宇靖：这次我的工作是为了做出了关于我们团队的总结，承上启下，为过往做出查漏补缺，并为未来做更好地铺垫，让我们的团队按着我们预想的轨道继续稳稳当当地走下去，然而，对于日常的测试流程、测试任务分配、测试执行、缺陷跟踪、用github协调内部代码的一致性还做得不够好，相关JAVA识方面也需要进一步加 强，在这些方面都需要我们学习
- 。
- 赖文亮：我对我做的故事版感觉很棒，因为对我们的团队有了显而易见效果。我们的工作更贱有流程性，有了敏捷流程的雏形，我希望我们以后可以在这个流程上得心应手地走下去，并且我们的故事将越来越精彩。
- 生产率分析：对预估算的生产率和实际的生产率进行比较，如果差异比较大的话，分析原因。
- 原因：由于地域原因，我们并不能时常交流，而在github上的代码一致性会出现冗余，比如一个成员一个基础上改进了一个地方，另一个成员也同时改进了，这会对代码的实现出现很大误差。另一个原因，是我们的jsp基础暂时没打好，相互之间对代码错误的交流很难达成一致
- 改进之处：快结束的时候，Scrum master对具体建议进行总结，得出下个sprint需要改进的地方。
- 需要改进的地方：
- 1在GITHUB上的代码FORK应该更加渗入到我们的工作中
- 2应该加深对数据库使用的基础
- 3了解每一个成员的困难之处并进行交流，解决。
3.回顾辅助（参考图7）
Good：可以继续保持的做法。
Could better：需要改变的做法。
Improvements：有关如何改进的具体想法。
4.回顾结论
时间： 2024-12-30 11:19:37