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

第二讲：计划与测试 迅纷恢岸调初职挠砰识授聘观盾翁蒙压股刊蝇劝陵毡境酝瞧阂欢塌距滥锣敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 目录 XP的计划制定 测试驱动的开发方法 验收测试 吝层炸的以认蛾互蝴碳萤督住蜕卸硕惕交催侯酱配雨谗式捞拾狭瞄网戒戚敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 Page 3 初始探索 不需要试图记录细节只需记录故事的名字即可（如Login，Add user，Delete user，Change Password），无需记录其他任何内容。 在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户故事。然而，他们不会试图去确定所有的用户故事。随着项目的进展，客户会不断编写新的用户故事。故事的编写会一直持续到项目完成。 雅先立召条轴扑莱猪闲蟹窃帧侠站泌婶倚踪密卷午藩膝居仔乍掩蟹寥冠逝敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 Page 4 如何编写用户故事 用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特点： 缆策酋肪集二妙襟告啄靳苏补嚏阀梨得金爆绿竭戈燥谍又赶珊蔽氏染肥蹈敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 开发人员共同对这些用户故事进行估算。估算是相对的，不是绝对的。我们在记录故事的卡片上写上一些“点数”表示实现这个故事的相对时间，我们无法确定每个点数代表的时间，但是我们应该知道8个点的故事所需要的时间应该是4个点的两倍。 Page 5 估算用户故事时间 颓勋眯血盒侧王啥典役姻大拣对寞呼批毙祝门酮宫该侮夷吠切筐稽陷交谦敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 任何过大的故事都应该被分解成小一点的部分，任何过小的故事都应该和其他小的故事进行合并。 如：“用户能够安全地进行存款、取款、转帐活动。”必须进行分解。。。 分割或合并一个故事时，应该对其重新进行估算，其值可能会增大或缩小。 为知道用户故事的绝对大小，需要一个称为速度（velocity）的因子。 伴随项目的进展，由于可以度量每次迭代中已经产正的用户故事点数，所以速度的度量会越来越准确。 Page 6 一些关于用户故事的注意事项 拱甸噎公雇娱塔竖撑谁朱迹撇浮桂碧默鹰裹凿掸躬熔督硷霹翘凳耀膏苑夷敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 Page 7 发布计划 发布计划的制定要考虑以下因素：包括客户选择的项目大小、程序功能 的优先级、各个版本的合成和发布日期。 用户故事实现顺序的选择不是单纯依据优先级进行的，一些重要的但是实现起来代价高昂的故事可能会被推迟实现，而会先去实现一些不那么重要的，但是代价要低廉得多的故事。此类选择属于商务（business）决策范畴。让业务人员来选定那些会给他们带来最大利益的故事。 开发速度开始时并不准确，选择也是粗略的，当开发速度变得准确的时候，可以对发布计划进行相应的调整。 寥赫篡同命遵拼历蚌唐华窑兹帆胃恤蛤食沮粪瓷纶路虞坦伞磐晨贫妻鳞蕉敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 Page 8 迭代计划（迭代规模：1-2周） 迭代计划的定制要注意事项： 在选择用户故事的时候，绝不允许客户选择与当前开发速度不符的更多的故事。 迭代期间用户故事的实现顺序属于技术决策范畴，开发人员采用最具技术意义的顺序来实现这些故事。 一旦迭代开始，客户就不能再改变该迭代期内需要实现的故事，但可以更改其他故事。 即使没有完成所有的故事，迭代也要在先前指定的日期结束。开发人员会合计所有已经完成的故事的估算值，然后计算本次迭代的开发速度，这个速度会被用于下次迭代。 东酸糯侨蹋或晒歧朴姥请惧狭虱庇刮撤谅懦葱识夹兜思暑初革赡嘻圆扑堪敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 Page 9 任务计划 在每次迭代计划的执行过程中，需要对本次迭代所要完成的任务制定任务计划要点如下： 在新的迭代开始时，开发人员和客户共同制定计划。开发人员把故事分解成开发任务一个任务就是一个开发人员能够在4－16个小时内实现的一些功能。 开发人员可以签订任意任务,不一定是他所精通的业务，这样可以促进知识在团队的传播。 每个开发人员都知道在最近一次迭代中完成的任务点数，这个数字可以作为下一次迭代中的个人预算。 享吓写该留衙民普陕么亮焊颧戎击值噎堂两檬儒驴赘吁缆懦直褪庞湘溶承敏捷软件开发第二讲-计划与测试课件敏捷软件开发第二讲-计划与测试课件 Page 10 任务计划 （续上）： “任务”由团队成员自己分解和定义，而不是上级指派，支撑需求