敏捷！敏捷？

iamredeye

好几年前就看到有极限编程的书在卖。单看封面，还以为是本编程方面的书，也就没有留意。

到今天已经被充斥大街小巷的一系列敏捷名词不停地轰炸到头晕，却对敏捷仍一无所知。突然间从一个pm身上发现了敏捷的魅力，对它一下好奇了起来。

CMM提升了我们看问题的视角，RUP用工具和可操作性充实了迭代理论。敏捷呢？它一系列的实践太具有吸引力了！你觉得敏捷是中国软件的一贴良药吗？

大家都在用什么方法呢？？？交流一下吧～


上一篇：敏捷软件开发的软件过程改进怎么进行？
下一篇：敏捷该如何管理？

xixiaojing666

不懂，不知道什么是敏捷！

iamredeye

我也不懂啊，略微接触之下发现眼前一亮。所以才想和大家交流一下。

我目前找到有关敏捷的资源不多，感兴趣可以参考一下：
http://www.infoq.com
http://www.agiledon.com
http://agilecommons.org
http://www.agilealliance.org

前两个是中文的。

看看这个，不错：www.extremeprogramming.org

[ 本帖最后由 iamredeye 于 2008-7-2 15:17 编辑 ]

step365he

如果楼主把Cowboy coding等其他几个较为陌生的名字解释下，可能效果更好：）
我在楼下放了篇文章，里面谈到几种方法，给大家参考。

sungubbi

觉得敏捷是过程中的一些最佳实践，是一些可以提高工作效率的方式或方法。

step365he

极限编程（XP）的创始人和“敏捷软件开发宣言”的执笔者之一，Ken Beck，一直是敏捷编程的倡导者，他认为敏捷编程可以缩短软件开发项目的开发周期。近日他参加了旧金山举行的Qcon大会，并接受了媒体的采访，谈论了敏捷开发的相关问题。

记者：你能谈论一下敏捷宣言和极限编程（XP）吗？

Ken Beck：在极限编程（XP）后面的基本设想是，肯定有一些对软件开发有帮助的敏捷行为。我曾经问过这个问题，“假若我们尽最大的热情来进行软件开发，会发生什么？”这就是“极限（Extreme）一词的由来。结果证明，如果你采取其中的一些做法，例如技术上的协作、测试，并比以前更加努力的推行这些做法，至少在一般的软件开发项目中你会获得比较好的结果。例如你的错误率会比较低，这意味着你可以更频繁的发布新版本软件。你能够以非常低的成本让项目启动进入最佳的可部署状态，与其他风格的开发模式相比，你获得了更低的开发成本和更短的开发周期。而且如果你将这种理念融入到后续的设计中，持续的对设计进行认真的投入，你可以在很长一段时间内以一种非常稳定的速率来继续部署新的功能。

这就是敏捷编程如何启动的方式，事实证明为了实现所有上述目标，无论是作为一个团队还是一个个体，你还必须学习许多新的社会技能：诚实、无私、有责任心。在获得一定的开发速度后，接下来的目标是，如果你想更快的进入下一步，你所要做的是能够更清晰和透明的交流正在进行的开发工作。

记者：你提到了推动敏捷编程发展的风格：可靠性、变化的低成本、增加的投资回报率。为什么软件开发市场正在从瀑布风格转向敏捷开发风格呢？或者现在是否只有一小部分开发者正在使用这个方法？

Ken Beck：是的，现在是只有一小部分开发者正在使用敏捷方法，但是我认为这一数字正在非常迅速的增长。我虽然没有明确的数字来证实我的观点，但是如果你关注一下敏捷开发者大会的增长，你会清晰的感觉到这一点。我认为现在推动敏捷开发的因素是这种开发风格更加贴近真实环境、更透明和更有责任感，如果你的开发周期比较短你会决定它就是你希望实现的开发方式。对于那些尊崇真实至上的软件开发，存在着巨大的潜在市场。

记者：为什么使用者还比较少？

Ken Beck：因为它存在的时间还不是很长。

记者：你今天早晨提到这个问题：用户不得不自己来确认你的软件是否可以正常使用。这本来是一件理所当然的事情，但是事实并非如此。为什么会出现这种情况？

