敏捷开发模型.ppt

1 1课程名称：软件工程课程名称：软件工程主讲教师主讲教师：丁洁：丁洁系系 部部:计算机系计算机系敏捷开发模型n敏捷是什么？nSCRUM 开发流程n用户故事非敏捷-瀑布式开发n软件开发的经典模型计划1需求分析2设计3编码4测试5维护6瀑布模型的主要缺陷：n程序的维护成本会越来越高（需要很多人）n团队氛围压抑（感受不到激情）n不方便做需求变更（引起客户不满）生活中的问题需求，设计阶段的问题敏捷是什么？n是一种从90年代开始逐渐引起广泛关注的一些新型软件开发方法。nXP(Extreme Programming)极限编程nScrumScrum 是什么？Scrum是英语中橄榄球运动的一个专业术语，表示“争球”。特指一种敏捷开发的模型。2024/5/25 周六9Scrum特点n自我管理的团队n以“sprint”为周期迭代的产品开发n以一系列“产品 Backlog”即产品或项目的将做(To-do)列表，记录了产品需求n没有特定的工程实践惯例n在以生成规则创造的敏捷开发环境交付产品n是其中一种“敏捷方法”2024/5/25 周六10SCRUM 开发流程开发流程 nSCRUM 开发流程是敏捷开发的一种，以英式橄榄球争球队形(Scrum)为名，基本假设是开发软件就像开发新产品，无法一开始就能定义 Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。nScrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，碓保每天、每个阶段都朝向目标有明确的推进，因此 SCRUM 非常适用于产品开发项目。2024/5/25 周六11SCRUM 开发流程开发流程nSCRUM 开发流程通常以 30 天为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排.nSCRUM较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。2024/5/25 周六12Scrum总体骨架总体骨架迭代迭代每30天Daily SCRUM每24小时高优先级可运行的软件可运行的软件工作项分解产品订单产品订单Product Backlog迭代订单迭代订单Sprint Backlog新的功能新的功能增量增量迭代规划会议迭代规划会议Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排迭代复审会议迭代复审会议Sprint Review 一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况迭代回顾会议迭代回顾会议Sprint Retrospective一般3个小时，ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议每日站立会议Daily Scrum Meeting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗?产品负责人产品负责人Scrum主管主管开发团队开发团队2024/5/25 周六13顺序 vs.重叠开发过程Scrum并非以一段时间集中完成一个过程.而是将所有过程中必须的每一部分集中在这段时间内完成需求设计代码测试2024/5/25 周六14敏捷开发-迭代计划最新版本最新版本验收测试验收测试发布计划发布计划迭代计划迭代计划开发开发项目周期项目周期用户故事用户故事n三要素：角色，功能，价值n按“作为一个，可以，以便”样式和思路写成的用户需求，就是用户故事。n样式是技法层面的东西，它保证了无需太多思考，用户故事中即包含角色、功能、价值这三个要素。角色角色n 角色切记不要总是写“作为一个用户”，而是要把用户区别对待。这样才能更好地理解他们使用什么功能，如何使用，为何使用。项目案例1n比如“作为一个开发人员，可以登录批量编辑页面，以便高效率地编辑多个故事”就是一个危险的举动，因为如果有多个程序员同时这么做，存储的时候会发生冲突（这个页面后来被删除了）。但“作为一个项目经理，可以登录迭代计划首页，同时编辑多个迭代的信息”则是可行的，因为项目经理一般就有一个，而且这个功能使用次数很少，即使有多个人有权限使用，偶然发生冲突的损害，与平时效率提高相比，也微乎其微。n所以把角色特化出来后，更容易理解 功能的价值和风险。功能功能n功能即用户能亲自执行的操作。n应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。项目案例2n使用手机，联系方式上在“拨出”之外，总是有一个“编辑拨出”，是为了能在前面加拨17951之类的IP电话前缀。n如何写成用户故事？n “作为一个用户，可以使用编辑拨出在拨打长途前输入IP前缀，以便节省话费。”n 不过这个功能从来没用过，因为太费劲。实际使用中要么我会把外地电话录入的时候就加上17951。项目案例3n使用另外一款Android手机，安装了360，它有一个自动IP功能。n如何写成用户故事？n “作为一个用户，可以在拨打长途的时候自动使用IP拨出功能，以便节省话费。”n 这个功能每月可以节省不下20块钱，如果有一天收费，也会有客户购买。可见这个用户故事编写成功。价值价值n价值是完成操作后，客户所得到的价值。n价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如前面的“高效地”“节省话费”。n“用例就是那个你能卖掉的东西。”用户故事也是用来被卖掉的东西，看不到价值的就不是用户故事。n比如上面的360的用户故事写得就比较好，估计如果有客户没装360，立刻就去装了。n敏捷开发中的用户故事采用的语法模式看似简单，却蕴含着深刻的思想。n“作为一个，可以，以（以便）”不同于一般专注于功能的需求条目描述方法，三个把角色、功能、价值跃然纸上。然而使用不当，却有可能形似而神不似。项目案例4n网络游戏的排行榜功能网络游戏的排行榜功能n“作为一个玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可。”n这个功能可以激发玩家的“斗志”，鼓励购买道具，是个不错的想法，但实现起来却有技术问题：服务器中的玩家太多了，实时查看排名非常不现实。另一个问题是小虾米们其实对自己的排名不太关心，即使关心，也不会为了提升排名去购买道具，只有一批（也有上百个）顶级大佬才会真正受此蛊惑。如何修改这个用户故事？n “作为一个排名靠前的付费玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可（以刺激消费）。”提示：每周重新排名一次，而且只显示TopXXX（很像csdn的“排名两万以外”）。这个用户故事给我们的启发 n当然，对小虾米们也有刺激消费的方法，比如打怪掉落了一个很棒的道具，却要花钱买打孔材料和镶嵌宝石，即使用保健因素而非激励因素让他们消费，那是另外一个故事了。n “用户”这个词太笼统了，如果他们的“价值观”差别很大，就要分别为他们写故事，才能吸引他们使用功能，达成价值观。项目案例5n权限查询功能权限查询功能n“作为管理员，可以查询所有用户的权限，以了解所有用户的权限”。n一种很常见的写之无味不写不行的故事，因为好像功能=价值。其实管理员不会平白无故地查看所有用户权限的管理员不会平白无故地查看所有用户权限的，多半有其目的：有人反映自己访问不了某个文件，有个项目死活加不上新用户，有人刚刚离职，有三个外包团队的人需要在最近三个月在项目中作为成员一起工作n知道这些就好多了，当点击“权限”这个tab后，多半不会出现“所有用户的权限”（倘若想想有10000人的企业），而是继续出现几个子链接：查询个人权限，项目成员，人员离职，限时权限（外包人员管理）这个用户故事给我们的启发n当然，这需要一大堆故事了，但如果一个给客户带来明确价值操作友好的产品正是我们所追求的，我们极有可能选择开发其中最高价值的几个，然后再留下之前那个“万能”但又什么都干不太好的。n 功能不等于价值，要理解用户操作功能不等于价值，要理解用户操作功能的业务目的，不要随意抛出万能的功能的业务目的，不要随意抛出万能的功能。功能。项目案例6n杀毒软件的防打扰功能杀毒软件的防打扰功能n“作为一个用户，可以选择认可所有相似操作，以便同意或禁止连续的相似操作。”n这看起来也是个很不错的功能，但笔者曾经在安装软件的时候用到这个功能，尽管选择了“认可所有相似操作”，窗口仍然跳个不停，直到后来仔细查看弹出的信息，原来在软件安装过程中要进行很多“不相似”的操作：修改注册表，创建C盘目录，向system32中拷贝dll而这个杀毒软件在处理的时候，连注册表不同位置的修改都认为是“不同的操作”。如何修改这个用户故事？n要改好这个故事，就要从最后的客户价值入手。比如如果安装软件是最常见的需要“认可所有相似操作”的过程，就可以写一个这样的故事：n“作为一个用户，可以在安装软件时选择认可本次安装操作，以便一键完成正常的安装操作。”这个用户故事给我们的启发n“客户价值客户价值”是要从客户的角度来理解的，是要从客户的角度来理解的，否则极可能跑偏。否则极可能跑偏。Sprint 计划会议n计划会议要有足够的时间，最好至少8个小时n取出部分产品需求做成sprint需求，并写成索引卡n确定并细分每一个索引卡的故事（Story）n进行工作认领（不是分配）n确定每日站立会议的时间和地点n确定好演示会议和回顾会议的日期场景展示-计划纸牌场景展示-故事看板站立会议n10-15分钟n迟到将接受惩罚n自问自答三个问题n昨天做了什么n今天要做什么n遇到了什么问题n更新燃尽图场景展示-燃尽图2024/5/25 周六36迭代结果的验收n团队需要演示所完成的迭代工作n典型的做法是使用演示形式展示新功能或者底层架构的实现n非正式的n2小时的提前准备n不需要正式演示文档n整个团队都需要参加n邀请所有关注产品的人参加Sprint开发周期n使用好任务看板n需求，设计，开发，测试，维护n注意燃尽图n不要使用软件取代看板n可以选择性的和XP的某些方式结合n测试驱动开发n结对编程场景展示-任务看板演示会议n演示是跨团队的，会产生不同团队之间的交流n不要关注太多的细节，以主要的功能为主n让老板和客户看到n非常的重要，绝对不可以被忽略回顾会议n时间在1-3个小时n找最舒适的地方（要有回顾看板）n开始的时候轮流发言，而不是主动发言n记录问题，总结，并讨论改进的方法，放在回顾看板上n每人三个磁铁，将最重要的2-3个改进点，成为下一轮的产品需求场景展示-回顾会议看板回顾会议问题举例n我们应花更多时间，把故事拆分成更小的条目和任务n我们办公室的环境太吵太混乱了n我们做出了过度的承诺，最后只完成了一半工作nScrum的主要缺陷：n压力大n不方便跨时区，跨语言n程序维护成本偏高n无法被中断n如何改善：n结合XP：n和客户坐在一起n结对编程n测试驱动开发（TDD）n使用编码规范n32小时工作制结对编程图书介绍4747谢谢！