敏捷软件开发管理-IBM孙昕.ppt

1、敏捷软件开发管理,IBM 高级技术顾问 孙昕,议程,如何有效的实施Scrum 第一款全面支持敏捷开发的工具 成功案例分享：IBM如何实现敏捷开发,敏捷宣言,Individuals and interactions over processes and tools (人和交互重于过程和工具 ) Working software over comprehensive documentation (可以工作的软件重于面面俱到的文档) Customer collaboration over contract negotiation (客户合作重于合同谈判) Responding to change o

2、ver following 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总体骨

4、架,7,Scrum总体骨架,使用Scrum of Scrums来进行扩展,Scrum对大型和小型的开发团队都有着良好的适应性 可以增加团队的层次，比如： 几个相互依赖的Scrum团队需要沟通 几个团队一起工作于一个单一的产品，并且团队间需要内部相互依赖 通过多层团队的建立来拓展不确定的项目规模 由团队来决定频率和是否出席和参与 Technical contributor 不需要Product Owner或者ScrumMaster, 但是他们可以协助,Are you about to put something in another teams way?,成功的Scrum需要做好准备工作,有准备

5、的 让正确的人来担当适当的Scrum的角色 具有良好的产品需求的规划以及需求的优先级的排序 开发和测试环境已经准备就绪 团队知道如何将产品需求转化为可装配和可运行的产品增量 扎实的 由团队来评估和估算产品需求项 产品负责人确定冲刺的目标并就相关的产品需求和团队进行讨论 由团队来决定它的可用性 ScrumMaster准备相关会议 GO! 项目已经初始化 第一个sprint计划会议可以开始启动,Well done. Good luck and enjoy!,Scrum项目也可能会失败,失败 摘自维基百科, 自由的百科全书,Failure (colloquially fail, phail or f

6、lop) in general refers to the 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

7、engineering. ,So you need to quickly identify Scrum Smells.,Scrum的误区: 丢失节奏,不一致的Scrum每日例会 Scrum每日例会被省略 会议的时间老是变化 不一致的Sprint周期 Sprint周期在中期被武断得改变 不一致的Sprint计划会议 Sprint计划会议被省略,Scrum的误区: 随意讲话的鸡,项目干系人在Scrum每日例会上款款而谈 产品功能的选择在Sprint计划会议之外进行 没有外部人员的肯定，团队没有办法做纯技术上的决策 项目的状态分析在Sprint计划会议之外进行 执行者试图干预团队 产品需求调整或不被

8、理睬,Scrum误区: 被遗忘的猪,不清晰和明确的期望? 竞争性的分配? 缺乏担当? 管理上的干涉? 厌烦? 恐惧?,Scrum误区: 缺少进展,Backlog持续的增长而不是减少 手头正在做的工作太多了 功能特性感觉永无止境 90%完成综合症 总是基于已完成的功能特性不断进行修改和修复 已完成的功能正在等待未完成的 项目干系人抱怨缺少进展 失败得交付,Scrum 误区: ScrumMaster 超越了自身的职责,工作是由ScrumMaster分配的，而不是由开发人员自己去认领的 团队无法自己掌控工作 Scrum每日例会感觉是团队成员在向ScrumMaster汇报工作进展,Scrum误区: 明

9、确的工作职责,项目团队具有非常专一的工作角色划分和描述： 架构师, 设计人员, DBA, or 测试人员, 团队包括专门的测试人员 Scrum团队没有“我们大家在一起”的态度 Scrum团队不需要完全有多面手组成,Scrum误区: 来自执行者的压力,执行者要求团队承诺在一个确定的日期发布一系列的所谓的“最低要求”功能项 执行者参加团队会议 执行者直接和团队成员沟通，并提醒他们最后期限,Scrum 误区: 不像一个良好的团队,固定的角色 任务是被分配的 没有互相帮助 没有持续的指导 用户需求没有被团队广泛的达成共识，所有的工作都是并行完成的 缺少协作 在Scrum会议上没有互相的交流和倾听 没有

