FreeOZ论坛

标题: 大家有人在用SCRUM吗？（技术讨论，长贴慎入） [打印本页]

作者: 空山鸟语 时间: 3-6-2011 12:56
标题: 大家有人在用SCRUM吗？（技术讨论，长贴慎入）
SCRUM是个当下非常时髦的jargon。不少公司都声称在推行Scrum，招人也要求有Scrum经验。如果你告诉别人你没用过Scrum，别人看你的眼光都好像城里人看乡下人似地。大家有人实际在用吗，效果如何？

按照Scrum的创始人之一Ken Schwaber估计：“75%尝试Scrum的组织无法获取他们预期的效果”。他给出的解释包括不应该干扰Sprint的执行、领导要对Scrum方法和开发团队充分信任等等。但是从我的角度看，这个Scrum好像也没有那么神奇，如果真的有这么高的失败率，不光是操作上的问题，我认为甚至于从理论上说这都是个不完备的体系。

一般来说一个软件项目的成功，需要首先对业务领域进行建模，然后把业务模型转换成技术方案，之后运用计算机软硬件加以实现，最后以构造的技术成果向业务领域进行反馈。从而完成业务领域和技术领域的交互。传统的瀑布型开发法、演进原型法、UP等等都是虽然形式不太一样，但都有这样一个过程的循环。后来的XP其实也是这样的。只不过它走向一个极端，把分析、设计、开发、反馈这四个过程混在一起，力图把开发过程中的交流最大化。

按照传统的软件工程的观点，一个软件项目的成功很大程度上依赖于对需求的把控。包括对于需求的挖掘、分析，需求范围的控制、需求变更的控制等等，都是项目管理的头等大事。项目成功的另一个重大课题是沟通，也就是怎么在业务领域跟技术领域之间进行有效的理解和反馈。这方面既包括两组不同的人之间的沟通也包括两个完全不同的知识领域间的沟通。从传统的瀑布模型到XP，可以看到项目中对于沟通是越来越重视了。

但是反观Scrum方法，开发团队得到的需求来源就是Back log，然后从中分批取出一些构成一个个的Sprint。这个Back Log怎么来的呢？product owner在制定这个Back Log时需要采用哪些方法呢？技术团队应该参与需求分析吗？对于这些问题Scrum都没有提及。貌似这些都不是Scrum关心的问题。

一般来说，除非是那种超级简单的项目，即使是需求非常明确了也还是需要有个设计的过程的。例如：数据库结构设计、软件的架构设计、UI设计、性能设计、可用性方案设计、测试方案、集成方案、数据迁移方案等等。这些都是需要在拿到需求规格说明书之后先有一个通盘的考虑的。在Scrum方法中，这方面的过程也没有体现。以从Back Log 到Sprint这种方式是不可能完成这么复杂的任务的。

而且Scrum描述的组织结构也很奇怪，product owner 负责产生back log，但是他不负责项目的整体成败；scrum master是项目团队之外的第三人，他的职责是“保护开发团队，使他们不受外界干扰，并负责与manager进行沟通“。这个Scrum master更不会负责项目的成败了。那么谁负责呢？PMP手册中，沟通管理是项目经理的职责中相当重要的一个方面，Scrum倒好，连项目经理的位置都找不到了，更别提项目关系人的沟通管理了。

对于这个问题解释不清其实是个非常致命的硬伤。项目管理不是写出能运行的代码这么简单。项目经理要做进度计划、资源计划、成本计划，要保证项目能使客户满意，还要能保证赚钱。这是工程跟工匠的思维方式的差别。但是如果到了出来Back Log从能评估时间成本，才能确定进度、资源，是不是太晚了？

所以我认为Scrum是个不可取的方法。在传统的软件过程从分析、设计、开发、测试、交付这个比较简化的过程链中间，Scrum它的概念覆盖到的也就是开发和测试两个阶段。他本身并不是针对于整个软件开发过程的方法。反而更像是开发团队内部管理的一个方法。而即便是用于开发团队内部管理，Scrum方法其实也是一个非常封闭保守的方法。说起来是Agile方法，但是实际上是反对沟通，拒绝变化的。所以实际上也不是什么好的方法。

以我比较狭隘的思想揣测，Scrum方法十有八九是一群开发人员连续加班之后一起发牢骚的时候想出来的方法。尽管Scrum声称能解决很多问题，但实际上这是一个不系统、不全面的方案，很可能什么也解决不了。我估计没有多久大家就会忘了它，又开始追逐下一个概念了。

作者: woodheadz 时间: 3-6-2011 13:47
我觉的作者是站在重型开发过程的立场上来评价类似Scrum之类的敏捷过程。
我们现在的软件开发过程有点接近Scrum，用的工具就是按照Scrum的理念建立的www.pivotaltracker.com。 Back Log里面的东西是大家一起完成的。我没有认真研究过Scrum，但在我看来Scrum是敏捷方法中的一种，而敏捷方法的核心价值就是重视直接沟通和重视代码本身，在秉承这种价值观的团队中，Scrum重视节奏感的特点会有比较好的发挥。
我把Scrum当成是敏捷中的一种最佳实践来看，实际使用时，是需要根据团队特点配合其它的最佳实践一同完成的。
当然我有这样的观点也许是因为我对Scrum理论本身了解不深有误会

作者: key 时间: 3-6-2011 14:24

原帖由 空山鸟语 于 3-6-2011 12:56 发表

 登录/注册后可看大图

SCRUM是个当下非常时髦的jargon。不少公司都声称在推行Scrum，招人也要求有Scrum经验。如果你告诉别人你没用过Scrum，别人看你的眼光都好像城里人看乡下人似地。大家有人实际在用吗，效果如何？

