近日,国外的敏捷社区热闹非常,关于Scrum与Scrum+XP之争的讨论更是甚嚣尘上。大家不但在Yahoo敏捷讨论小组进行了激烈的辩论,战火也燃烧到了多位专家的博客上。对此专题,InfoQ曾进行了连续报道:《
James Shore:敏捷的衰落》、《
采用敏捷需要面面俱到》、《
敏捷专家的衰落——实施敏捷必须面面俱到?》。
从这场著名的论战看来,国外采用敏捷的公司不但众多,而且越来越多,而且最常用的一种方式就是从Scrum做起[1]。为什么先用Scrum呢?因为Scrum主要是管理的实践。对组织里的领导来说,管理是其基础,改善的管理实践对他们是最能看得见、摸得着的,也最容易被他们接受。那么采用了Scrum之后的组织,是否真正敏捷了呢?是否达到实施敏捷的目的了吗?
Jame Shore认为,许多组织采用了Scrum,但是情况变得更糟:“So, unfortunately, a lot of self-described Agile projects are going to fail.”[2]。
然而Jurgen声称,他们的公司只用了Scrum,也相当成功:“Today all our project managers agreed that the introduction of Scrum has increased the success of our projects. ”[3]。
其实单独采用Scrum能否成功这才是这场论战的焦点之争。如果是实践是检验真理的唯一标准,暂且认为他们二人所述属实,则Shore的数据来自更多的公司,明显占了上风。而Jurgen仅从自己公司入手,在随后的辩论过程中,更让人疑窦丛生,比如Jonathon Golden就认为Jurgen一定有什么事儿瞒着我们:“There is clearly something he's not telling us.”
其实组织采用敏捷,目的无非体验是敏捷带来的好处:改善软件质量,提高软件交付的成功率。那么敏捷怎样达到这一点呢?单独采用Scrum为什么不够呢,Ron Jeffies给出了Scrum必须使用重构这个XP实践的理由,相当精彩[4]:
引用
如果你真的要用Scrum,那么:
* 你必须从第一个Sprint起开始交付软件;
* 你必须在随后的每一个Sprint中交付软件;
* 如果你在第一个Sprint里交付软件,那么当时所作出的设计就会比较脆弱,因为你没时间把一切都弄好。
* 因为这样一个设计没法从头到尾承载起项目,你就不得不改进设计;
改善既有代码的设计,即为重构之名。你必须做重构...
可见即使只采用Scrum的组织,重构也是很有必要的。既然已经采用Scrum了,不妨也采用重构吧。看看另一个实践TDD:
测试驱动开发与传统先写代码后补测试相比,更能保证代码有对应的测试覆盖。这样重构之后,通过运行单元测试可以保证重构不会引入新的bug。这也是为什么TDD把重构纳入它的一个步骤的原因。当然除此之外,TDD还有很多其它好处。所以既然重构了,为什么不采用TDD呢?
那么结对编程呢?很多尝试过结对编程的人说,2个人一块干活确实不如分别干活快;当然也有人得出类似结论,结对编程在某些情况下合适,在其它一些情况下不合适。但是看看结对编程给代码带来的质量的提高吧;看看频繁交流对组员带来的技术上的提高;看看交换结对后每个人都能熟悉每个模块,是怎样降低了人员流失带来的风险,等等诸多好处。对这些我想首先是毋庸置疑的。其次结对编程真的会使生产效率下降吗?以前有数据说编程人员的最高最低效率相差能够达到20倍,你的项目中会全部都是效率很高的牛人吗?他们一天8小时会一直效率很高吗?数据说明编程人员一天高效率的时间只有2-3个小时。而有了结对编程之后,Marko Majkic在Yahoo Scrum讨论小组中《
Rotten apple in Scrum team》中说道,某人的产出是其他人的一半:”Average contribution per developer is 38 usp (user story points). One of the members makes only 19 usp - twice less than the others.“所以最高最高效率的差别大大缩小了,可能只有2倍左右。同时也有数据表明结对编程后程序员的高效时间能够延长到4-5个小时。
如果以整个项目周期内每个程序员每日所做的工作量来看,结对编程的效率不但不会低,反倒很可能会高。何况代码有了更高的质量。所以,为什么不采用结对编程呢?
关于其它XP实践,我想都有类似的理由。虽然表面看来不采用某些实践,对你的项目影响不大,但实际上它们在各个方面扮演着重要的角色,是敏捷战车上的重要组件。因此,把它们作为一个整体,你会发现项目大有不同。
目前国内敏捷社区对此讨论甚少,平静如一滩死水。其中原因,想必主要是国内实施敏捷的公司太少。你的项目是否采用敏捷了?是否只实施了Scrum的实践呢?如果觉得哪里不太对劲,项目仍在苦苦挣扎的话,XP很可能就是你的答案。
分享到:
相关推荐
本书《Exploring Scrum: The Fundamentals》由Dan Rawsthorne与Doug Shimp合著,旨在对Scrum框架进行基础性和深入的探索。Scrum是敏捷开发方法的核心实践之一,它是一种迭代式增量软件开发过程,通常用于管理复杂的...
标题“Scrum+of+Scrums+-+Scaling”揭示了本文是关于敏捷开发中Scrum框架的扩展实践——Scrum of Scrums,即Scrum团队的团队。Scrum of Scrums是敏捷开发中的一种模式,它允许多个Scrum团队通过共享信息和协作来协调...
Scrum是一种广泛应用于软件开发领域的敏捷框架,它旨在提高团队的效率和灵活性,通过迭代和增量的方式交付高质量的软件产品。Scrum的核心理念是通过自我组织的团队、透明的流程和持续的反馈来应对变化,确保项目的...
**Scrum框架** 是目前最广泛使用的敏捷框架之一,它强调团队自我组织、迭代开发和持续改进。Scrum的核心要素包括: 1. **产品待办事项列表(Product Backlog)**:这是项目的全部需求集合,由产品负责人负责维护和...
《硝烟中的Scrum和XP》是一本深入探讨敏捷开发方法的书籍,主要聚焦于Scrum和极限编程(XP)两种流行的敏捷框架。在IT行业中,这两种方法论被广泛应用于软件开发项目,以提高效率、灵活性和产品质量。下面将详细阐述...
阅读《硝烟中的Scrum和XP-SCRUM与极限编程》可以帮助你理解这两种敏捷方法如何协同工作,提升软件开发效率。通过学习Scrum的迭代管理和XP的编程实践,你将能够更好地应对项目中的不确定性,为客户提供更优质、更适应...
《Scrum与XP:战壕中的敏捷实践》一书由亨里克·尼伯格(Henrik Kniberg)撰写,深入探讨了Scrum、XP(极限编程)以及敏捷开发方法在实际项目中的应用与实践。该书免费提供在线版,并鼓励读者通过购买印刷版来支持...
可能的讨论点包括:Scrum和XP如何处理风险管理、如何将XP的技术实践融入Scrum框架、如何平衡敏捷原则与传统项目管理方法、以及团队文化和组织结构对实施Scrum和XP的影响。 此外,文档可能会涵盖Scrum和XP对团队沟通...
书中的标签“scrum xp concept experience”暗示了本书将结合Scrum和XP的概念与作者的实际经验。这表明读者将会遇到丰富的案例研究、实用技巧和从一线敏捷实践者那里得到的宝贵建议。 总结而言,本书是关于Scrum和...
总的来说,Scrum+DevSuite的组合提供了一种强大的敏捷开发工具,帮助团队更有效地管理需求变更,提高开发效率,减少风险,并确保项目的透明度和可预测性。通过DevSuite,团队能够更好地实施Scrum流程,从而实现高效...
Scrum和极限编程(XP)是两种在软件开发领域广泛应用的敏捷方法论。它们都是为了应对传统瀑布模型在快速变化需求和不确定性中的不足而诞生的。在这个名为“硝烟中的Scrum和XP”的资料包中,我们将深入探讨这两种方法...
Scrum和XP(极限编程)是两种在软件开发领域广泛应用的敏捷框架,它们都是为了应对传统瀑布模型在面对快速变化需求和不确定性时的不足而诞生的。这两种方法论都强调了迭代、增量式开发和团队协作,以提高软件项目的...
Scrum和极限编程(XP)是两种非常流行的敏捷开发框架,它们在现代软件开发领域扮演着重要的角色。本文将深入探讨这两种方法的核心理念、实践原则以及如何在实际项目中应用。 **Scrum** Scrum是一种以人为核心、...
硝烟中的Scrum和XP XP
### 敏捷开发最佳实践:Scrum与XP在项目管理中的应用 #### 一、引言 随着软件行业的快速发展,企业对于项目管理的需求也日益增长。为了满足不断变化的客户需求和提升开发效率,敏捷开发方法逐渐成为业界主流。其中...
"SCRUM实施与检查列表"是指导团队有效执行Scrum方法的工具,旨在确保所有关键环节都得到充分考虑和执行。这个检查列表通常包含以下部分: 1. **角色**:Scrum有三个核心角色——产品负责人(Product Owner)、Scrum...