我所在团队应用的一些方法，希望大家能提意见和建议

[Rex Yan]

首先我们的团队主要针对某个项目的功能模块进行开发，有大体的功能描述，担不是具体需求分析。

1.团队内部会议讨论需求，确定子模块
2.邀请测试部门共同研究需求分析结果
3.review需求分析
====================完成一次迭代=====================
4.确定work list，并根据团队成员擅长来分配任务
5.每两天一次总结会议，包括项目进度，和技术分享，没有早会
====================完成一次开发迭代==================
6.代码review
7.提交测试
8.debug
====================测试============================
中间遇到的问题是关于文档的缺失，在和测试研究需求的过程中没有一份确定的文档，只是口头声明，在开始测试时有可能已经忘记了某些约定，引起开发与测试
之间的矛盾。

希望大家给提提建议和意见，谢谢！

[徐毅]

在08-4-10，Rex Yan <progra...@gmail.com> 写道：

- 测试是什么测试？
- 测试有无实现自动化？
- review需求分析之后你的输出是什么，不是文档吗？
- 看来测试人员也有加入到需求的分析过程中（在和测试研究需求的过程中），对么？那review需求的时候呢，有测试人员吗？

--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Mater
Blog : http://damianji.spaces.live.com
- - - - - - - - - -

[陈之过]

首先看你方法,应该是想走敏捷的尝试
存在的最大的问题应该是迭代和测试分离

在08-4-10，Rex Yan <progra...@gmail.com> 写道：

首先我们的团队主要针对某个项目的功能模块进行开发，有大体的功能描述，担不是具体需求分析。

[Wang Lijie]

乍一看，觉得缺少 Design Review，这个做好了可以大幅缩减code review + debug的时间

在08-4-10，陈之过 <chenzh...@gmail.com> 写道：

[li xian feng]

首先你所说的是项目开发的阶段而不是一次完整迭代。
文档的缺失估计是人力+时间不足的问题，无论如何都因该确定关键点文档。对于其他的可以在代码注释中做说明。
【2.邀请测试部门共同研究需求分析结果】的做法很好，但是我觉得可能还是不足以让测试部完整了解系统。

在08-4-10，Rex Yan <progra...@gmail.com> 写道：

首先我们的团队主要针对某个项目的功能模块进行开发，有大体的功能描述，担不是具体需求分析。

[Jun Liu]

那在2的过程中应该形成书面的acceptance test case。

2008/4/10 Rex Yan <progra...@gmail.com>:

[Bruce Zhang]

我有几个问题：
1、迭代周期有多长？
2、迭代结束后，是否交付了可运行的版本？
3、讨论需求时，客户方代表或者领域专家、Product Owner在哪里？
4、两天一次会议，那么会议讨论的内容是什么？
5、为什么测试放在迭代之外呢？
6、需求到编码之间的设计呢？

提到文档问题，既然在需求讨论阶段就引入了测试人员，那么形成的需求列表，不管是用例、用户故事或者backlog，乃至于功能特征，为什么没有书面的东西呢？而且这些内容就应该是测试用例的输入工件啊？

在08-4-10，Jun Liu <junl...@gmail.com> 写道：

--
捷道·敏捷堂：http://www.agiledon.com

[Rex Yan]

我觉得我们现在面临的主要问题在于开发与测试之间关于需求的冲突问题，能否依靠敏捷的方法解决这一问题？

On 4月10日, 下午9时42分, "Bruce Zhang" <bruce.e.zh...@gmail.com> wrote:
> 我有几个问题：
> 1、迭代周期有多长？
> 2、迭代结束后，是否交付了可运行的版本？
> 3、讨论需求时，客户方代表或者领域专家、Product Owner在哪里？
> 4、两天一次会议，那么会议讨论的内容是什么？
> 5、为什么测试放在迭代之外呢？
> 6、需求到编码之间的设计呢？
>

> 提到文档问题，既然在需求讨论阶段就引入了测试人员，那么形成的需求列表，不管是用例、用户故事或者backlog，乃至于功能特征，为什么没有书面的东西呢？-而且这些内容就应该是测试用例的输入工件啊？
>
> 在08-4-10，Jun Liu <junli...@gmail.com> 写道：
>
>
>
>
>
>
>
> > 那在2的过程中应该形成书面的acceptance test case。
>
> > 2008/4/10 Rex Yan <programer...@gmail.com>:

