51Testing软件测试论坛

标题: 敏捷测试实践 3 - 制定计划 [打印本页]

作者: woza    时间: 2009-6-28 11:38
标题: 敏捷测试实践 3 - 制定计划
这个话题事实上已经超出了测试本身的范围,姑且沿用这个标题。

目前我们采用的计划方法是,先计划一个发布周期所需要的完成的用户故事。这个周期一般是6周。Product Owner们先把所有希望并有能力在这个周期里面完成的故事放出来。这些故事都是预先由工程师们估算过的。然后把所有的故事按照优先级排序。最后按照每个团队70%-80%的工作量计算出保证能够完成的故事。这些就是这个发布周期之中,肯定能够完成的功能。然后把其他故事放到任务池中。一旦团队的开发进度超过预期,那么团队可以从任务池中选取计划外的任务来做。

在总的开发范围约定之后,每个团队自己来安排单个迭代周期中的任务计划。我们通常把2周作为一个迭代周期。团队可以按照优先级自由选择喜欢的任务。一旦任务选择完毕,那就意味着,团队做出了肯定能够按期保质完成的承诺。

以下是我非常喜欢敏捷的若干理由:

迭代周期是定死的,可以少做,不能延期。

如果团队对于任务需求不清楚,可以不接受这个任务。只要有一个团队成员不明白要做什么,那计划就不算完成。

工作量的预估由工程师们独立完成。包括开发和测试工程师。其他任何人,包括管理人员,只能旁听不能参与。

预估工作量的时候,已经包括开发和测试的时间。所以不存在测试时间不够的问题。

质量是整个团队的承诺,不是测试人员的个人任务。只要故事没有达到验收标准,就不算完成。(我们现在开发帮助做测试是常有的事情)
作者: EVA1987    时间: 2009-6-28 16:39
貌似要架空管理,由工程师自行分析定义给他们更大的空间和时间,甚至是权利。我在想,敏捷团队里的开发和测试工程师的各种能力都要比较强,尤其是分析和总结能力,更加考验了开发和测试工程师的综合能力,我觉得个人工作量也会相应的有所提高吧。
作者: woza    时间: 2009-6-28 16:57
简单讲不能算是架空管理,而且减少沟通层级。目前的情况是,管理层花了很多时间替工程师做决定,事实上效果并不好。所以管理层应该把决定权下放,自己去做管理者应该做的事情。

敏捷团队中有几个高手的确效果会比较好。我想任何一个公司,总有几个能力强的人物吧。即便缺少牛人,也不是什么大问题。不管团队成员水平如何,总能最大限度发挥他们的能力才是这个模型的优点。

我不是很明白ls工作量提高是什么意思。如果是指花时间做计划的话,那这些工作量的增加其实微乎其微。对于一个月的迭代周期来说,花半天做计划不算多吧。而且,这些工作量也是在8小时工作时间以内的。




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2