Scrum之成败——从自身案例说起，仅供参考

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

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

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

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

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

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

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

你把任务分的太粗了......不信你把用户故事

用如下问题过一过?
Are the requirements clear?
Are the requirements complete?
Are the requirements verifiable?
Are the requirements associated with valid scenarios?
Does the design meet all requirements?
Have all key design decisions been addressed and documented?
Have all terms been defined?
Have all terms been defined?
Are security concerns addressed?
Are privacy concerns met?
Is the UI fully accessible?
Is it ready for globalization and localization?
Are response and performance expectations clear and measurable?
Has instrumentation been specified?
Has programmability been specified?
Are there issues with backward compatibility?
Are there issues with forward compatibility?
Are failures and error handling addressed?
Are setup and upgrade issues covered?
Are maintenance issues addressed?
Are backup and restore issues met?
Is there sufficient documentation for support to do troubleshooting?
Are there any potential issues that impact patching?
----------------以下google翻译--------------

明确的要求是？
完整的要求是？
可核查的要求是？
是否有效的情况下与相关的要求？
设计是否满足所有的要求吗？
让所有重要的设计决策得到处理和记录？
是否所有条款已界定？
是否所有条款已界定？
是安全问题解决？
是隐私问题见过？
是UI完全访问？
是否为全球化和本地化准备好了吗？
是响应和业绩预期明确的和可衡量的？
是否已指定仪器？
有可编程被指定？
是否有与向后兼容问题？
是否存在前向兼容的问题？
有失败和错误处理的问题？
安装和升级问题是否涉及？
无需维护处理的问题？
是备份和还原问题见过？
是否有足够的文件支持做故障排除？
是否有任何潜在的问题，影响修补？

用仪式、图片、口号等噱头，造成一种神秘感和神圣感，能力方面实质上却达不到一丝改善。

如果没有XP的一系列工程实践的支撑，Scrum很容易变成“行为艺术”。
不知你们TDD和CI做的怎么样？
比如你们有多少单元测试case，覆盖率是多少？通过率是100%么？测试里面有足够的断言么？
另外你的第4点，结对儿可以很好的解决这个问题。

现在已转入XP近三周

在Scrum的4个Sprint从第一个Sprint开始写单元测试，第二个Sprint启用CI，代码覆盖率40%，每日最后通过率100%，一旦有不通过项，1小时内发现，2小时内修复。

在产出和Bug质量方面，团队做得不错，Scrum最后觉得不想搞的原因是太多干扰因素，技术团队还是聚焦到技术上来，发散因子靠个人修为。

期待中国特色的敏捷实践，目前大多数敏捷方法都是国外的技术团队经验。

在我看来，XP应该比Scrum能力要求更高。
楼主为什么说Scrum要求高然后又转入XP？

这就是心智能力和技术能力的范围不同。

我一开始也由scrum进入敏捷，也走了弯路，后来和一些搞布道的聊过才知错

楼主讲的心智的确是一个问题，结对不能完全解决，两个脑子不清楚的人一起乱搞，越专注越可怕

现在这样搞：

首先洗脑
痛斥传统软件工程的万恶
讲诉敏捷的真谛（我讲的是反馈和初心）
让一帮人愿意和你一起闹革命

然后是锻炼技能
重构、TDD、CI、用户故事最佳实践，都得练熟
个人敏捷也别拉下，什么GTD、番茄、生活平衡、早睡早起，搞得人风风火火、精精神神（再邪一点还可以练练什么记忆、潜意识）

最后，才是scrum这样的方法

附几张我给人洗脑时用的图，不全是原创，一些参考了Daniel Teng的一个ppt