敏捷项目管理14个问题

Scrum的角色，Scrum的工件，Scrum的仪式。prodbacklop的创建，关于冲刺，冲刺回顾，敏捷的核心价值观，敏捷管理与敏捷转型，敏捷开发主要框架，敏捷宣言，敏捷的核心思想，敏捷的12个原则，愿景声明与产品路线图。

敏捷项目管理的14个问题

• Scrum的角色
  • 项目负责人PO
    • 负责分析项目的商业价值，决定该项目应该完成的工作，并对其进行排序，制作并维护product backlog
  • 敏捷主管SM
    • 激发团队活力，推动每日的工作，促进项目成员间的正常交流，并扫除敏捷过程中的障碍
  • 开发团队
    • 负责每日的开发生产工作，是冲刺的执行主体
  • 项目干系人
    • 除了以上三个角色外，还包括客户，用户，主管等
  • 敏捷教练
    • 传授敏捷方法的人，并不直接参与到项目执行中
• Scrum的工件
  • Product Backlog
    • 一个记录了产品特性的列表，并按照特性的商业价值进行排序
  • Sprint Backlog
    • 当前冲刺中需要完成的任务
  • Product Increment
    • 每次冲刺结束后可发布的产品
  • Burndown Chart
    • 当前冲刺过程中剩余的工作时间
  • 看板
• Scrum的仪式
  • 简要介绍
  • 冲刺计划会议
    • PO，SM以及开发人员决定当此冲刺应该处理的任务以及冲刺结束后发布的产品
  • 每日例会
    • 一个简单的会议，由SM主持，开发人员汇报当前的工作情况，遇到的障碍以及之后的计划
  • 冲刺评审
    • 由PO向项目干系人展示当此冲刺的产品及其功能，并收集相关反馈
  • 冲刺回顾
    • 由PO，SM以及开发人员讨论回顾当次冲刺存在的缺陷，以及可能的解决方法
  • 产品backlog细化
• ProductBacklog的创建
  • PO从Product Backlog中选择优先级高的数个用户故事，作为下一次需要发布的内容，并且根据估算的工作量，确定发布时间 发布内容和发布时间作为冲刺计划的重要参考因数
  • 要素
    • 特性
      • 用户故事
        • 商业价值
        • 工作量
        • 优先级
          • 可隐含在条目的排列顺序中
        • 完成情况
• 关于冲刺
  • 定义
    • 指一次迭代，该迭代中产生的产品还能通过验收
  • 主要工作
    • 冲刺计划会议
    • 每日冲刺工作(每日例会)
      • 创建产品可交付的功能
        • 可交付功能是指可以发布的产品功能
      • 产品负责人与开发人员需要对任务进行细化，开发和测试
        • **细化**是指对用户故事和任务的进一步分析，从而更加明确需求 细化过程应该集体完成 **开发**是开发团队进行功能的编码测试，PO指导开发方向以及校验测试 SM解决开发外的问题 **验收**包括自动化测试，同行评审以及产品负责人评审 自动化测试包括单元测试，集成测试，系统测试以及静态测试 同行评审即团队内部的评审 产品负责人评审即评判提交内容是否满足对应的用户故事
      • SM需要做的是识别阻碍，并将其解决
    • 冲刺评审
    • 冲刺回顾
• 冲刺回顾
  • PO，SM以及团队成员回顾和总结当次冲刺存在的缺陷与不足，并提出改进的意见
  • 参与人员
    • SM(主持人)
    • PO
    • 开发人员
    • 可能还会有项目干系人
  • 会议关键
    • 活跃会议气氛，让团队成员能够积极参与进来
    • 讨论需要时刻关注重点，不应该分散
  • 优势
    • 刺激和鼓舞开发人员的士气
    • 挖掘优秀的开发经验和方法
    • 避免犯相同的错误
    • 改进团队气氛
