Scrum 框架及其背后的原则


Scrum 框架及其背后的原则 第一部分:Scrum 的框架 Scrum 并不是一个特定产品开发的流程或技术,而是一个容纳其它流程和技术的框架。作为一 个迭代和增量的产品开发框架,Scrum 本身十分简单和明确。下面的一段伪代码,是对 Scrum 框架的完整表述。 void run_scrum() { const int Sprint_Length = 10; int velocity = get_past_performance(); // Scrum 中的三个角色 Role team, product_owner, ScrumMaster; // Scrum 中的制品 Product_Backlog product_backlog; Sprint_Backlog sprint_backlog; Burndown_Chart sprint_burndown_chart, release_burndown_chart; Product_Increment product_increment; //开始项目的三个准备条件 setup_team(team); define_Definition_of_Done(team, product_owner); initial_project(&product_backlog ); //标红的为输出参数,将带回值,下同 //每一次 while 循环为一次迭代 while (!is_empty(product_backlog)) { run_sprint_planning_meeting(product_backlog, velocity, &sprint_backlog); //每一次 for 循环为一个工作日 for(num_of_day = 1; num_of_day <= Sprint_Length; num_of_day ++){ run_daily_scrum_meeting(&sprint_burndown_chart); do_development_activity(sprint_backlog, &product_increment); } run_sprint_review_meeting(product_backlog, product_increment); run_retrospective_meeting(); update_product_backlog(&product_backlog, &release_burndown_chart); update_velocity(&velocity); } } 这就是 Scrum 的完整框架,只有这些,很简单,我们下面将逐行解释。 const int Sprint_Length = 10; int velocity = get_past_performance(); Scrum 是一个迭代开发模型。每一个迭代周期,团队完成一部分产品需求,交付可工作的软件。 在 Scrum 中,迭代被称为 sprint (本意为冲刺跑,一般不作翻译),典型的 sprint 长度是 1 到 4 周。值得强调的是,对于同一团队,sprint 的长度是固定不变的。 Sprint_Length -- Sprint 长度:这里以 10 个工作日(两周)为例,const 常量修饰符,强调了 其不可变性。 Velocity -- 团队开发速率:也即每个 sprint 团队能完成多少量的用户需求,它是 Scrum 中计划 和承诺的最重要依据。开发速率来源自过去实际产出结果,并在产品开发过程中不断修正。 Role team, product_owner, ScrumMaster; 以上的实体定义是 Scrum 中的三个关键角色,在 Scrum 框架中也仅仅定义了这三个角色。 Team -- 团队:团队负责产品交付,规模一般为 5~9 人,Scrum 强调团队的多功能(cross functional)和自组织。多功能指的是,团队应该整体具备各个职能所需的技能,如系统,开发 和测试技能,同时也具备各个组件的技能如数据库设计、协议开发和 UI 设计等。团队的多功能 是短迭代开发的基础,只有做到这一点,独立的团队才可能在一个 sprint 中交付对用户有意义 的产品增量。自组织指,在目标清晰的前提下由团队自主决定完成目标的具体方法。 Product Owner – 产品负责人: 多直接称为 PO。PO 负责把握产品的方向,包括需求的收集、 定义,优先级设定等。PO 通过这些活动以及和团队的合作,最终确保产品 ROI(return of investment, 投资回报)的最大化。 ScrumMaster: 一般不作中文翻译,ScrumMaster 并不直接负责产品交付,它向团队负责,确 保团队按照 Scrum 的框架工作,具备良好的外部和内部工作环境,顺畅地交付产品,并不断的 改进,提升交付的效率和质量。与传统意义上的管理者不同,ScrumMaster 更多是起服务、协 调和引领的作用。如果注意观察会发现,在这段程序中,ScrumMaster 是一个定义,但从未使 用的变量,这也正反映了 ScrumMaster 的协调和支持的作用。 Product_Backlog product_backlog; Sprint_Backlog sprint_backlog; Burndown_Chart sprint_burndown_chart, release_burndown_chart; Product_Increment product_increment; 上面的结构变量是 Scrum 中的核心制品,它们贯穿整个 Scrum 操作过程,分别是: Product backlog -- 产品待办事项:很多时候直接用英文表示,简称 PB,是一份用户需求列表。 其中的每一项都是一个具体的端到端的用户需求,如“用户可以完成登录”等等。Scrum 产品开 发过程就是,通过一系列的 sprint,每个 sprint 完成一部分“产品待办事项”,交付包含这些需求 实现的产品增量,直至完成所有“产品待办事项”。Product backlog 的责任人是 Product Owner, 它在产品开发的初期生成,并在开发过程中不断更新完善。 Sprint backlog -- sprint 待办事项:是一个 sprint 中要完成的任务列表。其中的项目是为完成 特定用户需求而要进行的设计、开发、集成、测试等具体任务,如“为模块 A 添加外部接口”等。 完成sprint backlog中的所有任务,也意味着sprint 开发任务的完成,对应的用户需求可以交付。 Sprint backlog,在 spirnt 计划会议上生成,在开发过程中,可能会有所调整。 Sprint burndown chart – sprint 燃尽图:以坐标图表示团队在一个 sprint 中工作进展情况, 横坐标是 sprint 已进行的实际天数,纵坐标是还剩余的任务需要的时间的总和。它直观的反应 了 sprint 实际执行与计划的比较,以及团队离 sprint 的目标完成的距离。 Release burndown chart – 发布燃尽图:以坐标图表示当前版本的需求完成进展情况,横坐标 是已经进行的 sprint 的个数,纵坐标是待完成的用户需求的多少。它直观的反应了产品需求的 完成情况,以及团队离完成版本完全发布的距离。 Product increment -- 产品增量:Scrum 要求每一个 sprint 结束都产生用户可用的软件,也被 称着“潜在可交付的产品增量”(Potential shippable product increment, PSPI),事实上交付与 否还要受用户习惯的约束。能否每个 sprint 生成满足质量定义的 PSPI 是 Scrum 执行效果的试 金石。 setup_team(Team); define_Definition_of_Done(team, product_owner); initial_project(&product_backlog ); 上面代码中的三步操作是 Scrum 执行开始的准备条件。 Setup Team – 创建团队:创立和建设适合的团队是 Scrum 实施的第一步工作,团队应该满足 上面定义的 Scrum 团队的基本属性,并形成自己的目标和愿景,理解 Scrum 工作模式。 Define Definition of Done – 定义完成标准:完成标准,是指一个用户需求完成应该满足什么 样的标准。它是 Product Owner 和 团队之间的一个约定,有了这个约定,当团队说,这个需求 完成了的时候,Product Owner 将明确知道这意味着什么,比如是否包含了针对这个需求的性 能测试,或是否包含相应的用户使用手册等。在实际运用中,由于条件限制,团队在一开始可能 无法做到 sprint 结果可交付,而会剩余一部分工作在交付前完成,如性能测试等,这一部分工 作被称为“undone”的工作。完成标准在特定时间是固定的,但随着团队成熟度提高,团队应逐步 扩展自己的完成标准,使其逼近向客户交付的条件,undone 的部分越来越少。 Initial Project – 启动项目:项目启动,是项目进入开发阶段前的一系列准备工作,如:项目目 标的设定,项目初始需求的定义和澄清,工作量的估计,风险的识别,关键设计决策的产生,开 发基础设施的选择和构建等。一般由客户(如果可能),PO,团队以及相关干系人共同参与项 目启动。项目启动最重要的是输出一个初始 product backlog,它应该包含对其中条目的大小的 估计和优先级别的设定。 上面三个操作的结果是,有了合适的 Scrum 团队,团队和 PO 之间就需求完成的标准达成一致 的定义,并生成了一份初始的 product backlog。有了这三个条件便可以正式进入迭代开发了。 While (!is_empty(product_backlog)) { run_sprint_planning_meeting(product_backlog, velocity, &sprint_backlog); …… 每一次 while 循环代表一个 sprint 周期,直至 product backlog 中所有的需求被开发完成。 Run sprint planning meeting – 进行 sprint 计划会议: sprint 规划会议规划这个 sprint 目标 和具体任务安排,它标志着一个 sprint 的开始。在 sprint 计划会议上要依次完成以下的内容: 1. 团队决定在接下来的的 sprint 中要完成的用户需求,如过对需求存在疑问,团队应和 PO 进行澄清和确认。团队必须按照 PO 设定的 product backlog 的优先级别,从高到低 选择,如因实现上的依赖关系,要调整需求选择的顺序,也需要和 PO 进行确认,以确 保团队始终工作在最有价值的需求上。关于承诺多少需求,也并非取决于团队或专家的 主观判断,而是根据 product backlog 中对每一个需求的大小估计,以及团队过去的实 际开发速率(velocity),承诺相匹配数量的需求。 2. 针对所选择需求的实现,进行简单和必要的沟通、分析。以确保第三步可以顺利的进行。 3. 分别将每一个需求,分解成设计、开发和测试等任务。并估计每一个任务所需的工作量 (通常以小时计)。 Sprint 计划会议由团队主导,但需要 PO 的贡献,特别是上面的第一条,需要 PO 的现场参与。 其它条目,即使 PO 不在场,也应该随时可以提供远程的咨询。 作为 sprint 计划会议的结果,团队选择并承诺了接下来 sprint 中要完成的 product backlog 中的 用户需求,并且,将每一个需求分解成具体的多个开发任务。这些开发任务的列表被称为 sprint backlog,它是 sprint 计划会议的最重要输出,接下来的工作,就是完成这些开发任务,交付对 应的用户需求。 for(num_of_day = 1; num_of_day <= Sprint_Length; num_of_day ++){ run_daily_scrum_meeting(); update_burndown_chart(); do_development_activity(sprint_backlog, &product_increment); } 在这里,每一次 for 循环代表一个工作日,循环的次数也即 sprint 的时间长度。 Run daily scrum meeting – 进行每日 Scrum 会议: Scrum 团队每天都会进行一次同步 -- Scrum 会议。Scrum 会议被限定在 15 分钟之内结束,每一天在同样的时间,同样的地点举行, 旨在沟通同步项目开发状态,建立团队对项目的整体认识,并发现项目中的问题。会议上,每一 个人都向团队回答三个问题:我昨天做了什么?我今天计划做什么?在前进的道路上有什么障碍? Scrum 会议结束后,要更新 sprint 燃尽图以反映团队的工作进度,和离 sprint 目标的距离。 Do development activity – 进行开发工作:Scrum 强调团队成员间的紧密协作,原则上任务应 该由团队成员主动认领,而非被分配。为此,团队需要形成相应的规则,如:在同一时刻,不应 该并行开始过多用户需求开发,这样可以确保团队有明确的工作重点,也可以避免在 sprint 结 束时所有的需求都只是部分完成,而交付不了任何有价值的软件增量。随着开发进程的不断进展, 软件增量得以生成、扩展和验证。 run_sprint_review_meeting(product_backlog, product_increment); run_retrospective_meeting(); Run sprint review meeting – 进行 sprint 评审会议:Sprint 评审会议又称为 sprint 演示会议, 一个 sprint 结束,团队构建了包含新的用户需求的产品增量,团队在这个会议上展示过去的一个 sprint 所构建的产品。sprint 评审会议是开放的,应尽可能邀请相关人员参加,ScrumMaster、 团队、PO、市场人员、客户、管理人员、维护人员、领域专家以及关联团队等。在会议上团队 对照 product backlog 依次演示刚刚构建的用户需求,获取参与者的反馈,这些反馈将成为未来 的产品设计和规划调整的依据,以使产品更好的满足客户的需求,更好的服务于组织的业务目标。 Run retrospective meeting – 进行 sprint 团队回顾会议:在评审会议之后,团队进行回顾会 议,评审会议是对产品的检查和调整,而回顾会议是团队对自身的检查和调整。Scrum 强调通 过经验性的过程,逐步检查和调整团队的协作和工作模式,持续改善。回顾会议是 Scrum 运行 的十分重要的一环,其有效性是 Scrum 实施成功的保障。除非团队决定邀请额外人员,回顾会 议一般只有团队参加,在回顾会议上,团队回顾刚刚过去的一个 sprint,团 队在哪些方面做得好, 应该坚持;哪些方面有待改进,并挖掘其本质原因,定义具体的改进计划,以在下一个 sprint 去切实实施。为保证回顾会议的有效,组织和团队都应该承诺愿意做出适应性的改变。 update_product_backlog(&product_backlog, &release_burndown_chart); update_velocity(&velocity); Update product backlog -- 更新产品待办事项:sprint 结束,产品待办事项内的一部分需求被 交付,应该更新其状态。此外,由于 PO 和团队获取了更准确和详细的产品信息,product backlog 也应该相应更新,例如在 sprint 回顾会议激发了用户对优先级新的认识,在同 PO 确认后, product backlog 的优先级定义就需要做出相应的调整。更新产品待办事项的同时,发布燃尽图 也需要相应更改,以反映最新的需求完成情况。 Update velocity – 更新团队开发速率:前面提到,团队承诺多少需求的依据是团队过去的开发 速率。每个 sprint 结束,团队的参考发速率都需要根据实际情况做修正,这将有助于更好地把握 开发节奏,合理地计划未来的工作。 至此,一个 sprint 结束,潜在可交付的产品增量得以交付或演示,团队和 PO 获取了有意义的 反馈, product backlog 得到了调整,团队对工作进行了反思并定义了改进方案。这时就可以 进入下一个 sprint,直至交付整个产品。 总结 Scrum 框架为团队敏捷实施定义了一个简单和明确的边界。在边界之内,团队探索和完善相关 的管理和技术实践。我们一般建议,开始尝试 Scrum 的组织最初应严格遵循框架的定义,这时 常会引起过于教条和形式主义的争议,团队会提出“应该抓住 Scrum 的实质,而不是强调形式”。 问题是,只有通过严格的基本实践的学习和应用,我们才可能掌握其原则,区分哪些是实质,哪 些是可以调整的形式。Ken Schwaber 对此的描述是,“对 Scrum 规则的修改,只有在 ScrumMaster 确信团队足够深入的掌握了 Scrum 的运行原理,有足够的技能和思维来修改规则 时才可以进行”。 我们建议,那些准备实施Scrum 或者已经实施但还处于探索中的团队,可以打印出这段伪代码, 对照自身的实际操作,任何与这段伪代码不符的地方,团队都应该认真思考其合理性。我们更加 建议,团队在实施 Scrum 的过程中,深入理解和思考 Scrum 框架背后的价值观和原则,Scrum 为什么可以和将怎样改进产品开发,为此我们需要做出哪些改变。对原则的理解和思考,有助于 我们对实践的更好掌握,更快的从 Scrum 中受益。这也将是本文的第二部分要讨论的内容。(待 续……) 本文在上半部分以伪代码的形式讲述了 Scrum 的基本框架,图(一)是对该框架的总结。如此 简单的框架如何能提升组织的能力?做到什么才能保障 Scrum 实施的成功,并从中受益?理解 和贯彻 Scrum 框架背后的原则是关键。 图(一)Scrum 总体框架 PPT 格式大图下载链接 为了说明这些原则与 Scrum 框架的对应关系,在图(一)中我们以 Scrum 框架为索引,列出 了相对应的原则(见图中蓝色框),它们分别是: 1. 产品开发过程相关的原则 o 高度透明 o 不断反馈调整 2. 团队组织相关的原则 o 多功能 o 自组织 3. 持续改进相关的原则 o 将改进嵌入开发过程 o 不断暴露和解决问题 以下我们将分别对这三个方面原则进行讨论,并就每个方面分析 Scrum 实施过程中的不良症状。 产品开发过程 Scrum 是一个经验性(empirical)的过程,透明(transparent)、检验(inspect)和调整(adapt)是 它的三个支柱。Scrum 的产品开发过程是高度透明和不断反馈调整的自适应过程。 需要特别强调的是,与传统开发过程相比,Scrum 引入了一个根本性变化 —— 在每个固定长度 的迭代周期(spirnt)产出潜在可交付的产品增量(potential shippable product incremental - PSPI)。这是透明、检验和调整的基础,能否做到这一点是 Scrum 实施成功与否的试金石。 Scrum 产品开发过程应该做到高度透明 透明是团队合作信任,以及对产品开发过程进行检验、调整的前提。为了做到真正的透明,Scrum 开发过程中影响到最终结果的各个方面都应该是可见和可信的。在 Scrum 实施过程中要做到: a) 遵循共同的框架 共同的迭代和增量开发框架为开发过程的透明提供了统一的基准,Scrum 框架下的制品 (Artifacts)是高度透明:  Product backlog 反映了用户需求,以及它们的开发工作量、优先级和当前状态;  Sprint backlog 反映了 sprint 的目标、工作任务和当前状态;  发布燃尽图反映了项目的整体工作进展状态;  Sprint 燃尽图反映了当前 sprint 的进展状态 Scrum 的四个标准活动(event) —— sprint 计划会议、每日 Scrum 会议、sprint 评审和 sprint 回顾进一步促进了透明。 b) 信息真实可信 透明的信息为 PO 和团队提供了决策依据,信息可信与否直接影响决策质量的高低。敏捷开发的 透明性内建于开发活动当中,保证了其真实可靠。这些信息,即时从版本层面、迭代层面和日常 工作层面,反映项目的最新状态。 信息的可信还体现在,对相同信息的一致理解。例如,当声明一个需求已经完成时,PO 的预期 应该和团队的理解应该是一致的,这就是完成标准定义(Defintion of Done -- DoD),它必须清 晰明确,并被严格遵循。 c) 以最高效的方式及时沟通信息 良好的沟通促进透明。团队坐在一起,面对面的交流是最高效的沟通方式;有效的会议组织能改 善计划、评审以及回顾活动的效果;一个良好的可视化工作空间(如白板墙等),可以促进信息 的发布和交流,具体可参见《借助信息化工作空间实现高效的团队自我管理》。总之,采取一切 可能的手段改善团队内部以及团队对外的沟通。 d) 持续交付带来最可靠的透明 向客户交付产品,可以让团队得到最直接和真实的反馈,可运行的软件不会撒谎。受产品特性和 团队成熟度的限制,并不是所有的团队一开始就能做到每个 sprint 向客户交付软件。但团队应努 力让迭代的结果更接近交付的标准,并力争更频繁的实际交付,每一次交付都是对产品开发成果 和团队过程能力的检验,。 Scrum 开发过程中应该不断反馈调整 在传统开发过程中,团队根据目标制定计划,而后严格按照计划执行以达成目标,这是所谓定义 性的开发过程。然而计划可能不合理,执行过程可能出现偏差,这都会使结果偏离预设的目标。 即使计划被完美的执行,目标本身也会发生迁移,实际的业务目标和最初的设想总会有差距。如 图(二)所示,定义性的开发过程对于软件开发这样复杂的活动并不适用。 图(二)定义性的开发过程 Scrum 倡导“经验性”的开发过程。如图(三)所示,在开发过程中团队不断检查和汲取反馈, 调整下一步的行动,动态达成目标。经验性的开发过程让团队在复杂的市场和技术环境中更好的 把握和实现业务目标,取得竞争优势。为实现有效的调整和反馈,组织要做到: 图(三)经验性的开发过程 a) 周期性的检验和调整 Scrum 框架中包含多个检验和调整的反馈循环。每日 Scrum 会议上团队检验工作进展,和 sprint 目标进行比较,调整接下来的工作以更好地达成目标;Sprint 评审会议上,团队演示软件,获取 业务人员和客户的反馈,及时调整产品的方向以及开发计划。通过不断的检验和调整,团队和客 户持续修正产品开发方向和计划,更好的实现商务目标。 b) 业务人员更紧密的参与开发过程 不管业务人员还是用户,都不可能在项目一开始就准确无误地把握产品方向和定义完整的需求, 它们需要在开发过程中不断的被修订、调整和完善。如果,业务人员不参与到开发过程当中去, 在项目结束时就可能会出现“团队开发的产品和业务人员的定义不符”,或者“团队开发的与当初业 务人员所定义相符,但却不是业务人员和市场需要的产品了”。 业务人员参与开发过程,一方面团队能够及时获得对产品目标和需求的澄清和确认,确保双方的 理解一致;另一方面,通过参与开发过程,业务人员更准确地理解客户需、把握产品目标,并做 出及时的调整。 针对开发过程的不良症状分析 excel 版本下载 团队组织 通过 Scrum 开发过程的实施,组织更快的交付价值,更灵活的适应变化。同时,Scrum 的实施 对团队组织提出了新的要求。典型的 Scrum 团队应该是多功能和自组织的。 团队应该是多功能的 多功能是指团队具备为客户提供端到端服务的全部技能,对于 Scrum 团队这意味着有能力完成 从需求分析到交付产品的所有工作。如果团队为了完成一个工作要严重依赖其它部门,就无法实 现真正的短迭代交付;同时,因为团队仅凭自身的努力无法获取期望的结果,就会缺乏对目标的 认同和责无旁贷的责任感,也会缺乏改进的动力。为了做到团队的多功能,组织需要: a) 创建跨职能和跨组件的团队 跨职能指团队具备承担系统分析、架构、设计、开发和测试等工作的全过程能力;跨组件指团队 具备完成开发工作所需各个组件的知识,如 UI,中间件,底层驱动等。 b) 拓展团队成员的知识技能 需要指出的是,多功能的团队并非指团队中的每一个人都具备所有技能,这在操作上是不实际的。 Scrum 对团队成员的技能要求倾向于通才型的专家(Generalizing specialist)。团队成员具备 通用软件开发知识、业务领域知识、和自己的业务专长,同时应积极寻求拓展自己的技能。这有 助于成员产生更全面的思考,促进团队的协作,以及消除开发过程资源的瓶颈和等待,增加开发 过程中的灵活性等。 c) 团队应长期存在 一个团队从成立到高效运作需要一个过程,能力的拓展、团队的磨合、技术实践的优化、基础设 施的完善都需要时间。通常建议 Scrum 团队尽可能长期存在,而不是随着特定项目或开发版本 成立和解散,长期存在的团队才有长期的承诺,形成对目标的认同和坚持,并激发不断改进的动 力。 Scrum 团队应该自组织的 自组织团队是指,由团队而不是管理者决定“怎么做”。Scrum 团队被赋予并承诺组织目标,计划、 执行和监控的职责则属于团队。因决策权力的充分下放,自组织团队能够对现状做出准确和及时 的响应,并最大程度发挥团队成员能动性。但,简单地对一个团队说:“从今天开始,你们就自 组织吧”,不会带来期望的结果。自组织的团队的形成需要: a) 有意义和挑战的目标 有意义的目标可以协调团队成员努力方向,增加团队的凝聚力。一个通过努力可以达成的目标可 以激发团队的激情和能动性。 b) 自主完成目标的潜在能力 团队有了目标,还要有与之匹配的潜在能力配置。多功能团队是自组织的前提,团队的长期性则 保障了能力拓展和提升的可持续性。 c) 明确的边界 团队的自组织需要特定的边界。没有边界约束的自组织,很难确保其在执行上与组织目标的一致。 Sprint 周期是时间边界;Product Backlog 是范围的边界;DoD 是质量的边界。边界的存在让自 组织更有序的发生,边界既是对团队的约束,也是对外界干扰的约束。有了边界的约束,可以建 立外面的人对团队的信心和安全感;团队则在边界之内充分自主。 d) 良好的组织环境支持 组织环境之与团队,就像土壤之与种子。团队的自组织离不开良好组织环境的支持。面向团队而 非个人的奖励和认可机制、面向结果而非过程的绩效体系、简单扁平的组织结构、以及充分的授 权机制,都为团队自组织提供了良好的土壤。 针对团队组织的常见不良症状分析 持续改进 对开发过程本身的持续改进是 Scrum 的一部分,Scrum 实施能更好地暴露组织中存在的问题, 解决这些问题是 Scrum 成功实施的保障,也是组织能力提升的关键。 将改进融入开发过程 检验和调整针对的不仅是产品,团队还应经常对开发过程本身进行检验和调整,持续改进是 Scrum 框架的有机组成部分。如图(四)所示,下面的实线框内是对所开发产品的检验与调整, 这一持续循环的目的是使最终的产品更好的符合实际目标;上面的虚线框内是对开发过程的检验 与调整,其目的在于不断提高团队的过程能力,和长期交付的能力。 图(四)Scrum 中的两个调整与检验循环 影响过程能力的要素很多,如团队协作方式、开发流程、技术实践、基础设施等。每个 sprint 的回顾会议都应对以上要素进行反思和调整,为保证 sprint 回顾及其后续活动的有效,团队要做 到: a) 让团队成员,积极参与改进的过程 “retrospective prime directive”是回顾会议的基本指导原则,它明确的指出,回顾是为了改进开 发过程,而不是针对任何个人。一个被少数人主导的回顾会议,很难达到期望的效果,创造一个 安全开放的氛围,让每一个人都积极参与改进过程,是确保其有效的前提。尝试不同的形式来组 织回顾会议的进程,也有助于提高成员参与的积极性,Agile Retrospective 一书提供了丰富的回 顾会议的组织形式。 b) 每次聚焦有限的改进项目 一次改变太多的东西是不现实的,会导致分析不够深入彻底,执行的效果打折。每次聚焦一到两 点,集中力量,积累小的改进成果。 c) 找到深层次的原因 就问题解决问题是不够的,多问几个为什么,挖掘问题背后的本质原因,这样的改进才是彻底和 长久的。 d) 产生具体可执行的行动方案 光发现和分析问题还不行,要制定切实可行的方案。方案必须是具体和可执行的,可以落实到人, 而不是仅停留在口头或纸面。 e) 检验改进效果 改进计划落实执行后,需要检查其效果,形成改进环。每次回顾会议的开头检查上次改进方案的 执行结果,是一个比较好的做法。 f) 永远不要放弃改进的努力 Scrum 的改进过程没有终结,持续改进是 Scrum 的一部分。 在Scrum 实施中暴露并解决问题 Ken Schwaber 曾经对 Scrum 做出一个非常好的类比,他说:“Scrum 象丈母娘,她希望自己的 女儿好,总是对女婿不满意,不断挑他的毛病,却从来不提供改正方案”。相似之处在于,Scrum 暴露问题,却不提供解决方案,因为那是团队的责任。 Scrum 没有告诉你怎么开发软件,甚至也不告诉你怎么协作,这些由团队自主决定,《敏捷开 发艺术》的作者 James Shore 评论“Scrum 是一个有意为之的半成品”。这恰恰是 Scrum 的生命 力所在,维持了 Scrum 的简洁和包容性;这也是 Scrum 的陷阱所在,它可能误导使用者低估 Scrum 实施的难度,而事实上它却对组织和团队提出了很高的要求。通过 Scrum 实施暴露问题, 然后解决它们,这是 Scrum 引领团队成功的不二法门,这需要团队的勇气和智慧。 a) 尽可能暴露问题,并解决这些问题 Scrum 通过透明和检验使问题更易被发现。每个迭代产生潜在可交付的产品增量,暴露了过去 深藏于长开发周期中的问题;团队的直接沟通,暴露了隐藏于复杂组织结构下的问题;更少并行 开始的用户需求,暴露了隐藏于大量的半成品里的问题。因此选择更短的开发周期,更直接沟通, 同一时间更少的并行需求开发,都有助于问题的暴露。 没有重大的改变,就不可能有重大的不同。问题暴露了,就要去解决,不管是组织的问题、团队 合作的问题、工程实践的问题、还是研发基础设施的问题,都要去解决。在解决问题的过程中, 团队完善自己、提高交付能力并从 Scrum 实施中真正获益。 b) 技术实践必须跟上 Scrum 框架中并不包含任何技术实践,当然也不排除任何技术实践。问题是在实际操作中,技 术实践很容易被忽略。James Shore 在“The Decline and Fall of Agile ”中表达了对许多 Scrum 团队忽略技术实践的深深担忧,言辞激烈,但发人深思。Robert C. Martin 在 “The Land that Scrum Forgot”中也旗帜鲜明的指出离开技术实践的 Scrum 是无法长久的,他提出如果没有技术 实践的支持,更快的交付软件就意味着更快的积累技术债务,这篇文章还列举了最应该被重视的 技术实践,很有参考意义。 尽管,在 Scrum 的框架中,由团队自主决定技术实践的采用,团队在检验和调整过程中决定是 否需要技术上的改变和怎样改变。但理论和实践都已经证明 Scrum 的成功离不开敏捷技术实践 的支持,很多团队都因技术实践未跟上而走向失败。既然这是一个必然且十分重要的选择,那么, 在操作上单独去强调技术实践就十分必要。 针对持续改进的常见不良症状分析 总结 掌握自己的命运:Scrum 对不同组织含义是不同的, 对一个重流程的官僚组织,它可能意味着 拥抱变化、紧密的合作、充分的授权、和灵活的交付模式。而对于一个缺乏必要规范的组织,它 可能意味着加强团队纪律,用明确的框架来规范和拓展当前的实践。作为一个强调经验性过程的 框架,在 Scrum 框架的基础上,组织需要探索适合自身的实施过程,掌握自己的命运! Scrum 实施策略需要考虑所处阶段:不同阶段采用不同的策略 1)初始实施时,严格遵照 Scrum 框架进行 2)在实施过程中加深对 Scrum 原则的理解,在此基础上考虑创新突破。3)当对这些 原则把握自如时, Scrum 的形式就不再重要了,当然这可能需要好几年的时间。Alistair Cockburn 曾引用来自日本剑道的术语“守,破,离”来描述这三个阶段。 很痛苦,但非常值得:Scrum 框架非常简单,但简单不等于容易。Scrum 一定会带来巨大的改 变,你要做好准备,它意味着观念的转变,权力的重新分配,技术实践的配套,基础设施的优化 等。改变是困难的,过程是痛苦的,但非常值得。
还剩16页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

神木与瞳

贡献于2012-12-12

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf