拜读，总结和楼下的诸位的评论“头脑风暴”十分精彩，目前本人也在一个初级的scrum试点团队中，倡导scrum的领导与试点中的成员们，也都表示难度很大，目前对楼主总结中的两点十分的感同身受。 （以下言论主要是针对自己的试点团队的感受） a.团队成员能力参差不齐 我很主观地认为，现在国内的开发团队都会是一部分高级工程师搭配一部分初、中级工程师，这种搭配本身就决定了领用任务时的混乱，尤其是团队中一部分成员极度渴望去做那些自己没有经验的任务。结果造成一部分人一直搞不清楚自己在团队中的定位，一直处于“费力不讨好”的挫折中。高级工程师对另一些成员的效率、成果也颇有微词，对团队分工非常不满。 @@@这一点实在是难以克服，能者多劳，一直在帮助后来者“弱者”，时间长了十分的疲惫，而且没有发现后来者有什么明显的提升，久而久之导致强者也兴趣索然，不在在工作中关注如何引导后进者，仅仅将重心放在了交付和完成工作上。尤其在否个交付压力极大的阶段，甚至会导致极度的不满和冲突，这一点对团队是很恶劣的影响。个人感觉在这个scrum这个要求“自组织”的团队中，个人的性格、毅力、上进心是你能否在这个团队中立足的根本，离了这个，一切免谈。 b.高估了工程师的成熟度 敏捷对工程师的心智有过高的要求。为什么说是过高？其实，在公司里担任高层管理人员的，恐怕都不具备成熟的心智，何况处于一线年轻又尚轻的程序员？现在的程序员，从学校或从培训班子里出来，人际圈子小，知识面狭窄，遇事仅能从自身考虑，常常因生活中一些事情影响情绪和工作，遇到难题就放弃，全力投入到项目开发中来的，并不多见。所以，在项目和开发过程中，监控、管理，催促、激励甚至批评，是必须的！ @@@@@首先说sm，国内很少有真正尊重技术的土壤，至少在我目前的公司来说是如此。真正的热爱技术，是为了写程序而写程序，但是大部分的公司，应该都是为了不写程序而写程序。甚至有些有色眼镜“工作5年了还在一线编程”是种能力欠缺的表现。目前来看，一线的基层领导都是工作2-5年的程序员，5年都算很难得的了，但是一个2年的程序员能有多少经验来领导一个“自组织”团队的运作？再者都是由刚刚毕业的，或者工作1年左右的人来组成团队，这个团队有多成熟？至少现在来看，对scrum试点是持悲观态度的人居多。

每种方法执行的过程中都会有问题，能不能找到方式弥补您提到的种种问题又能保留敏捷开发带来的好处呢

不错

其实不明白为什么 AssemblyInfo.cs 中的GUID是什么作用， [b]注意上面的Guid，如果程序集内部的类未标注Guid，COM注册的Guid是会新生成的，此处的Guid没有作用[/b] 这句话从那里来？

这个写的好 正需要

[quote]rgqancy： 理论和实际有差别。 数学和工程学有差别。 4.高估了工程师的成熟度 我给出个馊主意：招人的时候，看他有没有耐心完成一个三阶魔方的复原。这个也许能考察心志吧。我瞎说的，呵呵。[/quote] 不知道魔方方式的人，想完成三阶魔方那是需要相当长的时间。

@辰 Agree with you totally.

最近正好在用这个

@大卫张 出现问题当然会寻找解决手段，至于怎么解决的，并不是这篇文章的主题，PM还需根据项目情况、成员情况细心应对。 本文的主题是实施Scrum过程，这个项目管理框架自身的特点所暴露的一些问题，比如说任务领用、演进式架构设计以及“自组织”。

理论和实际有差别。 数学和工程学有差别。 4.高估了工程师的成熟度 我给出个馊主意：招人的时候，看他有没有耐心完成一个三阶魔方的复原。这个也许能考察心志吧。我瞎说的，呵呵。

管理精髓是管人，就是sensitive。 制度没有任何意义。

一直觉得SCRUM中每一个人都必须是Sr，交付能力强才行，否则如同形式主义。

说得非常好！

听楼主说放弃？ 我们也在用这个东西，过程也是没想象的好，不过有部分用的还是很不错。 以前用CMMI，觉得文档太多太多，现在用Scrum觉得是有些承担不起来。不过两者结合使用，感觉还是挺不错的。 我觉得Scrum过程中，必须有较强技术的人员领头，有善于沟通交流的人组织，基本来就可以了。