• 敏捷的核心价值观
  • 承诺
    • 愿意承担任务 并承诺完成
  • 专注
    • 把精力集中在工作和任务中
  • 开放
    • 项目的一切都对项目内成员公开
  • 勇气
    • 有勇气做出承诺，并接受他人尊重
  • 尊重
    • 尊重每个人的背景和经验
• 敏捷管理与敏捷转型
  • 管理
    • 概念管理
      • 需求分析以及高层的架构设计，会产生product backlog
    • 计划管理
      • 冲刺计划以及进一步的系统设计
    • 开发过程管理
      • 冲刺/迭代过程管理
    • 验证管理
    • 发布管理
    • 生命周期管理
  • 转型
    • 例子
      • PPT上华为的例子
      • 三个阶段
        • 项目敏捷
          • 包括部分计划，全部的开发与验证过程
        • 版本敏捷
          • 包括全部的计划，开发，验证以及发布
        • 产品敏捷
          • 在上述基础上增加了对产品概念以及产品声明周期的管理
    • 核心
      • 敏捷转型的成功关键是团队意识的转变以及团队技能的提升，通过三步走的方式，实现人员技能，工程能力，流程，工具等方面的积累在风险可控的情况下达到全面敏捷的转型
• 敏捷开发主要框架
  • XP
    • XP是一种近螺旋式的开发过程，通过将项目分解为多个小周期，积极沟通反馈，从而调整开发过程，让客户了解项目进度
  • ASD
    • ASD是迭代开发的一种，每次迭代包括推测，协作以及学习三个阶段，共同推进项目的进程
  • FDD
    • FDD是轻量级的敏捷开发方式，融合了多种行业认可的最佳实践，能够快速地向客户展现有价值的软件
  • TDD
  • AUP
    • AUP是简化版的RUP，包括7个方面：建模，开发，测试，发布，配置管理，项目管理，环境管理
• 敏捷宣言
  • 个体交互高于过程工具
    • 强调面对面的沟通，而不是使用额外的工具或者标注约束或者减少沟通
  • 可运行程序高于文档
  • 客户合作高于合同谈判
  • 响应变化高于遵循计划
• 敏捷的核心思想
  • 以人为本，拥抱变更
• 敏捷的12个原则
  • 针对人的
    • 在整个项目开发周期中，业务人员应该与开发人员一起工作
    • 项目由有激情，可信的人合作完成
    • 在团队中面对面沟通效率最高
    • 每隔一段时间，团队成员应该进行自我反思和调整
  • 针对计划的
    • 即使在开发后期也应该接受变更
    • 工作的软件是衡量进度的首要标准
    • 敏捷开发过程应保持稳定的开发节奏
    • 不做过度的设计和预测
  • 针对产品的
    • 应该尽早向客户交付有价值的程序
    • 交付的频率应该越高越好
    • 最好的架构和设计来源于自组织的团队
    • 不断关注新的技术和设计
• 愿景声明与产品路线图
  • 两者属于项目的整体规划中
  • 愿景声明
    • 制作前提
      • 了解企业的战略目标
      • 考虑产品愿景与战略目标之间的关系——带来利润/扶持其它战略项目
    • 确定项目(产品)目标
      • 回答这几个问题，是为了起草愿景声明做准备。 愿景声明就是一段话： 为了：(目标客户) 能够：(需求) 这个：(产品名称) 是一个：(产品类别) 它：(如何完成需求) 不同于：(竞品) 我们的产品：(差异/竞争力)
      • 能够位企业带来何种利益
      • 目标客户是谁，特征如何
      • 客户所关心的/项目所能满足的需求为何
      • 已存在的竞品
      • 与竞品的差异/自身的竞争力
  • 产品路线图
    • 作用
      • 展示产品/项目的基本特性，及其时间安排——开启和发布时间
    • 创建过程
      • 识别产品的需求
        • 一般而言应该找到主题和特性
      • 归纳整理产品的主题和特性
        • 从主题，特性，进一步细化到各种用户故事，从大到小的史诗故事——用户故事 甚至最后到任务
      • 根据产品的特性，估算其优先级并排序(打分)
        • 给产品特性的工作量和商业价值打分 一般由开发团队对工作量进行打分 由PO和客户对商业价值进行打分 打分可以按照斐波拉契数列进行打分 主题，特性分数范围是55~144 史诗故事：13~34 用户故事：1~8 由于这里仅仅考虑特性，所以故事不用考虑分数 进行优先级排序 优先级=价值/工作量
      • 安排项目实施的时间规划
