引言：
我会以系列文章的形式跟踪记录我现在正在做的一个完整运用Scrum管理项目的笔记，里面会有一些经验教训总结心得，以便读者与我互相学习勉励。有写的不对的或者写的不好的地方还请海涵，当然我更希望大家多多提宝贵意见，读者的支持是我最大的动力。（之一，之二，之三，之四，之五，之六）
============================================================================================
正文：
我尽量保持每周都会跟大家分享一点我在上一个Iteration周期中碰到的问题以及收获，所有不一定有很多东西可以写，但是我尽量能把我认为有意义的东西留下来。
每次到了周五都会有一种罪恶感，到底我上一个Iteration完成了没有，对于敏捷来说，我们每一个Iteration或者是Sprint也好，都应该是阶段可交付。也就是说我们应该有一些对用户有价值的Story完成了。Iteration的产物不在多，而在于是否有可交付的Story，而对于可交付这个词我不知道大家的理解是不是一样，至少我认为就是得到客户的认可，对客户是可以用的场景或功能。而到目前位置我们已经结束第三个Iteration了。应该来说应该有东西可交付了。但是作为PM或者PO的我来说，我觉得还没有一个Story是可交付的。因为我认为可交付的意思是说，这个Story的价值都已完成，可以Demo演示给用户看，并且达到验收准则。那么关键词就是价值、Demo、验收准则。什么是价值？简单来说就是对用户来说是有意义的，最实惠的。比如说用户要一个查询系统特定用户权限的功能，那么我们有两种做法，一种是做一个权限查询的功能模块，可以查询所有用户的所有权限的通用模块。还有一种做法是，在特定场景下，按照特定用户查询权限。第一种很通用，满足客户要求了，甚至超出了，但是这样就是好的吗？第二种看起来很呆板，但是是不是用户更想要的呢？而且开放花的功夫比第一种更小，带来的价值更大。然后是Demo，为什么要强调Demo呢，我看来有这么几个优点，1.不是开发环境，可以更接近正式环境。2.更直观，不管是演示还是用户体验也好都很好。3.如果要做Demo开发人员会更用心，不会认为只是随便跑跑看。最后是要收准则，我的验收准则很简单就是在我这里0缺陷。有的人可能会说是不是太苛刻，我觉得并不苛刻，我是一个非专业测试人员，我更关注的是业务、价值，在我常规业务操作下还有缺陷的话，我相信真实用户也是不能接受的。
最后我想给大家分享一下项目运行到目前为止碰到的沟通问题，我是如何应对的。
首先要费点口舌介绍一下我目前的团队成员大致情况，PM项目经理1人，TM技术经理1人，开发6人，美工前端2人，测试2人，QA1人。 因为我们不是完全按照敏捷Scrum角色来定义，所以角色会比较多，公司规定嘛，没有办法。所以这么看来沟通就非常的重要了。我画了一个简单示意图，该图以开发一个完整Story为前提，以开发这个角色为主线，在开发过程中我们的团队协调沟通示意。自己理解，请高手们海涵，欢迎拍砖！呵呵
OK，今天的分享就到这吧，下次我想改讲一讲Iteration Planning Meeting了。谢谢收看。马上三八妇女节了，提前预祝天下辛劳的妇女们节日快乐。
注：如有转载还望标明出处，谢谢。