敏捷测试实践 3 - 制定计划
这个话题事实上已经超出了测试本身的范围，姑且沿用这个标题。目前我们采用的计划方法是，先计划一个发布周期所需要的完成的用户故事。这个周期一般是6周。Product Owner们先把所有希望并有能力在这个周期里面完成的故事放出来。这些故事都是预先由工程师们估算过的。然后把所有的故事按照优先级排序。最后按照每个团队70%-80%的工作量计算出保证能够完成的故事。这些就是这个发布周期之中，肯定能够完成的功能。然后把其他故事放到任务池中。一旦团队的开发进度超过预期，那么团队可以从任务池中选取计划外的任务来做。
在总的开发范围约定之后，每个团队自己来安排单个迭代周期中的任务计划。我们通常把2周作为一个迭代周期。团队可以按照优先级自由选择喜欢的任务。一旦任务选择完毕，那就意味着，团队做出了肯定能够按期保质完成的承诺。
以下是我非常喜欢敏捷的若干理由：
迭代周期是定死的，可以少做，不能延期。
如果团队对于任务需求不清楚，可以不接受这个任务。只要有一个团队成员不明白要做什么，那计划就不算完成。
工作量的预估由工程师们独立完成。包括开发和测试工程师。其他任何人，包括管理人员，只能旁听不能参与。
预估工作量的时候，已经包括开发和测试的时间。所以不存在测试时间不够的问题。
质量是整个团队的承诺，不是测试人员的个人任务。只要故事没有达到验收标准，就不算完成。（我们现在开发帮助做测试是常有的事情） 貌似要架空管理，由工程师自行分析定义给他们更大的空间和时间，甚至是权利。我在想，敏捷团队里的开发和测试工程师的各种能力都要比较强，尤其是分析和总结能力，更加考验了开发和测试工程师的综合能力，我觉得个人工作量也会相应的有所提高吧。 简单讲不能算是架空管理，而且减少沟通层级。目前的情况是，管理层花了很多时间替工程师做决定，事实上效果并不好。所以管理层应该把决定权下放，自己去做管理者应该做的事情。
敏捷团队中有几个高手的确效果会比较好。我想任何一个公司，总有几个能力强的人物吧。即便缺少牛人，也不是什么大问题。不管团队成员水平如何，总能最大限度发挥他们的能力才是这个模型的优点。
我不是很明白ls工作量提高是什么意思。如果是指花时间做计划的话，那这些工作量的增加其实微乎其微。对于一个月的迭代周期来说，花半天做计划不算多吧。而且，这些工作量也是在8小时工作时间以内的。
页:
[1]
