Submit My Question - Recent Questions - Recent Answer

Msdn China Tech >> 软件工程/管理 >> 开发过程

敏捷开发究竟敏捷在何处?

现在书店里讲敏捷开发的书非常火热，
可是我不明白敏捷开发究竟敏捷在何处？
不知道哪位牛人对此有深有体会，讲解讲解。
谢谢!!

[80 byte] By [zf0579-楚风萧萧] at [2008-5-24]

«« 69分求浙大acm1909
»» #define BEGIN_MESSAGE_MAP(theClass, baseClass) \

# 1

敏捷的意思就是“又快又好”。在有限的时间里出最好的结果。注重轻量级process以及软件的应变能力设计。

freegoer at 2007-10-26 >

# 2

快速、高效率地处理需求变化。

junlinjd-穷则独善其身,达则兼济天下 at 2007-10-26 >

# 3

以前的"重型"方法考虑的是怎么样把需求控制下来,然后在完整的需求的基础上进行设计,实现.所以需求的获取和系统的设计变得很重要,相对应的编码的工作就被一定程度的忽视了,致使工作在第一线的程序员s一度被认为可以随意替换的螺丝钉.

敏捷认为长远来看需求是在不断变化的,但是在一个较短的周期内需求是相对稳定的,那么我们就在这个周期内处理这些需求,这个周期就是一个迭代.下一个迭代的需求是什么我们现在不用管,那是以后的事了.因为范围的缩小,需求到实现的距离被大大缩短了,而敏捷所提倡的make it works 和 good enough 也是程序员的地位大大提高,但与此同时对程序员的要求也提高了,这也是敏捷好听好看但往往真正实施起来却困难重重的一个原因吧

caff-caff at 2007-10-26 >

# 4

现在看来，UP也是蛮敏捷的嘛

mig15-米格鸡 at 2007-10-26 >

# 5

敏捷开发就是让你的项目多一些灵活，少一些不该犯的错误：）

lovec-敏捷小子 at 2007-10-26 >

# 6

《人月》说：
最优秀的程序员和最差的程序员效率比为10:1

liu5644-残剑 at 2007-10-26 >

# 7

"人月》说：
最优秀的程序员和最差的程序员效率比为10:1"
==================================================================
这话你也信？我说应该是10000:1

mig15-米格鸡 at 2007-10-26 >

# 8

敏捷就是“里程碑+稳定+自动化”。

程序应该按照里程碑的方法开发出来，在开发周期中间尽快将一部分交给（准）用户使用和评价，并且当前开发周期中在发布和升级中要保持功能和数据，最典型的例子就是ms excel系统。一个公司公布出来的系统，外界以为它一个全新的系统，如果它已经被公司自己或者一些用户使用一段时间了，是不是很稳定？!

（最好每天）测试必须尽量使用稍微自动化的、比完全依赖手工测试高出几十倍并且全面、随机的测试方法。问题必须在当前测试周期中立刻解决。

w_rose-w_rose at 2007-10-26 >

# 9

可靠的测试方法，就是每一次（每一天）都将过去的所有测试实例都至少做一遍，如果可能还要将一些特殊的测试重复（但是随机）做上几千遍。

w_rose-w_rose at 2007-10-26 >

# 10

敏捷方法需要及其高超的软件设计技术、测试技术配合一些自行开发的小软件（例如代码管理软件、比较智能的编译预处理软件、测试软件等等）才能达到。这些辅助软件很小，关键还是看设计技术，是否能够充分真正看清软件的扩展思路（可扩展的地方应该分步骤去做，抓住重点，而不是一次就把所有细节都设计出来）。

w_rose-w_rose at 2007-10-26 >

# 11

测试优先,系统是可测试的,所以一定是可控制的,而且没有多余的代码(只有测试需要,你才加上响应的功能)
系统"任何时候"都是完整的,这一点相当重要,开发人员会有足够的信心,如果一个项目只有等1年后全部完成才能运行,那太折磨人的耐性了.
轮换结对编程,一可以让每个开发人员了解整个项目,各方面的技术都能进步,实现成员间的互相学习;开发速度会很稳定,因为都了解项目的各个部分,所以没有谁是不可缺少的.

Mybeautiful-天之痕 at 2007-10-26 >

# 12

敏捷是指过程简洁的，适用于需求变化剧烈的项目。

Voidest-白乌鸦 at 2007-10-26 >

# 13

个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

Richardhu-学无止境 at 2007-10-26 >

# 14

我的看法
所谓"敏捷"，是针对客户而言的，如果能在第一时间对客户的需求作出反应，那就是"敏捷"的。
因此，一方面要加强和客户的联系，加强对需求变更的预见性；
另一方面要对项目的运作情况有清楚的了解，知道什么能做什么不能做。

yyfhz-火山 at 2007-10-26 >