Ken Beck：嗯，我认为造成这种现象的原因比较复杂，是技术和社会因素的综合原因导致了在已部署的软件中存在所有的缺陷。一部分原因是人们抱有软件天生就是不可靠的态度，客户习惯了这种状况。开发者习惯了接受这种观点。测试者也对此习惯了。我们只是觉得它像天气一样，对它无能为力，但这不是一个负责任的态度，因为实际上开发者有很多关于它的措施可以采取。从技术上来说，可以通过测试驱动开发、自动化集成测试、持续集成等手段；从社会学的角度来讲，端正自己的态度，不想推出具有缺陷的软件。以及加强开发团队成员之间的交流和关系等。

记者：你所熟悉的这些研究也说明了现在有如此众多失败的软件项目的原因。敏捷方法能拯救它们吗？还是只是一个临时的解决办法？

Ken Beck：敏捷方法是失败软件项目的救星吗？我认为许多软件项目依然会失败，问题是除非你非常深入的了解这些软件项目，你不知道会失败的是哪一个。那么敏捷方法是它的救星吗？不。我认为它依然会失败，因为好的想法并不一定在实践中产生好的结果。敏捷开发可以带给你的一件事情是：让这些项目失败的更快、损失的更少，因为你可以将时间和精力用于开始做下一件事情。

记者：对于极限编程，你提到隔几个星期进行一次迭代（iterations），而不是六个月到一年，你如何定义这个迭代周期，以及软件发布的周期？

Ken Beck：在极限编程中的基本周期，基本的计划周期是一个星期，这是非常合理的，因为它是根据人们工作的时间来定的。在每个星期结束的时候，这个软件应该比这一星期开始的时候具有更多的功能。

极限编程（XP）与其他敏捷方法相比如何？比如Scrum。

关于极限编程我比较喜欢的一件事情是其全面性。它从关于与好的软件开发一致的观点的全面讨论开始。介绍了一些基本原则，介绍了获得我们讨论的某种目标的具体的实践。因此我认为极限编程区别于其他方法的特点是它具有这种全面性。

记者：你能指出一个使用极限编程完成的比较突出的软件项目吗？

Ken Beck：例如Carfax。

记者：我们曾经听过“牛仔编程（cowboy coding）”的叫法，敏捷方法和牛仔编程有什么区别？

Ken Beck：我偶尔会体验一下牛仔编程方式，尽管它在我的工作中不占有重要地位。在牛仔编程中，你可以像一个勇士一样去编程，你会对自己的工作感到很满意，因为你认为这个世界上再没有别人可能作出和你的一样的东西。

极限编程风格的开发也是需要勇气的；这一点它与牛仔编程类似。但是牛仔编程是完全不透明的，而极限编程则是透明的。牛仔编程是一种个体行为，而极限编程是一种团队行为。不仅仅是程序员一起工作，还包括用户、管理者和测试者。因此我认为它们还是有差异的。

在极限编程风格中，早早结束编码是因为可以更快的看到真正的用户反馈，从而继续改进。一个牛仔式的程序员也会做同样的事情。或许你刚刚介绍了一半问题的定义，它们会说，“好的，我明白了”，然后就去开始编程。是的，这一点看上去和极限编程团队有些类似，但是两者实际上是不同的，因为牛仔式程序员已经结束了这次交谈，而XP团队则是才刚刚开始这次交谈。

记者：牛仔编程有成功的时候吗？

Ken Beck：当然，在短期内它具有巨大的风险和巨大的成本、巨大的隐形成本。我有过使用它的经历，但是它有时候会效果不错。

记者：有的软件项目是由分散在不同地区的团队成员在不同的时间来进行开发的，在这种情况下的开发情形如何？敏捷方法可以解决这个问题吗？

Ken Beck：是的，这就是我大多数时间的工作方式，因为我住在南俄勒冈州，出于生计，我的大部分时间仍在编程。因此我一直在进行着跨地区的开发工作。时区是一个挑战，但是最大的挑战是保持团队成员之间的关系。这是一件非常困难的事情。如果你能做到这一点，如果你的团队之间有良好的关系，那么你就能制定出技术的详细信息，例如谁什么时候进行了重构，谁加入了什么代码和已经作出的程序。

记者：对于Java和.Net，敏捷方法和极限编程适合吗？

Ken Beck：一个技术平台如果可以让你以较低的成本进行修改，它就更适合敏捷开发。你当然可以在Java和.Net中使用敏捷方法。

