公司推行SCRUM有一段时间了，一直想把自己的想法整理一下写点东西，正好看到了这个帖子http://www.iteye.com/topic/748985，参与进去进行了讨论。把自己的回帖贴在这里，基本能完整表达我对SCRUM的看法。
简单一句话，我认为SCRUM不是一个拥抱变化的软件方法。
写道
topgun 写道
先不跑题，说说我们实践过的几种进度反馈方式：
站立会议，不说了
腾讯群，不知道有多少人用过，我们是在培训一些实习生时发现的，几个实习生建了一个群，在里面交流，后来我也加入群，可以及时了解他们的情况，也可加以指导，腾讯群有记录可以查询，可以方便的截图，可以群发邮件，可以改腾讯签名来汇报工作状态。我觉得是一种不正式但非常有效的方法
wiki或blog，对于一些技术研究类或解决问题类的工作，我们要求写wiki，如果不是很商业的东西，也鼓励发blog
微博，呵呵，用javaeye 的闲聊就不错，因为有个firefox插件，可以很方便的报告自己的情况，和了解他人的情况
通过daily build 的报告，从邮件，rss 或是fisheye 里就可以了解
rss订阅，除了第一二个，都是通过rss 订阅来了解，而且一定要，这样减低了获取信息的麻烦度，让沟通可行性提高
jira也用过，发现还是对bug 或一些任务性很强的工作比较合适，对开发工作的情况记录和反馈不太合适。还有写每周报告excel 表，改甘特图等不太成功的方式
再谈谈敏捷或是scrum吧，我们实施scrum，我觉得大部分不成功，后来自己总结的看法是：
楼主就不说了，wwccss春哥把scrum说的很简单，我觉得是不对的。我认为成功的实施敏捷，是一件难度很大的事。
首先是技术上的，敏捷不光是管理和方法，而且需要很好的技术支持，就像光有精益方法但没有很高的生产技术和技术水平很高的产业工人，还是做不到精益一样。具体到软件开发，重构和TDD 就会难倒一大批人，没有TDD就难以保证对需求的覆盖度和正确度，没有refactoring，就不能保证设计的良好。所以我认为，这两个做不到很好就不要谈敏捷
其他不那么技术的东西是不是就容易呢，也不一定，如果只是看了“硝烟”书，就认为自己学会了敏捷，并且想通过实施来获益，我认为很不靠谱，失败机会很大。很简单，站立会议，到底该讲些什么，这个如果不是很有经验的人来现场长期引导，很容易就讲歪了，被变味了
要建立实施scrum，我认为要做到以下几点：
首先要有高技术水平的团队，至少有一半是真正的程序员（真正程序员我也不好定义，反正理解为所有编代码的人里不到10%的可以是真正程序员就可以了）
团队中能有一个或多个通过了scrum中级以上培训认证的人担任scrum master
如果可能，团队实施初期，请专业的顾问公司对团队成员进行培训，甚至聘请顾问参与团队
反正我认为，要敏捷，就认真去做，不要搞什么我只借鉴部分思想，我搞个中国特色的敏捷，那还不如你自己搞自己的土飞机呢（没有贬低土飞机的意思，这也是一种可以成功的方法）。
难是不是就做不到呢，mba难吧，雅思难吧，还是大把人去，小公司只要肯搞，先抽出三四个人的精英团队，走正确的路，也是有得搞的。
敏捷=高效!=简单
公司最近一直在搞scrum。从一个developer的角度看来，scrum，至少我们实施的以及绝大多数我所了解的scrum，用处不大。从一个developer的角度看，一个项目要想作的好，无非是三点： 1）程序员了解业务，了解需求 2）程序员有能力清楚，正确，高效的完成代码 3）人员交替时能顺利完成代码移交，不出现知识遗漏对于1，scrum没有任何真正有效地手段，站立会议强调的是让大家了解别人的进度，对于如何让程序员深入业务，思考流程，scrum都没有说。XP里面还有个现场客户的概念，要developer和客户现场交流，虽然实施起来有难度，但毕竟是一个方向；而且一旦实施起来，能够接触第一手客户对于developer了解业务确实有很大帮助。而scrum呢？当然你可以说scrum也只是一个方法论，这个应该由具体项目去解决，不过这样还要你scrum有何用？对于2和3,这是我觉得scrum实施最让人不舒服的地方。XP里面解决这个问题的核心是TDD，有了TDD才有refactor，有了refactor才能让你在对业务有了新的了解后敢于将其反映到原有代码中，而非不敢动原来的，另搞一块。搞TDD对程序员的要求高一些（同时对程序员的提高也快一点），在我看来这是个能力问题，而scrum却没有谈程序员的能力差别，给我的感觉是“用了scrum，把能力问题通过流程的方式解决”。这不是扯淡嘛！敏捷本来就不是什么人都能用的，如果你找的都是1000块的代码工人，最好的方式就是外包公司那样反复的review再review，还搞什么敏捷？ 总体来说,scrum那些best practices，像什么sprint，stand meeting，daily build大多容易实施，这大概也是为什么有那么多scrum master能被生产出来的原因。但一把号子容易吹响也就意味着容易吹跑调，而scrum的实施者只会说“听啊，我们吹的多响！”却绝不会说“天啊，我们吹得多难听！”。站在项目管理的角度，燃尽图让PM不再那么彷徨，能够得到一丝掌握世界的安全感。我想，这大概是为什么那么多项目组容易被scrum打动，进而实施scrum的原因，除此之外，我真的想不出为什么会有这么多人追捧scrum。
先不跑题，说说我们实践过的几种进度反馈方式：
站立会议，不说了
腾讯群，不知道有多少人用过，我们是在培训一些实习生时发现的，几个实习生建了一个群，在里面交流，后来我也加入群，可以及时了解他们的情况，也可加以指导，腾讯群有记录可以查询，可以方便的截图，可以群发邮件，可以改腾讯签名来汇报工作状态。我觉得是一种不正式但非常有效的方法
wiki或blog，对于一些技术研究类或解决问题类的工作，我们要求写wiki，如果不是很商业的东西，也鼓励发blog
微博，呵呵，用javaeye 的闲聊就不错，因为有个firefox插件，可以很方便的报告自己的情况，和了解他人的情况
通过daily build 的报告，从邮件，rss 或是fisheye 里就可以了解
rss订阅，除了第一二个，都是通过rss 订阅来了解，而且一定要，这样减低了获取信息的麻烦度，让沟通可行性提高
jira也用过，发现还是对bug 或一些任务性很强的工作比较合适，对开发工作的情况记录和反馈不太合适。还有写每周报告excel 表，改甘特图等不太成功的方式
再谈谈敏捷或是scrum吧，我们实施scrum，我觉得大部分不成功，后来自己总结的看法是：
楼主就不说了，wwccss春哥把scrum说的很简单，我觉得是不对的。我认为成功的实施敏捷，是一件难度很大的事。
首先是技术上的，敏捷不光是管理和方法，而且需要很好的技术支持，就像光有精益方法但没有很高的生产技术和技术水平很高的产业工人，还是做不到精益一样。具体到软件开发，重构和TDD 就会难倒一大批人，没有TDD就难以保证对需求的覆盖度和正确度，没有refactoring，就不能保证设计的良好。所以我认为，这两个做不到很好就不要谈敏捷
其他不那么技术的东西是不是就容易呢，也不一定，如果只是看了“硝烟”书，就认为自己学会了敏捷，并且想通过实施来获益，我认为很不靠谱，失败机会很大。很简单，站立会议，到底该讲些什么，这个如果不是很有经验的人来现场长期引导，很容易就讲歪了，被变味了
要建立实施scrum，我认为要做到以下几点：
首先要有高技术水平的团队，至少有一半是真正的程序员（真正程序员我也不好定义，反正理解为所有编代码的人里不到10%的可以是真正程序员就可以了）
团队中能有一个或多个通过了scrum中级以上培训认证的人担任scrum master
如果可能，团队实施初期，请专业的顾问公司对团队成员进行培训，甚至聘请顾问参与团队
反正我认为，要敏捷，就认真去做，不要搞什么我只借鉴部分思想，我搞个中国特色的敏捷，那还不如你自己搞自己的土飞机呢（没有贬低土飞机的意思，这也是一种可以成功的方法）。
难是不是就做不到呢，mba难吧，雅思难吧，还是大把人去，小公司只要肯搞，先抽出三四个人的精英团队，走正确的路，也是有得搞的。
敏捷=高效!=简单
公司最近一直在搞scrum。从一个developer的角度看来，scrum，至少我们实施的以及绝大多数我所了解的scrum，用处不大。从一个developer的角度看，一个项目要想作的好，无非是三点： 1）程序员了解业务，了解需求 2）程序员有能力清楚，正确，高效的完成代码 3）人员交替时能顺利完成代码移交，不出现知识遗漏对于1，scrum没有任何真正有效地手段，站立会议强调的是让大家了解别人的进度，对于如何让程序员深入业务，思考流程，scrum都没有说。XP里面还有个现场客户的概念，要developer和客户现场交流，虽然实施起来有难度，但毕竟是一个方向；而且一旦实施起来，能够接触第一手客户对于developer了解业务确实有很大帮助。而scrum呢？当然你可以说scrum也只是一个方法论，这个应该由具体项目去解决，不过这样还要你scrum有何用？对于2和3,这是我觉得scrum实施最让人不舒服的地方。XP里面解决这个问题的核心是TDD，有了TDD才有refactor，有了refactor才能让你在对业务有了新的了解后敢于将其反映到原有代码中，而非不敢动原来的，另搞一块。搞TDD对程序员的要求高一些（同时对程序员的提高也快一点），在我看来这是个能力问题，而scrum却没有谈程序员的能力差别，给我的感觉是“用了scrum，把能力问题通过流程的方式解决”。这不是扯淡嘛！敏捷本来就不是什么人都能用的，如果你找的都是1000块的代码工人，最好的方式就是外包公司那样反复的review再review，还搞什么敏捷？ 总体来说,scrum那些best practices，像什么sprint，stand meeting，daily build大多容易实施，这大概也是为什么有那么多scrum master能被生产出来的原因。但一把号子容易吹响也就意味着容易吹跑调，而scrum的实施者只会说“听啊，我们吹的多响！”却绝不会说“天啊，我们吹得多难听！”。站在项目管理的角度，燃尽图让PM不再那么彷徨，能够得到一丝掌握世界的安全感。我想，这大概是为什么那么多项目组容易被scrum打动，进而实施scrum的原因，除此之外，我真的想不出为什么会有这么多人追捧scrum。
写道
daquan198163 写道
没有极限编程的最佳实践（如tdd、重构、ci）支持，scrum就会变成“行为艺术”，呵呵
这也是我一直的观点：没有XP，SCRUM当然可以作，当然也可以出结果，当然也可以让PM有虚假的安全感。但是这样的SCRUM相对于RUP等方法论来说得不到实质上的提高。
我当年之所以对TDD一见之下大为赞赏，并去学习和尝试，正因为TDD是能够解决实际问题的一种方法。尽管未必同意PP等方式，但TDD,refactor,CI等确实给我带来了安全感，使得我每次check in代码时不用去想到底要花多少时间改bug，也能够自然而然的敢于并乐于做重构，并进而用于使自己的代码贴近需求。
TDD是XP的核心。TDD要求程序员能够客户沟通，整理需求，构造用例，规划代码。这本身就不是所有程序员都能做到的。所以XP也并不适合所有水平的开发团队。乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。那剩下的三分之二呢？你就老老实实的搞你的瀑布吧！可是敏捷听起来多煊啊，这时候就冒出所谓“可裁剪的，灵活的敏捷开发方法”，也就是SCRUM了。
你不是不能搞TDD嘛？SCRUM中从标配改成选配了，你不搞TDD就不敢重构？没问题，咱把重构改成“持续改进”了。分个sprint，早上开个会，这样具有“可操作性”的步骤谁学不会啊。于是乎，无论阿猫阿狗都能通过SCRUM的便车走上敏捷的康庄大道，从此过着幸福快乐的生活了。
可是对这个“持续改进”，我始终没明白该怎么实现。我只知道我的同事们在“SCRUM without TDD”中，每次选择方案时总是选择对原系统改动最小的打补丁的作法，而不是将系统按照最新需求改造，因为risk，QA不想改，developer不愿改，连PM都倾向于不要改。每次改点东西都搞得和打仗一样紧张，这和以前的流程又有什么差别呢？
我觉得吧，之所以这么多人反对SCRUM正是因为SCRUM trainer把它放在了一个不恰当的位置。 如果把XP当成core的话，你把SCRUM定位成一个shell那是一点问题也没有，“如果你团队中的成员能够并且乐于实施XP了，那么我有这样一些方法可以帮你的团队更方便的融入敏捷开发，这些方法的集合称为SCRUM”，这样说相信没人反对。 可现在SCRUM的定位是另外一个core,"就算你搞不了XP,咱也能把你带入敏捷的门"。这样一来，对于那些实际没有搞XP（这是大多数）的团队来说，SCRUM真就是个花花架子了。
没有极限编程的最佳实践（如tdd、重构、ci）支持，scrum就会变成“行为艺术”，呵呵
这也是我一直的观点：没有XP，SCRUM当然可以作，当然也可以出结果，当然也可以让PM有虚假的安全感。但是这样的SCRUM相对于RUP等方法论来说得不到实质上的提高。
我当年之所以对TDD一见之下大为赞赏，并去学习和尝试，正因为TDD是能够解决实际问题的一种方法。尽管未必同意PP等方式，但TDD,refactor,CI等确实给我带来了安全感，使得我每次check in代码时不用去想到底要花多少时间改bug，也能够自然而然的敢于并乐于做重构，并进而用于使自己的代码贴近需求。
TDD是XP的核心。TDD要求程序员能够客户沟通，整理需求，构造用例，规划代码。这本身就不是所有程序员都能做到的。所以XP也并不适合所有水平的开发团队。乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。那剩下的三分之二呢？你就老老实实的搞你的瀑布吧！可是敏捷听起来多煊啊，这时候就冒出所谓“可裁剪的，灵活的敏捷开发方法”，也就是SCRUM了。
你不是不能搞TDD嘛？SCRUM中从标配改成选配了，你不搞TDD就不敢重构？没问题，咱把重构改成“持续改进”了。分个sprint，早上开个会，这样具有“可操作性”的步骤谁学不会啊。于是乎，无论阿猫阿狗都能通过SCRUM的便车走上敏捷的康庄大道，从此过着幸福快乐的生活了。
可是对这个“持续改进”，我始终没明白该怎么实现。我只知道我的同事们在“SCRUM without TDD”中，每次选择方案时总是选择对原系统改动最小的打补丁的作法，而不是将系统按照最新需求改造，因为risk，QA不想改，developer不愿改，连PM都倾向于不要改。每次改点东西都搞得和打仗一样紧张，这和以前的流程又有什么差别呢？
我觉得吧，之所以这么多人反对SCRUM正是因为SCRUM trainer把它放在了一个不恰当的位置。 如果把XP当成core的话，你把SCRUM定位成一个shell那是一点问题也没有，“如果你团队中的成员能够并且乐于实施XP了，那么我有这样一些方法可以帮你的团队更方便的融入敏捷开发，这些方法的集合称为SCRUM”，这样说相信没人反对。 可现在SCRUM的定位是另外一个core,"就算你搞不了XP,咱也能把你带入敏捷的门"。这样一来，对于那些实际没有搞XP（这是大多数）的团队来说，SCRUM真就是个花花架子了。
写道
wwccss 写道
引用
乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。
不要说三分之一，估计十分之一也不到。
引用
TDD是XP的核心。TDD要求程序员能够客户沟通，整理需求，构造用例，规划代码。这本身就不是所有程序员都能做到的。所以XP也并不适合所有水平的开发团队。乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。那剩下的三分之二呢？你就老老实实的搞你的瀑布吧！可是敏捷听起来多煊啊，这时候就冒出所谓“可裁剪的，灵活的敏捷开发方法”，也就是SCRUM了。
常识性错误。几篇文章，介绍scrum和xp出现的时间。
http://zh.wikipedia.org/zh-cn/Scrum
http://zh.wikipedia.org/zh-cn/极限编程#.E5.8E.86.E5.8F.B2
引用
1986年，竹内弘高和 野中郁次郎阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：[1]
他们将这种新的'整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而后者整个团队"tries to go to the distance as a unit, passing the ball back and forth"。
他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究。
1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》[2]一书中将这种方法称为 Scrum，在竹内弘高和 野中郁次郎的文章中提到的橄榄球术语。
1990年代初，肯·施瓦伯在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。
同时，杰夫·萨瑟兰在Easel公司开发了一种类似的方法，并首次称之为Scrum。[3]
1995年，在奥斯汀举办的OOPSLA '95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里合作，将上述的文章，他们的经验，以及业界的最佳实践融合起来，形成我们现在所知的Scrum。
2001年，施瓦伯与 麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。
scrum的概念早于xp提出。只不过国内的开发人员接触的xp反而比scrum要早。说是scrum是为了避免xp的问题而推出的，就大错特错了。
scrum和xp不矛盾。一个是面向宏观的管理，一个是面向具体的开发实践，两者可以很好的结合。
我想我大概能够明白je上面的朋友为什么对 scrum有很多的偏见了。因为大家都是开发人员，更多的是站在开发的角度来谈论这个问题。
我也和PM交流过对于SCRUM的看法。确实，从项目管理的角度说，SCRUM本身强调短周期的迭代，通过为期一到两周的sprint，事先的评估以及持续的追踪，使PM对于开发过程比更长周期的迭代把握的更清楚。这点也是PM认同SCRUM相对以前流程的优势。
我只是认为小步快跑原本是所有敏捷方法所提倡的。但没有TDD作为基础，即使你能小步，却无法快跑。因为新的需求总是不断出现，没有TDD，大多数developer合乎理性的选择就是通过补丁的方式加外挂。长期下来必然造成维护难度提高，也自然无法真正拥抱变化。这也是随着软件开发时间变长，系统越来越难以维护的根本原因，而SCRUM自身并没有对这个问题提出解决方法。
站在我的角度，SCRUM是一个不错的，也相对容易施行的软件开发流程。在我们这样水平的团队中，相比于瀑布或者RUP，它有着不错（至少不会更差）的效果。但这个方法本身没法解决“拥抱变化”这个敏捷的核心问题，所以我认为不应称其为“敏捷”方法。
也正如您所言，这是看问题的不同角度，不过世间争执原本也就是角度不同罢了。
另外关于
引用
常识性错误。几篇文章，介绍scrum和xp出现的时间。
http://zh.wikipedia.org/zh-cn/Scrum
http://zh.wikipedia.org/zh-cn/极限编程#.E5.8E.86.E5.8F.B2
不要说国外怎么样怎么样，在国内SCRUM就是作为一种“容易掌握的敏捷方法”粉墨登台的。如果这个都不相信，那只能说您是生活在象牙塔里面了。
引用
乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。
不要说三分之一，估计十分之一也不到。
引用
TDD是XP的核心。TDD要求程序员能够客户沟通，整理需求，构造用例，规划代码。这本身就不是所有程序员都能做到的。所以XP也并不适合所有水平的开发团队。乐观地说，当前水平能够正常实施TDD的团队，国内不超过三分之一。那剩下的三分之二呢？你就老老实实的搞你的瀑布吧！可是敏捷听起来多煊啊，这时候就冒出所谓“可裁剪的，灵活的敏捷开发方法”，也就是SCRUM了。
常识性错误。几篇文章，介绍scrum和xp出现的时间。
http://zh.wikipedia.org/zh-cn/Scrum
http://zh.wikipedia.org/zh-cn/极限编程#.E5.8E.86.E5.8F.B2
引用
1986年，竹内弘高和 野中郁次郎阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：[1]
他们将这种新的'整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而后者整个团队"tries to go to the distance as a unit, passing the ball back and forth"。
他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究。
1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》[2]一书中将这种方法称为 Scrum，在竹内弘高和 野中郁次郎的文章中提到的橄榄球术语。
1990年代初，肯·施瓦伯在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。
同时，杰夫·萨瑟兰在Easel公司开发了一种类似的方法，并首次称之为Scrum。[3]
1995年，在奥斯汀举办的OOPSLA '95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里合作，将上述的文章，他们的经验，以及业界的最佳实践融合起来，形成我们现在所知的Scrum。
2001年，施瓦伯与 麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。
scrum的概念早于xp提出。只不过国内的开发人员接触的xp反而比scrum要早。说是scrum是为了避免xp的问题而推出的，就大错特错了。
scrum和xp不矛盾。一个是面向宏观的管理，一个是面向具体的开发实践，两者可以很好的结合。
我想我大概能够明白je上面的朋友为什么对 scrum有很多的偏见了。因为大家都是开发人员，更多的是站在开发的角度来谈论这个问题。
我也和PM交流过对于SCRUM的看法。确实，从项目管理的角度说，SCRUM本身强调短周期的迭代，通过为期一到两周的sprint，事先的评估以及持续的追踪，使PM对于开发过程比更长周期的迭代把握的更清楚。这点也是PM认同SCRUM相对以前流程的优势。
我只是认为小步快跑原本是所有敏捷方法所提倡的。但没有TDD作为基础，即使你能小步，却无法快跑。因为新的需求总是不断出现，没有TDD，大多数developer合乎理性的选择就是通过补丁的方式加外挂。长期下来必然造成维护难度提高，也自然无法真正拥抱变化。这也是随着软件开发时间变长，系统越来越难以维护的根本原因，而SCRUM自身并没有对这个问题提出解决方法。
站在我的角度，SCRUM是一个不错的，也相对容易施行的软件开发流程。在我们这样水平的团队中，相比于瀑布或者RUP，它有着不错（至少不会更差）的效果。但这个方法本身没法解决“拥抱变化”这个敏捷的核心问题，所以我认为不应称其为“敏捷”方法。
也正如您所言，这是看问题的不同角度，不过世间争执原本也就是角度不同罢了。
另外关于
引用
常识性错误。几篇文章，介绍scrum和xp出现的时间。
http://zh.wikipedia.org/zh-cn/Scrum
http://zh.wikipedia.org/zh-cn/极限编程#.E5.8E.86.E5.8F.B2
不要说国外怎么样怎么样，在国内SCRUM就是作为一种“容易掌握的敏捷方法”粉墨登台的。如果这个都不相信，那只能说您是生活在象牙塔里面了。