按照Scrum的创始人 ...

很有意义的思考。scrum希望通过分散管理和逐步程现式的需求分析与实现来规避风险，
Scrum认为最大的风险是：
1. 全盘考虑问题的风险。因为基本上不存在对项目的全盘的准确的计划和架构。
2. 大管理架构的风险。包括大文档，大计划的风险。scrum推行的是小管理架构，小范围沟通（比如两人或小组沟通），小范围目标管理(sprint)

但是，避免全盘考虑问题本身就是一种风险，避免规范的大文档和大计划，本身也是一种风险。这些风险在空山同学的贴子里被提出来，
很有意义。

我公司现在正在用scrum在做一个大型项目。空山同学提到的问题，在这里都是问题，
如果这些问题得不到很好的解决，后果有点不堪设想。

作者: sliuhao 时间: 3-6-2011 15:02
任何方法都有优点和缺点，SCRUM的推出是最大限度的补充以往开发模型中的缺点，但是它本身并没有过多的对其他方法上优点的集成，SCRUM更多的是工程实践，而非方法。我本身对任何方法没有任何偏见，但是不得不说的是，
1）现在IT正在变成一个“时尚”行业，快速消费行业
2）任何方法变成商业实践，都会一定程度的失真
3）SCRUM是继续CMM/CMMI之后的另外一块猪肉
4）最重要的是人。

作者: mason00 时间: 3-6-2011 15:14
听说过，了解过，没用过，敏捷开发是高手无招胜有招，普通人学不了

作者: combread 时间: 3-6-2011 15:17
偶对方法论狗屁不通。
现在这个公司比我还山寨。

作者: woodheadz 时间: 3-6-2011 15:17

原帖由 key 于 3-6-2011 14:24 发表

 登录/注册后可看大图

很有意义的思考。scrum希望通过分散管理和逐步程现式的需求分析与实现来规避风险，
Scrum认为最大的风险是：
1. 全盘考虑问题的风险。因为基本上不存在对项目的全盘的准确的计划和架构。
2. 大管理架构的风 ...

我觉得敏捷方法也好，相对应的偏重型的方法也好，都有各自的优缺点，有自己适用的场景。
敏捷方法要求小团队，对团队中各个成员要求比较高。“表达力强而优雅的代码”，不是随便抓一个程序员都能写出来的。
我不太赞同LZ文章的观点，原因就是在谈论SCRUM的时候，他并没有摆正自己的立场。
我做一个比喻，就像一个做软件外包管理的老手跑来评价极限编程：“十有八九是一群开发人员连续加班之后一起发牢骚的时候想出来的方法”，站在这个老手的立场和以他的经验看来，的确是这样。但极限编程本来就不适用于外包软件开发这种低沟通效率、高人力投入的场景，你从外包的角度上去评价，有意义没有？

作者: 空山鸟语 时间: 3-6-2011 15:39
谢谢大家的讨论。我没有实际参加过Scrum项目，就是在研究这个方法的时候产生一些疑问，希望通过大家的讨论能帮助澄清一下。

但在我看来Scrum是敏捷方法中的一种，而敏捷方法的核心价值就是重视直接沟通和重视代码本身，在秉承这种价值观的团队中，Scrum重视节奏感的特点会有比较好的发挥。

这其实也正是我批评Scrum方法的一个原因啊，呵呵。

我认为敏捷方法是不错的。其中尤以XP为典型。XP方法因为强调沟通，所以提倡现场客户代表、结对开发；因为强调代码，所以提出了集体代码所有权、TDD、CI这些概念。这些概念都不错，都是让人很受启发的。不过我理解正确的有效沟通应该是范围比较宽的，需求分析人员与开发人员要加强沟通，项目团队跟客户也要加强沟通。XP的现场客户代表在做法其实正是反映了这样的思路。效果是不是最佳暂且不论，这种做法至少是比以前重型开发过程中throw the document over the wall进步太多了。

但是为什么我认为Scrum有问题呢？我觉得Scrum的沟通顶多是在开发团队内部有效。这种沟通甚至都没有办法扩展到需求人员那里，更没有办法到达用户那里。开发团队跟外界交流的界面就是Back log，提供的反馈只有Back log的时间、成本评估、Sprint进度评估，仅此而已。仅从概念上理解，这叫什么沟通质量啊，这哪里是敏捷开发啊，其实跟以前的瀑布模型差不多，只是不要详细的文档了而已。

而且由开发团队来挑选sprint任务好像也不是很合适。因为sprint结束后要给客户看的，哪些用例在关联在一起比较有意义能达到最好的沟通效果，其实也是业务分析人员比较清楚，开发人员不是很清楚的。Scrum中描述的这种做法给人的感觉就像把back log看做一个个离散的任务来处理。打个比方，用户想看到的是一棵树，但是Scrum方法在每次Sprint Review上拿出来的可能就只是一堆粗粗细细的木棍和树叶了。

所以以强调沟通作为敏捷开发方法的一个特征来看，Scrum恰恰是不合格的。这也是我对Scrum心存疑虑的一个原因。

作者: sliuhao 时间: 3-6-2011 15:47
标题: 回复 #8 空山鸟语的帖子
我记得当年kent beck和martin flower说过，啥都不比一个当场能拍板的客户经理重要.....

作者: 空山鸟语 时间: 3-6-2011 15:54

我做一个比喻，就像一个做软件外包管理的老手跑来评价极限编程

楼上误会了。我自己也是个开发人员，对于好的敏捷方法我也是很欣赏的。而且，我是做那种时间紧任务重又没文档的项目开发的，对于比较好的管理项目管理也多少有些体会。我对Scrum的批评是认为它不是一个好的敏捷方法。我不是说敏捷方法有问题。

