从07年中初次接触Scrum的概念到其中几年项目中逐渐实践CI、TDD，到亲自掌握项目实践Scrum近一年，最终我们放弃了Scrum这个框架和所谓的“自组织”。原因为何？

1. 成员放弃了Scrum所“赋予”的“权利”

比如领用任务、评估工作量、自组织协作、决策等。在第一次Scrum计划会议上排出任务让大家领用时，成员的态度可以用“反感”来形容。在经历四个Sprint后成员依然坚持认为，应为PM完成这些工作，故放弃。

Gopher的评论：

你缺乏对程序员足够的培训，为什么要切分任务、评估工作量，对比以前，我们需要解决什么问题？为什么人家会反感，估计是开会前缺乏足够的准备，PO自己都解释不清楚需求，慢慢的会议发展为头脑风暴。并且会议主持人对这种明显超出讨论范围的乱象并没有及时制止。

所以，结论是：1、你自己都没搞清楚为什么搞敏捷。

2、因为你没有搞清楚，所以你缺乏实施敏捷的路线图。

3、因为没有路线图，所以在人员选择上，你找了一群没有“敏捷人格”的人来做敏捷。

2. 团队成员能力参差不齐

我很主观地认为，现在国内的开发团队都会是一部分高级工程师搭配一部分初、中级工程师，这种搭配本身就决定了领用任务时的混乱，尤其是团队中一部分成员极度渴望去做那些自己没有经验的任务。结果造成一部分人一直搞不清楚自己在团队中的定位，一直处于“费力不讨好”的挫折中。高级工程师对另一些成员的效率、成果也颇有微词，对团队分工非常不满。

Gopher的评论：

根据团队的velocity，我们通常会对需求的粒度进行要求（这点也是我们敏捷QA的度量目标）。在确定需求粒度之后，任务切分肯定是全体团队成员一起进行的。如果有Issue，就记录并落实Issue责任人，同时解决Issue也形成任务并需要评估时间。当然，长官意志必不可少。

摆明了这人承担不起这项工作（解决Issue都有问题）你也让他选？找死！

摆明了这人面临的任务有多个待解决的Issue（导致团队工作延后）你也敢让他做，找死！

能力参差不齐不是关键，关键的是，scrum master缺乏控场技巧和领导力。这样的水平，当PM都成问题。

3. 没有清晰的设计阶段是造成上面第2个问题的另一个因素

众所周知，敏捷倡导演进式架构，其本质是，在目标不确定性极大的情况下，通过一次又一次短周期的反馈修正来不断接近目标，固在敏捷中，每项任务、剩余工时、成本燃尽，控制得如此之细，CMMI根本扛不起这样恐怖的基线变化次数。取消清晰的设计阶段，以及采用大量并行的测试，可谓敏捷的一种取舍，赢取更短的发布周期。也正因为如此，在任务分解时，无法清晰地定义设计任务，而将其混杂在功能化的任务中，事实说明，这里有大量的重复工作并且交付良莠不齐。

Gopher的评论：

首先，CMMI的基线并非通常意义上的敏捷的“广泛认可”或“增量输出”。所以CMMI在配置管理和质量管理的基线标准不会定义得如此变态。

再次，“清晰”是相对的，在我们的公司里面，一个成熟的敏捷团队，不用将任务粒度划分得过细。而一个才成立的团队，任务粒度几乎就是流程图级别的。当然，无论资深还是新手团队，Scrum Master必须是资深的。

最后，你的团队无法“清晰”的定义任务，要么是PO没有做到位，要么是成员不了解需求。对于团队中的资深的“个性”程序员，那么，尊重他们个性好了。也就是我说的，长官意志。

4. 高估了工程师的成熟度

敏捷对工程师的心智有过高的要求。为什么说是过高？其实，在公司里担任高层管理人员的，恐怕都不具备成熟的心智，何况处于一线年轻又尚轻的程序员？现在的程序员，从学校或从培训班子里出来，人际圈子小，知识面狭窄，遇事仅能从自身考虑，常常因生活中一些事情影响情绪和工作，遇到难题就放弃，全力投入到项目开发中来的并不多见。所以，在项目和开发过程中，监控、管理，催促、激励甚至批评，是必须的！

Gopher的评论：

在我的实践经验中，这种人最好培养。你们不会是因为成本考虑找的实习生吧。如果团队都是高手，我想这种团队，无论CMMI还是敏捷都不重要了。

5. Scrum缺乏领导者

Scrum把团队想象得太完美了，如果有完美的团队，开发方法根本就不重要。工作、项目在进行的过程中，必须会遇到困难、遇到卡壳、团队发生冲突和争吵，这时候，必须有一个人挺身而出，作出决定，解决问题，为大家指明方向，平息争端，警告不利分子，这个人只能是领导人物，能力、权力和职位比团队成员高的人。扁平式组织，想象得太完美了，团队里各种性格的人都有，不服你不爽你的也总有人在，吵个没完没了，各做一套，家常便饭。

Gopher的评论：

会议主持人能力相当重要，并不是每个人都可以做Scrum Master的。争论，是我最喜欢看到的情况。有分歧才有争论，有争论才有更详细的任务目标。关键是，你真的尝试过去引导争论并使之切题？

最后我想说说Scrum适合的团队，这样的团队需要有一些技术成熟度比较高（五至八年经验）、并且比较稳定地做技术的成员，使用Scrum可以使团队日益默契，并改善技术团队沟通交流不善、积累反思不多的常见问题。基本上，Scrum的正面意义在于，以前的项目管理、开发管理都只注意到了需求、技术、测试等机械性问题，而Scrum把团队管理、团队建设的思路引进到了技术团队。而在这个范畴里，Scrum还比较轻量级，它的回顾会议在工业产品开发中随处可见，可作入门指南，大家会问，进阶怎么走？我想未来软件开发团队的路子会和工业产品相似，渐渐地把决策过程、分析思路引进到团队中，这样子的团队才真正是一个“工程师团队”。