# 15

我的看法就是大家好好的去看看《敏捷宣言》，然后再来进行有针对性的讨论，现在的讨论只是一种凭个人的单纯感觉进行的无聊宣泄。

ozzzzzz-希望敏捷 at 2007-10-26 >

# 16

这与各人做事的态度有关。在开发和项目管理中，有些人太过注重成功，那些成事不足败事有余的东西与自己一点关系也没有；而另外有些人喜欢搞文字游戏，喜欢被人当作教授作“标准”方面的研究，并不认真去探讨什么是成功。

w_rose-w_rose at 2007-10-26 >

# 17

因此我认为“敏捷”是因人而异的。

w_rose-w_rose at 2007-10-26 >

# 18

当你忘掉敏捷的时候，你就真正敏捷了，事实上，现在许多人摆脱了做“重型方法”的奴隶的同时，却做了“敏捷”的奴隶。

smilemac-子非魚 at 2007-10-26 >

# 19

敏捷的目标就是快速交付可工作的软件，这里体现了两个方面，一个是快，另一个是保证质量，也就是“又快又好”，这就是它的敏捷之处

spgoal-敏捷的狗狗 at 2007-10-26 >

# 20

所谓"敏捷"关键在于追求能够"敏捷"地适应变化,所以在这里举MS的例子并不合适,MS在定义产品vision和feature方面有很正规,形式化的方法,虽然在开发中有多个里程碑进行迭代式的开发,但总的来说并不允许在feature/requirement方面有大的变化.而且这些里程碑中大多都只是内部的,能够用来获得用户反馈的Beta/JDP/TAP都是在产品开发的后期了.而任何一个MS产品的开发周期都是很长的.
MS开发的关键在于以尽量完善的方法在产品开发早期获取尽量完善的需求,而不是在开发的其它阶段去适应需求变化,这是其与"敏捷"方法的区别.
至于daily build, automation testing,这些是实现敏捷的手段,而不是用来解释"什么是敏捷"这个问题的.他们同样也可以用于任何非"敏捷"的方法.

mach-照虎画猫 at 2007-10-26 >

# 21

我认为敏捷首先主要针对客户而言，对客户来说，能在最快的时间内将其需求反映出来，他就觉得是敏捷开发，当然至于对于后期的需求变化、功能扩充等方面，最先开发出来的程序是否能够稳定、快速的扩充，这就在于最先的程序设计，所以我们当然可以说敏捷就是“里程碑+稳定+自动化”。

aswallow0323-我爱编程 at 2007-10-26 >

# 22

都是策略,只是侧重点不一而已,目标都是为了低代价的达到目标.
就像打星际,有些人就喜欢rush,有些人喜欢拼经济.
主要看对付谁了... 嘿嘿

hellowithsmile-张三_江南小百姓+抵制日货 at 2007-10-26 >

# 23

读者不同,体会也不同,
那上面书的尾页上,不是有很多的名人的笔记嘛!

好象都是大师一级的人员哟,人家能体会到敏捷
像我等水平之人,怎么能理解,

只有学习之!!

dearmite-笨笨的我*_ at 2007-10-26 >

# 24

《敏捷宣言》

benxie-结婚是幸福的！为了老婆努力赚钱！ at 2007-10-26 >

# 25

敏捷：
1. 小团队
2. 稳定团队
3. 团队
4. 不断进步的团队
5. 不断进步的软件设计
.....

xianjing-碧空流云 at 2007-10-26 >

# 26

我的理解是这样的：

其实目前我们的开发有很多步骤是没有涉及到的，有很多细节我们没有关注到，有可能我们只是着重在编码这个过程，但是整个软件工程中编码只是一个部分，而且这个部分比重不大。

不管使用什么方法或者流程，其实重在让别人的经验带领我们认识到我们在整个过程中要做的事情都有哪些。敏捷虽然让你理解敏捷，但是由于我们目前了解的开发过程要做的事情比较肤浅，所以看任何的有经验的过程都会让你觉得复杂，并不敏捷。

yorgo-羽高 at 2007-10-26 >

# 27

唉，啥也不懂啊，自卑

alaclp-陈石 at 2007-10-26 >

# 28

就是---要----加强语气-----赚更多的钱啊,兄弟!对于老板来说

aboush-无人居 at 2007-10-26 >

# 29

项目人员之间的无间合作——我认为太难

cita at 2007-10-26 >

# 30

又学到了一点点

beyondtkl-大龙驹*好久没来了,兄弟们好吧。* at 2007-10-26 >

# 31

昨天看到的一篇文章中提到xp的"light"问题
书中说xp对开发人员来说可能是light的,但对用户来讲绝对不是
因为他们需要一个"现场客户"持续呆在开发团队中
所以从用户的角度来看,xp是比传统意义上的软件方法要重的多