• 用户故事
  • 定义
    • 对某个产品需求的简单描述
  • 类别
    • 史诗故事
    • (一般)用户故事
  • 创建
    • 需求分析
      • 识别项目关系人
        • 专家，管理者，普通用户，技术用户
      • 识别客户(使用产品的人)
      • 识别需要完成的任务
    • 描述用户故事
      • 谁(客户)
      • 希望完成(功能/需求描述)
      • 以便(商业价值描述)
    • 评价用户故事(INVEST)
      • 独立的(Independent)
      • 可协商的(negotiate)
      • 有价值的(valuable)
      • 可估算的(estimate)
      • 小型的(small)
      • 可测试的(testable)
  • 估算(优先级排序)
    • 影响因素
      • 客户要求
      • 经济原因
        • 经济回报
        • 开发成本
        • 新技术的试探应该高优先级
        • 依赖关系
      • 风险因素
        • 风险识别，进度，成本，技术
        • 高风险，高价值优先
        • 高风险，低价值延后
    • 估算方式
      • 由PO选取商业价值高的用户故事
      • 开发成员同时给出工作量估算
    • 优先级
      • 价值/工作量
• SprintBacklog的创建
  • 要素
    • 用户故事
      • 任务
        • 负责人
        • 预估工作量
        • 完成情况
  • 意外情况的备注
• 冲刺评审
  • 由PO向项目干系人展示当次冲刺完成的产品及其功能
  • 参与人员
    • PO
    • 项目干系人
    • 用户代表
  • 会议关键
    • PO应该毫无掩饰地向项目干系人展示产品地所有功能
    • 会议的关注点在演示上，无需太多文档
    • 演示的环境必须与生产环境一致
    • 会议中需要收集干系人的反馈，作为项目变更的依据
  • 优势
    • 通过演示展示当前项目的实际进展
    • 尽早向用户反馈，从而获得更真实的需求
• 敏捷工程实践
  • 结对编程
    • 由两个人完成代码的编写，一人负责实施，一人从旁监督提醒
    • 优势
      • 及早发现编码中存在的缺陷
      • 提升代码质量
      • 促使团队在知识层面上更容易达成共识
  • 持续集成
    • 开发人员经常性地构建他们的工作，每天至少集成一次
    • 优势
      • 能够更直接地反应当前的项目进度
      • 能够及时发现集成后的缺陷并可以立即修复
      • 避免缺陷在最终集成时的堆积
    • 关键
      • 集成耗时因该尽可能短
      • 需要有完备的自动化测试工具以及测试用例
      • 修复失败的构建是开发人员最优先的任务
      • 集成结果应该向所有成员公开
  • 测试驱动开发
    • 以测试作为编程的中心，要求在编写代码前必须完成测试用例，并且围绕用例进行编码TDD还要求测试必须可自动化完成
    • 优势
      • 保证代码质量
      • 提高代码可读性
    • 关键
      • 测试用例需要设计完备，同时不能有依赖关系
      • 测试用例代码与开发代码都需要简洁
• 敏捷度量
  • 我猜的
  • 终端用户
    • 功能特性
    • 易用性
  • 投资人
    • 回报率
    • 风险
  • 企业
    • 管理难度
  • 团队
    • 技术开发
• 敏捷实践
  • 定义产品愿景以及产品路线图
  • 计划发布与冲刺
  • 全天的工作
  • 展示工作和集成反馈
  • 为发布做准备