计划 (资料).pptVIP

计划 When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind. 3.1 初始探索 在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户故事。然而，他们不会试图去确定所有的用户故事。随着项目的进展，客户会不断编写新的用户故事。故事的编写会一直持续到项目完成。 不会试图记录细节---只需记录故事的名字即可（如Login，Add user，Delete user，Change Password），无需记录其他任何内容。 开发人员共同对这些用户故事进行估算。估算是相对的，不是绝对的。我们在记录故事的卡片上写上一些“点数”表示实现这个故事的相对时间，我们无法确定每个点数代表的时间，但是我们知道8个点的故事所需要的时间应该是4个点的两倍。 3.1 初始探索（续） 任何过大的故事都应该被分解成小一点的部分，任何过小的故事都应该和其他小的故事进行合并。 如：“用户能够安全地进行存款、取款、转帐活动。”必须进行分解。。。 分割或合并一个故事时，应该对其重新进行估算，其值可能会增大或缩小。 为知道用户故事的绝对大小，需要一个称为速度（velocity）的因子。 伴随项目的进展，由于可以度量每次迭代中已经产正的用户故事点数，所以速度的度量会越来越准确。 3.2 发布计划 用户故事实现顺序的选择不是单纯依据优先级进行的，一些重要的但是实现起来代价高昂的故事可能会被推迟实现，而会先去实现一些不那么重要的，但是代价要低廉得多的故事。此类选择属于商务（business）决策范畴。让业务人员来选定那些会给他们带来最大利益的故事。 开发速度开始时并不准确，选择也是粗略的，当开发速度变得准确的时候，可以对发布计划进行相应的调整。 3.3 迭代计划（迭代规模：1-2周） 在选择用户故事的时候，绝不允许客户选择与当前开发速度不符的更多的故事。 迭代期间用户故事的实现顺序属于技术决策范畴，开发人员采用最具技术意义的顺序来实现这些故事。 一旦迭代开始，客户就不能再改变该迭代期内需要实现的故事，但可以更改其他故事。 即使没有完成所有的故事，迭代也要在先前指定的日期结束。开发人员会合计所有已经完成的故事的估算值，然后计算本次迭代的开发速度，这个速度会被用于下次迭代。 3.4 定义完成 除非所有的验收测试都通过，否则就不能说一个故事实现完了。 测试是每次迭代一开始就编写好的。 测试定义了每个故事的细节，并且是判断故事的行为方式正确与否的决定性依据。 3.5 任务计划 在新的迭代开始时，开发人员和客户共同制定计划。开发人员把故事分解成开发任务----一个任务就是一个开发人员能够在4－16个小时内实现的一些功能。 开发人员可以签订任意任务,不一定是他所精通的业务，这样可以促进知识在团队的传播。 每个开发人员都知道在最近一次迭代中完成的任务点数，这个数字可以作为下一次迭代中的个人预算。 3.5 任务计划（续） 任务的选择一直到所有的任务都被分配出去，或者所有的开发人员都已经用完了他们的预算时为止。 在迭代进行到一半（迭代中点）的时候，团队必须召开会议查看所完成的故事数量，应该是一半的故事都被完成，如果没有，那么团队应该设法重新分配没有完成的任务和职责，以保证在迭代结束时能够完成所有的素材。 3.6 迭代 每次（每2周）迭代结束时，会给客户演示客户演示当前可运行的程序。客户将会根据他们看到的反馈新的用户素材。 客户可以经常看到项目的进展，度量开发速度，按照他们自己的意愿去管理项目。 3.7 跟踪 对于XP项目来说，跟踪和管理就是纪录每次迭代的结果，然后使用这些结果预测后面几次迭代的内容。 速度图：每周结束时，一共完成了多少故事点。 3.7 跟踪 余量图（燃尽图）：每一周过后，还有多少点数需要在下一个主要里程碑或者发布中完成。 这2幅图是XP及所有敏捷方法的真正实质所在。 3.8 结论 通过一次次迭代和发布，项目进入了一种可以预测的、舒适的开发节奏。 使用敏捷方法并不意味着涉众就可以得到他们想要的。它不过意味着他们将能够控制着团队以最小的代价获得最大的商业价值。