记者：在敏捷编程中有什么比较重要的事情吗？

Ken Beck：是的，那就是你在一个技术中需要的东西。在一个技术平台中它真的很有帮助。我的父亲一直在从事敏捷开发的技术方面工作，以汇编语言为微处理器编程。他使用自动化测试、增量设计，他频繁发布小版本，他写绝对可靠的代码。

记者：那么像AJAX、Ruby和PHP等脚本语言呢？它们适合敏捷编程吗？

Ken Beck：当然。举个例子说，Ruby来自于以人为中心的语言。你可以通过一种非常具有可维护性的风格编写Ruby代码，在很长时间内可以非常轻松的修改。我担心的是当你使用数据库的时候，这种修改可能会突然变得非常困难。

记者：和Ruby语言有关吗？

Ken Beck：一般来说是和关系数据库有关。但是敏捷社区正在推出解决这个问题的技术。厂商也正在让数据库接受增量修改。

记者：Web开发如何？它是否与敏捷开发特别适合？还是它只是另一个应用程序领域？

关于Web开发的最伟大的地方之一是其开发非常省钱。而且如果你一直在做部署的话，简单的把它放到一些服务器上就可以了。传统应用软件的刻录成光盘然后进行分发，部署的成本要大很多。

iamredeye

大家可以在google上或者wikipedia上搜索一下不熟悉的名词。应该比我解释要好的多::$

思步

:lol  小样，你还害羞，赶紧把完整的理解放上来。。。

iamredeye

没什么难懂得词呐～

唯一可能没听过的就是cowboy coding，上面贴出来得文章里也提到了。其实就是没有软件工程，需求还没弄清楚就可以直接写代码，非常牛b的一种方式。我知道很多非软件公司的软件部门实际上就是这么做的。

Scott

敏捷也是我最近比较关注的问题。因为CMMI得确有一些骨子里的问题难以解决，比如必须假定某个版本有一系列相对固定的需求，然后按照需求做估计，在做进度计划，再去跟踪；而实际上这样做很难适应快速变化的市场。
我们现在讨论的敏捷多数只停留在开发阶段，实际上敏捷的领域已经扩展到整个项目开发，甚至整个产品开发各个环节，包括市场。这个领域微软走的比较快，VSTS里面介绍了一些很好的方法。精益生产、约束理论、系统思维、丰田生产方式、全面质量管理，这些感觉遥远的东西好像突然间都和敏捷挂上了勾。
现在的敏捷已经绝非03年我看到的XP、FDD那样简单了。最近正在研究，希望能够融入到我们的全员改进系统中，也希望能在实践中不断应用。

由于目前尚未有太多成型的应用，所以不好在这里乱说。仅仅提出一个新词，供大家揣摩：价值驱动。

iamredeye

现在各种方法体系很多，每个公司的实际情况和需求又不尽相同。所以不妨什么方法都研究一下，有好用或有启发的地方就坚决拿来主义，反正不掏钱^_^

每个方法都有它的有缺点，或者适用的情形，其实他们都只关注到了这个世界的某一个局部。经历过不同特点的项目，大到上千人几年，小到几个人几个月，背景文化甚至完全不同， 我的感受是按照项目的特点去抓药方就好了，管它黑猫白猫，必要的时候找只黑猫换条白腿也行啊（其实要换腿或加条机械手臂的情况很常见）。

Btw，最近刚好看到有人批评说微软的敏捷还是不敏捷 :D 其实也许都是外人说歪话罢了

另外正好Scott提到了CMM，有个问题我一直没弄清楚，因为我对CMM的了解毕竟没有那么深入。我感觉CMMI这个框架并没有限制一定要按waterfall的方式实现呐？iterative当然也可以。但为什么我在很多地方都看到大家评论CMMI是waterfall的框架呢？

这里没人投“cowboy coding”很正常，因为上这个论坛的大多都是QA或流程相关的朋友，这些人在以cowboy coding方式的公司混不下去的:D 但是目前好像还没有人投Agile的票，这个好像不合适嘛，本来我想揪几个agile专家出来的。:funk:

让弟兄们继续投吧，过一段时间（一年？）我们再回头看看结果会有什么不同

Scott