作者: bigapple2008 时间: 3-6-2011 15:57
1，稳定团队
2，和客户沟通很方便

作者: 空山鸟语 时间: 3-6-2011 16:11
标题: 回复 #9 sliuhao 的帖子
的确是这样的。
其实在SAP这些大型软件实施过程中也是有一套很成熟的方法的。其中也是特别强调跟客户的沟通。但是我们的XP方法才几年时间的历史啊，人家SAP这套方法已经几十年了。我们落后很多啊。

作者: woodheadz 时间: 3-6-2011 16:13

原帖由 空山鸟语 于 3-6-2011 15:39 发表

 登录/注册后可看大图

但是为什么我认为Scrum有问题呢？我觉得Scrum的沟通顶多是在开发团队内部有效。这种沟通甚至都没有办法扩展到需求人员那里，更没有办法到达用户那里。开发团队跟外界交流的界面就是Back log，提供的反馈只有Back log的时间、成本评估、Sprint进度评估，仅此而已。仅从概念上理解，这叫什么沟通质量啊，这哪里是敏捷开发啊，其实跟以前的瀑布模型差不多，只是不要详细的文档了而已。

所以说我觉得你可能是受了其它软件过程方法的影响，用同样的标准和思路去看待SCRUM了。
CMM，RUP之类的方法提供了从项目前期到交付的完整规范，但敏捷方法通常不会这样。
我见过的实用中的敏捷开发，通常都是在一组统一的价值观的指引下，团队根据自身情况选取若干最佳实践组合来作为自己的软件过程。
Scrum涉及到的内容中，能拿来和外界交流的界面好像是只有一个BackLog，可没人限制你用其它的方式和客户进行交流啊。
实际上，我认为BackLog存在的主要意义在于将已知的功能细分成尽量小的工作点，而不是“描述需求”。
至于如何“描述需求”，SCRUM似乎并未提及。
所以当你用其它软件方法中需求文档的角色去考察BackLog的时候，就会觉得是一组离散的内容，简直无法通过它和别人交流。你说的没错，只不过你没注意到Backlog本来就不是用来和别人交流的工具。

作者: 空山鸟语 时间: 3-6-2011 17:24
那么Scrum真正的核心价值是什么呢？

作者: woodheadz 时间: 3-6-2011 20:18

原帖由 空山鸟语 于 3-6-2011 17:24 发表

 登录/注册后可看大图

那么Scrum真正的核心价值是什么呢？

就我对Scrum的认识而言，我觉得Scrum和XP等方法本质上是差不多的。Scrum对团队指导方针显得更加具体一些同时对其它的敏捷开发“最佳实践”非常开放；而XP的发明者们似乎过于强调XP方法中几种“最佳实践”的整体性。所以Scrum比XP要容易实践，适应性也好一些。
我说Scrum对其它的敏捷开发“最佳实践”非常开放，这个话换一个说法就是Scrum没有去包含软件开发中的很多方面。Scrum更像是一个敏捷软件方法的框架，你可以从实践Scrum入手，在过程中放入其他的“最佳实践”，从而定制出适合团队自己的一套XP过程。

敏捷开发方法不是放之四海而皆准的，我自己的经验而言，用于精英小团队效果相当显著；而用于比较大的团队、尤其是其中多数程序员的编码设计水平离XP的理想状态比较远的时候，敏捷方法就很容易变成没有方法，沦为扯淡了。

作者: black_zerg 时间: 3-6-2011 20:31
提示: 作者被禁止或删除, 无法发言 http://programming-motherf ucker.com/
可以看看这个去掉 f 和 ucker 之间的空格，话说这个词居然被屏蔽了？至于么。。。

补充一下就我个人观点，再牛b的方法也不能把垃圾程序员写出好代码，不谈任何方法论，一个强程序员一个人就能把一个模块从沟通到设计到实现到集成全给你搞定。所以这些方法论都是扯淡的都是混饭吃充数的人来糊弄人的，这玩意真管用那才有鬼了。很多吹这些破玩意的自己连写程序都不会，根本就不知道整体框架，根本不懂技术效率，不懂实现，甚至连用户需求都分析不来，跟客户开个十几个会都在那里兜圈子把大家都弄糊涂了。就这水平还是不影响他在那里胡天胡地的吹methodology。悲剧！

[ 本帖最后由 black_zerg 于 3-6-2011 20:43 编辑 ]

作者: 空山鸟语 时间: 3-6-2011 21:01
标题: Bob大叔关于Scrum和敏捷的7条缺陷
在回应Scrum/Agile的固有缺陷这一问题时，Bob大叔写下这“7条”。他说Scrum天生有一些严重的缺陷（他强调说明：很多团队采用Scrum来避免这些问题）：

缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。Bob建议团队“需要从其他诸如XP的方法中借鉴技术实践。这套技术实践可能包括：TDD、持续集成、验收测试、结对编程、重构。”
30天的冲刺周期太长：多数讲师现在建议冲刺周期1-2周，大多数团队采用的是2周。
Scrum教练有时变成了项目经理:有些Scrum教练把Scrum当作微管理和控制的一种形式。“这不是Scrum固有的问题，而是Scrum发展中遇到的问题。或者这要怪‘master’这个单词了。”
对产品Backlog的指导太少：“经过多年实践，我们知道了backlogs有很多分层次的实体，包括史诗、主题、故事等等。我们学会了怎么对它们估计；学会了怎么把高层次的实体拆解成低层次：史诗->主题->故事->任务。”
Scrum暗中包含反管理：“Scrum过度强调了团队自管理的角色。自组织和自管理的团队本身是好的,但是具有局限性...Scrum的描述并没有给与很好的平衡。”
自动化测试：没有高质量的自动化测试，很难以短的迭代周期工作，很难知道故事是否真的做完了。
多团队：Scrum和通用的敏捷方法很少谈及怎样扩展，虽然很多实践者有一些想法，但是还没有达成广泛的一致。