caff-caff at 2007-10-26 >

# 32

"昨天看到的一篇文章中提到xp的"light"问题
书中说xp对开发人员来说可能是light的,但对用户来讲绝对不是
因为他们需要一个"现场客户"持续呆在开发团队中
所以从用户的角度来看,xp是比传统意义上的软件方法要重的多"

====================================================================
开发的软件给谁用的？--还不是用户，怎么说是对用户不敏捷呢？

mig15-米格鸡 at 2007-10-26 >

# 33

简单设计，Micro Design,Build and Deployment合成一个整体的过程，其中的活动有：
plan the release
Refine Requirements and Application Model
Refine Architecture Model
Perform Programming Cycle
Perform Tests
Plan Deployment
Perform Acceptance Test
Setup Production Environment
Deploy to Production
Perform Client Review

vc_hking-编程的尼采 at 2007-10-26 >

# 34

我的第一感觉就是文档少了:)

123hui-cr2003 at 2007-10-26 >

# 35

个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

这里面有4个“胜过”字样，意味着右面的是基础。
在这些基础的工作上采用左面的方法或者手段才能
更有实际意义。

Sustain-支点 at 2007-10-26 >

# 36

我讨厌“面面俱到的文档“，喜欢“文档一本化”

Sustain-支点 at 2007-10-26 >

# 37

敏捷不是什么新玩艺儿。

实际上，在你不知道敏捷的时候，如果你有相对丰富的开发经验，一定会积累起和敏捷所鼓吹的
大道理，不要教条主义就在这里。想当然的认为用了比如XP的开发手段就一定会成功的开发出好
质量的软件那是做梦。这和通过CMM或者ISO就想当然的以为可以生产出好的产品一个道理。

很多人可能有过这样的经验：你呆在客户（也许“客户”就是自己公司）那里，头儿把你和几个
人聚集在一起，开发一套什么系统，没有多少式样书，只有简单的几页纸，然后大致的要求画一
画，就开始动手干了。因为需求总是在变化的，大大小小，需要很快的开发，测试，发布。式样
少逼着大家不停的用嘴巴互相交流，以至于两个人甚至3个人围在一起编程，然后错误很快被发现，
不停的修改。。。。。

有了几次经验之后, 你有一天看到有人在高声用英语嚎叫敏捷，你于是恍然大悟，不过如此。

Sustain-支点 at 2007-10-26 >

# 38

相对于楼上的自发的"敏捷"，自觉的敏捷基于一些技术和工具的：OO技术，模式，重构，自动化...
体会到其中的乐趣后,再来想想以前自发的"敏捷"真是老土的开发方式

mig15-米格鸡 at 2007-10-26 >

# 39

所谓"敏捷"就是以最小的增量实现软件功能，以适应需求的变化

Samen168-Codetocoding at 2007-10-26 >

# 40

敏捷就是用小规模的轻量级的迭代，去适应变化

hahahahah-裆中央总竖鸡-以阿扁下野为荣，以小胡连任为耻！ at 2007-10-26 >

# 41

相对于楼上的自发的"敏捷"，自觉的敏捷基于一些技术和工具的：OO技术，模式，重构，自动化...
体会到其中的乐趣后,再来想想以前自发的"敏捷"真是老土的开发方式
------------------
工具的确带来了便利，但是开发方式没什么土，洋之分，实质是相同的。

Sustain-支点 at 2007-10-26 >

# 42

工具的确带来了便利，但是开发方式没什么土，洋之分，实质是相同的。

=================================================================
如果没有自动化测试工具,我看哪个程序员还会想重构,还想敏捷？--除非你的程序员都是勤劳的小蜜蜂

mig15-米格鸡 at 2007-10-26 >

# 43

敏捷开发的开题是如此说的：

个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

敏捷开发强调交流，强调合作，强调简单，强调快速发布。其最终目标是快速响应变化。

应为需求的不确定性和易变性，必须强调开发的轻装上阵，多多交流，及时发布，及早发现风险，快速做出变化。

cnepine-奔 at 2007-10-26 >

# 44

做正确的事情是最敏捷的

ComPlus206-孔夫子 at 2007-10-26 >

# 45

=================================================================
如果没有自动化测试工具,我看哪个程序员还会想重构,还想敏捷？--除非你的程序员都是勤劳的小蜜蜂
----------------------------------------
我根本不能同意“软件重构需要借助工具完成”这种观点。
不是所有的重构都需要自动化测试工具，不是左右的程序都能够自动化测试。
有工具更好，没有工具的时候或者无法使用工具的时候也比比皆是。
那就不重构了？程序员可以依靠工具去睡懒觉吗？

自觉的敏捷基于一些技术和工具的：OO技术，模式，重构，自动化...
-----------------------
自觉的敏捷又是个什么概念呢？头一次听说，呵呵，烦劳解释，那怕给一个可参考的连接。

