敏捷项目管理.ppt

* 最终客户 产品团队 开发团队 产品团队-客户界面 产品团队 开发团队 产品经理 客户 项目经理 产品构想 故事ID 故事优先级 需求对话 验收 定义产品团队-开发团队 * 自我组织策略：该策略确定了团队沟通、协调、协作、决策，以及其他个人与个人和团队与团体的相互交流方法。 自我组织策略问题 我们如何与客户协作？ 来自不同功能团队的项目成员如何协作？ 来自不同区域的团队如何协作？ 授权对我们团队来说意味着什么？ 谁需要在何时与谁交谈？ 相互交谈的这些人如何决策？ 谁负责什么？ 他们打算用那些做法来推动上面提出的问题？ 沟通与协作的区别：异步，相互交流产生共同结果。 * 流程架构裁剪 流程架构应该努力找出刚刚好（可以接受的最小程度）的项目组织标准。这个架构的“重量”越大，即流程组成元素的数量、必要的过渡产物数量、决策的数量、文档形式越多，项目团队敏捷度就越低。 流程架构裁剪依据： 项目探索系数 自我组织团队 流程裁剪 交付方法 指导原则 * 具体项目裁剪流程和做法，4个基本问题？ 1、哪些做法是必需的？ 2、还需要哪些辅助性做法？ 3、需要对选择的做法做哪些修改？ 4、做法的编档、批准和更改需要什么手续和形式？ * 推测阶段 比较：计划与推测 计划：通常是对未来的猜想，当我们“计划”时，我们期望实际结果与计划相符，而与计划背离则被视为是项目团队的错误或者表明团队不够努力； 推测：当我们“推测”时，将对实际结果予以肯定，人们会怀疑计划是否错了，计划或者推测是信息，但仅是我们将检验的信息，以确定下一次迭代中的行动。 推测阶段：关注产品和项目—创造和理解产品结构、性能和故事功能清单以及发布计划。 基于功能的计划和开发首要目标是制定有形的、客户团队可以理解的流程。 功能是开发工程师和产品团队之间的界面—共同理解的媒介。 产品经理控制那些功能应该包含在产品中，开发工程师控制功能的设计和实施方式。 * 产品功能清单 创建产品功能清单法，旨在通过演变的产品需求定义过程，将产品构想扩充成产品功能清单。 功能细节随着开发阶段的演变而演变： 构想阶段：团队创建初步的功能或者产品细目结构。 推测阶段：团队扩充这个清单，并为每种功能都建立一张或多张“故事”卡，其中包含基本的描述和估计的信息。 探索阶段：每次迭代，按照计划实施功能、详细地确定需求、建造和测试功能。 功能、故事的概念 功能或者故事被定义为产品的一部分，向客户提供一些有用的、有价值的功能。它们的区别是，故事是一个小的可交付的有用功能，但构不成一个完整的功能。所以性能、功能、故事构成一个分层结构来管理越来越大的产品规模。 功能—故事 范例 功能：作为信用分析师，我需要能够审查客户的信用等级 故事1：最为信用分析师，我需要能够审查客户以前的付款记录； 故事2：最为信用分析师，我需要能够审查客户的信用机构状况； 故事3：作为信用分析师，我需要能够根据记录和信用报告来计算客户的信用等级。 故事3 任务 故事2 任务 * 故事的重点 用户界面 业务对象 中间件 数据库 故事1 任务 T1 T2 T3 T4 T5 T6 业务重点分解 技术重点分解 故事1 故事2 故事3 传统项目关注的是技术任务领域，故事却以客户为导向。 开发人员会认为把故事拆分成小的技术任务导致效率低下。 在一次迭代期间，把几个故事的任务结合起来做，大多数所谓的效率低下情况就会消失。 在客户功能之前构建技术功能的危险是“黑洞”。 * 故事卡片 故事卡片提供简单的媒介，用于收集故事，列出功能，是客户和项目团队成员在一次迭代期间详细需求的讨论（以及制成最低限度的文档）后达成的协议。讨论是理解的关键，理解是估计的关键。 故事卡片信息 故事ID和名称； 故事描述:用一两句子，从客户的角度描述功能； 故事类型：（C=客户领域、T=技术领域）； 估计工作量：交付该故事所需的工作量的估计，包括需求收集、设计、编码、测试、和文档编制； 估计价值点： 需求不确定性：采用一个探索系数 故事依赖关系：可能影响实施顺序的依赖关系； 验收测试：客户团队用于接收或拒绝该故事的标准。 使用场合，信息化，共享，高风险故事。 * 创建功能清单 是产品团队确定的产品性能、功能和故事的一个列表。 包括ID，名称、简要描述，优先级别，探索系数和估算等内容。 客户，产品专员，协作 发布计划 发布计划是团队在项目数据表中所描述的在项目目标和约束内实现产品构想的路线图。 敏捷生命周期以迭代和故事驱动。 发布计划的主要任务是以价值和风险为基础把故事分配到迭代中。 制定进度计划时需要考虑的其他因素，如资源的可用性、依赖关系以及其他，都排在价值和因素之后。 发布计划应该是团队（包括产品团队、开发团队和主管）共同协作的结晶。 范围演变