51Testing软件测试论坛

标题: 敏捷过程实践[经验分享] [打印本页]

作者: Linda_123 时间: 2006-10-22 14:18
标题: 敏捷过程实践[经验分享]
参与敏捷过程有一段时间了, 我们享受到很多敏捷的好处, 也遇到了很多的问题.

在此将我的经验与大家分享, 希望对实施敏捷过程的同行们有一定的帮助.

文档中有争议的地方, 欢迎大家指出. 谢谢.sdlkfj2

作者: deyizhi 时间: 2006-10-23 09:28
谢谢了！

作者: evemond 时间: 2006-10-24 23:01
这个所谓敏捷过程是不是就是Scrum？这种项目管理模式现在在很多地方都很流行。最最累人的实际上说白了就是“早请示晚汇报”，也就是每天的例会，这很要命的，跟催命地似的。

作者: Linda_123 时间: 2006-10-25 10:42
敏捷过程中包括很多种，Scrum也是其中的一种。我们使用的是XP（极限编程）。

“催命”似的，我倒是理解为，像种田一样，每次只划分一小块，然后做完一小块就回顾一下。至少有一点可以保证，不会到整个项目快结束了，然后就疯狂的赶进度，疯狂的压缩测试的是时间。因为敏捷过程中开发和测试几乎示同步的。

（呵呵，感觉大家对这个话题不是很感兴趣。。。没什么人发言哦。）

作者: evemond 时间: 2006-10-26 01:35
嗬嗬，可能这里参与项目管理的人还没有“露峥嵘”。我那天肯定是理解错了，你说的这个敏捷过程应该就是Agile Project Management吧。XP应该就是Extreme Programming。抱歉，我们这里通常对这些新名词直接用英语，不翻译，我只好猜测你的中文所对应的概念，便于我理解。

对于你的经验分享，我觉得挺好的。虽然我自己暂时还没有接触这种项目管理模式，但是知道一些。

你所提到的用户改需求的问题，其实我有个问题：
需求应该在项目开始阶段就基本确定才对。你这里，客户要求该需求的时候，通常你们如何同意的？是否要和用户沟通诸如产品交付时间需要推迟什么的。其实对于这种Agile模式，很多人也有批评。我们这里通常认为对于小项目这种模式应该不错，如果项目大，翻来覆去的改需求，各种成本就上去了。

谢谢分享，并欢迎继续探讨！

作者: Linda_123 时间: 2006-10-26 14:54
标题: 回复 #5 evemond 的帖子
需求管理在敏捷项目中是很重要的一块。（至少我个人是这么认为的。）
需求在项目开始阶段就有了大的计划，会确定按照这个计划我们会什么时候交付产品，但这个计划不是绝对的，会根据需求的变化而变化。

但是我们给客户更多的空间，我们将整个产品分成很多个user story，（也就是是RUP意义上的user case）。开发人员来评估每个user story的时间是多少，由客户来定哪些先做，哪些后做。（当然开发人员也会对不合理的地方提出意见和建议。）

至于交付期，实际上我们每一次迭代都是一次交付期。比如说确定本次迭代会完成5个user story，（2个星期后发布）那么完成这部分后，我们就将release. 让客户来接收测试。并确定下一次的release将包含哪些user story。

所需要保证的就是，每次release都是可用的版本。这样客户也可以及早的发现需求交流上的问题，不至于到开发完毕以后才发现有很多是不符合自己的真正需求的。

如果客户更改了需求，那么开发人员将更改的需求列入新的user story中，估算需求修改所需的时间和经费，让客户自己选择是否修改原先的需求。
说白了就是，给你（客户）做多少东西就收多少钱。

在这其中，和客户的交流非常的重要

作者: shwonder 时间: 2007-3-6 12:55
对agile 稍微有一些了解，但是不知道这种过程应用于国内的情形如何，尤其对于中小企业。给人的感觉是，冒着风险在走。毕竟这种过程迭代需要双方都能适应。

作者: dulong 时间: 2007-3-18 04:43
ding

作者: jiangxk 时间: 2007-4-5 15:53
标题: 支持敏捷开发
但实际上我们还是原型加瀑布

作者: zhaoyinggf 时间: 2007-4-12 14:24
顶!
了解以下

作者: legendarylucc 时间: 2007-6-26 10:03
sdlkfj5

作者: yja007 时间: 2007-7-2 18:36
thanks

作者: zyttony 时间: 2007-8-13 10:00
xiexie

作者: youth81 时间: 2007-8-29 13:42
标题: 回复 #1 Linda_123 的帖子
很不错啊
一直想看看恩sdlkfj2

作者: changlang530 时间: 2007-8-31 15:50
谢谢

作者: tgbangbang 时间: 2007-8-31 16:18
bu mingbai