>
> > > 首先我们的团队主要针对某个项目的功能模块进行开发，有大体的功能描述，担不是具体需求分析。
>
> > > 1.团队内部会议讨论需求，确定子模块
> > > 2.邀请测试部门共同研究需求分析结果
> > > 3.review需求分析
> > > ====================完成一次迭代=====================
> > > 4.确定work list，并根据团队成员擅长来分配任务
> > > 5.每两天一次总结会议，包括项目进度，和技术分享，没有早会
> > > ====================完成一次开发迭代==================
> > > 6.代码review
> > > 7.提交测试
> > > 8.debug
> > > ====================测试============================
> > > 中间遇到的问题是关于文档的缺失，在和测试研究需求的过程中没有一份确定的文档，只是口头声明，在开始测试时有可能已经忘记了某些约定，引起开发与测试
> > > 之间的矛盾。
>
> --

> 捷道·敏捷堂：http://www.agiledon.com- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[徐毅]

在08-4-11，Rex Yan <progra...@gmail.com> 写道：

我觉得我们现在面临的主要问题在于开发与测试之间关于需求的冲突问题，能否依靠敏捷的方法解决这一问题？

什么样的冲突？

[Rex Yan]

主要在于对于需求的理解不同，缺乏测试开发之间的沟通，是否需要一个中间人来协调，或者定义确定的对需求的理解。
谢谢！

On 4月11日, 上午10时37分, "徐毅" <kaverj...@gmail.com> wrote:
> 在08-4-11，Rex Yan <programer...@gmail.com> 写道：

[Jun Liu]

你们在团队内外部是否已经划分了一些角色？

2008/4/11 Rex Yan <progra...@gmail.com>:

[Wang Lijie]

你都指出了问题所在，"在于对于需求的理解不同，缺乏测试开发之间的沟通"。

解决方法很简单，把大家叫到一起来，沟通沟通在沟通！

在08-4-11，Rex Yan <progra...@gmail.com> 写道：

主要在于对于需求的理解不同，缺乏测试开发之间的沟通，是否需要一个中间人来协调，或者定义确定的对需求的理解。

[徐毅]

我的看法：
1. 需求的理解是否正确，不是由开发或者测试来说了算的，谁呢？客户。
2. 解决纠纷，比较常见的选择是找个higher level的manager或者有声望的外部人员，等等，不过具体情况具体分析，需要你自己多思量才行。
3. 需求确认后，形成正式文档，作为测试的标准。

在08-4-11，Rex Yan <progra...@gmail.com> 写道：

主要在于对于需求的理解不同，缺乏测试开发之间的沟通，是否需要一个中间人来协调，或者定义确定的对需求的理解。

[Jun Liu]

Yes. 所以我问他是否有一些角色划分。如果已经有Product owner，那么由他来判断。开发和测试人员之间的争执不能反映真正的用户需求。另外角色存在的必要性，是因为如果人人都能负责，那么意味着没人负责。

2008/4/11 徐毅 <kave...@gmail.com>:

[徐毅]

在08-4-11，Jun Liu <junl...@gmail.com> 写道：

Yes. 所以我问他是否有一些角色划分。如果已经有Product owner，那么由他来判断。开发和测试人员之间的争执不能反映真正的用户需求。另外角色存在的必要性，是因为如果人人都能负责，那么意味着没人负责。

他们不见得使用的是敏捷方式，也就不见得有PO，但总之是需要有如此角色的一个人来担当这样的职责。

因为似乎楼主没有回复每个人的信件，所以我会把一些大家提过的意见再提一遍，确保他不会漏掉，非有意冒犯，sorry ：-（

[Rex Yan]

感谢大家的意见，我觉得我应该首先确定需求，确定的文档
其次是更多的沟通，看来通往敏捷的道路还需要更多大家的帮助啊！
谢谢大家！

On 4月11日, 上午11时08分, "徐毅" <kaverj...@gmail.com> wrote:
> 在08-4-11，Jun Liu <junli...@gmail.com> 写道：

[徐毅]

在08-4-11，Rex Yan <progra...@gmail.com> 写道：

感谢大家的意见，我觉得我应该首先确定需求，确定的文档
其次是更多的沟通，看来通往敏捷的道路还需要更多大家的帮助啊！
谢谢大家！

我想，"沟通"相比而言应该是你们首要解决的问题。你们先确定一个大家（开发，测试，可能还有其他人）都认同的工作方式，或者说流程，然后按照这个流程做，就可以了。大胆的猜测，开发和测试对需求的理解不同，很有可能就是因为没有一个机制要求他们要沟通，要达成一致。不知道我是否说对了，呵呵。