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

说些看法。为了一片落叶而放弃一个美丽的秋天，真的很可惜——这是我对楼主观点的主要看法。

Agile/Scrum是什么，恐怕三言两语说不清楚，但是有一点，Agile是一种“变革”，所以在变化面前，楼主说的1、2点就会暴露出来。是选择保持现状还是往前提升，需要团队领导和团队去做选择。

3这个问题，必须引入Refactory才能解决，kent beck在xp实践中指出，多种实践在一起运用才能发挥最大作用。

4需要引导，当你在实施第一个敏捷项目的时候，你的要求会放在身为位置呢？我领导过的一个项目实际情况是，队员没有丝毫任务分解概念，分解的任务粒度很粗，粗到无法画burndown图，但是我没有立即对这些问题做修正，而是通过更多示范和时间来解决。

5楼主说的很对，非常认同。

实施Scrum是既需要条件，也需要策略，前者门槛不高，后者需要有一定经验的人去引导，并且发现和解决问题。在实践中演进，这也是“变革”的一部分，唯有勇者可以为之。

使用敏捷对团队的要求会很高无论是技术上还是心理上 而且也锻炼技术 如果团队可以 推荐用敏捷
至于 scrum可以不依靠敏捷 让它成为一个单纯的 迭代开发过程 也很好用

另外说一点，楼主自认为是测试方面的高手，因此在测试方面似乎下了苦功，也做了n多实践尝试，是否对于你的团队来说要求过高？我这次在实施scrum的时候，测试仅仅放在service层做，对action一概不管，通过code review解决测试覆盖不到的问题，ci我也没有做（当然我是有条件做的，用hudson和cobertura），在这个项目中我把它们cut了。

很高的话就不称为轻量了，比如站立会议，非常简单。

TDD叫做测试驱动，我一直觉得是个威武的一塌糊涂的东西。

既然所谓驱动，个人以为，严格的来说，从高高在上的商业远景到用户目标所在直至支撑这些东西的子功能，这整个过程是需要由测试来驱动的，也就是要由可执行文件来驱动整个业务场景中的所有角色及其职责与协做的发现过程。

已经拆解到子功能了，再来搞单元测试驱动，收益是有的，一个完整的边届描述，单元重构的可靠保障。但真的是否有传道者们所宣扬的专制各种不服，我是持怀疑态度的。

在成本约束下，把单元测试的成本放到有效的地方，我觉得是很好的，但我以为Scrum中最好的几个点之一就包括对SCM的高度重视，CI的产出投入比高的一塌糊涂，你们为什么cut掉CI？

在开始时大家疑问肯定有，比如问时间紧张，这么做是否合适。

但如果我告诉你项目八个多月以来从来没安排专门修复Bug的时间阶段，Bug极少，程序应对变化极快的话，就很有说服力了。

某些测试大家不会做的，不知道如何在测试中复用来简化测试代码行的，我结对编写。

大哥，我正深受其害啊~~~~~用那个模式痛苦的要死~~

对于楼主正文中的1、2、3、4，可以尝试下：
1，强制结对。
2，结对必须是高低配（新老配），且是能力稍低（不熟悉遗留代码的主导）的动手。
3，模块级或者关键功能必须有方案设计，可以口头或图形描述。

关于story和task，从源头切分，对大点的story细分为若干个较小的story，是不是个比较好的办法。然后不再明确task。如果无法准确被验证的task，切分了也是个心理上的安慰意义，只要做到及时预警，哪怕你一个story两人做个5天又怎么样，不要为了task而分task。

敏捷，一个方法论而已，本来就不用过分盲从。

一般来说推荐书是我比较鄙视的行为，不过这个确实不错，大家讨论的东西有些也可以在其中找到答案，很短，90页。

http://wenku.baidu.com/view/42c15e4633687e21af45a995.html

当然了，仅供参考，有时候是和别人的不一定适合你。