SDM 341 队友(Scrum)软件开发方式和互联网在线服务部门的合作.ppt_第1页
SDM 341 队友(Scrum)软件开发方式和互联网在线服务部门的合作.ppt_第2页
SDM 341 队友(Scrum)软件开发方式和互联网在线服务部门的合作.ppt_第3页
SDM 341 队友(Scrum)软件开发方式和互联网在线服务部门的合作.ppt_第4页
SDM 341 队友(Scrum)软件开发方式和互联网在线服务部门的合作.ppt_第5页
已阅读5页,还剩47页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

SDM 341 队友(Scrum)软件开发方式和互联网在线服务部门的合作,/sundae_meng,问题:建造一栋独立屋的最快时间?,答案是:3 小时, 26 分 34 秒,提纲,长尾理论突破传统二八定律 互联网软件工程开发的主要挑战 敏捷开发与队友软件开发方式 事例解读 队友软件开发方式经验 改善流程管理 扩大交流和增进合作 增大自动化程度 Q & A,二八定律,巴莱多定律(二八定律),1897意大利经济学家巴莱多在研究英国收入分配发现 最重要的只占约,其余是次要的 1949,哈佛语言学家乔治.齐普夫 单词出现频率按照流行程度进行排序, 排在第k位的项目其比重为第一项的1/k:齐普夫定律 个人的财富和收入 城市人口 商店销售 图书、音乐和电影,二八定律的体现,百分之二十的消费者购买百分之八十的某一类商品 而百分之八十的消费者只购买另外百分之二十的商品 传统营销手段受制于薄弱的技术和高昂的成本 二八定律有失效的可能性吗?,二八定律的总结,预料不平衡的基础: 多样化 不平等现象 网络影响:例如新闻,报纸,电视, 互联网的不断发展,让我们看到了二八定律失效的可能性,长尾理论,长尾理论,克里斯.安德森: ”连线”杂志主编 只要存储和流通的渠道足够大,需求不旺或销量不佳的产品共同占据的市场份额就可以和那些数量不多的热卖品所占据的市场份额相匹敌甚至更大。 恐龙长尾”的分布特征,长尾理论例,亚马逊网上书店成千上万的商品书中,一小部分畅销书占据总销量的一半,而另外绝大部门的书虽说个别销量小,但凭借其种类的繁多积少成多,占据了总销量的另一半。,长尾的价值在互联网软件的体现,互联网软件的趋势,三股势力正改变目前软件产业经济 书写软件程序的费用大大减少: 世界各地人才 软件运送费用也大大下降: 网上下载既块又好 寻求最佳软件的成本也渐渐简单:网上用户群之间的沟通 通过网络提供网上软件并远程管理将成趋势,互联网软件体现长尾效因,定位在中高端、面向大中型企业的管理软件一度在市场上占据主流 软件的互联网应用环境为一些更为低端的用户创造了机会: 交易成本 广泛的用户基础 通过ASP的方式来得到软件服务 游戏软件和广告的插入及综合等,互联网软件工程开发的主要挑战,及时: 上市时间 效率 (关键) 成本: 投资回报 适合大部分用户的需要,敏捷开发,传统软件开发方法,大量的文档书写 实现各种功能, 最后组装在一起 不到项目最后, 无法知道终局 瀑布式方法是一个代表,瀑布式方法管理,传统软件开发方法的问题,这些文档往往并不准确 软件需要修改 修改软件会引起系统混乱, 一个微小的错误就能导致互联网系统崩溃,敏捷开发的卖点,尽快地, 经常地提供满意的软件版本 开发过程中是迭代的,可以不断地根据结果作出反应 总体功能的价值可以在早期就被评估,项目组可以调整下一阶段要开发的内容 时刻注意跟上市场变化的步伐,敏捷开发的要求,总体框架要灵活以有因变能力 简单设计反而好 尽量提供无缺陷的软件 不段的学习和提高以提高技术和设计能力 充分尊重个人意见, 提供个人决策权 耐性地听取意见, 尽快地改变采用最佳方案,队友(Scrum)软件开发方式,队友(Scrum)开发方式是敏捷方法之一,一个体育队加小队长,全体团队负责拿球向前冲,队友(Scrum)开发方式来历,Scrum一词来源于橄榄球运动,过程是迅速,有适应性,自组织的 1995年由先进的开发方法公司提出,2001年由 “敏捷联盟”推广 团队成员能够独立地,集中地在创造性的环境下工作,队友(Scrum)开发团队的组成,7人组成 管理者主持会议,负责对整个项目的成败 对于人数多于7人的项目团队,建议与其扩大团队规模不如将团队分组 通过Scrum会议对各个子团队的工作进行同步 团队不止是一个程序员队伍,它由各种背景下的不同角色组合而成,包括商业分析者,设计师,程序员和测试者等等。正确的组合决定了团队的能力和效率,大团队的组成,1 person from each team,团队再分组 多个小团体 最有效的大部门合作方法 也适宜地域分布的要求,队友(Scrum)开发团队的组成,Planning,Analysis,Architecture, Infrastructure,Coding,Design,Testing,Performance,User Acceptance,Pilot,Live,Extend the definition to include all development,队友开发人员的角色和责任,ScrumMaster,Product Owner,Team,Defines the features of the product, decides on release date and content Responsible for the profitability of the product (ROI) Prioritizes features according to market value Can change features and priority every 30 days Accepts or rejects work results,Cross-functional, seven plus/minus two members Selects the iterations goals and specifies work results Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal Organizes itself and its work Demos work results to the Product Owner,Ensures that the team is fully functional and productive Facilitates close cooperation across all roles and functions and removes barriers Shields the team from external interferences Ensures that the process is followed. Invites to daily scrum, iteration review and planning meetings,队友(Scrum)开发如何工作,产品拥有者持有产品订单,控制并区分功能的开发次序 队友团队和产品所有者共同检视订单,决定优先功能开发优先级 开始被称为“疾跑”的迭代过程: 时间为30天。 管理者负责团队与外界的交流都必须经由进行 在团队对“疾跑”的作用有更多了解以后,团队成员就可以调整原始的产品评估,并将“疾跑”过程中获得的信息加入到产品订单中,队友(Scrum)开发如何工作,每日的队友会议 每月的“疾跑”计划和“疾跑”审查会议紧密相连 “疾跑”审查会议持续半天: 团队演示完成的内容 总结: 订单 “疾跑”计划和回顾 管理承诺 每日的队友会议 进度回溯,队友开发工作流程,管理与阶段,队友(Scrum)事例,互联网软件服务模式,总体设计 源程序完成 QA部门测试 逐步程序调整 QA 质量鉴定和通过 送给在线服务部门 - 往往太迟,软件开发服务和互联网在线服务部门的合作事例,队友(Scrum)开发方式事例之一 队友(Scrum)开发方式事例之二,要利用队友开发方式吗?,可迅速优先满足不断变化的需求 可循序渐进地增加功能 不需一条路走到黑 “Death March” 顾客能先享用部分功能 自我管理团队士气高涨 鼓励大家树立工作责任感 适应化的学习过程 总结以往教训并立即采用,还是不要利用队友开发方式?,不适合文化的挑战 不适合大型项目的开发 最佳团队规模小于10 增加复杂性 难以沟通 不适合跨区域(地理)发展 可能导致长期成本的升高 要求很简单,一成不变 不适合自下而上工程设计,利用队友开发方式的经验,改善流程管理 扩大交流和增进合作 增大自动化程 度,改善流程管理,流程管理,为何还要流程管理 标准一致的工作流程有益于: 提高效率, 降低非生产性时间 提高产品质量 加速上市场时间 流程管理目标 保持低费用 质量 早日进入市场 减少意外,保持商业稳定和预测性,队友开发方式流程管理,文档管理 文档通常靠队友主动的建立, 无法依靠设计文档 建立文档也不在优先之列 文档是在线服务部门的重点, 服务客户 时间保留 保留一点解决问题的时间, 否则要等30天 队友下再队友的管理 大型项目的大部门合作方法, 队友可以参加跨越多个队 质量管理 在线服务部门既是客户, 也是团队成员,软件发布流程管理,软件发布标准 环境瞬息万变, 坚定和客观的标准是质量的保证 高质量服务建立在完善的系统控制和监视之上 系统变动管理 保持服务高质量和服务高效率要求相应完善的系统变动管理 所有修改必须程序化, 文件化, 并应简单 增加一个发布流程 系统变动阶段化 在线服务部门有投票权,扩大交流和增进合作,扩大交流,良好的沟通是成功基础: 软件设计变动是费用最便宜的时候 数据中心基础设施建设需要时间,往往受外来资源限制 在线服务部门要非常深入的参与软件开发以少走弯路 各方要了解大体发展动态 直接参加队友管理团队多过于间接参与,基本的交流,在线服务部门参于规格和设计审查 数据中心基础设施商讨的最佳时间 队友团队外人也可充分发挥专家责任 数据中心基础设施建设 要求与软件设计同步 减少上市时间 满足不断变化的需求 队友会议 在线服务部门必须参加有关会议并表达意见,增大自动化程 度,自动化,自动化的优点 队友软件开发方式增加了快速改变几率 任何改变多有代价 自动化的目标 降低成本的变化 各企业内部利用自动化的成果,软件开发部门自动化,构建流程 软件总体要能自动构建 能减少基础调查的时间和精力 代码检查工具 检查格法标准 检查安全代码 转送运

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论