收藏了，作为以后教学的案例。 为表示感谢，帮助LZ找一下问题： 你没有提到size Meeting ，这个size meeting 对于SCRUM team 是很重要的。对于组员熟悉需求和明晰除自己外别人的任务是必要的，如果你只是把自己定好point的任务让人员去随机的领取，那风险太大了。另外你们的QA ,DEv 比是多少，低于1：1 就不要谈SCRUM了。 还有velocity 是谁规定的，这个应该是团队自己实践出来的，哪怕都是刚毕业的senior，大不了就是velocity 低点，但是scrum还是可以运转的。

[quote]kkun： @Simon Pan OK,我感觉它偏方法论,也确实有借鉴管理学的一些东西 风险控制等,我且把它当成管理学了, 开发框架也可以[/quote] 或许是可以“当成”，毕竟PMI和CMMI这两年都开始大量关注敏捷。而且今年下半年，PMI就有敏捷相关的认证了。

任何洋概念到了国内这里都会水土不服，SCRUM 也不例外啊，在国内，强调的是严格的层级，有层级就会有矛盾，不会有扁平化的合作概念。

貌似我SCRUM和敏捷混淆了,呵呵

@Simon Pan OK,我感觉它偏方法论,也确实有借鉴管理学的一些东西 风险控制等,我且把它当成管理学了, 开发框架也可以

[quote]kkun：我们之前使用SCRUM超成功的说,头一次感觉到管理学的强大![/quote] Scrum不是管理学，只是开发框架而已。

Scrum的核心思想就是充分发挥每个成员的作用和能力，但这不意味着就不能存在一个管理者、领导者和协调者。如果是这样，那你要面临下岗了，因为不需要管理者了。

[quote]Justina Chen： 程序员把自己代码写好就行了，我看你们博客那水平也不咋地，JJWW没什么意思。 就此打住，再发此类评论，删除不商量。[/quote] 这个。。。。黯然飘过。。

Scrum是什么？

最近也遇见这类问题，公司高估工程师的成熟度，搞得项目很纠结！

本文还是比较客观的讲出了实施Scrum中碰到的问题。但是在描述中的各个步骤还是偏向于Scrum方法的实施，相对比较缺乏出现问题时的应对手段。而我个人认为，Scrum实施的关键在于价值观的实施，不过对大多数人来说虚幻了一点。

@Justina Chen 但是有一点，使用XP是不是会同样具有你所述的问题，如果还遇到类似的问题，是不是再换一套方法。

@Justina Chen XP也挺好。还是那句话——持续改进。至于使用什么敏捷方法，无所谓。有的人实施SCRUM，但死活不承认使用SCRUM。目的就是降低外界对名字和形式的关注，要注重的是敏捷的内涵。

[quote]Justina Chen： @徐少侠 你的回复更像是自己的歪曲，仔细看看，我文章要表现的哪一个是你回复表达的观点？[/quote] 额 没看仔细楼主的文章，冒失了。 呵呵 抱歉先。

程序员把自己代码写好就行了，我看你们博客那水平也不咋地，JJWW没什么意思。 就此打住，再发此类评论，删除不商量。

@Gopher 所谓交付“良莠不齐”，是指全方位的评估，比如交付物在系统中有机的结合度，代码可读性是否良好，在变更或重构来临时预期投入的工作量。而公司作为项目的客户方，标准就又不同，这点可以理解为项目目标和软件系统目标，短期目标和长期目标的不同。

[quote]Tony Zhou：是，北大青鸟毕业的估计用这个方法不好使[/quote] 现在青鸟出来的比较受歧视

[quote]Tony Zhou： [quote]Justina Chen： @Tony Zhou 只有自卑的人才会歧视别人。北大青鸟毕业的一样能做好开发，成为好的人才。[/quote] Oops, good luck[/quote] 不是鄙视，北大青鸟出来的，成为好的开发的概率非常非常的低。小学毕业，也有成为好开发的例子，照你这么说小学毕业也能做好开发了

#17楼[楼主]2011-05-17 13:14 | Justina Chen @Gopher 选人、做项目，是以开发、产出重要，还是以实现敏捷为重要？ 我们的项目目前取得的成绩是，每次都达成目标（以约定发布日期）经历一次大的重构，七八次需求变更，整整9个月内，每人加班时间在两天以内。在以公司目标为衡量标准的前提下，我们是成功的，并且项目已到尾声，所以我才发出了这个总结的贴子。 ------------------------------------------------------ 首先，对于你帖子前面描述的情况。我对该项目组能够在你描述的情况下（敏捷模式完全失控，甚至在第3点你也承认交付良莠不齐。）能够“成功完成”表示十分怀疑。我只能说你颠覆了客观规律.awesome! 对于项目来说，当然是完成项目既定目标重要。我不在乎是不是pure agile。我们这里是CMMI3+Scrum。因为过程同样重要。我很难想象，这样一个项目会对公司产生什么积极的“组织过程资产”或者是"Lessons Learned Database"。 敏捷还是非敏捷不重要，重要的是，现在这个很热。有成功者也有失败者。大家不应该教条式的专注于“敏捷宣言”或者“CMMI最佳实践”。根据不同的关注点来持续不断的改进组织过程，提高交付能力和交付水平，才是最终的目标。大家共勉！ 另外，XP很好，但XP实施难度较大。祝成功！

