大家有人在用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声称能解决很多问题，但实际上这是一个不系统、不全面的方案，很可能什么也解决不了。我估计没有多久大家就会忘了它，又开始追逐下一个概念了。 我觉的作者是站在重型开发过程的立场上来评价类似Scrum之类的敏捷过程。
我们现在的软件开发过程有点接近Scrum，用的工具就是按照Scrum的理念建立的www.pivotaltracker.com。 Back Log里面的东西是大家一起完成的。我没有认真研究过Scrum，但在我看来Scrum是敏捷方法中的一种，而敏捷方法的核心价值就是重视直接沟通和重视代码本身，在秉承这种价值观的团队中，Scrum重视节奏感的特点会有比较好的发挥。
我把Scrum当成是敏捷中的一种最佳实践来看，实际使用时，是需要根据团队特点配合其它的最佳实践一同完成的。
当然我有这样的观点也许是因为我对Scrum理论本身了解不深有误会:lol 原帖由 空山鸟语 于 3-6-2011 12:56 发表 http://www.freeoz.org/ibbs/images/common/back.gif
SCRUM是个当下非常时髦的jargon。不少公司都声称在推行Scrum，招人也要求有Scrum经验。如果你告诉别人你没用过Scrum，别人看你的眼光都好像城里人看乡下人似地。大家有人实际在用吗，效果如何？
按照Scrum的创始人 ...
很有意义的思考。scrum希望通过分散管理和逐步程现式的需求分析与实现来规避风险，
Scrum认为最大的风险是：
1. 全盘考虑问题的风险。因为基本上不存在对项目的全盘的准确的计划和架构。
2. 大管理架构的风险。包括大文档，大计划的风险。scrum推行的是小管理架构，小范围沟通（比如两人或小组沟通），小范围目标管理(sprint)
但是，避免全盘考虑问题本身就是一种风险，避免规范的大文档和大计划，本身也是一种风险。这些风险在空山同学的贴子里被提出来，
很有意义。
我公司现在正在用scrum在做一个大型项目。空山同学提到的问题，在这里都是问题，
如果这些问题得不到很好的解决，后果有点不堪设想。 任何方法都有优点和缺点，SCRUM的推出是最大限度的补充以往开发模型中的缺点，但是它本身并没有过多的对其他方法上优点的集成，SCRUM更多的是工程实践，而非方法。我本身对任何方法没有任何偏见，但是不得不说的是，
1）现在IT正在变成一个“时尚”行业，快速消费行业
2）任何方法变成商业实践，都会一定程度的失真
3）SCRUM是继续CMM/CMMI之后的另外一块猪肉
4）最重要的是人。 听说过，了解过，没用过，敏捷开发是高手无招胜有招，普通人学不了 偶对方法论狗屁不通。
现在这个公司比我还山寨。 原帖由 key 于 3-6-2011 14:24 发表 http://www.freeoz.org/ibbs/images/common/back.gif
很有意义的思考。scrum希望通过分散管理和逐步程现式的需求分析与实现来规避风险，
Scrum认为最大的风险是：
1. 全盘考虑问题的风险。因为基本上不存在对项目的全盘的准确的计划和架构。
2. 大管理架构的风 ...
我觉得敏捷方法也好，相对应的偏重型的方法也好，都有各自的优缺点，有自己适用的场景。
敏捷方法要求小团队，对团队中各个成员要求比较高。“表达力强而优雅的代码”，不是随便抓一个程序员都能写出来的。
我不太赞同LZ文章的观点，原因就是在谈论SCRUM的时候，他并没有摆正自己的立场。
我做一个比喻，就像一个做软件外包管理的老手跑来评价极限编程：“十有八九是一群开发人员连续加班之后一起发牢骚的时候想出来的方法”，站在这个老手的立场和以他的经验看来，的确是这样。但极限编程本来就不适用于外包软件开发这种低沟通效率、高人力投入的场景，你从外包的角度上去评价，有意义没有？ 谢谢大家的讨论。我没有实际参加过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心存疑虑的一个原因。
回复 #8 空山鸟语 的帖子
我记得当年kent beck和martin flower说过，啥都不比一个当场能拍板的客户经理重要..... 我做一个比喻，就像一个做软件外包管理的老手跑来评价极限编程楼上误会了。我自己也是个开发人员，对于好的敏捷方法我也是很欣赏的。而且，我是做那种时间紧任务重又没文档的项目开发的，对于比较好的管理项目管理也多少有些体会。我对Scrum的批评是认为它不是一个好的敏捷方法。我不是说敏捷方法有问题。 1，稳定团队
2，和客户沟通很方便
回复 #9 sliuhao 的帖子
的确是这样的。其实在SAP这些大型软件实施过程中也是有一套很成熟的方法的。其中也是特别强调跟客户的沟通。但是我们的XP方法才几年时间的历史啊，人家SAP这套方法已经几十年了。我们落后很多啊。 原帖由 空山鸟语 于 3-6-2011 15:39 发表 http://www.freeoz.org/ibbs/images/common/back.gif
但是为什么我认为Scrum有问题呢？我觉得Scrum的沟通顶多是在开发团队内部有效。这种沟通甚至都没有办法扩展到需求人员那里，更没有办法到达用户那里。开发团队跟外界交流的界面就是Back log，提供的反馈只有Back log的时间、成本评估、Sprint进度评估，仅此而已。仅从概念上理解，这叫什么沟通质量啊，这哪里是敏捷开发啊，其实跟以前的瀑布模型差不多，只是不要详细的文档了而已。
所以说我觉得你可能是受了其它软件过程方法的影响，用同样的标准和思路去看待SCRUM了。
CMM，RUP之类的方法提供了从项目前期到交付的完整规范，但敏捷方法通常不会这样。
我见过的实用中的敏捷开发，通常都是在一组统一的价值观的指引下，团队根据自身情况选取若干最佳实践组合来作为自己的软件过程。
Scrum涉及到的内容中，能拿来和外界交流的界面好像是只有一个BackLog，可没人限制你用其它的方式和客户进行交流啊。
实际上，我认为BackLog存在的主要意义在于将已知的功能细分成尽量小的工作点，而不是“描述需求”。
至于如何“描述需求”，SCRUM似乎并未提及。
所以当你用其它软件方法中需求文档的角色去考察BackLog的时候，就会觉得是一组离散的内容，简直无法通过它和别人交流。你说的没错，只不过你没注意到Backlog本来就不是用来和别人交流的工具。 那么Scrum真正的核心价值是什么呢？ 原帖由 空山鸟语 于 3-6-2011 17:24 发表 http://freeoz.org/ibbs/images/common/back.gif
那么Scrum真正的核心价值是什么呢？
就我对Scrum的认识而言，我觉得Scrum和XP等方法本质上是差不多的。Scrum对团队指导方针显得更加具体一些同时对其它的敏捷开发“最佳实践”非常开放；而XP的发明者们似乎过于强调XP方法中几种“最佳实践”的整体性。所以Scrum比XP要容易实践，适应性也好一些。
我说Scrum对其它的敏捷开发“最佳实践”非常开放，这个话换一个说法就是Scrum没有去包含软件开发中的很多方面。Scrum更像是一个敏捷软件方法的框架，你可以从实践Scrum入手，在过程中放入其他的“最佳实践”，从而定制出适合团队自己的一套XP过程。
敏捷开发方法不是放之四海而皆准的，我自己的经验而言，用于精英小团队效果相当显著；而用于比较大的团队、尤其是其中多数程序员的编码设计水平离XP的理想状态比较远的时候，敏捷方法就很容易变成没有方法，沦为扯淡了。
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特有的，如果深入研究自管理团队的历史和文献，会发现管理角色的变化是一个普遍的话题。然而，与任何其他角色类似，如果被告知当前的任务不需要再做，很容易把这理解成“反”的。 原帖由 black_zerg 于 3-6-2011 20:31 发表 http://freeoz.org/ibbs/images/common/back.gif
补充一下就我个人观点，再牛b的方法也不能把垃圾程序员写出好代码， 不谈任何方法论，一个强程序员一个人就能把一个模块从沟通到设计到实现到集成全给你搞定。所以这些方法论都是扯淡的都是混饭吃充数的人来糊弄人的，这玩意真管用那才有鬼了。很多吹这些破玩意的自己连写程序都不会，根本就不知道整体框架，根本不懂技术效率，不懂实现，甚至连用户需求都分析不来，跟客户开个十几个会都在那里兜圈子把大家都弄糊涂了。就这水平还是不影响他在那里胡天胡地的吹methodology。悲剧！
部分赞同。methodology不是银弹，在业内确实是被吹的过分了。再好的methodology，离开程序员和团队的素质还都是瞎扯淡。
但methodology也不是纯粹胡吹，大型项目里面没有适当的methodology是很恐怖的，人在牛也不行。
即便是中小型项目中，适当的方法还是能够提高些效率（当然不能起到决定性的作用）。
敏捷方法核心就是人。 实施敏捷方法的团队最核心的任务是把大家编码设计的水平提高，而不是把关注点都集中在各种各样的方法上。
当人的素质达到一定程度的时候，才谈得上敏捷方法的实施。 原帖由 空山鸟语 于 3-6-2011 21:01 发表 http://freeoz.org/ibbs/images/common/back.gif
缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。
敏捷开发本来就是一种全新的开发理念。 以往的软件开发过程例如瀑布、CMM本质上不依赖于单纯的软件技术本身，然而敏捷开发则严重依赖。没有优秀的设计，丑陋的设计+各种怪招弄出来的单元测试只会带来无穷的麻烦；没有优秀的设计，“代码即文档”就成了一句笑话。
大叔说这句话我认为是想提醒大家，不要把Scrum当成一个独立完整的软件过程（比如CMM）来看待。
我认为世界上就不存在一种放之四海皆准的软件过程。那把软件开发过程像工业生产过程一样标准化基本上是不可能的。
每种方法都有很多毛病，都有对实施者独特的要求。不考虑这些条件而盲目用管理手段推行软件过程，结果多数时候就是楼上说的“Programming, Motherf uckers”
回复 #17 空山鸟语 的帖子
17楼中提到的一些观点我非常赞成：“对产品Backlog的指导太少”，尽管提到有“史诗->主题->故事->任务”这样令人头晕的名词，但是还是不成体系。Back Log的产生方法没有介绍，Back Log本身要达到什么标准也介绍的很粗。Work Breakdown Structure这样一个简单的词其实就足以覆盖所有这些术语，甚至内容还要更丰富一些。；
“在团队和业务的交流上会产生局限”，这就是我说的Scrum在沟通上的局限。Scrum还是聚焦在开发团队身上，对于业务层面的事情关注太少，两个不同领域间的沟通更是严重不足；
“Scrum暗中包含反管理”，这就是为什么我开玩笑说Scrum是几个技术人员头脑激荡的产物。靠团队的自我管理来实现项目的高效率，我认为即便不排除会有奇迹式的成功案例，但是总体而言，这始终不是特别有价值的尝试。即使在一些规模很小的项目中能取得成功，可能也多半是因为对于特定的情况而言，只需要比较简单的项目管理而已。 原帖由 black_zerg 于 3-6-2011 21:17 发表 http://freeoz.org/ibbs/images/common/back.gif
人在牛也不行？ 这么说吧，强势程序员绝对不是只知道敲键盘的，他必须要熟悉软件生命周期而且非常熟悉需求，知道怎么用最少的时间让客户绝对满意，如果你对自己的要求说只是会敲点代码，那根本就算不上什么牛程序员， ...
我看你是走极端了。
对于三五条枪的小团队而言，由个把你所描述的强势程序员带领可能是最佳方案。但对于十几几十人以上的大中型团队，不敲代码占预算的人就不是浪费了。而在类似外包开发之类的场景中，过程和方法就更重要了。
我自己是比较纯粹的技术人员，厌恶复杂的过程，现在也在一个相当技术化的弱过程团队中工作。 我们公司自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 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我是consultant，目标就是专攻小项目，我认为大项目以后都会外包。 大公司大项目那种情况我说个实话你的people skill会更重要，更能帮助你往上爬。我之所以厌恶这些方法学是他们本质上把 开发人员当工具当机器看，认 ...
你说的这些都是实践中天天发生在我周围的事情，scrum催生了一堆天天开会，指手画脚的人，把这些人拉来干活，屁都干不出来。也就是这些人最为支持这个神奇的方法论，让他们变得无比有价值。我们几个主要的经理对当前技术并不是很了解，现在招了几个senior的开发员，所以把希望都寄托在scrum上，让各个项目能够自己管自己，我只能称这个叫掩耳盗铃，画饼充饥。可惜老板不懂这两个成语。
回复 #19 black_zerg 的帖子
真正好的程序员应该不是只会敲键盘，应该能一针见血地提出有价值的解决方案。在这点上我完全同意。其实所谓的XP所追求的最高境界也就是这样：团队里面每一个人都既是高水平的程序员又是很不错的业务分析人员，旁边随时坐个客户代表。效率特高、文档特少、客户特满意，项目特赚钱，程序员也特赚钱。人人堵满意，呵呵。但是这样的理想状态却是不稳定的，很容易就会失去平衡。比方说如果工作量超出了团队的生产力极限，需要增加相对水平差一些的程序员进来，以前的程序员就得抽出很多时间指导新人了。他自己就没办法象以前那样专心搞技术了。如果新加入的成员很多，甚至就得考虑职责分化，安排专门的人来负责整个团队的协调了。
再比如，如果碰到了比较陌生或者比较复杂的项目需求，以往的经验可能就遇到了瓶颈，没办法象以前那样运用自如了。这时候与其让开发团队在战斗中成长，还不如引进一个对这个领域比较熟悉的人专门负责需求分析呢。
所以说楼上描述的团队结构，或者说XP的团队结构，适合于比较熟悉的项目环境和不太大的项目中。在这个之外就不是很合适了。
从管理的角度来说，随着组织的膨胀，组织的人均效率和组织的智商是不断降低的。大团队肯定比小团队效率低，小团队肯定不如最好的个人效率高。这个是已经有了结论的东西。讨论一下团队的组织形式还是挺有价值的，不定哪天就能用得到。 原帖由 black_zerg 于 3-6-2011 22:22 发表 http://freeoz.org/ibbs/images/common/back.gif
我是consultant，目标就是专攻小项目，我认为大项目以后都会外包。 大公司大项目那种情况我说个实话你的people skill会更重要，更能帮助你往上爬。我之所以厌恶这些方法学是他们本质上把 开发人员当工具当机器看，认 ...
重型过程确实是这样。 我工作经历中让我第一次让我尝到干得“不爽”的经验，就是在重型过程里面得到的。
我做过外包软件的管理，经历过的项目有超级烂烂到最后花了绝大部分预算完成的文档和勉强运行起来的代码完全是两回事的，但也有规模不小的项目最后通过大量的会议和沟通基本完成了用户需求的。 所以我觉得对重型方法也不能一杆子打死。
当然重型方法从来都会扼杀创造力，而且单个成员的工作效益远不及小团队成员。但大项目就是如此，也是无可奈何。 讨论那么多，总结起来我觉得还就是一句话：没有银弹。
SCRUM也罢，XP也罢，如果想着一旦实施后就能给团队带来如何如何的改观，最后的结果一定是失望。
尤其通过管理手段自上而下实施类似SCRUM这类敏捷方法的做法，实在是和敏捷方法的核心价值相悖，结果多半就是鸡飞狗跳，一地鸡毛。 XP 我感觉是很快就知道什么意思了，要传达什么精神，要达到什么目的
SCRUM 给人云山雾绕的感觉，我们现在就是SCRUM team，说实话，我不知道确切什么是SCRUM:L 原帖由 woodheadz 于 3-6-2011 22:45 发表 http://www.freeoz.org/ibbs/images/common/back.gif
重型过程确实是这样。 我工作经历中让我第一次让我尝到干得“不爽”的经验，就是在重型过程里面得到的。
我做过外包软件的管理，经历过的项目有超级烂烂到最后花了绝大部分预算完成的文档和勉强运行起来的代码完全 ... 重的轻的项目类开发都做过，说实话，我都不喜欢，讨厌之。 现在做产品/library软件的R&D，感觉很好，把程序员当人看，不当牲口使，让你有种你是architect的错觉:loveliness:
页:
[1]
2