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

楼上的，受我一大拜

我也小拜一把

关于洗脑这位哥们，哥也不得不拜一下。

膜拜，很好的思想上的指导。

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

下面是我的一些理解，没想到一下子写了这么多，看来憋了很久了，共大家探讨：
1、什么流程并不十分重要（我们这里就不讨论CMM和敏捷的是非了，好吧），关键是流程应用要契合项目现状，产品目标、团队能力。
  发挥一个流程的优势，进行一些必要的调整，关键还是树立正确的价值观和团队导向，让流程为产品和团队服务，而不是倒过来。
  不过很多时候是倒过来的，因为领导和质量工程师已经脱离了实际工作，更为信任流程、指标，而不是团队和实实在在的产出。盲目的“以数据说话”，对于软件工程而言其实就是在欺骗自己，我见过太多过程数据漂亮，但是产品问题较多的项目了。
2、敏捷之后，一个很大的挑战是所谓的“领导的控制力”。
  CMM中，有一个较为成熟和相对合理的指标体系，这是管理者的拐杖；敏捷之后，sorry，请领导来感受真实产品，数据离散在各个迭代中，该看什么数据？这些数据意味着什么？领导慌了。。。然后质量工程师也慌了，拉着项目利益相关人，赶快针对敏捷制定度量指标。
  结果，一堆并不科学的着指标满天飞，团队成员比以前更麻木的应付更多的指标数据。。。
3、人是最重要的因素，结合者项目管理者对于流程的驾驭能力，将会较好的完成项目。

•   一个团结的团队、积极的团队，效率将会很高，对此管理者的主要工作是通过自己的协调，降低流程对于项目的干扰。这种团队很难碰到，只有相对接近的完美团队。多年来我就碰到一个有点接近的类似团队，这个团队的骨干都是我一手带出来的，设计能力一流、编码能力一流、沟通配合上已经有了较好的基础。新版本在诸多困难情况下，依旧顺利的完成了部分前面迭代的开发……

•   如果一个团队尚未形成团队合作的习惯，不要贸然敏捷。在这种团队来看，敏捷崇尚的集体负责、代码集体所有制，是“吃大锅饭”，体现不出成员的“独特价值”。文化的问题，还要从文化上解决。树立正确的团队导向，形成骨干间互助，骨干与新人间的新老协作的氛围，人尽其用，大家都一心将项目做好，不要过多计较个人。这样团队会更为成功，成员反而得到了更多，尤其是贡献较多的骨干。

•   如果一个团队的成员能力中等或者偏下，不要完全抛弃现有流程全盘敏捷，这是对于团队的摧残：
  • 没有流程的保护，团队会被“随心而动”的需求严重冲击
  • 没有流程的指导，团队茫然迷失方向，不知道该做什么，直接面向对中目标--交付代码，迅速退化为“裸奔”（拿着需求直接开发，不做任何设计）
  • 没有流程的约束，设计能力迅速退化、测试能力很开就会瓦解，出现一个典型的窘境：
    • 设计简化了，模块级设计没有了，异常分支无人考虑了，开发交付的东西脆弱无比
    • 开发不再UT、IT、ST，直接给测试人员ST，所谓开发和测试融合；
    • 不高的开发质量导致测试太容易发现bug了，大量的问题单导致开发测试无法正常有效的运转
    • 每个迭代的包袱越滚越重，然后更为“简化”，以交付基本功能的代码为最高目标
    • 有个比较流行的词叫“带病迭代”，很贴切。但是有时我们尽量避免这种情况的措施有些问题，如“问题单解决率要达到XX%才能进入下一迭代”，这种做法类似“在别处丢了钥匙，反而在路灯下寻找，因为那里有灯，看得见”。
  • 敏捷的各种实践要求人员和团队具备很高的能力和一定的基础:
    • 简单设计、测试驱动、持续集成、自动测试、持续重构、迭代验收、循环。上述每个实践环环相扣，任何一个环节的断裂都会让迭代无法有效运转、轮回。
    • 简单设计。说着太容易了，但是有几个人搞得清楚“简单”到什么程度比较合适？
      • 这种简单要契合开发团队的能力，正所谓“看人下菜碟儿”，多一分浪费，少一分说不清。
      • 设计人员足够了解现有架构、实现和各种约束，以便提前识别风险？短时间内完成需求确认后就启动开发，苦了我们后面的开发人员。
    • 测试驱动。有多少团队做到了设计、开发、测试的融合？各个环节相互配合，相互促进确实很有受益匪浅，但是要打破固有限制
    • 持续集成需要理清各个系统间关系，前期投入较大，不是一个简单的版本可以承受的，“起步价”很高。
    • 自动测试，需要领导的战略眼光、团队的共同认可、成员的持续努力、每个版本的传承和坚持，否则前期投入很容易付之东流。就像在在海边堆积沙堡，在没有形成一定规模时，一点懈怠就会被一个浪冲垮。自动测试的收益要从1到2个版本的长度来衡量，不能太急功近利仅看到1、2个月的收益。
    • 持续重构，是简单设计的必然结果。说实话，重构对于成员能力要求很高，并且强依赖于自动测试能力。没有完善的自动测试能力作为后盾，谁敢在项目中后期开展些许的重构？结果呢，代码腐化严重，1、2个版本后马上就走不下去了。正所谓“技术债务”太多。
    • 迭代验收。看起来很容易，但是需要魄力和执行力、应对力的。验收后，用户迸发了新的想法和要求，如何处理？如果用户要求合理，团队能否承受得住？能够搞定的前提都是，前面介绍的实践执行到位，没有太多技术债务，否则此时团队可能生存都成为问题，谁来“拥抱变化”？另外团队owner的规划能力、客户协调能力很重要，要控制好客户期望，无人可以交付完美的软件。

写了很多了，自己眼睛都看花了，辛苦各位了：），后面有机会再聊。

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

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

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

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

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

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

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

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

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

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

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

动不动就弄到禅上什么的，最傻逼了

故事和任务我觉得倒不是太大的问题。

套用Cockburn的视角，以用户目标为海平面，商业价值在上，具体功能拆解在下。
为什么-做什么-怎么做的拆解过程合理，最终都是殊途同归。

scrum在过程上有很多好的东西，对时间盒的强调，对沟通的高度重视。
但在组织模式上，我以为他并不以人为本，高度扁平化的自组织方式，责权不平衡，人员的能动性事实上会被降低，在实际应用中有大量的问题，当然，这也和整个产业环境和公司文化相关。

非常赞同。并且我霸道地说，很多知识体系，因个人家庭背景丰厚，早已通读，突地包装到企业管理亦或敏捷中，为我等耻笑是活该。


虚心接受批评并暴力点头

诚然，我只给了大家一种方式，就是自由领取任务！后每次总结，大家都说酱紫不好：
1.领来一堆任务，不知如何排序
2.领了又做不完，时间又是自己估的，人家又提前做完，鸭梨大

最后导致估工时束手缚脚，能力强的自然 能力不强的就


我们的故事和任务是两个不同的东西，虽然在开始时，开发人员认为任务即故事，还专门讨论过一场。这些任务是每个Sprint计划会议一时，由大家一起在投影屏幕上根据故事分解开来，然后估算工作量。

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