MX Logic的软件开发主管Steve Ropa说：“我个人的经验是：在一定层次上，团队和成员需要领导。有时候领导来自于团队，但有时候不行。我感觉Bob大叔是说在团队和业务的交流上会产生局限，而这正是我的经历。”

Mark Woyna反击说“如果团队定期交付高质量的产品，客户比较满意，还要管理干什么？如果团队没有交付，尝试自我修正也不行，团队应该去寻求外部的帮助。”

《C#极限编程探险》一书的作者Ron Jeffries说：“多数Scrum团队所在的公司都有管理人员，并且在用他们。事实上这样对Scrum不但无益，而且经常由于管理人员的有意诋毁，使得Scrum被错误实施。”

Matt Heusser，软件工匠和测试专家，则建议:“更准确的说，应该把认证scrum教练描述成‘介绍一种新的产品开发方法’。这能把课程从软件开发中扩展开来，吸引整个团队，而不是团队中的一两个人。课程结束时可以发给一个证书，而不使用华丽虚饰的单词，比如‘认证’”。

《精益和敏捷开发应用指南》的作者之一Bas Vodde对讨论内容做了修订：“不应该把它叫做缺陷，相反应该指出Scrum本身需要其他实践的支持”。此外他不认为Scrum暗中包含了反管理，相反：

我认为许多人采用Scrum都会遇到这样的困难，即怎样处理管理角色的变化。自管理的团队确实把职责派发到团队中，因此管理的角色会发生变化。但太多的时候管理层认为“他们”不需要变化就可以使用Scrum这个框架（而不是命令...“你来做Scrum！”这已经意味着失败）。

我认为这不是Scrum特有的，如果深入研究自管理团队的历史和文献，会发现管理角色的变化是一个普遍的话题。然而，与任何其他角色类似，如果被告知当前的任务不需要再做，很容易把这理解成“反”的。

作者: woodheadz 时间: 3-6-2011 21:08

原帖由 black_zerg 于 3-6-2011 20:31 发表

 登录/注册后可看大图

补充一下就我个人观点，再牛b的方法也不能把垃圾程序员写出好代码，不谈任何方法论，一个强程序员一个人就能把一个模块从沟通到设计到实现到集成全给你搞定。所以这些方法论都是扯淡的都是混饭吃充数的人来糊弄人的，这玩意真管用那才有鬼了。很多吹这些破玩意的自己连写程序都不会，根本就不知道整体框架，根本不懂技术效率，不懂实现，甚至连用户需求都分析不来，跟客户开个十几个会都在那里兜圈子把大家都弄糊涂了。就这水平还是不影响他在那里胡天胡地的吹methodology。悲剧！

部分赞同。methodology不是银弹，在业内确实是被吹的过分了。再好的methodology，离开程序员和团队的素质还都是瞎扯淡。
但methodology也不是纯粹胡吹，大型项目里面没有适当的methodology是很恐怖的，人在牛也不行。
即便是中小型项目中，适当的方法还是能够提高些效率（当然不能起到决定性的作用）。

敏捷方法核心就是人。实施敏捷方法的团队最核心的任务是把大家编码设计的水平提高，而不是把关注点都集中在各种各样的方法上。
当人的素质达到一定程度的时候，才谈得上敏捷方法的实施。

作者: black_zerg 时间: 3-6-2011 21:17
提示: 作者被禁止或删除, 无法发言 人在牛也不行？这么说吧，强势程序员绝对不是只知道敲键盘的，他必须要熟悉软件生命周期而且非常熟悉需求，知道怎么用最少的时间让客户绝对满意，如果你对自己的要求说只是会敲点代码，那根本就算不上什么牛程序员，甚至不能算好程序员。起码说在我所做的领域里算不上什么牛人。我在工作里觉得最大的抱怨就是烧预算的人太多，吹牛不干事，这些人就可以完全忽略，有跟没有一个样。再就是强程序员不多，都是只能做点小东西或者没啥积极性去负责任。最后就是大家开会扯皮，大家一起玩嘴皮子。
我遇到的爱谈methodology的没一个强的，他在团队还总给人出主意让你该这么做这么做，让他单独负责个模块马上傻眼，做的东西狗屎一样。这样的人有什么用。一般来说我支持术业有专攻，但是 methodology 这个东西真的是没有编程底子全部是瞎扯淡。除非能自己把自己那块做的无可挑剔，再来谈methodology才有点说服力，不然大家都卖嘴皮子好了谁不知道说话最省事啊。
一个强的程序员在职业生涯中必然会发展出他自己的methodology,他自己也会很自然的按照自己的习惯去做，但是每个人最舒服的方法则可能有不同，所以我更倾向于每个人搞好自己的模块，很简单么，1+1=2，别搞得三个和尚没水吃，大家都想指导别人。当然了各人职业发展我不敢乱说，我只是从我的角度看怎么样给客户省钱，那么多闲人光吹牛不做事，一个项目怎么可能不超预算

所以我的methodology应该还是算agile的：一个人设计好了架构大家就开始按specs做，做了两星期就集成给客户看一回，人家不高兴就改，然后再继续做，做到完成所有功能客户高兴为止。就一句话的事情，不用谈什么高深理论,你要是在每个环节里都安插个中转人在找些专职tester，那也行，有钱就烧呗。

