敏捷过程实践[经验分享]

xiaoxiao2009

agile project management 学习了

zuiwengoo

学习学习，，，

myfreecall

先了解一下

chbhaha

介绍的不错。

JOBSDB_joyce

看看先

ling11

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

秋爽

听说很有用  要好好学才是  谢谢了

dsc_vida

支持~谢谢~

pulingwang

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

pulingwang

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

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

pulingwang

回复 1# Linda_123


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

pulingwang

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

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

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

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

青海论坛阿A

非常谢谢楼主，顶一下

13718414026

赞一个！

云永悦

我们之前项目也是这样做的，但感觉人员技术有限有，作起来不但混乱，而且代码共享后造成某些功能直接阻塞

妖妖_scropio

谢谢啦