第五章：在敏捷环境中交付

今天分享《敏捷实践指南》第五章：在敏捷环境中交付。分支内容包括：项目章程和团队章程、常见敏捷实践、解决敏捷项目的挑战、敏捷项目的衡量指标。

第五章 在敏捷环境中交付

• 5.1 项目章程和团队章程
  • 敏捷项目需要回答
    • Why要做这个项目
      • 项目愿景
    • Who会从中受益
    • How从中受益
    • 项目远景/目标的一部分
    • What条件达成才意味着项目完成
      • 项目发布标准
    • How团队合作
      • 预期的工作流
  • 团队社会契约/团队章程
    • 团队价值观
      • 如：可持续的开发速度
      • 核心工作时间，等
    • 工作协议
      • 如，“就绪”如何定义
      • “完成”如何定义
      • 时间盒
      • 使用工作过程限制，等
    • 基本规则
    • 团队规范
      • 子主题
    • 团队章程的目标是创建一个敏捷的环境。只要团队知道如何一起工作，制定章程就不需要一个正式的过程。
• 5.2 常见敏捷实践
  • 5.2.1 回顾（定期反省）
    • 最重要的
      • 因为它能让团队
        • 学习
          • 找到根源
        • 改进
          • 设计对策
        • 调整
          • 制定行动计划
            • list/pool
            • 重要性的优先级排序
            • 选择适合的数量行动
            • 行动是否有效的标准
    • 关键时间点
      • 完成一个发布，或加入一些功能时
      • 自上次回顾后又过了几周
      • 团队出现问题，或完成工作不顺畅时
      • 达成任何里程碑时
    • 回顾并不是责备
    • 子主题
  • 5.2.2 待办事项列表编制
    • 所有工作，有序列表
    • 以故事的形式呈现给团队
    • PO令你感到
    • 仆人式领导可以主持人和必要的相关会议
  • 5.2.3 待办事项列表的细化
    • 基于迭代的敏捷中
      • 细化足够的故事
        • user stroy
        • background
      • 细化的时长
        • 即时细化
        • one hour timebox
          • 每周一次
          • 如果超过1小时说明
            • PO过度准备
            • 成员缺乏评估和细化所需的关键技能
        • 多次细化
      • 颗粒度
        • 故事足够小
        • 每天能完成至少一个故事
      • 挑战、问题、风险、依赖关系
  • 5.2.4 每日站会
    • 彼此承诺，发现问题（发现的问题不在站会上解决）
    • 规定时间盒<15min
    • 过一下看板或任务版
    • 任何人都可以主持
    • 反模式
      • 站会变成了状态报告会
      • 站会变成了解决问题的会
        • 站会上发现的问题应该添加到停车场区，然后在另一个会上解决
    • 常见的两种类型
      • 基于迭代的敏捷
        • 上次站会以来我都完成了什么？
        • 到下次站会我计划完成什么？
        • 我的障碍/风险/问题是什么？
      • 基于流程的敏捷
        • 我们还需要做些什么来推进这一工作？
        • 有人在做看板清单以外的事情吗？
        • 我们需要完成什么？
        • 工作流是否存在瓶颈/阻碍？
    • 何时需要站会
    • 站会是否有效
  • 5.2.5 展示/评审
    • 定期展示
    • PO接受或拒绝
    • 每两周至少一次
    • 展示的时机
      • 基于迭代的敏捷中
        • 迭代结束时
      • 基于流程的敏捷中
        • 需要时。通常是累积到足以构成一个连贯组合是
  • 5.2.6 规划基于迭代的敏捷
    • 团队完成user stroy的能力
    • 团队估算完成工作时间的能力
    • 在一个工作块中不会只计划一次，而是滚动式规划，渐进明细
  • 5.2.7 帮对团队交付价值的执行实践
    • 来自极限编程（XP）的最佳实践
      • 持续集成
        • 频繁继承，重新测试
      • 在不同层面测试（Test at all levels）
        • 端到端-系统级测试
        • 构建块-单元测试
        • 集成测试
        • 冒烟测试
        • 回归测试
        • 自动化测试
      • 验收测试驱动开发（ATDD）
      • 测试驱动开发（TDD）和行为驱动开发（BDD）
      • 刺探（时间盒研究或实验）
  • 5.2.8 迭代和增量如何帮助交付工作产品
    • 迭代可以帮助团队船舰一个交付的节奏
    • 团队会为交付和反馈创建增量
    • 为团队的交付节奏安排适当的演示和评审
