《敏捷软件开发管理IBM孙昕ppt课件.ppt》由会员分享，可在线阅读，更多相关《敏捷软件开发管理IBM孙昕ppt课件.ppt（48页珍藏版）》请在三一办公上搜索。
1、敏捷软件开发管理,IBM 高级技术顾问 孙昕,议程,如何有效的实施Scrum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发,敏捷宣言,Individuals and interactions over processes and tools(人和交互重于过程和工具 )Working software over comprehensive documentation(可以工作的软件重于面面俱到的文档)Customer collaboration over contract negotiation(客户合作重于合同谈判)Responding to change over foll
2、owing a plan (拥抱变化胜于遵循计划 ),That is, while there is value in the items on the right, we value the items on the left more.关注敏捷软件开发是因为我们认为它是一种很好的软件开发理念，能够应对现实中的软件需求经常不完善和快速变更的问题，用好它能够提高客户满意度，降低项目失败的风险。但什么时候使用它、如何很好地实施这些理念，是我们需要考虑和解决的问题。,敏捷的定义(IBM),“使用持续的项目干系人的反馈，通过用例（用户需求）和一系列的较短的、稳定的、时间固定的迭代来交付高质量, 可用
3、的代码.”,This figure shows the Four Ss that describe agile in a nutshell.,Scrum开发方式是敏捷方法之一,在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动、奋力实现同一目标胜利,Scrum一词来源于橄榄球运动，过程是迅速，有适应性，自组织的旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进 适用于需求难以预测的复杂商务应用产品的开发1995年由先进的开发方法公司提出，2001年由 “敏捷联盟”推广团队成员能够独立地，集中地在创造性的环境下工作,6,Scrum总体骨架,7,Scrum总体骨
4、架,使用Scrum of Scrums来进行扩展,Scrum对大型和小型的开发团队都有着良好的适应性可以增加团队的层次，比如：几个相互依赖的Scrum团队需要沟通几个团队一起工作于一个单一的产品，并且团队间需要内部相互依赖通过多层团队的建立来拓展不确定的项目规模由团队来决定频率和是否出席和参与Technical contributor 不需要Product Owner或者ScrumMaster, 但是他们可以协助,Are you about to put something in another teams way?,成功的Scrum需要做好准备工作,有准备的让正确的人来担当适当的Scrum的
5、角色具有良好的产品需求的规划以及需求的优先级的排序开发和测试环境已经准备就绪 团队知道如何将产品需求转化为可装配和可运行的产品增量扎实的由团队来评估和估算产品需求项产品负责人确定冲刺的目标并就相关的产品需求和团队进行讨论由团队来决定它的可用性ScrumMaster准备相关会议 GO!项目已经初始化 第一个sprint计划会议可以开始启动,Well done. Good luck and enjoy!,Scrum项目也可能会失败,失败摘自维基百科, 自由的百科全书,Failure (colloquially fail, phail or flop) in general refers to th
6、e state or condition of not meeting a desirable or intended objective. It may be viewed as the opposite of success. Product failure ranges from failure to sell the product to fracture of the product, in the worst cases leading to personal injury, the province of forensic engineering. ,So you need to
7、 quickly identify Scrum Smells.,Scrum的误区: 丢失节奏,不一致的Scrum每日例会Scrum每日例会被省略会议的时间老是变化不一致的Sprint周期Sprint周期在中期被武断得改变不一致的Sprint计划会议Sprint计划会议被省略,Scrum的误区: 随意讲话的鸡,项目干系人在Scrum每日例会上款款而谈产品功能的选择在Sprint计划会议之外进行 没有外部人员的肯定，团队没有办法做纯技术上的决策项目的状态分析在Sprint计划会议之外进行 执行者试图干预团队产品需求调整或不被理睬,Scrum误区: 被遗忘的猪,不清晰和明确的期望?竞争性的分配?缺乏
8、担当?管理上的干涉?厌烦?恐惧?,Scrum误区: 缺少进展,Backlog持续的增长而不是减少手头正在做的工作太多了功能特性感觉永无止境90%完成综合症总是基于已完成的功能特性不断进行修改和修复已完成的功能正在等待未完成的项目干系人抱怨缺少进展失败得交付,Scrum 误区: ScrumMaster 超越了自身的职责,工作是由ScrumMaster分配的，而不是由开发人员自己去认领的团队无法自己掌控工作Scrum每日例会感觉是团队成员在向ScrumMaster汇报工作进展,Scrum误区: 明确的工作职责,项目团队具有非常专一的工作角色划分和描述：架构师, 设计人员, DBA, or 测试人员
9、,团队包括专门的测试人员Scrum团队没有“我们大家在一起”的态度Scrum团队不需要完全有多面手组成,Scrum误区: 来自执行者的压力,执行者要求团队承诺在一个确定的日期发布一系列的所谓的“最低要求”功能项执行者参加团队会议执行者直接和团队成员沟通，并提醒他们最后期限,Scrum 误区: 不像一个良好的团队,固定的角色任务是被分配的没有互相帮助没有持续的指导用户需求没有被团队广泛的达成共识，所有的工作都是并行完成的缺少协作在Scrum会议上没有互相的交流和倾听没有欢笑 相反一个合作愉快的团队总是充满欢笑,Scrum误区: 大猩猩在房间里,一个人 (资深开发人员, 技术带头人, 主管人员)
10、支配交流和会议大家不愿意发言直到大猩猩开口发言团队成员对大猩猩的观点言听计从,议程,有效的实施Scrum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发,Rational Team Concert对于敏捷实践的支持,仪表盘,构建,工作项,配置管理,敏捷和适应性,流程,21,内置了Scrum等多种敏捷方法模板,创建Project Area时选择需要的模板包含了Scrum，Eclipse Way，OpenUP等流行的敏捷方法论模板用户可以对模版进行配置和修改,Scrum过程模版 角色和权限,常用工作项类型,Scrum过程模版中所包含的常用工作项类型:Defect: 在项目开发的过程
11、中,对于缺陷的追踪管理Story: 用户需求,通过一两句用户的业务语言所描述的文档化的需求Retrospective: 在每个冲刺之后由项目组召开的冲刺回顾会议,用来讨论和总结这次迭代中,一些好的成功的经验,同时还有那些不足的地方需要改进.最后就在以后的迭代中如何更好的工作达成一致的建议. Impediment: 阻碍和风险,妨碍团队成功的达到迭代和冲刺的目标,B. 用户需求工作项: 状态流(生命周期),创建自管理的团队（Scrum角色支持）,定义自管理团队的流程（Scrum流程支持）,为团队定义自己的流程,管理项目计划和迭代（Sprint）,增加工作项（work item），全面支持Scru
12、m所需的工作产品,Product Backlog和Sprint Backlog,Sprint Planning Meeting上，选择Product Backlog作为Sprint Backlog,为Product Backlog和Sprint Backlog定义其他信息，例如：迭代目标等等为Product Backlog和Sprint Backlog定义任务,Sprint plan中，利用Task组织选定的Product Backlog（Sprint Backlog），并分配给Team Member,基于上下文的团队协作,我可以,基于上下文的团队协作,我还可以,查看了解工作状态，项目状态,预
13、定义和自定义的各种报告全面监控Scrum流程信息,Burndown Chart,看看是不是出现问题了？,Scrum Dashboard,RTC可以增强业务敏捷性和保持项目的成功概率,促进高效能团队的原则,响应变更,客户协作,透明目的共同性项目健康状况检查上下文驱动,流程的灵活性迭代的计划执行多次发布JIT代码审查,启动特设团队团队感知流程感知特设共享,持续集成管理团队资源变更驱动的已集成的 / 可追溯的,支持任何流程的设定，包括敏捷,议程,有效的实施Scrum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发,地理上分布的开发团队如何采用RTC实施Scrum,BidiEgypt,
14、采用RTC开发RTCz 项目,RTCz 开发的项目信息Selfhosted on RTCz for System z Project基于Scrum过程模版地理上分布的开发团队两个主要的Scrum开发小组RTP (Raleigh, US)FASL (France & Australia)两个并行开发线Main development（主开发流）Release v2.0 within 6 SprintsIPD Product Delivery（产品集成发布流）,RTCz 项目干系人角色, 可以称之为“鸡”,PMC（产品管理委员会）Stakeholder: Danny Mace, David Mye
15、rsPMC: Pamela, Rosalind, Teresa, Sandra, Alex, Nicolas, Robin, Jean-YvesIPD Product DeliveryStakeholder: Danny Mace, David MyersPMC: Pamela, Rosalind, Teresa, Sandra, Nicolas,RTCz 开发角色, 我们可以称之为“猪”,RTCz 项目产品负责人: GuyRTP Scrum(Raleigh Scrum团队)ScrumMaster: Robin Team Member: Bruce, Andrew, Daniel, Hung
16、John, Matt, Steve, TamiFASL Scrum (France & Australia Scrum团队)ScrumMaster: Jean-YvesTeam Member: Valrie, Liam, Nicolas, Jean-Bernard, Pierre, Pascal, XavierUATeam Member: Stephanie, JocelynBidiTeam Member: Adir, Gregory, Heba, Mohamed, Ramy, SemionSUPATeam Member: Mordechai, Uri,RTCz Scrum 过程,首先是基于标准的Scrum过程模版角色PMC: 产品管理委员会 (基于项目干系人角色)新增的工作项类型Minutes: 会议记录修改了缺省的权限PMC能够来修改迭代计划当有项目成员新增时，增加新的自动化的任务 automatic tasks Joining a Team Update your calendar with your Scheduled AbsencesJoining a Team Update your Work Environment,Thank you!,
