许愿池，常见於各大庙宇以及名胜古迹之中，不管愿望能否真的实现，丢个硬币就可以拥有“有梦最美，希望相随”的片刻。对于出门在外手头不方便的屌丝而言，顺手捞几个硬币就可以换一个午餐或者买一张回家的火车票，省去了拦路要钱的尴尬。因为有了许愿池，制造者（Producer，在这里指那些将硬币丢入许愿池的人）和消费者（Consunmer，在此指到许愿池中顺手捞硬币的人）各取所需，王不见王。从软件架构的角度来看，这种降低“软件系统耦合度（decoupling）”的特色，相当具有扩充性。

许愿池的种种优点，从事软件研发工作的朋友们当然也发现了，就在Scrum中，每个Sprint结束时都要进行的活动——retrospective meeting——就是开发团队的许愿池。

Retrospective Meeting是Scrum设计用来改善开发流程的一道关卡，每一个Sprint结束之前都要经过这一关。在这个会议当中，开发团队讨论在这个Sprint当中，有哪些事情做得很好，要继续持续；哪些做得不好，应该改善，并挑出几个比较重要的改善项目，列出改善的行动方针。

一下我们举几个例子：

好的部分：

引入Scrum开发框架

有一个公开的Product backlog

有制定产品的release plan

有持续整合的环境

有自动化功能测试案例与测试环境

有待改善：

工作任务分配不均

电脑效能不佳（都是微软的阴谋！）

没有写单元测试

没有pair programming

Task完成条件定义不清

JIRA打开速度太慢（以前的团队真的有人提出过这个改善事项……5555……）

改善行动方针：

长期目标：增进工作环境效率

    行动计划：增加内存条到8GB

    行动计划：都统一使用360优化（或者我们穷的只能够用360优化了）。

长期目标：所有method至少都有三个对应的单元测试案例。

    行动计划：安排一个小时的讲座教导JIRA使用方法；

    行动计划：下个Sprint，每个人至少写三个测试案例；

长期目标：50%的开发工作都以Pair programming 方式进行

    行动计划：因为目前工作环境并不适合Pair programming，因此先改善工作环境。首先向公司申请22寸屏幕、无线键盘及鼠标。

由于改善开发流程是一条很漫长的道路，有多长？这么长…… 长到你看不到底。所以，很多改善项目需要长时间的关注。例如，光是做测试这件事，就足够玩个一年半载以上才会小有成果。所以，为每一个改善项目制定长期目标，然后列出本次的行动计划（action plan，就是下个sprint准备采取的改善措施）。这样一来，周而复始、无穷巡回卯起来力量来改善流程，便最终可以达到“人人有事做，月月有钱领”的最高境界，一直到堆叠溢出（Stack overflow）为止。