Scrum Sprint 回馈机制: Review vs Retrospective Meeting

Review meeting

每个sprint结束时，开发团队要展示本此所完成的功能给客户（或是客户代表）看，让客户确定此次所开发的功能是否符合客户期待。如果不符合则可以在之后的sprint加以修正（此为回馈机制的意义，有错则改之）。由于每个sprint週期很短（一般Scrum团队採用2週至4週的sprint），所以可以避免传统开发专案在专案晚期客户才发现问题但却没时间加以修正的困境。

Retrospective meeting

软体开发除了需求可能不符合客户所需，软体开发流程本身如果没有做好管理，也很容易开发出『低品质』的软体。例如，bugs太多，程式无法扩充，没有自动化测试等等。所以，在每个sprint结束时，除了review meeting以外，Scrum还有一个称之为retrospective meeting的活动，用来检讨与软体开发流程有关的议题。在这个活动中，团队成员们探讨:

那些开发作法是好的，应该要继续维持下去。例如，有导入持续整合，或是有持续做pair programming；有那些与开发流程有关的地方没有做好需要改善的。例如，自动化单元测试做的不够多，或是测试硬体设备不够；拟定改善计画（action plan）。