敏捷软件开发第二讲-计划与测试

《敏捷软件开发第二讲-计划与测试》由会员分享，可在线阅读，更多相关《敏捷软件开发第二讲-计划与测试（30页珍藏版）》请在文档大全上搜索。

1、广州大学华软软件学院软件工程系主讲教师：谭翔纬答疑时间：周三 10:30-12:00 周四 9:00-12:00Tel：660028Email：第二讲：计划与测试目录目录nXP的计划制定的计划制定n测试驱动的开发方法测试驱动的开发方法n验收测试验收测试Page 3初始探索l不需要试图记录细节不需要试图记录细节-只需记录故事的名字即可（只需记录故事的名字即可（如如Login，Add user，Delete user，Change Password），），无需记录其他任何内容。无需记录其他任何内容。l在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户故事。然而，在项目开始时，开发人员和客户

2、会尽量确定出所有真正重要的用户故事。然而，他们不会试图去确定所有的用户故事。随着项目的进展，客户会不断编写新的用户故他们不会试图去确定所有的用户故事。随着项目的进展，客户会不断编写新的用户故事。故事的编写会一直持续到项目完成。事。故事的编写会一直持续到项目完成。Page 4如何编写用户故事 用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特点：p开发人员共同对这些用户故事进行估算。估算是相对的，不是绝对的。我们在记录故事的卡片上写上一些“点数”表示实现这个故事的相对时间，我们无法确定每个点数代表的时

3、间，但是我们应该知道8个点的故事所需要的时间应该是4个点的两倍。Page 5估算用户故事时间p任何过大的故事都应该被分解成小一点的部分，任何过小的故事都应该和其他小的故事进行合并。 如：如：“用户能够安全地进行存款、取款、转帐活动。用户能够安全地进行存款、取款、转帐活动。”必须进行分必须进行分解。解。p分割或合并一个故事时，应该对其重新进行估算，其值可能会增大或缩小。p为知道用户故事的绝对大小，需要一个称为速度（velocity）的因子。p 伴随项目的进展，由于可以度量每次迭代中已经产正的用户故事点数，所以速度的度量会越来越准确。Page 6一些关于用户故事的注意事项Page 7发布计划发布计

4、划的制定要考虑以下因素：包括客户选择的项目大小、程序功能包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期的优先级、各个版本的合成和发布日期。l用户故事实现顺序的选择不是单纯依据优先级进行的，一些重要的但是实现起来代价高昂的故事可能会被推迟实现，而会先去实现一些不那么重要的，但是代价要低廉得多的故事。此类选择属于商务（business）决策范畴。让业务人员来选定那些会给他们带来最大利益的故事。l 开发速度开始时并不准确，选择也是粗略的，当开发速度变得准确的时候，可以对发布计划进行相应的调整。Page 8迭代计划（迭代规模：1-2周）迭代计划的定制要注意事项：l在选择用户故事的时

5、候，绝不允许客户选择与当前开发速度不符的更多绝不允许客户选择与当前开发速度不符的更多的故事。的故事。l迭代期间用户故事的实现顺序属于技术决策范畴，开发人员采用最具技术意义的顺序来实现这些故事。l一旦迭代开始，客户就不能再改变该迭代期内需要实现的故事，但可以客户就不能再改变该迭代期内需要实现的故事，但可以更改其他故事。更改其他故事。l 即使没有完成所有的故事，迭代也要在先前指定的日期结束。即使没有完成所有的故事，迭代也要在先前指定的日期结束。开发人员会合计所有已经完成的故事的估算值，然后计算本次迭代的开发速度，这个速度会被用于下次迭代。Page 9任务计划 在每次迭代计划的执行过程中，需要对本次

6、迭代所要完成的任务制定任务计划要点如下：l在新的迭代开始时，开发人员和客户共同制定计划开发人员和客户共同制定计划。开发人员把故事分解成开发任务-一个任务就是一个开发人员能够在416个小时内实现的一些功能。l开发人员可以签订任意任务,不一定是他所精通的业务，这样可以促进知促进知识在团队的传播识在团队的传播。l每个开发人员都知道在最近一次迭代中完成的任务点数，这个数字可以作为下一次迭代中的个人预算。Page 10任务计划 （续上）：l“任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务；任务要落实到具体的责任人；l任务粒度要小，工作量大于两天的任务要进一步分解；用

7、小时做为任务剩余工作量的估计单位，并每日重估计和刷新。l任务的选择一直到所有的任务都被分配出去，或者所有的开发人员都已经用完了他们的预算时为止。l在迭代进行到一半（迭代中点）的时候，团队必须召开会议查看所完成的故事数量，应该是一半的故事都被完成，如果没有，那么团队应该设法重新分配没有完成的任务和职责，以保证在迭代结束时能够完成所有的素材。Page 11迭代l每次（每2周）迭代结束时，会给客户演示客户演示当前可运行的程序。客户将会根据他们看到的反馈新的用户素材。l客户可以经常看到项目的进展，度量开发速度，按照他们自己的意愿去管理项目。Page 12跟踪l对于XP项目来说，跟踪和管理就是纪录每次迭

8、代的结果，然后使用这些结果预测后面几次迭代的内容。l速度图：每周结束时，一共完成了多少故事点。Page 13跟踪l余量图（燃尽图）：每一周过后，还有多少点数需要在下一个主要里程碑或者发布中完成。Page 14测试驱动开发l测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。lKent Beck最早在其极限编程（XP）方法论中，向大家推荐“测试驱动”这一最佳实践，