[如需转载，请在转载时注明出处，并保证本文的完整性]
1986年，竹内弘高和野中郁次郎阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：他们将这种新的'整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而后者整个团队"tries to go to the distance as a unit, passing the ball back and forth"。他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究。1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一书中将这种方法称为 Scrum，在竹内弘高和野中郁次郎的文章中又再次提到这个来自橄榄球的术语。
Scrum，原本是橄榄球的术语，意指两队争球的动作。软件开发的 Scrum 之所以会从橄榄球借来这个词，其实是出自野中郁次郎与竹内弘高两位日本知名教授在1986年于哈佛商业评论发表了《新产品发展游戏》(The New New Product Development Game) 一文，文中采用"橄榄球"这个比喻，来描述新产品发展的速度和弹性，就好像整个橄榄球队有默契地在球场中移动和传球一般。
在野中郁次郎与竹内弘高两位所写的The Knowledge-Creating Company一书中，和橄榄球式相对的新产品开发方式，类接力赛的方式。
A、在接力赛的方式下，新的软件产品的开发，遵循的是概念、可行性分析、需求分解、产品设计、coding、测试等等不同阶段循序渐进，由不同的部门持棒子交给另一个部门。在接力赛中，分工清楚，各部间各有职掌。它的主要缺点是产品发展的前置期较长，优点则是由于各个阶段职责清晰，每个部门可以竭尽全力的追求完美，以致产品能达到较高的交付标准。
B、而相对的橄榄球方式，它的危险之处在于为了要维持团体的和谐与一致性，它可能会向较低的标准而妥协。
目前的软件行业，通常把这种循序渐进、一棒接一棒的接力模式，称为Waterfall，瀑布式的开发流程，也是最传统，也最常见的方法。那么，Waterfall的开发方式，相较于Scrum的方式，是否真能如野中与竹内两位管理大师所说的，能够达到更高的标准？
时下大家常常津津乐道的Scrum方式，是否又能真正意义的取代以往的传统开发模式呢？经过多年的测试工作，我看过的瀑布式的软件项目也不少，个中方式下的产品质量，孰优孰劣，难见高下。（当然不排除项目管理中的诸多因素，诸如成本、进度，当然还有人的因素）
先让我们摒弃开发模式上无谓的PK吧！那么，撇开流程的问题，那么真正问题出在哪里呢？
抱着大师的书翻来覆去地想，我想通了大师的话了。大师其实已点明了问题，橄榄球式的危险之处在于为了要维持团体的和谐与一致性，而可能会向较低的标准而妥协。
因此，真正的问题在于团队的组织文化，是不是会为了要"和谐"，而把产品的交付标准给和谐掉了呢！在这种文化下，采用waterfall的开发流程，就会比较不和谐吗？这倒也未必，如果在上游的市场与产品管理，对设计、研发影响力较强，那么这就已经开始向低标准倾斜。试想下，在下游执行开发、测试的部门，也不容易提出较突破的创新科技与良性的质量保持方案。
不过，两位大师的理论还是给了我一些思考，在推动Scrum的时候，千万不要在强调跨部门合作的同时，流于过度强调整体的和谐与一致，反而把大家推向最低的标准妥协。因此，在软件项目开始之初的计划阶段，包括产品的概念定义、测试的策略都要澄清具体，而"完成的定义（Definition of Done)" 也要透过密集的讨论以达成决议，一旦概念与策略决定，各个Team各自像橄榄球队般的运作，沿着沟通的目标，大家一起发力，不断相互传接配合，并共同达成目标。
寄希望能在Scrum下的提高软件的质量的窝友，切忌不要太过激进，建立良好的沟通机制与团队文化，才是克敌制胜的法宝。毕竟没有绝对好与坏之分的项目，也没有绝对优与劣之分的流程，怕只怕 对的人来实施。
注：本文部分概念引用网络与书籍
对，事无绝对，但求常理。
