Scrum 开发模式失败案例总结（待续）

一．团队Team人数超过7人，在经历的多个Sprint过程发现团队人数最佳人数是5-6人，一旦到达7个人就有些臃肿和拖沓，机动性降低，Planning
Meeting 和Scrum
Review就会时间过长，每天的立会也是时间过长，并且对团队的积极气氛也会有所削弱。每个Team的人员不应该是一成不变的，二是根据每个Sprint的Backlog的划分，来制定最佳的组合团队，这样有利于团队跟团队之间互相的了解，每个人的脾性和技能优秀点都能互相了解，整个项目的参与者如果是50人，最少在这个项目结束的时候有1/3人你应该非常熟悉其能力特点，有人可能会有疑问，如果我跟某个人刚结对编程有效率上的提高，磨合了一段时间有需要接触新的人对于沟通是一种成本。我的意见是，对于程序上的合作特点，可以进行长时间的XP，Scrum要充分拥抱变化，所以每个人都应该是积极主动的去改变和适应变化，掌握变化。

二．不适合Scrum开发模式的人加入到Team中，经过长时间对Team人员的沟通和交流，可以通过其个人能力以及沟通能力，主观能动性判定其到底是不是适合Scrum开发模式，如果不适合应该果断的分离出Team，以减少对其他人的影响。

三．对Sprint的User Story划分不明确，团队的任务职责划分不明确，这里我用到了“划分”其实是不正确的，Sprint的目标完全取决于Team，取决于每个人的努力，取决于每个人对每个BackLog的完成情况，这就有可能导致部分人在接手任务的时候错误的理解了Target，导致任务的失败。一个Sprint中的小失败，就将导致整个项目的延期，此问题不断出现就可以怀疑Team Member的能力了。

四．Scrum Master成为Team的决策者，Scrum Master永远只是为团队服务的角色，完完全全满足团队的需求，不应该是一个引导者也不应是督促者，到底谁来承担督促和引导的作用，全由Team决定，Scrum
Master最大的作用就是防止其他外界因素干扰Team的工作。

五．Team和Team之间的合作应该有一个协调者，此协调者可以称作是Team的组长，但是他不应该全部承担Team的责任，只是Team中大家推举出来的一个默许角色，如果需要跟别的Team沟通，应该他来做协调和督促别的Team来合作。

六．用户不明确，用户永远都是看不见摸不着的，这是Scrum开发中最大的问题，如果没有确切的用户，连需求到搞不清楚，谈何去做项目。

七．目标不明确，如果用户是确切的，那制定目标的Producer +
User如果不能确切的给出每个Sprint的目标，以及每个里程碑的目标，和最终项目的目标，并在每个Sprint的Planning
Meeting去做项目进度演说，其很难保证大家有更好的激情去做好每个Sprint的目标，每个Sprint的目标有一点点失败，就将导致最终项目的失败。

八．不要照搬所有Scrum的东西，在中国他不是万能的，尤其对中国人惯有的需要一个领导这样的思想来说，完全跟Scrum背道而驰，Scrum最核心的理念在于自主能动性，团队就是所有资源，团队就是项目的掌控着，每个人都是其中的螺丝钉螺丝帽，但是少一个螺丝钉螺丝帽都有可能导致整个项目的失败。所以能进入到Scrum开发模式中的人毕竟是少数，可以分而管制，不必所有团队都压在上面，尤其对于开荒的公司更不可冒这个风险。

九．管理层过多的干预Team的工作，Scrum
Master应该很好的保护Team的成果，一旦管理层非要改变，这个Sprint应该正式的Cancel，由于某个人被调用，导致的Sprint失败不应该团队来承担。

十．每个Sprint过于强调每个人目标，而忘记了最终目标，成为Sprint的奴隶，每次都要在Planning Meeting上把每个人的工作非要分配满才算Planning Meeting结束，有些工作是不得不跨Sprint去完成的，可以分为两个阶段，每个Sprint的时间周期总是一成不变，不能去根据相应的User Story做相应的调整。

未完，待续。。。。。。