[ 本帖最后由 black_zerg 于 3-6-2011 21:34 编辑 ]

作者: woodheadz 时间: 3-6-2011 21:38

原帖由 空山鸟语 于 3-6-2011 21:01 发表

 登录/注册后可看大图

缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。

敏捷开发本来就是一种全新的开发理念。以往的软件开发过程例如瀑布、CMM本质上不依赖于单纯的软件技术本身，然而敏捷开发则严重依赖。没有优秀的设计，丑陋的设计+各种怪招弄出来的单元测试只会带来无穷的麻烦；没有优秀的设计，“代码即文档”就成了一句笑话。
大叔说这句话我认为是想提醒大家，不要把Scrum当成一个独立完整的软件过程（比如CMM）来看待。
我认为世界上就不存在一种放之四海皆准的软件过程。那把软件开发过程像工业生产过程一样标准化基本上是不可能的。
每种方法都有很多毛病，都有对实施者独特的要求。不考虑这些条件而盲目用管理手段推行软件过程，结果多数时候就是楼上说的“Programming, Motherf uckers”

作者: 空山鸟语 时间: 3-6-2011 21:48
标题: 回复 #17 空山鸟语的帖子
17楼中提到的一些观点我非常赞成：

“对产品Backlog的指导太少”，尽管提到有“史诗->主题->故事->任务”这样令人头晕的名词，但是还是不成体系。Back Log的产生方法没有介绍，Back Log本身要达到什么标准也介绍的很粗。Work Breakdown Structure这样一个简单的词其实就足以覆盖所有这些术语，甚至内容还要更丰富一些。；

“在团队和业务的交流上会产生局限”，这就是我说的Scrum在沟通上的局限。Scrum还是聚焦在开发团队身上，对于业务层面的事情关注太少，两个不同领域间的沟通更是严重不足；

“Scrum暗中包含反管理”，这就是为什么我开玩笑说Scrum是几个技术人员头脑激荡的产物。靠团队的自我管理来实现项目的高效率，我认为即便不排除会有奇迹式的成功案例，但是总体而言，这始终不是特别有价值的尝试。即使在一些规模很小的项目中能取得成功，可能也多半是因为对于特定的情况而言，只需要比较简单的项目管理而已。

作者: woodheadz 时间: 3-6-2011 22:04

原帖由 black_zerg 于 3-6-2011 21:17 发表

 登录/注册后可看大图

人在牛也不行？这么说吧，强势程序员绝对不是只知道敲键盘的，他必须要熟悉软件生命周期而且非常熟悉需求，知道怎么用最少的时间让客户绝对满意，如果你对自己的要求说只是会敲点代码，那根本就算不上什么牛程序员， ...

我看你是走极端了。
对于三五条枪的小团队而言，由个把你所描述的强势程序员带领可能是最佳方案。但对于十几几十人以上的大中型团队，不敲代码占预算的人就不是浪费了。而在类似外包开发之类的场景中，过程和方法就更重要了。
我自己是比较纯粹的技术人员，厌恶复杂的过程，现在也在一个相当技术化的弱过程团队中工作。

作者: TonyPan 时间: 3-6-2011 22:20
我们公司自09年底开始实施scrum，到现在基本是鸡飞狗跳，几个所谓成功的项目也都是挂羊头卖狗肉的。同意LZ的一些观念，scrum的方法论更适用于原型功能的开发，对开发阶段的项目控制有明显帮助，对于开发人员内部的沟通也有促进，但是其作用不能涵盖过往瀑布模型的生命周期。

如同scrum鼓吹的那样，把product owner纳入到scrum团队，是开发者和需求者之间的沟通更加通畅，但在实践中呢？需求者与开发者之间的鸿沟，是有其天然的存在背景的，需求者从来不属于开发团队，不可能dedicate到一个项目中的，不是通过一个软件实施的方法论就能够改变的。折中后的妥协也只是用BA来带代替product owner的角色，传统PM成为scrum master，反倒不用队项目的整体成败负责，只需要督促scrum的运作，我个人的感觉就是能够指手画脚的地方多了，承担的责任却少了。可天下有这个便宜的事情吗？没有明确的项目总负责人，就只有整个团队一起负责，也就是不负责。

在具体实践中，backlog的定义完全是从需求角度定义的，在这个基础上定义user story，然后分拆到sprint，task。整个项目的详细设计过程被弱化到可以忽略的地步，最后的结果就是导致系统的模块性差，可重用性差。我们scrum团队内包含master，owner，BAs，Developers，Testers，号称各人的role不固定，可以合作完成task，实践中这属于bullshit，每人的技术背景和作用完全不同，基本还是各人干自己的一摊子，但因为同在一个scrum团队中，多了很多指手画脚，扯皮打架。敏捷的目标没实现，效率却大大降低。

或许我们公司实践中有失误的地方，但从结果看，很不理想。因为从管理层的各个经理以前都没有接触过这种方法论，我们花了大量的时间和精力去完善scrum的实施，但收效甚微。

软件项目的核心还是人，懂管理的人，懂技术的人，负责任的人，能拍板的人，没有什么方法论能够把垃圾变成牛人，但不当的方法论实践肯定可以毁掉牛人参与的项目。
现在行业里这个词火的不行，各种实践，争论一直没停过。帮助了多少公司成功实施项目我不清楚，但至少催生了一个推广scrum的市场。