[b]没有对团队中每个“人”（不管他是从青鸟毕业还是从哈佛毕业）的尊重，敏捷不可能成功。[/b]

@wanghui 我们已转入XP，没必要官方，我认为，对开发人员，所谓“开发方法”的变更，没有必要大势宣扬，简单宣布接下来我们怎么怎么做，询问有无问题，大家认为没有问题，再在过程中参与指导，上路即可。

@Gopher 选人、做项目，是以开发、产出重要，还是以实现敏捷为重要？ 我们的项目目前取得的成绩是，每次都达成目标（以约定发布日期）经历一次大的重构，七八次需求变更，整整9个月内，每人加班时间在两天以内。在以公司目标为衡量标准的前提下，我们是成功的，并且项目已到尾声，所以我才发出了这个总结的贴子。

我们之前使用SCRUM超成功的说,头一次感觉到管理学的强大!

路漫漫其修远兮，在国内的浮躁环境中，恐怕没有几个团队可以坚持下来！！！

[quote]Mainz： 借鉴，学习！ 公司人员流动率高的团队适合用Scrum吗？[/quote] 严重的不适合！！

敏捷包含很多内容，但我透过所有内容就看到四个字——持续改进。实施SCRUM中有很多问题，不要紧。既然找到的很多问题，这很好呀！总比不知道倒在哪里要好。实施SCRUM的真正失败，是在尝试中的发现了问题，但是没有持续改进的勇气和手段。如果楼主是主导转型的人，并且还没有官方地宣布停止实施SCRUM，我觉得还有机会。看得出楼主所在企业像是自上而下式的转型，缺少了自下而上的力量，转型成功应该两者叠加的结果。我的一点建议，可以搞企业内训，改进社区等，目的是让所有的直接参与者（PO,SM, Team)都能明白为什么要搞SCRUM，它能给我带来什么好处。 什么时候可以宣布停止SCRUM？仅当你确认不使用SCRUM后的生产力肯定大于使用SCRUM的时候。 希望楼主不要放弃。

[quote]Gopher： @Mainz 不适合，最起码，你的团队velocity无法度量。再有，你能想象，一个团队里面，隔三差五的来个陌生人，如何保证沟通？这种情况，CMMI也无法解决。因为再详细的文档。同样不是万能[/quote] 顶

[quote]Justina Chen： @Tony Zhou 只有自卑的人才会歧视别人。北大青鸟毕业的一样能做好开发，成为好的人才。[/quote] Oops, good luck

PO 用户故事写的不好，团队成员机能熟练度至少都要是熟练等级。

@Mainz 不适合，最起码，你的团队velocity无法度量。再有，你能想象，一个团队里面，隔三差五的来个陌生人，如何保证沟通？这种情况，CMMI也无法解决。因为再详细的文档。同样不是万能

