敏捷开发模型.ppt

1、1,1,课程名称：软件工程 主讲教师：丁洁 系 部: 计算机系,敏捷开发模型,敏捷是什么？ SCRUM 开发流程 用户故事,非敏捷 - 瀑布式开发,软件开发的经典模型,瀑布模型的主要缺陷： 程序的维护成本会越来越高（需要很多人） 团队氛围压抑（感受不到激情） 不方便做需求变更（引起客户不满）,生活中的问题,需求，设计阶段的问题,敏捷是什么？,是一种从90年代开始逐渐引起广泛关注的一些新型软件开发方法。 XP ( Extreme Programming )极限编程 Scrum,Scrum 是什么？,Scrum是英语中橄榄球运动的一个专业术语，表示“争球”。 特指一种敏捷开发的模型。,2020/1

2、2/9,9,Scrum特点,自我管理的团队 以“sprint”为周期迭代的产品开发 以一系列“产品 Backlog”即产品或项目的将做(To-do)列表，记录了产品需求 没有特定的工程实践惯例 在以生成规则创造的敏捷开发环境交付产品 是其中一种“敏捷方法”,2020/12/9,10,SCRUM 开发流程,SCRUM 开发流程是敏捷开发的一种，以英式橄榄球争球队形 (Scrum) 为名，基本假设是开发软件就像开发新产品，无法一开始就能定义 Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。 Scrum 将软件开发团队比拟成橄榄球队，有明确

3、的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，碓保每天、每个阶段都朝向目标有明确的推进，因此 SCRUM 非常适用于产品开发项目。,2020/12/9,11,SCRUM 开发流程,SCRUM 开发流程通常以 30 天为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排 . SCRUM较为有特色的，是它特别强调开发

4、队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。,2020/12/9,12,Scrum总体骨架,2020/12/9,13,顺序 vs. 重叠开发过程,Scrum并非以一段时间集中完成一个过程,.而是将所有过程中必须的每一部分集中在这段时间内完成,需求,设计,代码,测试,2020/12/9,14,敏捷开发-迭代计划,最新版本,验收测试,发布计划,迭代计划,开发,项目周期,用户故事,三要素：角色，功能，价值 按“作为一个，可以，以便”样式和思路写成的用户需求，就是用户故事。 样式是技法层面的东西，它保证了无需太多思考，用户故事中即包含角色、功能、价

5、值这三个要素。,角色,角色切记不要总是写“作为一个用户”，而是要把用户区别对待。这样才能更好地理解他们使用什么功能，如何使用，为何使用。,项目案例1,比如“作为一个开发人员，可以登录批量编辑页面，以便高效率地编辑多个故事”就是一个危险的举动，因为如果有多个程序员同时这么做，存储的时候会发生冲突（这个页面后来被删除了）。但“作为一个项目经理，可以登录迭代计划首页，同时编辑多个迭代的信息”则是可行的，因为项目经理一般就有一个，而且这个功能使用次数很少，即使有多个人有权限使用，偶然发生冲突的损害，与平时效率提高相比，也微乎其微。 所以把角色特化出来后，更容易理解 功能的价值和风险。,功能,功能即用户

6、能亲自执行的操作。 应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。,项目案例2,使用手机，联系方式上在“拨出”之外，总是有一个“编辑拨出”，是为了能在前面加拨17951之类的IP电话前缀。 如何写成用户故事？ “作为一个用户，可以使用编辑拨出在拨打长途前输入IP前缀，以便节省话费。” 不过这个功能从来没用过，因为太费劲。实际使用中要么我会把外地电话录入的时候就加上17951。,项目案例3,使用另外一款Android手机，安装了360，它有一个自动IP功能。 如何写成用户故事？ “作为一个用户，可以在拨打长途的时候自动使用IP拨出功能，以便节省

7、话费。” 这个功能每月可以节省不下20块钱，如果有一天收费，也会有客户购买。可见这个用户故事编写成功。,价值,价值是完成操作后，客户所得到的价值。 价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如前面的“高效地”“节省话费”。 “用例就是那个你能卖掉的东西。”用户故事也是用来被卖掉的东西，看不到价值的就不是用户故事。 比如上面的360的用户故事写得就比较好，估计如果有客户没装360，立刻就去装了。,敏捷开发中的用户故事采用的语法模式看似简单，却蕴含着深刻的思想。 “作为一个，可以，以（以便）”不同于一般专注于功能的需求条目描述方法，三个把角色、功能、价值跃然纸上。然而使用不当，却有可