作者: black_zerg 时间: 3-6-2011 22:22
提示: 作者被禁止或删除, 无法发言 我是consultant，目标就是专攻小项目，我认为大项目以后都会外包。大公司大项目那种情况我说个实话你的people skill会更重要，更能帮助你往上爬。我之所以厌恶这些方法学是他们本质上把开发人员当工具当机器看，认为这个就是体力劳动，实际上杀灭了创造力，同时这些模棱两可的理论支持养活了一大帮闲人，又给了懒汉滥竽充数的机会，最终的结果就是毁掉团队，项目没人负责任，强的人走人，弱的反而都留下来混。当然仁者见仁智者见智。楼上是可能没见过那些真的耗你budget的，一个简单需求能开十几个会还在那里讨论，然后manager唯一会做的就让你报百分之几的数字，就这些个人就这么点破事就浪费掉你一半的预算，然后程序员就开始不爽开始糊弄manager,反正大家空对空的瞎扯，真干活的都是吃力不讨好那还谁愿意花时间在研究技术琢磨怎么提高设计上？大家都学着吹牛开会，有机会就 delegating 去。这些中间环节本来是能精简就精简，但如果你插一个人在那里，他会往死里强调和拉长他的工作，没有困难还制造好多困难，客观地说：不是方法不重要，而是这些脱离实际的过度强调方法太容易让混混钻空子毁掉项目预算和破坏团队文化。

[ 本帖最后由 black_zerg 于 3-6-2011 22:32 编辑 ]

作者: TonyPan 时间: 3-6-2011 22:43

原帖由 black_zerg 于 3-6-2011 22:22 发表

 登录/注册后可看大图

我是consultant，目标就是专攻小项目，我认为大项目以后都会外包。大公司大项目那种情况我说个实话你的people skill会更重要，更能帮助你往上爬。我之所以厌恶这些方法学是他们本质上把开发人员当工具当机器看，认 ...

你说的这些都是实践中天天发生在我周围的事情，scrum催生了一堆天天开会，指手画脚的人，把这些人拉来干活，屁都干不出来。也就是这些人最为支持这个神奇的方法论，让他们变得无比有价值。我们几个主要的经理对当前技术并不是很了解，现在招了几个senior的开发员，所以把希望都寄托在scrum上，让各个项目能够自己管自己，我只能称这个叫掩耳盗铃，画饼充饥。可惜老板不懂这两个成语。

作者: 空山鸟语 时间: 3-6-2011 22:45
标题: 回复 #19 black_zerg 的帖子
真正好的程序员应该不是只会敲键盘，应该能一针见血地提出有价值的解决方案。在这点上我完全同意。其实所谓的XP所追求的最高境界也就是这样：团队里面每一个人都既是高水平的程序员又是很不错的业务分析人员，旁边随时坐个客户代表。效率特高、文档特少、客户特满意，项目特赚钱，程序员也特赚钱。人人堵满意，呵呵。

但是这样的理想状态却是不稳定的，很容易就会失去平衡。比方说如果工作量超出了团队的生产力极限，需要增加相对水平差一些的程序员进来，以前的程序员就得抽出很多时间指导新人了。他自己就没办法象以前那样专心搞技术了。如果新加入的成员很多，甚至就得考虑职责分化，安排专门的人来负责整个团队的协调了。

再比如，如果碰到了比较陌生或者比较复杂的项目需求，以往的经验可能就遇到了瓶颈，没办法象以前那样运用自如了。这时候与其让开发团队在战斗中成长，还不如引进一个对这个领域比较熟悉的人专门负责需求分析呢。

所以说楼上描述的团队结构，或者说XP的团队结构，适合于比较熟悉的项目环境和不太大的项目中。在这个之外就不是很合适了。

从管理的角度来说，随着组织的膨胀，组织的人均效率和组织的智商是不断降低的。大团队肯定比小团队效率低，小团队肯定不如最好的个人效率高。这个是已经有了结论的东西。讨论一下团队的组织形式还是挺有价值的，不定哪天就能用得到。

作者: woodheadz 时间: 3-6-2011 22:45

原帖由 black_zerg 于 3-6-2011 22:22 发表

 登录/注册后可看大图

我是consultant，目标就是专攻小项目，我认为大项目以后都会外包。大公司大项目那种情况我说个实话你的people skill会更重要，更能帮助你往上爬。我之所以厌恶这些方法学是他们本质上把开发人员当工具当机器看，认 ...

重型过程确实是这样。我工作经历中让我第一次让我尝到干得“不爽”的经验，就是在重型过程里面得到的。
我做过外包软件的管理，经历过的项目有超级烂烂到最后花了绝大部分预算完成的文档和勉强运行起来的代码完全是两回事的，但也有规模不小的项目最后通过大量的会议和沟通基本完成了用户需求的。所以我觉得对重型方法也不能一杆子打死。
当然重型方法从来都会扼杀创造力，而且单个成员的工作效益远不及小团队成员。但大项目就是如此，也是无可奈何。

作者: woodheadz 时间: 3-6-2011 22:50
讨论那么多，总结起来我觉得还就是一句话：没有银弹。
SCRUM也罢，XP也罢，如果想着一旦实施后就能给团队带来如何如何的改观，最后的结果一定是失望。
尤其通过管理手段自上而下实施类似SCRUM这类敏捷方法的做法，实在是和敏捷方法的核心价值相悖，结果多半就是鸡飞狗跳，一地鸡毛。

作者: coredump 时间: 3-6-2011 22:54
XP 我感觉是很快就知道什么意思了，要传达什么精神，要达到什么目的
SCRUM 给人云山雾绕的感觉，我们现在就是SCRUM team，说实话，我不知道确切什么是SCRUM

作者: coredump 时间: 3-6-2011 22:57

原帖由 woodheadz 于 3-6-2011 22:45 发表

 登录/注册后可看大图

