966,690 四月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
为什么有些公司敏捷实施不成功？
为什么有些公司敏捷实施不成功？
日. 估计阅读时间:
不到一分钟
相关厂商内容
相关赞助商
ArchSummit深圳-8日，深圳&华侨城洲际酒店，
在X公司，敏捷方法能成功；在Y公司，敏捷方法则将失败。
在固定报价软件开发中，软件开发工作是要在某个时间点结束的。为了获取项目经费，需要你预先定义范围，进行估算，分配资源，开发，测试，实施，然后将其交给支持部门。这是Y公司所采用的方法。
而在时间和材料（time and materials）决定经费的情况下，公司做出决定，有必要组建软件开发团队，因为未来会有很多需要开发得很好的项目。他们会在预算期内（1年，2年） 估算可以承受的开发团队大小，并据此分配资源，然后决定项目范围和安排进度。这是X公司所采用的方法。
发现区别了吗？在X公司，总是有软件在被开发。这一活动没有结束点，团队经费据此划拨。所以，在基于时间盒的迭代中，把任务放入backlog、按优先级排序、进行估算和评审才有意义的。
而在Y公司中，他们通常只为某个预算期的一些子集（例如3个月）的工作划拨经费。在此之后，就没有更多的钱或者公司不愿再拨出额外款项了。他们不希望维持 一个长期的开发团队，因为他们负担不起，再说也不会有足够的开发工作使团队一直有事可做。因此，就必须通过严格控制和强有力的项目管理来确保3个月后项目能交付。
从财务角度来看，敏捷是一种奢侈品。它假定你始终有一个软件开发团队，并且总有开发工作。它假定你的团队每年都能得到经费支持，并且你作为管理者，不必担 心需要按单个项目来划拨经费。作为敏捷管理者，你主要关注于日程安排、范围和团队能力。预算是每年或每两年才需要考虑的事情。你根据公司所面临的经济现状 向上或向下调整预算。成功的标准，则主要集中在一段时间内所交付的功能。
在Y公司，你可能被分配了5万美元，要在3个月内完成项目。制定预算和控制费用至关重要，它们决定项目成功与否。管理者会在资本周期的不同时段得到按照项 目划拨的经费。你可能按时交付了所有功能，但如果超过了预算，也不会被视为一个成功的项目。作为这家公司的一名经理，你需要关注项目管理三角形的方方面面。你的团队可能是临时性的，并由合同工组成。在这种情况下实施敏捷是个错误...甚至可以说是个低级错误。为什么呢？
关键在于估算。
在敏捷软件团队中，只有当你开始工作的时候，你才对其进行估算。就Scrum来说，你仅仅估算下次迭代的工作。因此你怎么能知道产品需要多长时间完成呢？ 你不可能知道。而且，你确实不在乎这点。因为你将持续在每次迭代中交付功能。只要产品经理和QA说你有个足够好的产品，它就可以作为正式版本发布。你也许 有一个猜测值，但是直到团队对它进行估算&.你真不知道它还需要多长时间。
在固定报价项目中&.你的估算需要在最开始就进行。公司会问你需要多少经费来构建此应用程序，因为他们不想无休止地资助它。他们希望它能结束&.最好是早 一点而不是迟一点。资金是有限的，而且你的项目，虽然可能是必需的，但不会被看作对公司的未来至关重要。它的投资回报率甚至可能为负数。如果你回复公司的 领导者说；&我不知道此产品需要多长时间完成...请为团队提供一年的经费，然后我们看看每次迭代后会它会是什么样子&，那你可就犯错了，其结果很可能是你被解雇了。
第二种情景中，如果我在取得经费并雇用团队成员后告诉他们：&我们将使用Scrum&。他们将会估算下次迭代的工作。他们会假定他们的估算被认真对待并且你会据此给予他们时间去完成工作，而不管他们的估算是否适合你初始的项目经费。这很公平的，只是不幸的是，你作为管理者将处于难受的位置，因为你需要提交 预算/日程变动，并且/或者要在初始估算被证明为不准确时削减项目范围。最终你无法管理项目还因此得出结论.......&敏捷这事儿行不通&。
这里的错误在于假定公司的领导者了解并且从上至下地致力于实施Scrum和敏捷原则。从他们要求你估算完成项目所需的经费这一细节，可以察觉出实情与假定大有出入。如果他们问的是，&在后面三年需要多少经费来维持一个软件开发团队？&那么我们就会明智地从敏捷观点出发着手处理了。
因此，什么才是公司实施敏捷的真正难题？这可以概括成以下几点：
敏捷假定公司需要长期的软件开发工作而不是短期的项目。
敏捷经常被公司管理层假定为是一种对预算没有影响的开发流程。但事实并非如此。
开发团队假定领导者明白实施敏捷对于预算层面意味着什么。
我们不应低估这些问题的复杂性。开发人员和团队往往对预算毫无概念，所以他们不知道从财务角度是怎么解读敏捷开发的。对于这一点，在网络上很多关于敏捷的 文章中体现得很明显。同样，管理人员往往对开发和特定的敏捷实践一无所知。实施敏捷需要通过培训来减少这两个世界之间的冲突和误解。
所以，试图在一个固定报价项目中实施敏捷实践会有什么后果呢？本质上，这其实就是给瀑布项目批了层敏捷的&羊皮&。
敏捷团队经常使用故事点来衡量当前工作的复杂性。每次迭代中完成的点数确定了他们的速度（每次迭代点数），同时基于速度可以向管理层提供一个估算，用于表明某个给定的迭代能完成多少工作。
如果你来自像Y那样的从事固定报价项目的公司，你的第一个问题就是：&这怎样和时间联系起来？又如何计划成本和投资回报率？&事实是：不能。并且也不打算能。重申一下，敏捷学家假定你正在为一个软件开发团队而不是一个软件开发项目提供经费。
在X公司，你甚至可以用汉堡包或香烟作为参照，来估算每个迭代的工作。这没关系。你总会在某个时间点完成这个产品（根据要求增加/减少功能）。唯一真正的问题是：何时我们能称之为完成然后作为产品发布？团队经费并不取决于工作量的估算。
而在Y公司，项目经费直接与工作量的估算相关。至关重要的是，我们将其与时间紧密联系起来。因为我们的成本动因往往是以小时来计算的。故事点在这里毫无意义。
ScrumMaster vs 项目经理
&敏捷不需要项目经理。&你曾听到过这种说法吗？这种不经意的吓唬会使传统型项目经理提心吊胆。然而，这一说法是对的。如果你假定团队每年都能得到 经费，并且经费不受项目工作量影响，那么组织和管理开发工作就的重点将是技术指导、任务和风险管理。这种情况下根本不需要时间表和预算，ScrumMaster就足够了，他能更好地完成任务。
不过，如果你在像Y这样非敏捷的公司工作，那么传统的项目管理实践不仅有效，而且对于控制预算和工期偏差来说是必要的。这种情况下，就需要开发团队的领导去尽量节约公司的每一份宝贵资源，并且需要具备一个准CEO的技能。
在有经费支持的开发团队中，项目经理的角色的确被改变了。而固定报价项目开发团队则没有。
每日站立会议
因为种种原因，敏捷使用每日站立会议。这其中包括：激励团队成员、缓解风险、汇报工作、问责、建设团队等。即使在固定报价瀑布式的项目中，这也是个好主 意，没有理由不继续使用这一实践。但从事固定报价项目的团队必须意识到：你并不是在真正地实施敏捷开发，最后期限正在悄悄地逐步逼近。你还可能需要权衡时 间需要。每日站立会议应该很短。但当你只有三个月的经费时，即使每天15分钟也得累计并考虑在总开销之内。
有充分经费的敏捷软件团队会渐进式地回答何时能完成产品这个问题。在每次迭代（例如30天）结束后，他们都会进行功能评审，并评估产品发布的准备情况。同 样，这也是个能被用于固定报价项目的好主意，但需要去引导业务负责人理解：迭代评审是一种缓解风险和问责的方法，而不是对已完成产品的演示。
迭代规划的确假定你是在一个有经费支持的团队中使用敏捷。它需要确保你的成本已知，预算周期固定，并且团队做出的任何估算都不会严重破坏你的预算。在固定报价项目中使用迭代规划基本上肯定会导致混乱、预算差异、和/或功能丢失。
燃尽图展示了一个特定迭代中完成功能的进度。它们是对一段时间内团队业绩的衡量，但并不能用于阐释离项目完成还有多远。如果我们将所有燃尽图都总结在一 起.....它们可能能够说明这一点。但鉴于燃尽图通常被严格地用于衡量项目开发工作量，所以即使这点也并不是总能被做到。
在固定报价项目中，问题通常不是团队在一个时间段内完成多少功能，这真的不重要，重要的是在经费允许的时间段内所有的功能都必须完成。
因此，在固定报价项目中使用燃尽图和迭代会向团队和客户传递错误信号。
首先，我建议不要试图在固定报价或基于项目划拨经费的情况下尝试实施敏捷。取而代之，作为经理，你应该评估你的公司是否能够支持敏捷实践以及一支人员配备 齐全的开发团队。如果能，那么你应该实施敏捷...它能运作良好；如果不能....那么你最好明智地坚持使用传统项目管理实践。
如果你确定你的公司有足够资源和工作负荷来支持软件开发工作，但没有使用敏捷，那么问题就涉及到如何使管理层相信敏捷对于开发工作是有意义的。戴顶变革管理和销售的帽子....你会需要它们的。
其次，项目经理和ScrumMaster不是一成不变的角色和头衔。在一家公司，项目经理/ScrumMaster可能要负责预算；在另一家，他们可能不负责。有时候，在一个传统组织结构的公司 中，他们可能有直接下属；而在另一家，组织结构可能更偏向于矩阵式，项目经理/ScrumMaster没有直接下属。我提到这些差异，是因为有关敏捷的文 章，就像所有的著作，都是从作者的观点出发的来阐述。往往一些在某些情况下能起作用的过程或技术会被拔高说成万能的过程或者技术.......然而实际情 况是该组织和角色都能很好地适应这个过程和技术。如果角色和组织发生了变化，它可能就不会再起作用了。在敏捷vs瀑布开发的博客圈中，这种背景信息经常缺失。
最后，有关敏捷的争论往往被比喻成一种哲学的战争。但是，从我的经验和角度来看，这种混乱很大程度上是误解的产物。很多时候，一个技术经理并未全面仔细考 虑实施敏捷的商业内涵。同样，业务人员则常将敏捷误解为与他们如何提供经费无关的&一些开发工作&。在我的职业生涯中，很幸运，这两类问题我都遇到过，并 且找到了解决之道。通过这些，我也才深刻地理解了有关预算的假定：这个导致敏捷实施失败却常常不被识别出来的原因。
查看英文原文：。
译者简介：刘洋，上海交通大学计算机系硕士，目前在某外企任职项目经理，拥有多年Web开发及团队管理经验，致力于敏捷思想和实践在软件服务行业中的应用。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家加入到中与我们的编辑和其他读者朋友交流。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
太武断了吧
为什么有些公司敏捷实施不成功？
huang zheng
视角很独特
Andrew Zeng
固定报价的项目可以用故事点来和时间联系起来
Keqiang Zhang
有些可以借鉴，但是不敢苟同
Wang nethibernate
适用才是硬道理啊
Chou Jacky
个人觉得X公司类型的团队相对而言更适合点
weng crystal
应该如何去理解敏捷？
Chan Jackei
经费和投资回报对公司永远是第一位的。
Zhang Lovrane
划分太武断
Zhang Double
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。软件测试（3）
团队管理（4）
敏捷实践（10）
导语：日前，酷壳站长陈皓编译的一篇《为什么Scrum不行？》再次引发了敏捷社区的一阵骚动。原文出自《Why Scrum will never work》，在那篇文章中，原作者分析了Scrum不适用的几种情况。当然，作者并没有对Scrum全盘否认，而是做了负面思考——思考事物的负面因素。因为这样才能更全面的分析一项事物的优缺点，并知道：它会起作用吗？缺点是什么？它有什么问题？为什么不能做。
作为敏捷方法领域最火的概念之一，批判Scrum是需要勇气的。在本文开篇处，陈皓也进行了“免责说明”，“这些东西相当的现实。希望各种Scrum的实践者们认识到这些问题，从而可以让你们明白软件开发中的人的重要性”。
以下是原文中提到的9个Scrum不行的理由。除此之外，陈皓在里面加入了自己的分析（感谢陈皓提供的精彩内容）。
Reason 1: Scrum的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且政治和竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗？
Reason 2: Scrum认为只要给员工足够多的自由员工就能做得最好。这该死的理论是基于什么玩意？不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，还可能基本甚至达不到其相应的报酬，大多数人都在混日子。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，你就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，看闲书，反正不干正事。直到你催了，他们才动一动。
Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。
Reason 4:Scrum只不过是一个流程。这世上有太多的流程，尤其是那那些执行CMMI的公司。几乎所有玩CMMI流程的公司，你都能看到的是员工都是那一副副难看的脸。所以，Scrum的流程同样会这样。因为这些都不是开发团队自发出来的，而是上面管你喜欢不喜欢按给你的。Scrum根本不可能增进你的软件质量和技术，只能是优秀的人才才可能！使用Scrum的公司都是些吝啬&#39740;，他们不愿花大钱招优秀的人，他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率，Scrum成了push程序员最有用的工具。
Reason 5:Scrum delivers ‘business value’。不是这样的，实际上，Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队，那些人谁TMD愿意和苦&#36924;的技术人员加班啊。 那些人喜欢和我们的用户吃吃喝喝，花天酒地的，根本不会和你们那些奇怪的东西（如：backlog）或是那堆ugly的内向古怪的技术人员打交道，更别说什么技术了。所以，你的团队就像一个客服团队或救火队一样疲于奔命。
Reason 6: 一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好，什么需要改进，并定义行动方案。你真的以为员工想进步吗？让他们不得不去想想自己和团队怎么进步，然后他们还不得不去执行行动方案。别天真了，人的天性是不喜欢改变的，人的天性是习惯于一些按部就搬的事，也许那样做令人讨厌，但是人家还是能干点东西出来。如果你&#36924;着人家改变，你就是在压迫人家，人家自然会反抗。
Reason 7:Product Owner专注于 ‘what’ 和 ‘why’ 的问题，开发团队决定 ‘how’。很不错的分工，于是可以造就一个即高速有重质量的团队。然而，这根本不行。你的Product Owner马上就想要这个功能，他才不管你的软件开发的技术难题，人家只要快，要你meet deadline，要你给我们重要的客户做出承诺。另外，你千万不要以为你们可以轰走这个初级的product owner，因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰，或者只是外包公司，你觉得可能吗？你觉得建立信任可能吗？
Reason 8: 软件质量和生产率成正比。也就是说，质量越高，生产率越高。如果质量不高，你开发效率就会低下，但是谁管呢？我们朝九晚五的上班，质量好了也是做8小时，质量差了也是做8小时，无所为嘛。另外，我们的project manager (或者是Scrum master!) 总是会批评我们没有按计划完成。所以，这根本不可能。
Reason 9: “是的，如果我们只做需要的功能，那么我们就会最低的成本，对吗？”，为什么这世上总是会有这些幼稚的人？这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价&#26684;（可能还会有回扣），为了打单子，销售什么都干得出来，让你去做项目是因为你是廉价劳动力，而且，他们会不断地加需求，因为软件合同谈好的价&#26684;时候，连需求都没有，你去做了才有，还是模糊和不确定或根本就是错的，然后需求是越来越多，越改越多。等你精疲力尽的时候，你才意识到，销售早就把你卖了。
有人看到这篇文章后也分享了团队实践Scrum后的心得，他觉得在他的团队里不适用Scrum有几个原因：
1.大家对技术不熟悉，因为目前主要的工作量在前端。大家以前都是做java后台的，对js不熟悉，把js当作java来面向对象。而且没有一个成熟的控件库使用。
2.没有在项目开始前做足够的技术调研。本来，应该有个architector来做这些事情。我觉得什么TDD，就是胡扯。没有前期调研，什么都是假设我们能做到，然后就去break down,然后就是估时间，只能是瞎估。估完了，真正implement的时候才发现，一堆东西stand in my way。
3.人的本性就是利己。如果一个team的performance，不和salary挂钩，大家凭什么会齐心协力，deliver更快，更好。目前情况下，scrum只是pm push developers的工具。现在，大家都想到偷懒的方法，就是尽量多估一些时间，或者implement的时候粗一些，反正都是一个个task领的，谁知道bug是谁的code导致的。以前如果一个人responsible for one module,就很容易知道谁的代码质量不高。
4.user story 拆分的不好，容易漏掉很多东西。大家现在都关注task,只想着做完就拉倒，根本不会想着各个task之间的边界和交叉影响。而且，大家现在就习惯看看task就做了，根本不会去看case,所以有些重要的flow全都漏掉了。
5.pm就是scrum master,整个team就是在一个不平等的环境下，scrum只不过是pm试验的工具，能在她的简历上添砖加瓦。我们只不过是小白鼠。
另一种观点认为，Scrum适用于一帮资深程序员组成的team，每个人都是牛人，每个人都有激情干活，这样才work。在国内大家只是干活拿工资，没什么激情，很不适合Scrum。
Scrum就是一把双刃剑，如何用、是否合适还是要看具体的情况。那么，您的团队是否采用过Scrum模式，效果如何呢？
更多精彩评论：
本人也捧一下：中国人更像C语言，而西方则更像是C&#43;&#43;;中国的更多的时候是太极，西方就是拳击。所以只接拿老外的东西到中国生搬硬套，肯定是找死！
scrum只是提供了一种方式，如何去运作团队和管理项目，至于这种流程是否适合这个团队，是因人而异的，可能在西方适用，中国人不适用，所以我觉得还是应该回归敏捷本质，就是找到适合自己团队的运作方式
scrum对团队文化的要求很高的，如果团队整体都缺乏诚信，拒绝改变，拒绝进步，那不仅是scrum，无论采用何种方式开发都是一塌糊涂的。
scrum要求团队稳定，通过一轮又一轮的冲刺与回顾，提高整体的开发人员素质。
如果发现开发中有不认真对待项目的成员，趁早剔除，绝不能带坏整体团队氛围，否则这个团队就算是毁了。
scrum master绝不是什么领导，他和程序员是平级，要擅长理解，沟通与确认开发时间。他不负责开发，但是必须对开发精通。
所有的矛盾，程序员不必直接面对，都是scrum master来负责沟通解决的，所以沟通这样的软技能对scrum master很重要。
scrum 的基石不是简单的相信人，而是有条件的相信被多次项目筛选出来的人。没有技术底蕴的人，别搞scrum，否则保准被忽悠的一塌糊涂。
scrum的角色分为2组，猪组全权负责开发，鸡组部分参与监控项目。如果鸡组的这部分人对技术不了解，就有可能被猪组的这部分忽悠的一塌糊涂。
所谓的技术底蕴，并不单指计算机技术，指的是完成项目所需的技能知识。对于鸡组的成员，对这些不求掌握，但要熟悉。如果鸡组的团队对这些都不熟悉，那么这些环节上的任意一个人都有忽悠鸡组成员的能力。
当你一次一次进行scrum迭代的时候，对成员的工作状况都要有所了解，逐步加压直到发现成员压力过大。但如果你实际上不了解相关的技术，你能分辨出他是装出来的，还是能力不够，还是真的压力过大吗？
有良心的技术人员当然不屑欺骗你，绝大部分的技术人员也都是有良心的。但是很遗憾，这个社会上存在没有良心的人。
大多数实施敏捷的团队，都不是自发的，是“被敏捷”；大多数敏捷的团队都是在人员没有掌握足够的敏捷技能的情况下开始实施的，即是是团队中敏捷的积极倡导者，对敏捷的理解也不完全是正确的...敏捷团队缺少指导，而那些敏捷的咨询公司则完全是在忽悠。公司内的一个部门从外面聘请了一个咨询公司团队帮助实施敏捷项目，咨询师年轻的让团队中的女生都嫉妒羡慕恨，我问他们如何判断一个团队是否在敏捷开发，他们的回答是：“照着我们说的方法做就是敏捷”，这让我想到了当初的CMM。敏捷就是这样被唱衰的，Scrum和其它敏捷方法一样也不例外...
我是07年开始接触SCRUM，08年使用至今，当时是CMMI3实施到一半，团队讨论后停止CMMI的实施，直接转到SCRUM上，实施SCRUM的这几年，使我们团队在软件研发的氛围、成就感、责任心方面都有很大提升，我个人很喜欢演示会上获得客户认可的那种感觉，回顾上分享每一期的小小进步和下期的改进点，产品经理和测试作为一个团队互相支撑，客户经常参与我们的计划会和演示会也更加理解我们。
敏捷模式也需要相适应的企业文化做基础，国内能有这样企业文化的又有几家呢。
孙子兵法：
一曰道，二曰天，三曰地，四曰将，五曰法。道者，令民于上同意，可与之死，可与之生，而不危也...法者，曲制、官道、主用也。
团队一样，气场是前提。群情激奋下，不犯大错都能行。方法论，形式而已，所以只能放在第5位。
个人觉得Scrum告诉我们什么样的团队有气场，是结论，不是条件。（幸福的人都是一样的，不幸的人各有各的不幸）
不好意思。在下语文学得不好，影响交流了。
我的意思是，成功的团队氛围总是好的，内部总是和谐的。一堆崇尚敏捷的程序员在一起做Scrum当然成功几率大很多。
相反，如果在现有的环境下Scrum会引起广泛反感，那么用它做什么呢？一定要试水的话，也只能找一个独立的有局部氛围的小团队来做，这还是出于保护氛围的考虑啊。
幸福就是团队和谐的那种感觉啊。但凡成功的团队都有这种感觉，不管它是不是敏捷的。
根本就没有&本身很好&的东西.任何的模型的运作都是有前提条件的.离开了那些貌&#20284;不起&#30524;的前置条件,而只谈某型本身,那肯定连狗屁都不如.这正的有价&#20540;的东西都隐藏在那些细节当中.如果不不重视细节.必定会败的一塌糊涂.
尤其是结对编程。
团队中通常程序员的水平是参差不齐的，我曾今和一个很差的程序员结对过。结果都是我在写代码，他在旁边发呆，因为他看不懂。
如果我每一句代码都要向他解释，这是一件多么恐怖的事情啊~
但是我仍然不得不结对，因为我希望他能看懂，然后将其他相同的工作丢给他做。当然结果我知道，他做剩下的工作中其中一个所用的时间，我自己写可以把剩下的全部写完。而且他写的程序却有很多的让你哭笑不得的错误。
但是我仍然又不得不这样做，否则我就需要做全部的事情，而他却什么也不需要做。
这是一个悲哀，我至今无法解决。
RUP都没玩好的公司的敏捷无非是给混乱的管理，找个借口。公司真正达到CMMI3水平及以上,估计实施敏捷还有可能成功；像练武一样，没有一招一式的基本功，直接就想无招胜有招，那不是骗人，就是白痴。有人说我们是搞互连网的，都是小项目，特点是短平快，相对于瀑布模式，我们是就是敏捷了，真的要喷饭了
其实问题不是出在方法上面，关键是出在执行方法的人上面，人的意识上不去，执行不力，任何方法都无济于事，瀑布开发流程一定不好吗，这世上有的是用这方法开发的，目前为止软件行业还无法摆脱它的影响。很多打仗的都读过《孙子兵法》，可是为什么有的人带兵还打不过连书都没读过的呢，原因不在《孙子兵法》，而在运用的人。这和我们的软件过程一样，大家天天在改进方法，其实应该改造的是做事的人。
从我们还是小朋友的时候，到长大，在遇到选择哪个职业的问题时，老师，家长，朋友，整个社会的观点都是惊人的一致：
要稳定，要挣钱多，要好找工作，要轻松~~
就是没有一个人告诉你，要想想自己的兴趣是啥。
在这样的大环境影响下，中国能出几个优秀的软件工程师？？
解决不了人的素质问题，就解决不了根本的问题。
用什么都没用，充其量就是糟糕和稍微好一点的区别。
要我说，多花点钱请优秀的人，同时把不合&#26684;的人开掉比什么都强。
另外看完文章最大的感觉就是：tmd做程序员太苦&#36924;了！干活多挣钱少还要担责任，简直就是一群因为情商太低，无法混成领导或做销售的一群！！！
软件研发，人是第一位的。中国企业引入scrum是希望在人不太行的情况下，还能发挥一点效益。为了推scrum，不少公司因此养多了一些不干实事的人，人均效益反而减低了。
其实，根本的原因两点：
（1）在中国，国内的开发环境导致Scrum在某些场景不适合
中国的软件开发工程师非常多，但是有多少人能够真正的将开发作为自己的职业爱好，有多少人能够严&#26684;要求自己每天都在不断进步？每天想到的更多的是“QQ”、“微博”、“下班”、“看电影”、“加薪”等问题。
（2）中国的软件工程师的薪资待遇较低，职业规划问题严重
国外的软件工程师是高薪职业，薪资奖励制度非常好，有的公司的开发工程师也有像销售一样的提成，这样工程师哪还没有激情和动力去做好呢？
另外，国内的工程师在30岁以上基本都要考虑转型，而国外很多大型优秀软件的研发团队，很多都是有经验的老员工，包括技术架构代码实现等做的都非常的好。
scrum也无法解决， 没有给够足够能力的团队被要求在指定时间指定成本完成任务的问题，因为scrum不能逆天。如果给我一票谷歌的人，我去睡上一&#31036;拜我相信他们也能做出很多有意思的东西。但是事实上，多数PM可能经常需要能带着各种心态和能力的人去挑战各种难题。
有保留的赞同部分观点. 我不知道scrum的核心思想是不是对人的信任, 如果是的话, 那么我敢说大部分scrum team确实只是学了一点表面, 也就是实施scrum的那一套process. 不过及时这点皮毛, 其实还是对项目有正面收益的: 1) process在需求风险控制, 进度控制上确实是有效的(当然也可以理解为pm push developer的有效工具) 2) 别人问你用什么模式开发, 你告诉他是scrum模式, 倍儿有面子. 然后你可以阐述一堆书上描述的虽然没实践过的理论, 倍儿有技术含量.
做敏捷本质上是对人的信任,做CMMI本质上是对法律的信任,做国内的项目本质上是对权力的信任.
我们就在用Scrum，当然理论归理论，实践起来要灵活变通。文中说的问题确实是问题，但是我们需要看到，每天组织大家一起聊一会天，效果确实不错。TDD再怎么不行，至少可以帮我发现很多很愚蠢的错误，及时修改，另外可以迫使我们团队去检查自己的代码，尽早地发现并解决问题。现在看来效果不错呀。
Scrum只是提供了一个指导原则，并没有说一定要怎么样怎么样，根据实际情况灵活变通才是一道。
文章说得太好了，深有体会，scrum中的自由、分享、进步、激情——对成员的素质提出非常高的要求。
好的团队可遇不可求
实施了scrum走入正轨了，成长性太可怕了。
作者只从他有限的了解来做了评论。如果题目改为《在XX公司Scrum不行》，《在XX群体Scrum不行》，又或者《在XX国家Scrum不行》那就更确切了。有一定深度的东西不是靠模仿来的，需要积累，而Scrum对文化的积累要求很高。
高水准的项目源于高素质的团队
技术，士气，热情，方法，在这些之后才能进行成功的项目管理
昨天还发现一个问题，项目中技术核心经验越丰富
对项目的估算精度就越高，项目在整个过程中就越接近成功点
------------------------------------------------------------------------------------
理想的项目状态
前景广阔的创意，充裕的资源，严谨的立项，强大的核心技术，成熟的项目管理方法
如果用数学划分
不知道各位的项目，能拿到多分呢？
世上本来就没有银弹，所以，也不指望Scrum能合适所有的项目。 3年前，我也带领一个团队做了一个产品的两个版本，用了Scrum。但是，团队里的人都十分有经验，并且，之前已经在这个产品开发上有多年的经验，所以最终我们还是基本上按照Scrum的思想去，切分Sprint， 用点去做Estimation，用工具生成Burn Down Chart, 早上有Stand Up Meeting。 当然，我们做很很多的定制，比如一个Sprint的周期，改成了5周，其中第一周是对前面的总结和下个Sprint的计划。 ...
总体来讲，还是不错的，特别是对有经验的团队做熟悉的项目。
现在，我们做项目即不是Scrum，又不是传统的waterfall，偏向迭代开发。
把软件做好的前提条件是团队里每个成员都要发自内心的想做、想做好。而这往往不是项目层面所能解决的问题。scrum只是个方法，解决不了所有管理问题，也解决不了之前提到的那个根本问题。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：13617次
排名：千里之外
转载：10篇
(1)(1)(2)(3)(2)(2)(1)(1)(5)