作者: zhouzxcv 时间: 2007-9-19 11:57
sdlkfj1 3Q楼主

作者: ylylpp 时间: 2007-9-19 15:21
好东东，收下了

作者: zhyly101 时间: 2007-9-24 12:15
好，就是看不了，郁闷了。

作者: oumingzhu 时间: 2007-9-26 09:57
标题: FDASF
放大

作者: 1001 时间: 2007-9-27 21:19
标题: 回复 1# 的帖子
看一下

作者: labtime 时间: 2007-9-27 21:45
不错

作者: isn 时间: 2007-9-28 17:21
谢谢楼主啊！

作者: hairet 时间: 2007-10-8 17:48
学习中……支持下

作者: macco 时间: 2007-10-11 11:02
好东西！感谢楼主！

作者: macco 时间: 2007-10-11 11:16
感谢分享！

作者: oumingzhu 时间: 2007-10-24 11:21
标题: DDD
DDD

作者: elong602 时间: 2007-11-6 23:39
敏捷可理解为在以前软件开发方法基础上的整合，取其精华，去其糟粕，不断的去改善，而非创新。因此敏捷继承了不少以前方法的优势。是一种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的。个人看法，不断的check in,check out。希望大家踊跃的参与并谈论！！

作者: ruanyongjie 时间: 2008-8-22 08:43
下了,学习

作者: mianbaoshu 时间: 2008-9-8 23:39
还是感觉到很多问题现实中会更复杂，不好处理。

作者: wttoyou1221 时间: 2008-10-28 15:20

作者: guangyuchong 时间: 2008-10-31 15:05
支持分享

作者: 红尾鱼鱼 时间: 2008-12-17 17:30
谢谢楼主，抱走了！！

作者: 千纸鹤 时间: 2009-5-26 17:45
可能我们部门处于一个半尴尬的境地，项目初始采用瀑布，但是由于工期限制，左后改成敏捷了，所说缩短了工期，其实潜在的隐患和风险还是挺多的

作者: 随风飘 时间: 2009-6-16 13:54
在实施Scrum的时候还是会遇到很多意料之外的事情发生的，比如楼主说的在开发过程中遇到改需求的问题，在测试过程中遇到不全部按照case走流程的问题，所以大的项目持续半年以上的项目不建议使用Agile管理模式，且每个Scrum团队最好不超过9个人～～～每天早上的stand up meeting如果用心还是能学到很多的～～不是催命作业～～现在我们Scrum的时间定为5小时，因为还有3小时必定做了其他的事情，所以从现实出发修改我们的estimated hours.

作者: Juix 时间: 2009-7-14 15:24
谢谢，目前正准备在公司参考敏捷开发的思想来进行项目管理方面的改革，正好学习下。

作者: moving1000 时间: 2009-7-23 10:51

作者: woza 时间: 2009-7-31 22:10

原帖由 随风飘 于 2009-6-16 13:54 发表
在实施Scrum的时候还是会遇到很多意料之外的事情发生的，比如楼主说的在开发过程中遇到改需求的问题，在测试过程中遇到不全部按照case走流程的问题，所以大的项目持续半年以上的项目不建议使用Agile管理模式，且每个 ...

我们做scrum有2年了。产品开发一直没有停过。没觉得长期的项目用agile有什么问题。个人觉得常规的team，开发加QA，四人左右比较好。不过我们有一次做紧急任务，用Lean和scrum混合的开发模式，40个人一个team。结果做的非常开心。那个效果真是没得说。

作者: zhap 时间: 2009-10-15 17:18
感谢！

作者: cas 时间: 2009-11-26 14:24
嘿嘿，可以嘛

作者: xiaoxiao2009 时间: 2009-12-1 20:33
agile project management 学习了

作者: zuiwengoo 时间: 2009-12-21 16:04
学习学习，，，

作者: myfreecall 时间: 2010-4-27 15:30
先了解一下

作者: chbhaha 时间: 2010-11-9 09:42
介绍的不错。

作者: JOBSDB_joyce 时间: 2010-11-25 15:13

看看先

作者: ling11 时间: 2011-1-14 16:02
不知道楼主中所提到测试人员所做的测试，是针对story的测试还是本次迭代开发完后转交给测试人员的额SDV测试呢？在我们公司的项目中，测试人员比较少，只是针对基本的功能进行测试的。

作者: 秋爽 时间: 2012-2-20 20:11
听说很有用要好好学才是谢谢了

作者: dsc_vida 时间: 2012-6-5 09:16
支持~谢谢~

