所谓的敏捷开发

红宝石

一个突如其来的项目完全颠覆了我身为QA根据项目计划去跟踪项目过程、审计项目成果的思路。。。
项目特点：以产品的形式开发，后期推广（公司有类似的项目，基本上算是改造）
工期：时间紧迫
现状：没有详细的Project项目计划，任务被分割并以便签的形式张贴在白板上，白板划分了很多区域：已分配、已完成、未完成、待验证、已验证等等
QA的苦恼：1.针对未完成（延期）的任务，或一延再延的任务，我无从监控。每次去白板区，看到未完成区域的便签，不晓得有些任务是被延了几次了，也不晓得要延到何时；
2.因为赶工期，需求和开发同步进行，有专职的需求工程师针对旧项目进行需求整理，不清楚是项目组不适应这种没有需求就开发的模式还是大家很喜欢这种天马行空的感觉，反正感觉需求和开发总是不对路子。

诶。。。
大家公司的敏捷开发模式大致是啥样的啊？

myfreecall

也在纠结中......

小幸福

这是现在企业中的常见问题啊；

时间紧迫，大家都喜欢敏捷，但是 项目组的成员的能力、资历、环境是否适合敏捷？

建议楼主可以根据项目的实际情况 裁减一下，看哪些关键过程是必须做的。

红宝石

还是感觉没有计划的项目实在是乱啊，无论采用什么开发模型；
敏捷开发对项目经理的项目掌控能力提出了更高的要求。。。

liangshi

我个人猜测，你们项目组的内部交流不好。你似乎不太了解开发的进度，不太了解有需求工程师提供的需求；开发不太在乎QA的需要；也没有人在整体上梳理工作项的优先级、依赖关系、实现顺序。

似乎，引入敏捷的一些实践打破了原有的开发流程，引入了混乱但是没有带来效率的提升。

我的建议是要加强交流与沟通。（1）你需要与开发面谈，了解他们的当前工作，他们的打算。（2）你需要与需求工程师密切合作，不掌握需求很难把握项目的质量。（3）你要找项目负责人或开发经理面谈，坦诚你的忧虑或困扰。他应该担任或找出一个人来做“执行经理”。执行经理应该梳理工作项，排定优先级，每日同步工作进度，每周检查项目进度。从某种角度，他是交流的核心。

8596991

记得微软的敏捷开发：communication，simple，courage，贯穿这个项目过程

47385024

不清楚你们采用的是哪种敏捷，采用敏捷并不代表没有计划。

我们公司采用的是Agile + Scrum模式，每个Sprint的任务划分的比较明确，项目经理会全力保证每个Sprint都严格按照计划进行。即使出现变更，项目经理也会尽可能的与客户沟通，将变更放到下一个Sprint中，而不影响当前Sprint的进行。每个Sprint结束后都要让客户对当前Sprint的工作成果进行验收。客户认可后，项目进入到下一个Sprint。每个Sprint结束后，项目组成员必须保证在当前的Sprint中的BUG被修复并关闭。如果出现在当前Sprint中暂时无法解决的BUG，需要与客户沟通，将BUG放入后面的Sprint中去解决。至于整体项目进度，可以尝试一下用燃尽图进行简单的把控。

采用敏捷开发后，文档相对来说会少很多，但并不是没有。比如每个Sprint中的user story都是非常明确的，并且是文档形式经过客户确认的（需求确认）。测试人员可以根据user story去编写测试用例。而客户进行sprint验收的时候，基本也是按照user story进行验收。一定要和客户保持良好的沟通，不然你做的东西客户不认可就是个大问题了，而且一定要留下客户确认后的证据。

至于项目监控，每日10分钟左右的例会是必不可少的。在例会上，项目组成员会干脆的说出当前工作的进度以及遇到的问题。项目经理会根据实际情况作出相应的调整。让每个项目组成员都明确自己今天的任务是什么，该在什么时候提交。
至于测试。。。我们是这样的：每个Sprint开始的时候，项目组所有成员都坐在一起，对新的user story一起讨论研究，直至整个项目组成员（开发人员+测试人员）对需求的理解全部达成一致（概要设计评审）。我们通常会将每个Sprint中的user story分解成task，形成WBS任务列表（简洁的计划），并在项目管理工具中给相关的开发人员分配相应的时间和任务。这是需要相关人员对所分配的任务进行确认和承诺的。在估算task的时候，一定要把相应的风险考虑进去。当然，作为项目经理是一定会这么做的。