• 5.3 解决敏捷项目的挑战
  • ----------痛点----------
    • 解决痛点的可能性
  • 团队任务或目标不明确
    • 敏捷章程中关于目标的部分—愿景、使命和使命测试
  • 团队工作协议不明确
    • 敏捷章程中关于一致性的部分—价值观、原则和工作协议
  • 团队环境不明确
    • 敏捷章程中关于环境的部分—边界、承诺资产和前瞻性分析
  • 需求不明确
    • 帮助发起人和相关方制定产品愿景。考虑使用实例化需求、用户故事地图和影响地图来构建产品路线图。让团队和产品负责人一起来明确需求的期望和价值。逐步将路线图分解为具有更少具体需求的待办事项列表。
  • 用户体验不佳
    • 开发团队的用户体验设计实践应在早期就让用户经常参与。
  • 估算不准确
    • 通过分解故事来让故事变小。让整个团队使用相对估算进行估算。考虑通过敏捷建模或刺探来理解故事。
  • 工作分配或工作进展不明确
    • 帮助团队认识到要自我管理工作。考虑用看板面板查看工作流程。考虑利用每日站会，根据看板查看工作进展。
  • 团队面临障碍
    • 仆人式领导能帮助消除这些障碍。如果团队不知道他们都有哪些可选方案，就要考虑聘请教练。有时，团队或仆人式领导无法消除障碍，团队就需要上报故事。
  • 由于产品待办事项列表不够完善，导致工作延误/超时
    • 产品负责人和团队一起研讨故事。为故事创建一个准备就绪的定义。考虑分拆故事以使用更小的故事
  • 缺陷
    • 考虑对特定环境有效的技术实践。它们可能是：结对工作、产品集体负责制、普适测试（测试驱动方法和自动化测试方法）以及稳健的完成的定义。
  • 工作未完成
    • 团队确定故事完成的定义，包括验收标准在内。另外，还要为项目补充发布标准。
  • 技术债务（代码质量降级）
    • 重构、敏捷建模、普适测试、自动化代码质量分析、完成的定义
  • 产品复杂性过高
    • 无论是软件项目还是非软件项目，都要常常鼓励团队思考： “最简单的有效方法是什么？”，并应用“简洁，即尽最大可能减少不必要的工作，这是一门艺术”的敏捷原则。这样做将有助于降低复杂性。
  • 团队合作过程进展缓慢或没有改善
    • 在每次回顾中，选择的改进项目不要超过三个。让仆人式领导帮助团队学习怎样整合这些待改进项。
  • 前期工作过多导致返工
    • 不要做过多的前期工作，而要考虑让团队通过刺探来学习。另外，在项目开始时衡量在制品 (WIP)，看看哪些部分团队并不需要设计，只需要交付价值。缩短迭代，并创建一个稳健的完成的定义。
  • 错误的开始，前功尽弃
    • 让产品负责人成为团队不可分割的一分子。
  • 产品待办事项列表杂论无续
    • 按价值排序，并考虑延迟成本按持续时间 (CD3) 和其他价值模型划分
  • 仓促/等待，不均匀的工作流程
    • 计划要对应团队的能力，而不是超出能力所及。要求人员停止多任务，为一个团队专注工作。请团队利用结对、群集或群体开发等方法，平衡整个团队的能力。
  • 相关方要求无法满足
    • 仆人式领导与这个相关方（可能是产品负责人）一起工作。
  • 意想不到或不可预见的延误
    • 让团队更频繁地检查，使用看板面板检查工作流和在制品限制，了解需求对团队或产品的影响。也可以在障碍板上跟踪障碍和障碍消除情况。
  • 孤立的团队，而不是跨职能团队
    • 让项目人员作为跨职能团队自我组织。使用仆人式领导技巧帮助管理人员理解为什么敏捷需要跨职能团队。
• 5.4 敏捷项目的衡量指标
  • 5.4.1 敏捷团队的衡量结果
    • 基于经验和价值的衡量标准
    • 图表
      • 飓风图
      • 燃起图
      • 燃尽图
    • 敏捷处理知识性项目在交付价值的同时，会伴随学习
    • 团队报告经验数据，并重新规划其他小的增量，以此管理项目的不确定性
    • 基于流程的敏捷的衡量指标
      • 交付周期
      • 交付时间
      • 响应时间
      • 累积流图
    • 可用的软件（或者，如果不是软件，则是其他的产品） 是衡量进度的主要指标
    • 敏捷中的挣值
  • Pending....