就敏捷这个词，应该来源于自动车行业最先提出的敏捷制造。而敏捷开发不过是一些开发
手法重新包装（以适应鼓吹者赚钱的需要？）。所以不要以为穿上“OO技术，模式，重构，
自动化”就能让别人认不出来。没有“OO技术，模式，重构，自动化”的方法未必就不叫
敏捷，关键看其实质是什么东西。

Sustain-支点 at 2007-10-26 >

# 46

我觉得那种增量式开发的重要成功前提之一就是
在一开始要设计一个具有良好扩展性的体系结构，而且设计过程中应该预测将来增量的方向。
如果增量的基础不好，那怎么开发都会很别扭，很累，而且会越来越累。
所以最初的设计更重要，而且，因为需求可能不足或难以挖掘导致设计难度更大，一旦设计失误，将来绝对是灾难。

sniper81-菜鸟也是人 at 2007-10-26 >

# 47

"我根本不能同意“软件重构需要借助工具完成”这种观点。
不是所有的重构都需要自动化测试工具，不是左右的程序都能够自动化测试。
有工具更好，没有工具的时候或者无法使用工具的时候也比比皆是。
那就不重构了？程序员可以依靠工具去睡懒觉吗？
"

=================================================================================
没有测试支持的重构能叫重构吗？--你怎么确定你的修改不会造成类外部行为的变化？

我们就是喜欢能依靠工具去睡懒觉的程序员!而不是勤勤恳恳的不睡懒觉的程序员

mig15-米格鸡 at 2007-10-26 >

# 48

炒作，关键是要实用，适用，能为我所用。

JafyLiu-自由的代价 at 2007-10-26 >

# 49

没有测试支持的重构能叫重构吗？--你怎么确定你的修改不会造成类外部行为的变化？
---------------------------------------------
找你这么说，不使用“类”的编程就没有重构了是吗？
你不会接着说现在还有谁不合“类”打交道？

重构是指在不改变代码的外部行为情况下而修改源代码,
提高代码的可读性，可维护性和稳定性，对吧？好像没
有规定必须使用“类”的时候才能重构啊？是不是一定要回
到概念阶段去讨论？

没有工具的时候一样要种地。
没有自动化测试的时候，一样要重构。
不用XP开发，一样重构。

重构就是重构，跟工具没有因果关系。

Sustain-支点 at 2007-10-26 >

# 50

"重构是指在不改变代码的外部行为情况下而修改源代码,
提高代码的可读性，可维护性和稳定性，对吧？好像没
有规定必须使用“类”的时候才能重构啊？"

=====================================================
那好，把类改称代码：
没有测试支持的重构能叫重构吗？--没有测试你怎么确定你的修改不会造成代码外部行为的变化？

mig15-米格鸡 at 2007-10-26 >

# 51

=====================================================
那好，把类改称代码：
没有测试支持的重构能叫重构吗？--没有测试你怎么确定你的修改不会造成代码外部行为的变化？
--------------------------------------
没有工具（指自动化测试工具）的测试和没有测试是一回事吗？

假设自动化测试是拖拉机，那用锄头就是跟手工改代码一样了。
没有拖拉机的时候，用锄头一样耕地，更早的时候甚至用手刨坑。
我只有3分地的时候，无论如何永不来拖拉机，我插稻秧的时候
就无法用东方红。但是，这不妨碍我改进种植技术。改进插秧的
间距插秧的时间施肥的多少和农药的比例。有一天，我买了好的
插秧机不是因为技术的原因，而是因为我技术提高了，获得了收
益，需要扩大再生产，而人力能够控制的范围有限。

这样举例虽然不太恰当，但是应该说明白这个问题了吧？

我从来没有说过重构无需测试，不测试的后果是极其严重的。仅
仅依赖自动化测试工具的后果同样会很严重。

Sustain-支点 at 2007-10-26 >

# 52

搞你的一亩三分去，懒得和你说了

mig15-米格鸡 at 2007-10-26 >

# 53

呵呵,拿你那种几个人围在一起画画图的编程来说你那也是敏捷!

Stitanleen-Inmethetigersniffstherose at 2007-10-26 >

# 54

还有看见和敏捷连在一起就觉得这是个新概念.编程累了就去读读毛选或者任正非,看看什么叫自觉\自发\自由

Stitanleen-Inmethetigersniffstherose at 2007-10-26 >

软件工程/管理

开发过程

微软中文技术开发社区是一个面向广大程序员与开发者的信息资讯网站,主要介绍和发布各类程序示例和所遇到的问题,是IT技术社区,为IT专业技术人员提供最全面的信息传播和服

敏捷开发究竟敏捷在何处?

软件工程/管理 Hot Topic

软件工程/管理 New Topic

软件工程/管理

Site Classified