重型过程确实是这样。我工作经历中让我第一次让我尝到干得“不爽”的经验，就是在重型过程里面得到的。
我做过外包软件的管理，经历过的项目有超级烂烂到最后花了绝大部分预算完成的文档和勉强运行起来的代码完全 ...

重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉

作者: woodheadz 时间: 3-6-2011 23:02

原帖由 coredump 于 3-6-2011 22:57 发表

 登录/注册后可看大图

重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉

哈哈，同感！

我觉得把很多精力花到过程里是件很恶心的事，尤其对小点的团队而言，大家遵循一些尽量简单的基本原则就好，出现问题再针对问题个别解决。
对于大团队嘛，最佳实践就是把它分成小团队

[ 本帖最后由 woodheadz 于 3-6-2011 23:04 编辑 ]

作者: key 时间: 4-6-2011 10:58

原帖由 coredump 于 3-6-2011 22:57 发表

 登录/注册后可看大图

重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉

这个事老core说过两次了，
但每次都只是点到即止，希望能多分享一下。

作者: 空山鸟语 时间: 4-6-2011 14:42
在国内做项目的时候我一般也是用“混搭”的，介于瀑布模型、XP之间。我自己认为实际效果还不错，项目成员都很happy，客户很满意，项目的成本进度都控制的很好。其实一个项目管得好或者不好，多会有一种特殊的smell。不用讲太多理论模型，如果大家都觉得不爽那就肯定是有问题了。估计真正的Agile原教旨主义者也就是Thoughtworks这种公司吧，大部分公司都是以混搭为主的。
俱往矣，数澳洲IT民工，算我一个。来了这面带队做项目的机会估计比较渺茫了。

最近赋闲在家，每天富裕时间一大把，正好翻箱倒柜把自己不太熟的东西拿出来晒晒。通过大家的讨论，基本看清了，scrum真的是黔之驴啊。下次Interview的时候如果有人再提scrum就可以理直气壮地直接鄙视回去了。呵呵。

作者: key 时间: 8-6-2011 10:59

原帖由 空山鸟语 于 4-6-2011 14:42 发表

 登录/注册后可看大图

在国内做项目的时候我一般也是用“混搭”的，介于瀑布模型、XP之间。我自己认为实际效果还不错，项目成员都很happy，客户很满意，项目的成本进度都控制的很好。其实一个项目管得好或者不好，多会有一种特殊的smell。 ...

呵呵，还是小心点。
要知道全球目前大量软件公司转向Agile，
以你个人的观察和思考就下结论，未必有说服力。

作者: yuba 时间: 8-6-2011 13:21
标题: 回复 #33 空山鸟语的帖子
支持“混搭”，但是不要说“混搭”，要说 customised scrum process，重音在scrum上

等过些年scrum不流行了，谈起这段经历，重音放在customised上

作者: sliuhao 时间: 8-6-2011 13:33

原帖由 yuba 于 8-6-2011 13:21 发表

 登录/注册后可看大图

支持“混搭”，但是不要说“混搭”，要说 customised scrum process，重音在scrum上

等过些年scrum不流行了，谈起这段经历，重音放在customised上

老油条

作者: 空山鸟语 时间: 8-6-2011 13:36
标题: 回复 #35 yuba 的帖子
This is really really a good idea!

作者: black_zerg 时间: 8-6-2011 13:53
提示: 作者被禁止或删除, 无法发言 agile 四个目标还是没什么问题的，其实说的就是不要瞎搞，总之要让客户高兴，结果后来那些方法我觉得都是反agile的

作者: liluliang 时间: 8-6-2011 14:27
scrum实在不适合业务逻辑相对复杂的系统
前几周公司内部推广了jira上的一个新组件GreenHopper，说是专门支持scrum模型的
刚开始花花绿绿的挺好看
后来上百个card一出来，我看了真想吐

现在已经没人用了。。。

作者: 空山鸟语 时间: 8-6-2011 14:42
楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能力了。在小纸片上写用例肯定表达能力不如UML里的用例那么强，而且数量还不能太多，那就只能适合很小的项目了。

作者: woodheadz 时间: 8-6-2011 15:00

原帖由 空山鸟语 于 8-6-2011 14:42 发表

 登录/注册后可看大图

楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能 ...

我们现在的产品待实现的story上百个,还不是好端端的在用Backlog。 Backlog又不是用来描述需求的，里面的项目仅仅是一个周期里面要完成的内容，能有多少呢？你把所有的用例一股脑放到backlog里，还指望完全依赖Backlog帮你管理需求，当然用起来就很头疼。
一个方法提出来，具体应用时得根据实际情况确定应用方法，生搬硬套用起来当然就很别扭。
Scrum的确不大合适太大的项目，但这个和用例数量是没有关系的。

作者: Richard.G 时间: 8-6-2011 15:08

原帖由 空山鸟语 于 8-6-2011 14:42 发表

 登录/注册后可看大图

楼上说的没错。Scrum可能应付小型项目可能更适合一些。BA给把use case摆个龙门阵，程序员连蒙带猜的差不多也就可以开始干了。
当初学UML的时候曾经有一条就是讲一个画面上用例数量不能太多，不然就超过人脑的处理能 ...

我是真倒霉啊，从来没有碰到agile或者scrum的项目，看来waterfall和V－MODEL要用到老了。。。。

作者: 空山鸟语 时间: 8-6-2011 15:53
标题: 回复 #42 Richard.G 的帖子
你家娃贵姓？看起来好口爱啊。

作者: Richard.G 时间: 8-6-2011 16:03

原帖由 空山鸟语 于 8-6-2011 15:53 发表

 登录/注册后可看大图

