敏捷开发方法与实践交流new

敏捷开发方法与实践交流new

ID:34652138

大小:1.99 MB

页数:76页

时间:2019-03-08

敏捷开发方法与实践交流new_第1页
敏捷开发方法与实践交流new_第2页
敏捷开发方法与实践交流new_第3页
敏捷开发方法与实践交流new_第4页
敏捷开发方法与实践交流new_第5页
资源描述:

《敏捷开发方法与实践交流new》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、敏捷开发方法与实践交流张邱溪2011年4月提纲了解敏捷(为什么要使用敏捷方法?)实践Scrum(什么是Scrum?我们Scrum了么?)问题探讨(寻找属于我们的敏捷之道)项目成功率统计即使软件交付了,也不意味着成功了why?软件开发项目中的复杂性远离清晰混乱复杂需求复杂的简单的复杂的接近清晰接近明确技术远离明确传统软件工程的做法架一座通往按时交付的桥搭一个棚子来拒绝需求拒绝改变一个小漫画糟透了就像十五个喝醉你的项目你的项目进展怎样最近如何,一团的猴子在玩一个拼图游戏了?啊?乱麻很好,进展正常问题隐藏如

2、果不能改变它,那就去适应它!敏捷宣言–个体和交互胜过过程和工具–可以工作的软件胜过面面俱到的文档–客户合作胜过合同谈判–响应变化胜过遵循计划虽然右项也有价值,但是敏捷开发认为左项具有更大的价值!也就是说:自组织团队与客户紧密协作,通过高度迭代、增量式的软件开发过程响应变化,并在每次迭代结束时交付经过编码与测试的有价值的软件胜过与客户确定合同后在初期制定并遵循基于活动的完整计划,在重型过程和工具指导下,通过完成大量文档进行知识传递,最后交付需求敏捷原则l1、我们最优先要做的是通过尽早的、持续的交付有价值

3、的软件来使客户满意。l2、即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。l3、经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。l4、在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。l5、围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。l6、在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。l7、工作的软件是首要的进度度量标准。l8、敏捷过程提倡可持续的开发速度。责任人、

4、开发者和用户应该能够保持一个长期的、恒定的开发速度。l9、不断地关注优秀的技能和好的设计会增强敏捷能力。l10、简单是最根本的。l11、最好的构架、需求和设计出于自组织团队。l12、每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。敏捷关注什么敏捷带给我们什么对一系列敏捷项目的分析结果表明产品上市时间平均减少了69%成本降低了57%工作量降低了62%致命缺陷平均减少了80%普通缺陷减少了60%。员工士气提升责任感增加协调与合作促进...…提纲了解敏捷(为什么要使用

5、敏捷方法?)实践Scrum(什么是Scrum?我们Scrum了么?)问题探讨(寻找属于我们的敏捷之道)Scrum的起源Scrum的样子来自最终用户、客户、ScrumMaster团队或其它干系人的日站立会议需求输入1-4周ProductOwnerTeam审核会议选择下一个Sprint承诺的内容周期和目标不变可交付产品增量SprintSprint计划会议Backlog(SBI)ProductBacklog(PBI)回顾会议Scrum的特征•敏捷过程之一•自组织的团队•迭代开发•信息可见性•一份产品需求清单

6、•没有任何工程实践说明•强调营造一个敏捷环境,并不断改善Scrum的五个价值观勇气尊重承诺专注CourageRespectCommitmentFocused开放Openness越来越多的企业开始用Scrum深入ScrumScrum的3-3-5工件仪式ProductOwner(PO)l定义产品的Feature(功能/特性)l负责产品的利润(投资回报)l根据市场及业务价值对产品特性排定优先级l对发布日期和内容进行决策l需要时,每一个迭代调整产品特性和优先级l接收或者不接受工作的结果案例&问题分析1谁是合适

7、的ProductOwner?没有ProductOwner可以么?传统的产品经理、专业的需求分析师可以是PO的人选,但是要完成角色的转变,担负起PO应有的职责,尤其是为用户和客户负责。一个ScrumTeam不能没有PO,否则软件的业务价值将无从谈起。案例&问题分析2ProductOwner对团队说他不能够参加这次的Sprint计划会议,因为要和一个合作伙伴公司的上层打一场重要的高尔夫球。他不介意团队计划独自进行会议。这样做可以么?不可以,因为Sprint计划会议中,需要制定Sprint的目标,向Scru

8、m团队宣贯ProductBacklog,解答团队在UserStory评估和任务拆分时遇到的业务问题,而这些都是离不开PO的参与的。团队(Team)l建议通常5-9人l跨职能(团队、个人两个角度)l成员最好是全职的l团队是自组织的,理想是没有职称之分l迭代之间,成员构成才做变更案例&问题分析3原先的TeamLeader、架构师、界面设计、专职测试职位还有存在的价值么?理想的Scrum团队,除了ScrumMaster、ProductOwner和Team外,再

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。