在最近的一次回顾会议上，大家希望回顾一下上一个迭代的效率和质量，今天和小R、小S、小L和小K一起讨论了一下怎么将效率和质量可视化。
小S率先发言，开发效率可以看
- Story个数燃尽图（我们没有点数）
- Todo的燃尽图
开发质量可以看 - Should find bug的数量
- Bug数量燃尽图
可以看出小S特别喜欢燃尽图，的确燃尽图简单直观能快速暴露问题。然后大家纷纷表示Should find bug很重要。
小K补充到TT bug（线上bug，影响了用户正常使用系统，需要紧急cutover）也很重要。小L表示可以投票选出最不能容忍的bug在回顾会议上回顾，当然目的不是批斗生产bug的责任人，而是怎么避免类似的bug再出现。
轮到小R发言，小R表示开发效率可以通过延到下一轮的Story数量来体现，小L表示大家可以投票选出最不能容忍的延期Story在回顾会议上回顾一下。
小K补充到延期一般是由实际的开发时间远远大于预计的开发时间造成的，可以分析一下出入特别大的意外Story是由什么原因造成的。
最后小结一下，开发效率可以由延期Story的数量，意外Story的数量和燃尽图体现，开发质量可以通过Should find bug数量和TT bug的数量来体现。期待下下次retro可以看到可视化的开发效率和质量。