你家娃贵姓？看起来好口爱啊。

谢谢！！俺家娃的确怪腔比较多。不过楼歪的太厉害了，哈哈

作者: ginobilis 时间: 14-6-2011 21:53
我自己是certificated scrum master. certificated scrum product owner,certificated scrum developer但是我也不太喜欢用scrum
对于中小型项目来说客户是挺喜欢scrum的。风险最小，每个sprint做出来的都是priority 最高 potential shipable product. 就算最后项目出现问题。最大价值的部分也都deliver了
但是对于程序员来说scrum那么繁多的ceremonies就感觉死板，甚至不Agile了。有些企业执行了scrum 但不agile，比如yahoo
像TDD，当然有很多好的方面，但是我也确实感觉到影响了我的开发效率，总之不爽
总体来说scrum太注重deliver，对于架构设计很忽视，我不认为能适用于大型项目
当然我觉得学学还是好的，比如学学scrum的CI 标配selenium + hudson + SVN+sonar 虽然我还没来澳洲，但scrum那些破证和一通吹牛搞不好哪天来澳洲找工作会有那么点用呢呵呵

作者: 空山鸟语 时间: 14-6-2011 22:37
标题: 回复 #45 ginobilis 的帖子
楼上是专家了。
我只是自己简单分析了一下Scrum的特点，不知道说得对不对，见笑了。Scrum既然这么火，肯定也有它一定的道理的。真心希望楼上给多介绍介绍Scrum主要的优势和价值在哪里。
我的几个主要疑问1是感觉Scrum好像更侧重开发团队的内部管理，对于需求方面涉及的比较少，不知道是不是这样；2 是对于Scrum团队的管理模式比较疑惑，请问在一个标准的Scrum项目里项目经理处于什么位置呢？

作者: ginobilis 时间: 15-6-2011 00:34

原帖由 空山鸟语 于 14-6-2011 22:37 发表

 登录/注册后可看大图

楼上是专家了。
我只是自己简单分析了一下Scrum的特点，不知道说得对不对，见笑了。Scrum既然这么火，肯定也有它一定的道理的。真心希望楼上给多介绍介绍Scrum主要的优势和价值在哪里。
我的几个主要疑问1是感觉Scrum好像更侧重开发团队的内部管理，对于需求方面涉及的比较少，不知道是不是这样；2 是对于Scrum团队的管理模式比较疑惑，请问在一个标准的Scrum项目里项目经理处于什么位置呢？

我也是混混，Scrum只主要价值就是降低项目风险最短时间交付最有价值部分。但是也正是因为太注重交付，我认为就有点不Agile了
以我个人的观点，Scrum对需求的要求可以概括成Adapter to client。所以很欢迎有任何需求变更，那scrum观点来讲，一开始就把需求考虑得很完善很详细，本来就不Agile了。还是做一步交付一步，随时让客户满意这种方式更好。甚至每个Sprint Review时候要交出来的product，也没有任何文档或PPT - 'Slides are lies'。 Review meeting上，让product owner玩交付的产品玩到满意，那就是scrum就最终目地达到。在Scrum实践中，需求最细化的文档很多就是细化的user story，比如里面对各个字段的要求进行说明。
Scrum项目里没有项目经理，只有scrum master，其实你前面也提到，scrum master没有起到管理作用，主要任务是对项目排除一切障碍。这种管理模式其实和scrum的起源也有关，scrum起源于橄榄球运动，这项运动本质上要求各个队员竭自己所能，没有明确的分工。“每个成员都可以干所有的事情，每个成员又都有选择权干自己最能干的事情。” PM的角色被基本弱化了。Master除了领导一些常规事务外，和其他开发人员也没啥区别。Scrum team 里只有三种role: Scrum master, team member, Product owner. PM这个角色是不存在的。

Scrum好处主要站在客户角度，确实对于中小型项目而言。如果很好实践，scrum客户满意度超高。一来TDD+CI等上去后代码质量绝对有交代，二来每个礼拜都交付，客户风险很小。我们瀑布经常碰到的问题就是整个项目delay，客户恼火。但是以每个sprint交付的模式，而且还是所有user stories已经被prioritized的情况下。客户认为最有价值的东西以最短的时间进行交付，即使最后因为经济原因项目终止，大多数可用的价值已经被交付。因为Scrum对交付的要求很高，必须是potential shipable product。所以根据我的经验中小型客户还是欢迎scrum的

[ 本帖最后由 ginobilis 于 15-6-2011 00:43 编辑 ]

作者: 空山鸟语 时间: 15-6-2011 07:52
标题: 回复 #47 ginobilis 的帖子
哦，那我估计Scrum项目在签合同的时候肯定不是固定总价合同，而是按照人月工时计价的。不知道是不是这样？

作者: ginobilis 时间: 15-6-2011 11:04

原帖由 空山鸟语 于 15-6-2011 07:52 发表

 登录/注册后可看大图

哦，那我估计Scrum项目在签合同的时候肯定不是固定总价合同，而是按照人月工时计价的。不知道是不是这样？

我做technical consulting的确实是按工时计价，但是关于这个问题我跟scrum training讨论过。他认为即便是传统的固定合同，以TDD+每个sprint交付这种形式，风险也比传统方式小很多。因为传统瀑布容易把风险积累到最后不可收拾，scrum把风险分散了。而且就算合同是传统的，一般客户也愿意参加每个sprint的review来验收功能模块，客户还是希望早点看到能运行的功能的。

如有兴趣可以参考下我公司里某个scrum 项目的现实进程 http://blogs.perficient.com/mult ... ficient-scrum-team/

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/forum/)