|
这个话题事实上已经超出了测试本身的范围,姑且沿用这个标题。
目前我们采用的计划方法是,先计划一个发布周期所需要的完成的用户故事。这个周期一般是6周。Product Owner们先把所有希望并有能力在这个周期里面完成的故事放出来。这些故事都是预先由工程师们估算过的。然后把所有的故事按照优先级排序。最后按照每个团队70%-80%的工作量计算出保证能够完成的故事。这些就是这个发布周期之中,肯定能够完成的功能。然后把其他故事放到任务池中。一旦团队的开发进度超过预期,那么团队可以从任务池中选取计划外的任务来做。
在总的开发范围约定之后,每个团队自己来安排单个迭代周期中的任务计划。我们通常把2周作为一个迭代周期。团队可以按照优先级自由选择喜欢的任务。一旦任务选择完毕,那就意味着,团队做出了肯定能够按期保质完成的承诺。
以下是我非常喜欢敏捷的若干理由:
迭代周期是定死的,可以少做,不能延期。
如果团队对于任务需求不清楚,可以不接受这个任务。只要有一个团队成员不明白要做什么,那计划就不算完成。
工作量的预估由工程师们独立完成。包括开发和测试工程师。其他任何人,包括管理人员,只能旁听不能参与。
预估工作量的时候,已经包括开发和测试的时间。所以不存在测试时间不够的问题。
质量是整个团队的承诺,不是测试人员的个人任务。只要故事没有达到验收标准,就不算完成。(我们现在开发帮助做测试是常有的事情) |
|