敏捷与速度

陈能技

Linda Hayes在她的文章《From Here to Agility：The Physics of Speed》（http://blog.csdn.net/Testing_is_ ... /12/25/1967132.aspx）中说道：

我开始对敏捷的狂热感到惊讶。敏捷看起来成了快速的代名词，就像他们说的：“我们每个月发布一次，我们变得敏捷起来了。”但是你并不是因为更快而敏捷，你是因为敏捷而更快。事实上，如果你什么也不做，仅仅是缩短了发布周期，而其他什么都一样的话，你会比以前完成更少的工作。
明白敏捷开发如何让你更快速 – 而不是相反的 – 是让敏捷工作的关键。


想知道有没有哪位同行在采用了敏捷开发方式的项目组中工作过，谈谈感受。

[ 本帖最后由 陈能技 于 2007-12-26 00:18 编辑 ]

yuandjing

学习了，建议放精华，呵呵，免得以后找不到

siwanglongjuan

学习中

huazai_888

bucuo

Linda_123

还想补充一点:

Agile 不等于 XP
XP只是Agile的一种!
Agile不仅仅包括XP,还包括Scrum 等等

Linda_123

大家说的很理论, 我说点实际的吧 :
我们的项目都是敏捷项目.
使用的也是敏捷方法. 频繁的发布不代表不给测试足够的时间. 相反成功的频繁发布可以给team很大的信心, 应为所作的一切, 马上就是可以使用的.(系统) (同时, agile也建议大家进行自动化的冒烟测试.)

敏捷测试是建立的尽早的发现问题的基础上, 所以,里面有条需要每日构建. 意思就是说测试人员每天都可以有测试的版本.

最后, 我们项目是每两个星期就会发布,  我们目前的发布中没有存在加班现象.

还有一个关键点, 争对楼主所说, 可能完成的工作没有以前多. 我有个问题反问一下大家. 大家都知道Windows的各种操作都有进度条(比如安装文件). 其实这个一般有这个进度条比没有的时候花费的时间更多, 为什么还要保持使用进度条呢?! 用户体验!. 试想哪个用户愿意干等在那,却不知实际已经进展到什么程度了呢?
这个规则也适用于项目! 哪个投资人不愿意知道现在到底进展到什么地方了呢?

如果说大家在这种项目中, 经常要加班, 质量无法保证, 我觉得可以和项目管理人员进行沟通.(敏捷是不提倡,甚至是反对大家加班的哈) 个人的意见是在于项目没有规划好.

以上是本人的愚见, 请批评指点.

[ 本帖最后由 Linda_123 于 2008-7-14 16:29 编辑 ]

liulinzhu

敏捷开发要求团队内各小组协调配合，包括从需求--开发--测试--验收。
并不是想敏捷就能“敏捷”起来的。

xll2hjc

我所在的项目组现在就是3周发布一次,所以测试任务很重,经常加班,大家搞得都很疲惫...
不知道敏捷测试能不能给我们一些好的建议?

cangmang

小弟现在就在这样一个项目组..工作量巨大,需求不断的在更新..我们测试人员的工作量是越积越大,现在正在关注敏捷测试相关的知识

luoyear

敏捷与其是一种过程管理技术
还不如说是一种文化
首先是个体行为模式和工作认识的改变；
没有规则其实也隐含着最强的规则，
就是大家要一次把能做到的事情做好，
大家的责任心是对等的，
大家都有做好产品的强烈意愿。

试想你和一个人结对，
你XP了，人家的XP打折扣，
你还愿意和这样的人合作吗？

再次，对于大团队的技术和进度风险控制尤为关键。