很可惜的是我们也没有standup meeting,目标变得模糊起来，这会导致问题，就像上学的期末考虑，把所有问题最终都堆积到临考试的前两周，结果可想而知，能及格就不错了。
需求传递流程不规范先说问题，我们的产品经理传递需求都是通过口头来传达的，有以下几个缺点：
口头传达会有信息损失，表达出来的东西和想法可能就会有出入，再传递到另外一个人的脑子里，理解的可能和你表达的又不一样，一次次传递，到最后的实施人员，最终可能面目全非。可能有点夸张，我们的团队也很小，沟通成本也小，但终究还是有问题。你碰到过开发和产品打架么？开发：你就是这么说的，我做的完全是照你说的做的。产品：我没这么说过，你肯定是误解我的意思了。呵呵。
人的想法是会变的，人是会遗忘的。今天以为东西这么做好，头脑里有一套完整的功能流程，但明天可能觉得那里不对，但却想不起来具体是哪里不对了。
有些东西不是一下就能理解的，实施人员得到需求后，可能一下就以为自己明白了，但设计和实现过程中才会发现产品需求有更深层次的用意。在反复揣摩产品需求，加深自己的理解时，记在脑子中的需求可能没有原先那么清晰明确了，好吧，又得去找产品团队确认。
我说这么多的目的只有一个：需求需要书面形式的写下来。产品团队写的过程中会多一个反复揣摩的过程，怎么表达更准确无误，自己的这种想法对不对？然后写下来，写下来就是写下来了，产品可以在这个基础上反复更改，直到无误。实施人员可以反复的理解产品的需求，这回反复理解的需求每次都是清晰可见的。
我们这次也碰到了需求理解不到位的问题，开发人员的功能实现和需求传递者的想法出现了偏差。
最后说说测试的问题最近研发团队加入了Scrum Master新成员，有比较丰富的管理经验，但他做出的决定是先不要招测试人员。功能自己做自己测试。我对测试人员的看法如下：
我觉得开发和测试是对立的，某种意义上来说，开发人员测试自己的代码往往不客观，尤其是单元测试覆盖不到的功能点，开发往往认为自己的功能是没问题的，有一个比喻：程序员写出的代码就是自己的孩子，哪有老给自己孩子揭短的。呵呵。因此这两个角色看问题的角度是不一样的。所以我认为测试人员还是必要的。
Scrum Master可能觉得我们目前的功能还没有那么复杂。所以自测应该没问题吧。在没有测试人员的情况下，为了保证软件质量，覆盖率高的单元测试就很有必要了。
希望我们以后能够做的更好，加油！