未来的日子里面小编会为大家专门讲解 敏捷软件开发的原则、模式和实践，希望可以对正在进行敏捷和打算转型的读者们有所帮助~
今天，我们的内容是极限编程（XP）中计划游戏部分的初始探索小节。它和其他的敏捷方法和自适应软件开发ADP中做计划的方式相似。不过其他的方法都没有极限编程对此面熟的详细、精确。好啦，我们正式开始~
初始探索
在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户素材。随着项目的进展，客户会不断编写新的用户素材。素材的编写会一直持续到项目完成。
开发人员共同对这些素材进行估算。估算是相对的，不是绝对的。
我们在记录素材的卡片上写上一些“点数”来表示实现这个素材所需要的相对时间。我们可能不能确定一个“点”代表多少时间，但是我们知道实现8个点的素材所需要的时间是实现4个点的两倍。
探究、分解和速度
过大或者过小的素材都是难以估算的。
开发人员往往会低估那些大的素材而高估那些小的素材。任何过大的素材都应该被分解成效一点的部分，任何过小素材都应该和其他小的素材合并。
来来来 举个栗子~
我这里有这样一个素材：“用户能够安全地进行存款、取款、转账活动”。这是一个大的素材。对它进行估算将会很困难，有可能还不准确。然而，我们可以把它分解成以下几个更容易估算的素材。
①用户可以登录
②用户可以退出
③用户可以向其他账户存款
④用户可以从其账户取款
⑤用户可以从其账户向其他账户转账
当分割或合并一个素材时，应该对其中心进行估算。简单地加上或者减去估算值是不明智的。对一个用户素材进行分解或者合并的主要原因，是为了使其大小适于被准确地估算。
当一个估算为5点素材被分解为几个点数总和达到10点的素材时，没什么令人惊讶的！
随着项目的进展，由于可以度量每次迭代中已经完成的用户素材点数，所以对于速度的度量会越来越准确。在开始时，开发人员可能对他们的速度没有很好的认识。开发人员必须要创建一个出事的猜测值，在创建这个猜测值时，可以采用他们感觉会带来最好结果的任何方式进行。此时对于准确性的需要不是非常迫切，所以他们无需在这个上面花费过多的时间。通常，花费几天时间去原型化一到两个用户素材来了解团队的速度就足够了。
这样的一个原型化过程成为探究（Spike）。
当你能够度量你所说的，并且能够用数字去表达它时，就表示你了解了它；若你不能度量它，不能用数字去表达它，那么说明你的知识就是匮乏的、不能令人满意的。——凯尔文勋爵（英国物理学家），1883
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！