1.成员放弃了Scrum所“赋予”的“权利” 比如领用任务、评估工作量、自组织协作、决策等。在第一次Scrum计划会议上排出任务让大家领用时，成员的态度可以用“反感”来形容。在经历四个Sprint后成员依然坚持认为，应为PM完成这些工作，故放弃。 [b]你缺乏对程序员足够的培训，为什么要切分任务、评估工作量，对比以前，我们需要解决什么问题？ 为什么人家会反感，估计是开会前缺乏足够的准备，PO自己都解释不清楚需求，慢慢的会议发展为头脑风暴。并且会议主持人对这种明显超出讨论范围的乱象并没有及时制止。 所以，结论是 1、你自己都没搞清楚为什么搞敏捷。 2、因为你没有搞清楚，所以你缺乏实施敏捷的路线图。 3、因为没有路线图，所以在人员选择上，你找了一群没有“敏捷人格”的人来做敏捷。[/b] 2.团队成员能力参差不齐 我很主观地认为，现在国内的开发团队都会是一部分高级工程师搭配一部分初、中级工程师，这种搭配本身就决定了领用任务时的混乱，尤其是团队中一部分成员极度渴望去做那些自己没有经验的任务。结果造成一部分人一直搞不清楚自己在团队中的定位，一直处于“费力不讨好”的挫折中。高级工程师对另一些成员的效率、成果也颇有微词，对团队分工非常不满。 [b]根据团队的velocity，我们通常会对需求的粒度进行要求（这点也是我们敏捷QA的度量目标）。在确定需求粒度之后，任务切分肯定是全体团队成员一起进行的。如果有Issue就记录并落实Issue责任人同时解决Issue也形成任务并需要评估时间。当然，长官意志必不可少。 摆明了这人承担不起这项工作（解决Issue都有问题）你也让他选？找死！ 摆明了这人面临的任务有多个待解决的Issue（导致团队工作延后）你也敢让他做，找死！ 能力参差不齐不是关键，关键的是，scrum master缺乏控场技巧和领导力。这样的水平，当PM都成问题。[/b] 3.没有清晰的设计阶段是造成上面第2个问题的另一个因素 众所周知，敏捷倡导演进式架构，其本质是，在目标不确定性极大的情况下，通过一次又一次短周期的反馈修正来不断接近目标，固在敏捷中，每项任务、剩余工时、成本燃尽，控制得如此之细，CMMI根本扛不起这样恐怖的基线变化次数。取消清晰的设计阶段，以及采用大量并行的测试，可谓敏捷的一种取舍，赢取更短的发布周期。也正因为如此，在任务分解时，无法清晰地定义设计任务，而将其混杂在功能化的任务中，事实说明，这里有大量的重复工作并且交付良莠不齐。 [b]首先，CMMI的基线并非通常意义上的敏捷的“广泛认可”或“增量输出”。所以CMMI在配置管理和质量管理的基线标准不会定义得如此变态。 再次，“清晰”是相对的，在我们的公司里面，一个成熟的敏捷团队，不用将任务粒度划分得过细。而一个才成立的团队，任务粒度几乎就是流程图级别的。当然，无论资深还是新手团队，Scrum Master必须是资深的。 最后，你的团队无法“清晰”的定义任务，要么是PO没有做到位，要么是成员不了解需求。对于团队中的资深的“个性”程序员，那么，尊重他们个性好了。也就是我说的，长官意志。[/b] 4.高估了工程师的成熟度 敏捷对工程师的心智有过高的要求。为什么说是过高？其实，在公司里担任高层管理人员的，恐怕都不具备成熟的心智，何况处于一线年轻又尚轻的程序员？现在的程序员，从学校或从培训班子里出来，人际圈子小，知识面狭窄，遇事仅能从自身考虑，常常因生活中一些事情影响情绪和工作，遇到难题就放弃，全力投入到项目开发中来的，并不多见。所以，在项目和开发过程中，监控、管理，催促、激励甚至批评，是必须的！ [b]在我的实践经验中，这种人最好培养。你们不会是因为成本考虑找的实习生吧。如果团队都是高手，我想这种团队，无论CMMI还是敏捷都不重要了。[/b] 5.Scrum缺乏领导者 Scrum把团队想象得太完美了，如果有完美的团队，开发方法根本就不重要。工作、项目在进行的过程中，必须会遇到困难、遇到卡壳、团队发生冲突和争吵，这时候，必须有一个人挺身而出，作出决定，解决问题，为大家指明方向，平息争端，警告不利分子，这个人只能是领导人物，能力、权力和职位比团队成员高的人。扁平式组织，想象得太完美了，团队里各种性格的人都有，不服你不爽你的也总有人在，吵个没完没了，各做一套，家常便饭。 [b]会议主持人能力相当重要，并不是每个人都可以做Scrum Master的。争论，是我最喜欢看到的情况。有分歧才有争论，有争论才有更详细的任务目标。关键是，你真的尝试过去引导争论并使之切题？[/b] 敏捷，在我看来是CMMI的高度抽象。CMMI里面有的，敏捷里面都有，只是表现形式不同。完全自组织，在一般的公司不可能做到。所以我更倾向于有限的制度，完整的流程，明确的实施路线图。

@Tony Zhou 只有自卑的人才会歧视别人。北大青鸟毕业的一样能做好开发，成为好的人才。

是，北大青鸟毕业的估计用这个方法不好使

我认同楼主的观点，楼主表达的是，SCRUM的成功实施的要素，没说SCRUM本身是失败的，也不存在对SCRUM的否定

恩从博主的结果看是一个失败，是Scrum的失败？ 很明显Scrum本身并不失败，那是什么，只有是失败的团队与管理了！ 的确如ls所说博主有算是再现在总结，当时进行中的时候肯定没有认真总结吸取教训贯彻实践，做程序的哪回一帆风顺，都是一路坎坷过来的！ 不过一点反感Scrum的团队使用Scrum一定会失败！ 就像人逼着他做厌恶的事情他能做好吗! 有两种反感一种是完全了解了Scrum的， 还有一种就是完全不知道Scrum的，这种就是管理思想工作没统一了！

@徐少侠 你的回复更像是自己的歪曲，仔细看看，我文章要表现的哪一个是你回复表达的观点？