8、能形似而神不似。,项目案例4,网络游戏的排行榜功能 “作为一个玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可。” 这个功能可以激发玩家的“斗志”，鼓励购买道具，是个不错的想法，但实现起来却有技术问题：服务器中的玩家太多了，实时查看排名非常不现实。另一个问题是小虾米们其实对自己的排名不太关心，即使关心，也不会为了提升排名去购买道具，只有一批（也有上百个）顶级大佬才会真正受此蛊惑。,如何修改这个用户故事？,“作为一个排名靠前的付费玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可（以刺激消费）。”,提示：每周重新排名一次，而且只显示TopXXX （很像csdn的“排名两万以外”

9、）。,这个用户故事给我们的启发,当然，对小虾米们也有刺激消费的方法，比如打怪掉落了一个很棒的道具，却要花钱买打孔材料和镶嵌宝石，即使用保健因素而非激励因素让他们消费，那是另外一个故事了。 “用户”这个词太笼统了，如果他们的“价值观”差别很大，就要分别为他们写故事，才能吸引他们使用功能，达成价值观。,项目案例5,权限查询功能 “作为管理员，可以查询所有用户的权限，以了解所有用户的权限”。 一种很常见的写之无味不写不行的故事，因为好像功能=价值。其实管理员不会平白无故地查看所有用户权限的，多半有其目的：有人反映自己访问不了某个文件，有个项目死活加不上新用户，有人刚刚离职，有三个外包团队的人需要在最

10、近三个月在项目中作为成员一起工作 知道这些就好多了，当点击“权限”这个tab后，多半不会出现“所有用户的权限”（倘若想想有10000人的企业），而是继续出现几个子链接：查询个人权限，项目成员，人员离职，限时权限（外包人员管理）,这个用户故事给我们的启发,当然，这需要一大堆故事了，但如果一个给客户带来明确价值操作友好的产品正是我们所追求的，我们极有可能选择开发其中最高价值的几个，然后再留下之前那个“万能”但又什么都干不太好的。 功能不等于价值，要理解用户操作功能的业务目的，不要随意抛出万能的功能。,项目案例6,杀毒软件的防打扰功能 “作为一个用户，可以选择认可所有相似操作，以便同意或禁止连续的相

11、似操作。” 这看起来也是个很不错的功能，但笔者曾经在安装软件的时候用到这个功能，尽管选择了“认可所有相似操作”，窗口仍然跳个不停，直到后来仔细查看弹出的信息，原来在软件安装过程中要进行很多“不相似”的操作：修改注册表，创建C盘目录，向system32中拷贝dll而这个杀毒软件在处理的时候，连注册表不同位置的修改都认为是“不同的操作”。,如何修改这个用户故事？,要改好这个故事，就要从最后的客户价值入手。比如如果安装软件是最常见的需要“认可所有相似操作”的过程，就可以写一个这样的故事： “作为一个用户，可以在安装软件时选择认可本次安装操作，以便一键完成正常的安装操作。”,这个用户故事给我们的启发,

12、“客户价值”是要从客户的角度来理解的，否则极可能跑偏。,Sprint 计划会议,计划会议要有足够的时间，最好至少8个小时 取出部分产品需求做成sprint需求，并写成索引卡 确定并细分每一个索引卡的故事（Story） 进行工作认领（不是分配） 确定每日站立会议的时间和地点 确定好演示会议和回顾会议的日期,场景展示 - 计划纸牌,场景展示 - 故事看板,站立会议,10-15分钟 迟到将接受惩罚 自问自答三个问题 昨天做了什么 今天要做什么 遇到了什么问题 更新燃尽图,场景展示 - 燃尽图,2020/12/9,36,迭代结果的验收,团队需要演示所完成的迭代工作 典型的做法是使用演示形式展示新功能或

13、者底层架构的实现 非正式的 2小时的提前准备 不需要正式演示文档 整个团队都需要参加 邀请所有关注产品的人参加,Sprint开发周期,使用好任务看板 需求，设计，开发，测试，维护 注意燃尽图 不要使用软件取代看板 可以选择性的和XP的某些方式结合 测试驱动开发 结对编程,场景展示 - 任务看板,演示会议,演示是跨团队的，会产生不同团队之间的交流 不要关注太多的细节，以主要的功能为主 让老板和客户看到 非常的重要，绝对不可以被忽略,回顾会议,时间在1-3个小时 找最舒适的地方（要有回顾看板） 开始的时候轮流发言，而不是主动发言 记录问题，总结，并讨论改进的方法，放在回顾看板上 每人三个磁铁，将最重要的2-3个改进点，成为下