晚上18:38分，code review之后，可以肥家家啦！
六月，我们组正式认真实践敏捷开发里面的code review的第一天，会议从五点开始，开到了不到八点，那天的calendar订了一个小时；
前两天，收到一个半小时的calendar，内容是做几张卡的estimation。结果业务背景分享完，大家在技术解决方案上无法达成统一，最后这个会议被用来讨论技术解决方案，总耗时1小时50分钟；
七月三十一号，我写了三个小时左右的代码，一整天被各种会议切的零零散散：站会，二十分钟；一个同事要下项目了，他要transfer一个我们都没做过又需要维护的项目，1小时；IPM，1小时；Code review，1.5个小时。比起会议本身耗时，无法正常结束的会议们更让我心累（🤷♀️）。
老实说，会议无法正常结束，我真的觉得是个问题。比如说，code review的时间是订在每天下班前的，大家的初衷很好，放在一天的结尾，不会影响正常工作，正好是个总结；同事会有想要回家的欲望，效率会高。而实际情况就变成了经常拖堂，我甚至无法正常安排自己的下班时间，比如健身约课，我只能跟教练说，我大概什么时候会去，如果到时候没结束，我继续改时间，反反复复，不胜其烦。
同事会讨论，我自己也在思考，为什么我们的会议无法正常结束，以及怎样才能让我们的会议按时完成。
观察了若干结束不了的会议之后，感觉原因可能有：
- 发calendar的人并不确定内容多久完成，先发出来，再慢慢开着看；
- 会议中遇到问题讨论的时候，大家会跑题，讨论着讨论着，已然离题万里，却还在继续；
- 有些会议需要有前置更小范围人群的会议进行讨论，比如纯dev先讨论出技术解决方案；
- 不是所有人对自己的时间都有占有欲......
我从六月下旬开始组织我们组每天的code review以来，也在不断的观察改进，现在，我会这么做：
- 先统一定了每天下午的五点到六点的会议室，毕竟订了会议室才是王道啊，我很不希望每天到处找会议室，还有可能被人“驱逐”；
- 每天下午4点的时候，询问每一个同事当天的代码量，分享的内容及有无需要讨论的问题，预估时间，在不影响个人计划的前提下调整calendar；
- 会议进行中的时候，适时拉回来讨论，嗯，这点还有很大提升空间，其实也会担心大家没讨论尽兴啦；
- 当然啦，有时候到我们会议开始的时间，上一场还没结束，我会有礼貌的走进去，提醒他们该出来啦，哈哈哈，对，其实我是在帮他们。
time's up.png
我认为对我们来讲很关键的点是，根据会议的内容，针对合适的人群，安排合适的时间，而且订好了时间，就尽量遵从它。在时间的压力下，大家会更有效率的挑重点内容说；即便真的时间不够没有讲完，再拉一个会不就好啦？
经过了快两个月，我们的code review每天都可以按时完成嘛？哈哈，并没有哦！不过对比第一天的拖堂两小时，我们现在普遍拖个十分二十分钟，已经很好啦～毕竟，我们还在进步呢，对吧～
网友评论