10、欢笑 相反一个合作愉快的团队总是充满欢笑,Scrum误区: 大猩猩在房间里,一个人 (资深开发人员, 技术带头人, 主管人员) 支配交流和会议 大家不愿意发言直到大猩猩开口发言 团队成员对大猩猩的观点言听计从,议程,有效的实施Scrum 第一款全面支持敏捷开发的工具 成功案例分享：IBM如何实现敏捷开发,Rational Team Concert对于敏捷实践的支持,仪表盘,构建,工作项,配置管理,敏捷和适应性,流程,21,内置了Scrum等多种敏捷方法模板,创建Project Area时选择需要的模板 包含了Scrum，Eclipse Way，OpenUP等流行的敏捷方法论模板 用户可以对模版

11、进行配置和修改,Scrum过程模版 角色和权限,常用工作项类型,Scrum过程模版中所包含的常用工作项类型: Defect: 在项目开发的过程中,对于缺陷的追踪管理 Story: 用户需求,通过一两句用户的业务语言所描述的文档化的需求 Retrospective: 在每个冲刺之后由项目组召开的冲刺回顾会议,用来讨论和总结这次迭代中,一些好的成功的经验,同时还有那些不足的地方需要改进.最后就在以后的迭代中如何更好的工作达成一致的建议. Impediment: 阻碍和风险,妨碍团队成功的达到迭代和冲刺的目标,B. 用户需求工作项: 状态流(生命周期),创建自管理的团队（Scrum角色支持）,定义自

12、管理团队的流程（Scrum流程支持）,为团队定义自己的流程,管理项目计划和迭代（Sprint）,增加工作项（work item），全面支持Scrum所需的工作产品,Product Backlog和Sprint Backlog,Sprint Planning Meeting上，选择Product Backlog作为Sprint Backlog,为Product Backlog和Sprint Backlog定义其他信息，例如：迭代目标等等为Product Backlog和Sprint Backlog定义任务,Sprint plan中，利用Task组织选定的Product Backlog（Sprin

13、t Backlog），并分配给Team Member,基于上下文的团队协作,我可以,基于上下文的团队协作,我还可以,查看了解工作状态，项目状态,预定义和自定义的各种报告全面监控Scrum流程信息,Burndown Chart,看看是不是出现问题了？,Scrum Dashboard,RTC可以增强业务敏捷性和保持项目的成功概率,促进高效能团队的原则,响应变更,客户协作,透明 目的共同性 项目健康状况检查 上下文驱动,流程的灵活性 迭代的计划执行 多次发布 JIT代码审查,启动特设团队 团队感知 流程感知 特设共享,持续集成 管理团队资源 变更驱动的 已集成的 / 可追溯的,支持任何流程的设定，包

14、括敏捷,议程,有效的实施Scrum 第一款全面支持敏捷开发的工具 成功案例分享：IBM如何实现敏捷开发,地理上分布的开发团队如何采用RTC实施Scrum,BidiEgypt,采用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 Sprints IP

15、D Product Delivery（产品集成发布流）,RTCz 项目干系人角色, 可以称之为“鸡”,PMC（产品管理委员会） Stakeholder: Danny Mace, David Myers PMC: Pamela, Rosalind, Teresa, Sandra, Alex, Nicolas, Robin, Jean-Yves IPD Product Delivery Stakeholder: Danny Mace, David Myers PMC: Pamela, Rosalind, Teresa, Sandra, Nicolas,RTCz 开发角色, 我们可以称之为“猪”,R

16、TCz 项目 产品负责人: Guy RTP Scrum (Raleigh Scrum团队) ScrumMaster: Robin Team Member: Bruce, Andrew, Daniel, Hung John, Matt, Steve, Tami FASL Scrum (France & Australia Scrum团队) ScrumMaster: Jean-Yves Team Member: Valrie, Liam, Nicolas, Jean-Bernard, Pierre, Pascal, Xavier UA Team Member: Stephanie, Jocelyn Bidi Team Member: Adir, Gregory, Heba, Mohamed, Ramy, Semion SUPA Team Member: Mordechai, Uri,RTCz