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

... 这个任务不是非常优质的“开发任务”，其原因就在于没有清晰的设计阶段。大家应该都清楚，有一个专门的设计阶段，最终可确定假如技术方案为A，咱们就会有任务A1、A2……An，但是没有这个阶段的话，任务就会是B1、B2……Bn，完全不同。后者的优势在于，确实能够达到快速发布反馈，也确实让整体交付物尽可能地与需求吻合，让用户非常信赖我们的能力，但带来的繁重工作、重复工作、浪费、设计不好也体现得非常明显。现在正在逐步优化。

请参考一下我的类似的总结。
2008年的体会：敏捷，想说爱你不容易－－从CMM向敏捷过渡的一点体会（1）
2010年的体会：后CMM时代的思考

首先，我对发言各位表示极端的不信任，建议各位努力反思一下。

我必须承认异常说的还有点道理，但是仅仅是面子上的道理。首先我们应该明白，在开始阶段就把故事分的很细致，粒度很合适是非常困难的。其次，即使粒度很细，也很明确，但是其背后的逻辑关系是否就能很难搞明白。第三，即便都搞的很好，但是问题还是问题，没有解决方法的问题一样是陷阱。当然后面我还可以说第四、第五、第六等等，但是算了，有上面三条就足了。

至于说洗脑之类的是小术，是邪道，虽然可以在某些时候有效，但是不值得学习，更加不值得推广。这种方法是最最应该被程序员阶层反对的做事方式。

对于RCFans的问题，我只说一点，我觉得就够了。那就是他曲解了自我管理和自我组织的含义。当然他的做法，并非只有他一个人在那么做，实际上你看小刀翻译的硝烟，那里也是那么做的，而且我知道很多scrum书里面和培训里面都是这么教育的。这个可以算给他们犯错误找的客观理由吧。

当然我们说给人以选择的自由是没有错误的，但是你要真的给人选择的自由，而不是虚假的自由。其实你仅仅是给了大家一种方法进行选择，也就是用一种强制的方法做所谓的自由选择。

其实这里至少要给大家三种选择的方式。
第一，你自己给出一种你的任务配属方式，也就是告诉大家，你认为各自做些什么比较合适。
第二，你应该给一种默认的机械式的分工方法，比如按照工号顺序去配属任务。
第三，完全自主的去选择各自的任务。
而实际的工作中往往是这三种方法的结合，并且最终还需要做私下的协调。

以上是从的做事情的方法。

下面我再谈一个问题，那就是故事和任务是不是一个东西。这也是很多书和人都没有讨论过的，或者我干脆的说除了我之外，我还真没看见别人说过这个事情，当然我还不是一次说过这个事情，而是多次在多个场合，多个角度的说过这个事情。

故事是故事，是用来反应需求的的，是面向客户的，是沟通的一种方法。
而任务是认为，是用来分配和管理工作的，是面向内部管理的，是管理的一种方法。
开发者应该明白，故事需要根据某种原则进一步的去转化为任务。
也就是说你在分配工作的时候，交给大家的是任务而不是故事。

当然我们也要明白，在某种技术背景和管理方式下，故事和任务可以形成一种表达。但是作为初次接触，经验不够，技术支持不足，能力有限，总之就是条件不是那么好的情况下，还是应该分开处理。

最终我还要说清楚一个事情，也就是软件开发的方法，不应该也不会在短期内起到提高个人素质和开发能力的作用，任何人也不该去奢求这一点。方法也好，管理也吧，是用来维持和协调各种不同能力水平和性格的人一起工作的。当然就长期来看，好的方法和管理肯定可以提高人的素质和能力，但是必须知道这个是长期目标，不可能短期实现。这一段是对一蓑烟雨任平生说的那话的评价。或者我直接的说一蓑烟雨任平生是在抬杠。