然后开发人员开始编码，测试人员进行测试用例的编写。每当开发人员发布新的版本的时候，开发人员会在SVN上记录当前完成了哪些功能，对哪些BUG进行了修改。然后测试人员会根据记录的信息与开发人员确认后，选择与完成的user story对应的测试用例进行测试。当测试人员发现第一个BUG的时候，就马上通知相关的开发人员并记录BUG。当测试人员完成测试后，马上给项目经理发送一个测试summary，汇报当前项目的健康状况。

在每个Sprint开发期间，测试人员是需要反复迭代的进行测试，大部分的时间是用在了回归测试上。所以需要引入自动化测试工具来节省项目时间。很多的时候测试人员可能同时对应好几个项目（至少我们公司是这样的），可以白天做手工测试，晚上进行自动化测试（根据用例或BUG来录制自动化测试脚本）。第二天早上的时候根据测试报告就可以得到测试结论了。

我们回过头来谈谈你说的问题。

1：针对未完成（延期）的任务，或一延再延的任务，我无从监控。每次去白板区，看到未完成区域的便签，不晓得有些任务是被延了几次了，也不晓得要延到何时；

在敏捷开发中，QA的工作的确会很少。但是QA很多的工作是需要靠自己来发掘的。比如像你说的，想跟踪项目的进度。没问题。我看了你说的情况，可以在第一次分配任务的时候把白板上的内容照下来作为记录。然后整理一下将照片和整理后的结果通过邮件的形式发送给项目组的每一个成员，至于是表格形式的还是什么形式的，怎么进行跟踪，看你自己的喜好。总之，QA在工作中一定要主动。因为QA本身就是项目组的成员之一，一定要和项目组保持良好的沟通。


2.因为赶工期，需求和开发同步进行，有专职的需求工程师针对旧项目进行需求整理，不清楚是项目组不适应这种没有需求就开发的模式还是大家很喜欢这种天马行空的感觉，反正感觉需求和开发总是不对路子。

这个情况在我们公司没遇到过，所以有什么好的建议。我们在进入Sprint工作时，对当前Sprint的任务是很明确的。即使出现变更，项目经理也会去直接和客户进行沟通，跟客户讲清楚在Sprint开始后增加或改变需求的风险和弊端。当然了，也不是所有的变更都不接受，中间的尺度需要把控好，不然很容易影响Sprint的进度。通常我们公司的项目经理会多估算一个或者半个Sprint来，对前几个Sprint残留的BUG进行大扫除。公司的几位项目经理都是经验非常丰富、非常牛的，在项目中从来没有遇到过迷茫的时候。即使有问题，项目经理也会很快的带领团队解决。

这些都是在项目中的体会，写的可能有些啰嗦、杂乱。呵呵  希望能帮到你。

[ 本帖最后由 47385024 于 2010-5-29 21:19 编辑 ]

彼岸渔歌

这位大哥，我是新手，无法联系您，有很多关于敏捷的东东想跟您请教啊：）
能不能联系下我QQ1454203380

junhong_006

2.因为赶工期，需求和开发同步进行，有专职的需求工程师针对旧项目进行需求整理，不清楚是项目组不适应这种没有需求就开发的模式还是大家很喜欢这种天马行空的感觉，反正感觉需求和开发总是不对路子。

个人觉得还是项目计划没做好，项目经理没把控住，做敏捷沟通和执行力很重要~一个经验丰富的项目经理更重要

依零99

学习中

huli_susey

受教了

ling11

刚刚接触敏捷方面的知识，跟的项目敏捷实施情况也不好，但是公司总有自己的流程体系，你按照公司的流程体系来就可以了，当然在工作中加强与项目组的交流，有时间的话参加他们的晨会，看下项目的任务状态，就会了解项目的进度情况了