一、重新整理产品需求
PM的思考：经过3个Sprint，从目前看来，觉得我们在禅道上输入的产品－模块－需求树形结构比较散乱，当时一方面对系统不够熟悉，另一方面希望能够兼顾产品视图和工程视图，但这样做难度太大。
如果全部按照产品的角度来分解需求，那么有些底层的需求如何分解，比如各模块都需要的外部通讯等等，这需要我们从实践中寻找答案。
另外，配合中秋节前讨论的看板调整方案，我们将在新的需求上增加“How To Demo”的信息。
二、代码走读的安排
今天我和DPM讨论代码评审如何安排，我们先总结了需要改变的现状：
1、代码问题是普遍问题，主要是新员工良好的编码习惯还没有养成，会导致较多低级错误；
2、DPM日常为帮助工程师解决疑难问题，会查看他们的代码，发现不好的，会告知工程师，但没有起到作用，工程师仍旧会犯同样的错误；
3、安排工程师在一个周期内互相做代码走读，但工程师经常在最后一刻仓促完成走读活动，质量并不好；
4、没有形成固定输出，只是利用邮件交互，加之工程师的个人学习方法没有形成，不会对照备忘；
4、代码走读时机太晚，事实上没起到更早发现问题的作用。
我们对现状的判断
1、看板中有明确的开发任务，而代码走读任务并没有粘贴到看板，就变成一个隐形的任务。因此，工程师会就不会关注这个任务，导致拖到最后仓促完成；
2、新员工还没有体验过修改Bug的辛苦，因此，尚没有这方面的教训，质量意识尚未培养起来；
3、DPM的教导谆谆教导看来对工程师的刺激不够明显
4、开发任务的验证环节不够明显
针对问题和判断，我们拟定尝试的解决方案
1、增加代码走读的任务，并粘贴到看板上，初步意见是每个backlog设置一到两条“code review”任务。争取当然太多则滥。（我们讨论后征询PM的意见，她就是比较担心各种各样的任务太多，使得开发目标被弱化）
2、文档化Codereview的输出，必要的话可以考虑贴在作战室墙上，或者利用其它更醒目的方式刺激工程师注意此事（这个还是要兼顾工程师感受）
3、大致确定频率，每个工程师每周走读一次别人的代码，这样大约每天都有一个次的走读，这样应该可以天天可以提醒了:)
PS:关于代码走读，一个不错的普及文章：http://www.neco.com.cn/DRNECO/Content_003/code%20review.htm
