《敏捷开发模型 .ppt

敏捷开发模型 敏捷是什么？ SCRUM 开发流程 用户故事 非敏捷 - 瀑布式开发 软件开发的经典模型 瀑布模型的主要缺陷： 程序的维护成本会越来越高（需要很多人） 团队氛围压抑（感受不到激情） 不方便做需求变更（引起客户不满） 生活中的问题 需求，设计阶段的问题 敏捷是什么？ 是一种从90年代开始逐渐引起广泛关注的一些新型软件开发方法。 XP ( Extreme Programming )极限编程 Scrum Scrum 是什么？ 　　 Scrum是英语中橄榄球运动的一个专业术语，表示“争球”。 　　 特指一种敏捷开发的模型。 用户故事 三要素：角色，功能，价值 按“作为一个……，可以……，以便……”样式和思路写成的用户需求，就是用户故事。 样式是技法层面的东西，它保证了无需太多思考，用户故事中即包含角色、功能、价值这三个要素。 角色 角色切记不要总是写“作为一个用户”，而是要把用户区别对待。这样才能更好地理解他们使用什么功能，如何使用，为何使用。 项目案例1 比如“作为一个开发人员，可以登录批量编辑页面，以便高效率地编辑多个故事”就是一个危险的举动，因为如果有多个程序员同时这么做，存储的时候会发生冲突（这个页面后来被删除了）。但“作为一个项目经理，可以登录迭代计划首页，同时编辑多个迭代的信息”则是可行的，因为项目经理一般就有一个，而且这个功能使用次数很少，即使有多个人有权限使用，偶然发生冲突的损害，与平时效率提高相比，也微乎其微。 所以把角色特化出来后，更容易理解 功能的价值和风险。 功能 功能即用户能亲自执行的操作。 应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。 项目案例2 使用手机，联系方式上在“拨出”之外，总是有一个“编辑拨出”，是为了能在前面加拨17951之类的IP电话前缀。 如何写成用户故事？ “作为一个用户，可以使用编辑拨出在拨打长途前输入IP前缀，以便节省话费。” 不过这个功能从来没用过，因为太费劲。实际使用中要么我会把外地电话录入的时候就加上17951。 项目案例3 使用另外一款Android手机，安装了360，它有一个自动IP功能。 如何写成用户故事？ “作为一个用户，可以在拨打长途的时候自动使用IP拨出功能，以便节省话费。” 这个功能每月可以节省不下20块钱，如果有一天收费，也会有客户购买。可见这个用户故事编写成功。 价值 价值是完成操作后，客户所得到的价值。 价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如前面的“高效地”“节省话费”。 “用例就是那个你能卖掉的东西。”用户故事也是用来被卖掉的东西，看不到价值的就不是用户故事。 比如上面的360的用户故事写得就比较好，估计如果有客户没装360，立刻就去装了。 敏捷开发中的用户故事采用的语法模式看似简单，却蕴含着深刻的思想。 “作为一个……，可以……，以（以便）……”不同于一般专注于功能的需求条目描述方法，三个……把角色、功能、价值跃然纸上。然而使用不当，却有可能形似而神不似。 项目案例4 网络游戏的排行榜功能 “作为一个玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可。” 这个功能可以激发玩家的“斗志”，鼓励购买道具，是个不错的想法，但实现起来却有技术问题：服务器中的玩家太多了，实时查看排名非常不现实。另一个问题是小虾米们其实对自己的排名不太关心，即使关心，也不会为了提升排名去购买道具，只有一批（也有上百个）顶级大佬才会真正受此蛊惑。 如何修改这个用户故事？ “作为一个排名靠前的付费玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可（以刺激消费）。” 这个用户故事给我们的启发 当然，对小虾米们也有刺激消费的方法，比如打怪掉落了一个很棒的道具，却要花钱买打孔材料和镶嵌宝石，即使用保健因素而非激励因素让他们消费，那是另外一个故事了。 “用户”这个词太笼统了，如果他们的“价值观”差别很大，就要分别为他们写故事，才能吸引他们使用功能，达成价值观。 项目案例5 权限查询功能 “作为管理员，可以查询所有用户的权限，以了解所有用户的权限”。 一种很常见的写之无味不写不行的故事，因为好像功能=价值。其实管理员不会平白无故地查看所有用户权限的，多半有其目的：有人反映自己访问不了某个文件，有个项目死活加不上新用户，有人刚刚离职，有三个外包团队的人需要在最近三个月在项目中作为成员一起工作…… 知道这些就好多了，当点击“权限”这个tab后，多半不会出现“所有用户的权限”（倘若想想有10000人的企业），而是继续出现几个子链接：查询个人权限，项目成员，人员离职，限时权限（