听Introduction to the cmmi时，老师得确说过CMMI没有限制一定要用瀑布，但是为啥我忘记了：（另外，我最近感觉敏捷提到的迭代实际上也有问题，和我们的实际情况环境不同，我们更多的是用瀑布式增量开发。
最近看了一本书，我觉得讲得很有道理，不论哪种生命周期，其实最根本的是看周转的周期，就像生产里面的周转率，迭代里的时间盒。如果这种周期足够的短，那么增量式开发可能是最好的，同时也是现实中最多被采用的。迭代也足够短，但迭代和增量本质区别在于迭代带来了更多的不可预测性，或者说混沌。
经验也有显性的和隐性之分，迭代就是靠隐形的，即每个人的特殊技能；而增量还是可以依赖显性经验来更加合理的“预估”。

Scott

原帖由 iamredeye 于 2008-6-25 10:45 发表
现在各种方法体系很多，每个公司的实际情况和需求又不尽相同。所以不妨什么方法都研究一下，有好用或有启发的地方就坚决拿来主义，反正不掏钱^_^

每个方法都有它的有缺点，或者适用的情形，其实他们都只关注到了这 ...

我1，2个月之前也是这样认为，就像“建立自优化流程框，推动全员过程改进”中提到的一样http://www.step365.com/bbs/thread-64-1-1.html
如果是这样，那我们需要的就是有选择的“拿来主义”。

但我现在觉得这种思路有点问题，问题在于两点，第一这样的组合方式太多了，而且随着新优秀实践的演进，组合会爆发式的增长；第二这样的组合可操作性不强，试想哪个开发人员在进入编码阶段时还要先评估一下哪个优秀实践更适合我，然后再去做，即使是QA很了解并且给他们培训，那怎么保证他们把优秀实践做到原汁原味或者更加优秀。

HW曾经并且一直在沿用优秀实践DNA，即优秀实践具备哪些可复制特性，这样更易于复制。这种方式和“敏捷与秩序”一书中思想基本一致。但结果呢，据我了解实践并不是很理想，具体数字我现在不得而知了。

我现在更倾向于Humphrey的PSP，让每个开发人员形成自己的技能集，在统一的TSP下高效运作。但是Humphrey的PSP感觉太学术化，实际中存在困难，尤其是在中国职业化严重落后的情况下，我真不知道中国是否有应用PSP成功的企业？曾经参加过2007SEPG大会，当时联想的一个外包公司曾经做过这样的演讲，公司使用PSP/TSP效果很好，假设这种情况真的存在，那接下来该如何做呢？继续实施CMMI？那不是又回到了我们的老路上。“一堆牛粪差了一朵鲜花，远处看上去很美，但实际上还是一堆牛粪。”“张了翅膀的不一定是天使，可能还是个鸟人。”--我一直不太看好CMMI，虽然我一直在大公司里不停的在讲解着如何应用CMMI在项目中，可我每次都要耐着心思去和项目经理解释，为什么估计有用，为什么要做一个详细的进度计划，引导了2，3年，结果问题依然存在，项目复盘的生产率仅仅能作为规模到工作量的一个除数，而规模我们依然要拍着脑瓜子去猜测；进度计划依然在写，可写完了基本上也没有人再去更新了。

也许iamredeye会问，那你看好什么：）我不说，还是那个词：价值驱动～～

iamredeye

你误会我的意思了。我说的拿来主义并不是让开发人员按他的想法随意选择或组合，而是针对公司的流程管理人员或所谓的SEPG。SEPG针对公司的情况制订最合适的流程，这个过程中可以从任何地方选择任何有价值的框架或经验来参考。

另外再聊两句上面CMM的话题。CMM是个非常空的框架，规定了一些针对流程改进需要关注的点。按cmm来实施改进的公司需要针对自己的情况用流程来填充这个框架，用RUP也好，waterfall也好，应该都是可以的。我在网上也看到有人用迭代的方式实现CMM框架，另外我个人感觉应该也是可以的:D

Scott

：）我的意思恰恰与你相反，不是SEPG组合一个公司级的流程，而是开发人员自己组合自己的流程（也就是Humphrey说的PSP）。不由SEPG来制定的原因就是SEPG有点脱离项目组甚至产品线。

SEPG应该有较少的牛人组成，主要是围绕公司高绩效做文章，比如引入TL9000，建立标杆管理等。

你说网上有人说用迭代方式实现CMM，CMM没有限制生命周期。