《敏捷软件开发管理IBM孙昕》由会员分享，可在线阅读，更多相关《敏捷软件开发管理IBM孙昕（48页珍藏版）》请在金锄头文库上搜索。
1、2009 敏捷软件开发管理敏捷软件开发管理IBM 高级技术顾问 孙昕2009 议程如何有效的实施Scrum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发2009 敏捷宣言敏捷宣言Individualsandinteractionsoverprocessesandtools(人和交互重于过程和工具)Workingsoftwareovercomprehensivedocumentation(可以工作的软件重于面面俱到的文档)Customercollaborationovercontractnegotiation(客户合作重于合同谈判)Respondingtochangeoverf
2、ollowingaplan(拥抱变化胜于遵循计划)That is, while there is value in the items on the right, we value the items on the left more.关注敏捷软件开发是因为我们认为它是一种很好的软件开发理念，能够应对现实中的软件需求经常不完善和快速变更的问题，用好它能够提高客户满意度，降低项目失败的风险。但什么时候使用它、如何很好地实施这些理念，是我们需要考虑和解决的问题。2009 敏捷的定敏捷的定义(IBM)“使用持续的项目干系人的反馈，通过用例（用户需求）和一系列的较短的、稳定的、时间固定的迭代来交付高质
3、量,可用的代码.”ThisfigureshowstheFourSsthatdescribeagileinanutshell.2009 Scrum开发方式是敏捷方法之一在比在比赛赛中每个中每个队员队员都都应时应时刻保持刻保持对场对场上全局的判断，然后通上全局的判断，然后通过过集体行集体行动动、奋奋力力实现实现同一目同一目标标胜胜利利Scrum一词来源于橄榄球运动，过程是迅速，有适应性，自组织的旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进 适用于需求难以预测的复杂商务应用产品的开发1995年由先进的开发方法公司提出，2001年由 “敏捷联盟”推广团队成员能够独立地，集
4、中地在创造性的环境下工作2009 6Scrum总体骨架总体骨架冲刺规划会议冲刺规划会议Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排冲刺复审会议冲刺复审会议Sprint Review 一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况冲刺回顾会议冲刺回顾会议Sprint Retrospective一般3个小时，ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint
5、周期中更加有效和令人愉快每日站立会议每日站立会议Daily Scrum Meeting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗?产品订单产品订单Product Backlog冲刺订单冲刺订单Sprint Backlog新的功能新的功能增量增量产品负责人产品负责人Scrum主管主管开发团队开发团队干系人干系人燃尽图燃尽图角色角色工件工件活动活动产品订单产品订单Product Backlog冲刺规划会议冲刺规划会议每日站每日站立会议立会议每日工
6、每日工作作产品订单产品订单冲刺复审会议冲刺复审会议冲刺回顾会议冲刺回顾会议冲刺目标冲刺订单产品新的功能增量新的功能增量开发流程开发流程2009 7迭代迭代每30天Daily SCRUM每24小时高优先级可运行的软件可运行的软件工作项分解产品订单产品订单Product Backlog冲刺订单冲刺订单Sprint Backlog新的功能新的功能增量增量冲刺规划会议冲刺规划会议Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排冲刺复审会议冲刺复审会议Sprint R
7、eview 一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况冲刺回顾会议冲刺回顾会议Sprint Retrospective一般3个小时，ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议每日站立会议Daily Scrum Meeting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗?产品负责人产品负责人Scru
8、m主管主管开发团队开发团队Scrum总体骨架总体骨架2009 使用使用Scrum of Scrums来进行扩展来进行扩展Scrum对大型和小型的开发团队都有着良好的适应性可以增加团队的层次，比如：几个相互依赖的Scrum团队需要沟通几个团队一起工作于一个单一的产品，并且团队间需要内部相互依赖通过多层团队的建立来拓展不确定的项目规模由团队来决定频率和是否出席和参与Technicalcontributor不需要ProductOwner或者ScrumMaster,但是他们可以协助Are you about to put something in another teams way?2009 成功的成
9、功的Scrum需要做好准备工作需要做好准备工作有准备的让正确的人来担当适当的Scrum的角色具有良好的产品需求的规划以及需求的优先级的排序开发和测试环境已经准备就绪团队知道如何将产品需求转化为可装配和可运行的产品增量扎实的由团队来评估和估算产品需求项产品负责人确定冲刺的目标并就相关的产品需求和团队进行讨论由团队来决定它的可用性ScrumMaster准备相关会议GO!项目已经初始化第一个sprint计划会议可以开始启动Welldone.Goodluckandenjoy!2009 Scrum项目也可能会失败项目也可能会失败失败失败摘自维基百科,自由的百科全书Failure(colloquially
10、fail,phailorflop)ingeneralreferstothestateorconditionofnotmeetingadesirableorintendedobjective.Itmaybeviewedastheoppositeofsuccess.Productfailurerangesfromfailuretoselltheproducttofractureoftheproduct,intheworstcasesleadingtopersonalinjury,theprovinceofforensicengineering.So you need to quickly iden
11、tify Scrum Smells.2009 Scrum的误区的误区: 丢失节奏丢失节奏不一致的Scrum每日例会Scrum每日例会被省略会议的时间老是变化不一致的Sprint周期Sprint周期在中期被武断得改变不一致的Sprint计划会议Sprint计划会议被省略保持一致性和协调性在Scrum当中避免混乱和杂音，专注于交付本身明确的阐明预期进行适当的引导和培训求助于基本的Scrum规则节奏能够帮助我们走上正轨如何解决如何解决如何解决如何解决如何解决如何解决2009 Scrum的的误区区: 随意随意讲话的的鸡项目干系人在Scrum每日例会上款款而谈产品功能的选择在Sprint计划会议之外进行
12、没有外部人员的肯定，团队没有办法做纯技术上的决策项目的状态分析在Sprint计划会议之外进行执行者试图干预团队产品需求调整或不被理睬始终如一的防止狼群的骚扰指导和培训作为项目启动的一部分在项目启动过程中认定角色通过回顾加固预期把鸡从猪圈里赶出去适当的变更会议时间和地点或许鸡可以下蛋成为一个称职的牧羊犬团队成员活在不恰当的技术决策的痛苦当中vs.干系人感觉被强制的为团队做决定如何解决如何解决如何解决如何解决如何解决如何解决2009 Scrum误区误区: 被遗忘的猪被遗忘的猪不清晰和明确的期望?竞争性的分配?缺乏担当?管理上的干涉?厌烦?恐惧?角色框架变更会议的时间和地点解释,说服,和商讨拥抱技术
13、改组团队团队成员活在不恰当的技术决策的痛苦当中vs.干系人感觉被强制的为团队做决定如何解决如何解决如何解决如何解决如何解决如何解决2009 Scrum误区区: 缺少缺少进展展 Backlog持续的增长而不是减少手头正在做的工作太多了功能特性感觉永无止境90%完成综合症总是基于已完成的功能特性不断进行修改和修复已完成的功能正在等待未完成的项目干系人抱怨缺少进展失败得交付需求可以尽早的看到其进展、尽早的看到其价值以及按时地完成对于客户存在极大价值的功能特性可以很容易的构造“零缺陷”的产品总是对即将交付的产品保持承诺总是愿意去问,“是否没有交付有用的可执行的代码,有什么好处呢?”意识到缺陷是不可避免
14、的良好的Sprint backlog管理如何解决如何解决如何解决如何解决如何解决如何解决2009 Scrum 误区误区: ScrumMaster 超越了自身的职责超越了自身的职责工作是由ScrumMaster分配的，而不是由开发人员自己去认领的团队无法自己掌控工作Scrum每日例会感觉是团队成员在向ScrumMaster汇报工作进展让团队自己掌控工作团队自己来做任务分配Scrum每日例会由团队参与并且最终是为了团队团队的自组织和自管理是Scrum的核心原则之一如何解决如何解决如何解决如何解决如何解决如何解决2009 Scrum误区误区: 明确的工作职责明确的工作职责 项目团队具有非常专一的工作
15、角色划分和描述：架构师,设计人员,DBA,or测试人员,团队包括专门的测试人员Scrum团队没有“我们大家在一起”的态度Scrum团队不需要完全有多面手组成工作由团队自己分配Scrum每日例会可以进行工作的分配每个专家都要对整个系统负责“我将尽一切我所能来帮助团队”的态度“同舟共济” 的态度如何解决如何解决如何解决如何解决如何解决如何解决2009 Scrum误区误区: 来自执行者的压力来自执行者的压力执行者要求团队承诺在一个确定的日期发布一系列的所谓的“最低要求”功能项执行者参加团队会议执行者直接和团队成员沟通，并提醒他们最后期限私下里和执行者沟通，告诉他们他们的做法和期望可能背道而驰询问执行
16、者到底什么是他们真正关心的，依此来指导团队让产品负责人和执行者就产品的优先级问题进行充分的商讨支持它，承诺必须来之团队如何解决如何解决如何解决如何解决如何解决如何解决2009 Scrum 误区误区: 不像一个良好的团队不像一个良好的团队 固定的角色任务是被分配的没有互相帮助没有持续的指导用户需求没有被团队广泛的达成共识，所有的工作都是并行完成的缺少协作在Scrum会议上没有互相的交流和倾听没有欢笑相反一个合作愉快的团队总是充满欢笑用榜样和指导者来领导，并帮助团队成员完成他们的任务打破竖井和一成不变的角色适当的改变团队架构来鼓励团队而不是个人英雄主义鼓励结对编程,代码复查等能够促进团队协作和交流
17、的实践活动Scrum项目的效率来自作为一个整体的团队如何解决如何解决如何解决如何解决如何解决如何解决2009 Scrum误区误区: 大猩猩在房间里大猩猩在房间里一个人(资深开发人员,技术带头人,主管人员)支配交流和会议大家不愿意发言直到大猩猩开口发言团队成员对大猩猩的观点言听计从让大猩猩在每个问题的最后发言让大猩猩多问问题而不是下结论需要考量大猩猩是不是必须的参与者?可以让其适当的缺席一二次会议在某些情况下，有必要让项目干系人永远离开会议(因为即使没有发言，他们也可以对团队产生极大的影响)团队的智慧 vs. 个人的天赋如何解决如何解决如何解决如何解决如何解决如何解决2009 议程有效的实施Sc
18、rum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发2009 Rational Team Concert对于敏捷实践的支持对于敏捷实践的支持仪表盘仪表盘增量设计增量设计持续集成持续集成测试驱动得开发测试驱动得开发迭代迭代/冲刺冲刺构建构建工作项工作项配置管理配置管理Backlog（需求）（需求）敏捷和适应性敏捷和适应性流程流程212009 内置了内置了Scrum等多种敏捷方法模板等多种敏捷方法模板n创建ProjectArea时选择需要的模板n包含了Scrum，EclipseWay，OpenUP等流行的敏捷方法论模板n用户可以对模版进行配置和修改2009 Scrum过程模版过程
19、模版 角色和权限角色和权限2009 常用工作项类型常用工作项类型Scrum过程模版中所包含的常用工作项类型:A.Defect: 在项目开发的过程中在项目开发的过程中,对于缺陷的追踪管理对于缺陷的追踪管理B.Story: 用户需求用户需求,通过一两句用户的业务语言所描述的文档化的需求通过一两句用户的业务语言所描述的文档化的需求C.Retrospective: 在每个冲刺之后由项目组召开的冲刺回顾会议在每个冲刺之后由项目组召开的冲刺回顾会议,用来讨论用来讨论和总结这次迭代中和总结这次迭代中,一些好的成功的经验一些好的成功的经验,同时还有那些不足的地方需要改同时还有那些不足的地方需要改进进.最后就在
20、以后的迭代中如何更好的工作达成一致的建议最后就在以后的迭代中如何更好的工作达成一致的建议. D.Impediment: 阻碍和风险阻碍和风险,妨碍团队成功的达到迭代和冲刺的目标妨碍团队成功的达到迭代和冲刺的目标2009 B. 用户需求工作项用户需求工作项: 状态流状态流(生命周期生命周期)2009 创建自管理的团队（创建自管理的团队（Scrum角色支持）角色支持）2009 定义自管理团队的流程（定义自管理团队的流程（Scrum流程支持）流程支持）为团队定义自己的流程2009 管理项目计划和迭代（管理项目计划和迭代（Sprint）2009 增加工作项（增加工作项（work item），全面支持）
21、，全面支持Scrum所需的工作产品所需的工作产品2009 Product Backlog和和Sprint Backlog2009 Sprint Planning Meeting上，上，选择Product Backlog作作为Sprint Backlog2009 为为Product Backlog和和Sprint Backlog定义其他信息，例如：迭代目标等等定义其他信息，例如：迭代目标等等为为Product Backlog和和Sprint Backlog定义任务定义任务2009 Sprint plan中，利用中，利用Task组织选定的定的Product Backlog（Sprint Backl
22、og），并分配），并分配给Team Member2009 基于上下文的团队协作基于上下文的团队协作我可以2009 基于上下文的团队协作基于上下文的团队协作我还可以2009 查看了解工作状态，项目状态查看了解工作状态，项目状态2009 预定义和自定义的各种报告全面监控预定义和自定义的各种报告全面监控Scrum流程信息流程信息2009 Burndown Chart 看看是不是出现问题了？看看是不是出现问题了？2009 Scrum Dashboard2009 RTC可以增强业务敏捷性和保持项目的成功概率可以增强业务敏捷性和保持项目的成功概率促进高效能团队的原则促进高效能团队的原则工作工作工作工作软软
23、件件件件人人人人员员交互交互交互交互响响响响应变应变更更更更客客客客户协户协作作作作透明目的共同性项目健康状况检查上下文驱动流程的灵活性迭代的计划执行多次发布JIT代码审查启动特设团队团队感知流程感知特设共享持续集成管理团队资源变更驱动的已集成的/可追溯的IBM Rational Team Concerttransparentintegrated presencewikisOPENreal-timereporting chatautomatedhand-offsWeb2.0custom dashboards automateddatagathering EXTENSIBILITY Eclips
24、e plug-ins servicesarchitecture FREEDOM TO CREATE支持任何流程的设定，包括敏捷支持任何流程的设定，包括敏捷 2009 议程有效的实施Scrum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发2009 地理上分布的开地理上分布的开发团队如何采用如何采用RTC实施施ScrumDevelopment AustraliaRational Team Concert for System z配置管理配置管理工作项管理工作项管理构建构建DevelopmentRTP, USDevelopmentFranceUASVL, USBidiIsraelB
25、idiEgypt2009 采用采用RTC开发开发RTCz 项目项目RTCz开发的项目信息SRTCzforSystemzProject基于Scrum过程模版地理上分布的开发团队两个主要的Scrum开发小组RTP(Raleigh,US)FASL(France&Australia)两个并行开发线Maindevelopment（主开发流）Releasev2.0within6SprintsIPDProductDelivery（产品集成发布流）2009 RTCz 项目干系人角色项目干系人角色, 可以称之为可以称之为“鸡鸡”PMC（产品管理委员会）Stakeholder:DannyMace,DavidMye
26、rsPMC:Pamela,Rosalind,Teresa,Sandra,Alex,Nicolas,Robin,Jean-YvesIPDProductDeliveryStakeholder:DannyMace,DavidMyersPMC:Pamela,Rosalind,Teresa,Sandra,Nicolas2009 RTCz 开发角色开发角色, 我们可以称之为我们可以称之为“猪猪”RTCz项目产品负责人:GuyRTPScrum(Raleigh Scrum团队)ScrumMaster:RobinTeamMember:Bruce,Andrew,Daniel,HungJohn,Matt,Steve
27、,TamiFASLScrum(France & Australia Scrum团队)ScrumMaster:Jean-YvesTeamMember:Valrie,Liam,Nicolas,Jean-Bernard,Pierre,Pascal,XavierUATeamMember:Stephanie,JocelynBidiTeamMember:Adir,Gregory,Heba,Mohamed,Ramy,SemionSUPATeamMember:Mordechai,Uri2009 RTCz Scrum 过程过程首先是基于标准的Scrum过程模版角色PMC:产品管理委员会(基于项目干系人角色)新增的工作项类型Minutes:会议记录修改了缺省的权限PMC能够来修改迭代计划当有项目成员新增时，增加新的自动化的任务automatictasksJoiningaTeamUpdateyourcalendarwithyourScheduledAbsencesJoiningaTeamUpdateyourWorkEnvironment2009 2009