作者: pulingwang 时间: 2012-9-27 14:16
对于敏捷开发模式，我也有实践过。
说说其中的难点，就是得到领导的支持。敏捷开发，需要独立的空间。这样团队的工作效率不会受到很多干扰。和别的部门分开了，领导会有很多猜忌，感觉敏捷团队是小山头。
敏捷开发中，测试的价值又体现在哪里？每个项目的流程不长，就2周。实际上测试3天就可以全部结束了。一周半的时间，测试人员的工作又如何安排。在第一周如果能把单元测试做了，那确实很好。到了第二周准备用例和测试，版本展示，也会有好的效果。

作者: pulingwang 时间: 2012-9-27 14:19
敏捷开发的结对编程。我不知道大家有没有实践过。这个流程要开展，和团队的氛围有很大关系。如果大家都相互嘲笑，互相不服气，那放在一起结对，真的很可怕。

还好我们团队的结对编程，是开发经理和自己的徒弟结对编程，所以很和谐。
我也和开发经理结对编程，其实就是让他指导我怎么做一部分开发工作。

作者: pulingwang 时间: 2012-9-27 14:23
回复 1# Linda_123

计划的制定，确实实践要相对宽松些。因为需要保证能够全部完成。否则scrum 就算失败。
楼主罗列了实践中的很多的问题，对于开发团队和客户的交流这块，我们也学习了。

作者: pulingwang 时间: 2012-9-27 15:58
说说敏捷测试的那些事情
敏捷测试的沟通—欢迎你随时沟通
1 和团队成员沟通
传统的开发模式是以个人为主导完成一件工作的。敏捷开发也是。但是当遇到问题的时候，他们的响应就不相同。传统模式一般采用的沟通方式是指导。指导意味着服从，意味着权威。如果不服从领导，那后果可能会有点~~
敏捷开发对提倡求助必须得到响应的，所以你可以毫无障碍的求助，或者采用结对编程的模式，请求另一个人给你一些意见。他们可能是你认可的成员，和你测试着相同的产品，这种经验的分享是很珍贵的。没有压力，聚焦你的工作提升。
2 和领导沟通。其次，关于阶段工作目标，你可以喝你的领导坐下来商谈。借助敏捷开发的需求记录版和工作量估计模版，听听他的意见，同时拿出自己的工作量预计，让你们更清楚自己在做什么。
3 和组内测试成员沟通。分享用例和测试的经验。类似于结对测试。
在这种方式中，你可以修改他的用例，也可以和她一起测试，说说你的测试思路。不久她就知道该怎么做了—她会从中得到启发。
从沟通中，你明确了下个版本的任务安排，增进了对于开发版本互相了解的机会，同时和成员分享了你的测试经验，也学到他们的。你会喜欢这个团队的。

项目的计划和进度---大家来决定，大家来实现
4 敏捷开发的工作安排与跟踪
工作安排也是员工自己争取的，这会提高他们的积极性。
站会中每个成员会说明自己的进度以及问题，你会了解并且及时响应求助。成员会感到自己的独立性，你也不会因为自己疏忽或者成员忘记告诉你而遗漏了什么。
你不需要安排，你卸下了对组内成员的估计，他们也能找到自己喜欢的工作。这在采取一人分配工作的时候，是不能实现双赢的。~ 或许几个成员有意见，但是他们理智的想了想，还是决定不告诉你了。

5 共同分享经验，共同享受劳动成果。
项目结束后，大家会分享劳动经验。还会说出自己感谢的人。
这是个开心的话题，我们会注重改进，并且享受着别人的感谢。我很激动。
劳动成果是大家的，两周的成果，会安慰不少吧

敏捷开发的模式之测试—学的更快，工作节奏要快
1 你可以做什么？测试的角色稍微有点变化。承担项目质量的是开发和测试。你的角色是对产品提出自己的见解，帮助实现稳定版本的目标。测试的价值体现：你完全可以再项目需求中，设计思路时，甚至开发的初期测试时，提出自己的意见。他们会感谢你的，而不是排斥你。当然，你还有时间，有可能拿着开发的代码，告诉他们你需要帮助，然后你学会了做白盒测试。这种挑战是你需要迎接的。
2 你需要注意什么？
测试的开始点，测试策略。
测试的开始点永远需要你去揣摩。及时和开发沟通，只要有一个模型，就可以开始测试。
测试策略。你是采取探索测试+用例后补，还是采取粗粒度的用例测试，这取决于你。当然，保证交付的产品质量是目的。

作者: 青海论坛阿A 时间: 2013-12-11 13:55
非常谢谢楼主，顶一下

作者: 13718414026 时间: 2014-6-13 11:06
赞一个！

作者: 云永悦 时间: 2016-4-8 15:23
我们之前项目也是这样做的，但感觉人员技术有限有，作起来不但混乱，而且代码共享后造成某些功能直接阻塞

作者: 妖妖_scropio 时间: 2017-1-11 22:11
谢谢啦

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)