敏捷项目框架：构想，推测，探索，适应，结束

  1. 构想：确定产品的构想、项目范围、项目团队以及团队共同的工作方式
  2. 推测：制定基于功能发布计划、里程碑和迭代计划，确保交付构想的产品
  3. 探索：在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。
  4. 适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。

  5. 结束：终止项目，交流主要的学习成果并庆祝。

    敏捷价值观

  6. 个体交互胜于过程工具

  7. 可运行软件胜于详尽文档
  8. 客户合作胜于合同谈判
  9. 适应变化胜于遵循计划

    生命周期

    | 高需求不确定性 | 增量型 | 适应型（敏捷型） | | —- | —- | —- | | 低需求不确定性 | 预测型 | 迭代型 | |
    | 低技术不确定性 | 高技术不确定性 |

Scrum四个会议

  1. 迭代规划会 Sprint Plan：4周迭代，不超过8小时
  2. 每日站会 Daily Scrum：不超过15分钟
  3. 评审会议 Sprint review：4周的迭代，不超过__4小时
  4. 回顾会议 Sprint retrospective：不超过3小时
  5. Scrum 三大支柱：可视透明 Transparency、检查 inspection、适应 Adaptation

  6. Scrum 价值观：勇气 Courage、承诺 Commitment、专注 Focus、尊重 Respect、开放 Openness

    敏捷环境&团队 Agile Environment & Team

  7. 先在低风险、低不确定性项目，执行：混合型（预测+敏捷）让团队接受，变革就绪。

  8. ！！注意，那些，将敏捷4大价值观故意错位配对的选项。指鹿为马就曲解了敏捷价值观
  9. 敏捷团队：1.适应变化；2.通才型人才组建。目的只有一个：更好的客价值交户付
  10. 发起人是什么角色？提供资金和确认总体里程碑的
  11. PO的责任是将客户的愿景转化为客户价值并驱动产品路线图和PBI创建
  12. 团队在与客户接治方面有困难，客户几乎不回应问题，经常缺席迭代和评审和演示，此时需要找PO代表客户，而做出决定
  13. 高敏捷情商，为了促进有效合作。
  14. 富有动力的敏捷团队，最终目的是提高生产效率
  15. 面对面沟通，被誉为高宽带沟通模式
  16. 敏捷团队是：积极的、自我管理的、自由交流的、以人为中心（不是以团队为中心！）
  17. 团队促成者（项目经理， Scrum主管、项目团队领导、团队教练）反正都是等价于敏捷教练，熟知敏捷方法。
  18. SM要为团队排除障碍，移除瓶颈
  19. SM要为团队讲解每日站会的意义和作用。
  20. 对于技术文档，主张刚好够。而不是，一旦你离开还要保证新手快速上手。因为敏捷是团队互动。
  21. 仆人式领导，根据团队的需要而给定不同指导和辅导
  22. 团队一起做决策——团队参与式决策模型
  23. 合适的敏捷环境：阳光，植物，舒适座椅，咖啡
  24. 同理心：客户与程序员共鸣，程序员与测试员共鸣
  25. 当团队成员发生冲突，SM，是鼓励该团队成员亲自解决这个问题
  26. 衡量敏捷团队绩效指标：
    1. 经验指标（已完成的功能数）
    2. 定性衡量指标：业务满意度、团队士气、团队希望跟踪的
    3. 燃起图、燃尽图
    4. 交付周期：从添加至看板上直 交付给客户的时间。
    5. 周期时间：从开始任务到完成任务的时间。
    6. 响应时间：一个工作项目等待工作开始的时间
    7. 一个迭代的挣值管理
    8. 【注意没有速率】因为不同团队差异性大，不同团队技术能力不一样，告诉了我们团队的能力，而不是项目的进展。
  27. T型人才，通才型人才，在多个领域拥有一定能力，而不是专才。敏捷价值观是主张学习更多技能，通过培养、鼓励团队成员到新岗位学习新技术。因此，长期做自己擅长的工作是不利于培养敏捷项目所需的广泛技能
  28. 敏捷合同：风险和共享项目奖励的关系，实现所有方共赢
  29. 敏捷领导者应该培养团队成员，即使这意味着失去他们
  30. 敏捷教练，在帮助团队解决问题前，先让团队自己想办法
  31. 敏捷教练，允许项目团队成员在认为有必要时解决问题，即使效率低下
  32. 敏捷教练说，每周保持上班5天，每天8小时，合计40小时，意味着：让团队可持续发展
  33. 敏捷教练，是不分配任务给成员，是成员自己认领任务（再三强调）
  34. 敏捷阻碍通常来源于冗长流程：对于非敏捷组织，三座障碍大山：财务部门、CCB、审计部门。
  35. 发展团队个人技能，扩展跨职能团队能力，有助于减少瓶颈
  36. Common与Caves
    1. Common 公共区域对于团队成员是公共的、渗透交流和合作在此起作用；
    2. Caves是一个私人活动的预留空间。
  37. 敏捷环境下的办公室，应该是开放办公室，便于面对面沟通
  38. 积极聆听：
    1. 聆听：关注当下，聚焦演讲者。
    2. 记录：作笔记，不打断。
    3. 理解：用意译来确认和回顾所收听的内容。
    4. 积极响应：讲话结束时为后续归纳对话内容。提出开放式问题，适当肢体语言和沉默来提高聆听技巧。
  39. 分布式团队，更注重，文化差异
  40. 分布式团队，可以用视频会议实现“面对面”沟通，但是相比真正的集中办公的面对面沟通，效果大打折扣
  41. 让干系人参与，关注用户利益

  42. 敏捷开发与瀑布开发最大区别：关注共同目标

    4个驱动开发

  43. ATDD，验收测试驱动开发：先有测试验收标准，再去开发。

    • ATDD，4个步骤可简记为4个Ds
      • Discuss 讨论：与客户干系人讨论用户故事应有和不应有预期行为
      • Distill 提取：提取可确认和验证的行为测试，识别DoD
      • Develop 开发：编写测试和测试代码
      • Demo 示范，向客户演示，获得反馈，确定是否已完成
  44. TDD，测试驱动开发（零缺陷思维模式）：开始前定义验收测试的。软件按照如何会被接受的前提而编写__。当按此正确完成后，软件肯定能通过测试并被验收。
    • 1）编写测试代码（用例）
    • 2）核对和确认测试
    • 3）编写产品代码，接着采用测试
    • 4）重构（改善设计）
  45. BDD，行为驱动开发，系统设计、确认实践测试优先。类似于英语脚本

  46. FDD，功能特征驱动开发Function/Feature Driven Development：由客户重视的产品功能、特征驱动开发

    • FDD Feature Team
      • 项目经理 Project manager
      • 首席架构师 Chief architect
      • 开发经理 Development manager
      • 首席编程人员 Lead programmers
      • 类负责人 Class owner
      • 领域专家 Domain experts
    • FDD的五项活动
      1. 开发高层级模型 Develop overall model
      2. 开发功能列表 Build feature list
      3. 依据功能规划Plan by feature
      4. 依据功能设计Design by feature
      5. 依据功能构建Build by feature

        极限编程XP Extreme programming

  47. XP核心价值观

    1. 简单 Simplicity
    2. 交流 Communicatino
    3. 反馈 Feedback
    4. 勇气 Courage
    5. 尊重 Repect

  48. XP 核心原则 | 结对编程 Pairring Programming | 尽早发现错误，共享知识 | | —- | —- | | 重构 Refactor | 调整代码改善软件质量和性能，使架构更合理，提高扩展性和维护性 | | 简单设计 Simple Design | 简洁的设计是降低风险的策略 | | 测试驱动开发 Test-driven Development | 争取可以尽可能短地进行测试-反馈循环 | | 代码集体所有 Collective Code Ownership | 任何人都可以修改任何代码 | | 编码规范 Coding Standard | 统一的编码标准与规则才能实现代码集体所有 | | 隐喻 Metaphor | 能够让人更清楚明白系统在做什么、如何工作 | | 稳定的步伐 Sustainable Pace | 团队需要可持续的工作状态（不加班） | | 持续集成 Continuous Integration | 尽早增量交付和持续改进的基础 | | 现场客户 On-site Customer | 客户代表参与，提高反馈效率 | | 计划游戏 Planning Game | 发布计划和迭代计划 | | 客户测试 Customer Test | 团队可以根据验收标准进行自动化测试 | | 小版本发布 Small Release | 频繁对小版本，更快的交付价值 |

  49. XP最佳定义：建立被测试的代码与产品代码库的集成，一旦测试代码被集成，那么整个产品代码库就会被测试。

  50. XP原则是代码建立后，即集成到完整代码库。由此集成后，代码库和整个系统即建成和测试完成
  51. 持续集成，提高快速软件交付和集成缺陷早期探测的一个极限编程的原则。持续整合理论上是指随时有可传输的工作产品。
  52. 持续集成（continuous integration）：每小时每天，都在交付变化的代码
  53. 结对编程，其实也是一种“师徒模式”，能让新手，快速上手。
  54. 结对编程，优点：代码集体所有、线上审查、减少开发时间。
  55. XP，对端到端，系统级测试；对模块，单元测试。对修改旧代码，回归测试
  56. XP极限编程，其实就是，先写测试用例，再开发代码。。主张回归测试
  57. 在集成到完整的代码库前被广泛的测试，其次是完整的代码测试以确保成功整合的软件增量开发
  58. XP是极限编程，主张的是【只做一次】
  59. XP的目的是每天提交新功能（提交给回归测试），而不是每天提交软件给客户
  60. 重构是不改变预期功能，优化代码，以便日后容易维护。
  61. 力场分析，是找出阻碍的因素，标上编号，以了解力量两边的总和。
  62. DoD一定是团队负责定义，不是PO也不是SM
  63. 持续集成的目的在于：尽快找到代码问题，然后解决它。
  64. 探索性测试是为了提高产品质量。探索性测试往往是作用在成品软件上，测试出系统设计漏洞并发现任何可能会增加客户价值的新特性。探索性测试应涵盖开发者在一般单元测试中未预见的内容。探索性测试者运用产品的项目大纲作为测试的向导
  65. 渗透沟通：团队成员之间捕捉视觉暗示、肢体语言，一种无意识共享促进沟通共同体制
  66. 刺探：在一个较短的时间内做测试验证，目的：为了验证风险问题。也是强调学习改进
  67. 刺探，是在设计阶段中执行
  68. 刺探，的好处
    • 降低风险
    • 可选的试验
    • 快速试错
    • 更好地评估
    • 验证投资价值
  69. 技术债务，即本冲刺未完成的工作
    1. 给公司团队带来经验和知识
    2. 消除风险
    3. 开发成本

  70. 当刺探成功找到降低风险的解决方案后，应在下一个迭代执行，而不是当前迭代。

    精益 Lean

  71. 精益思想：作用多种现代管理方法，以社会需求为依据，以充分发挥人的作用根本，有效配置合理使用资源。最大限度为企业谋求经济利益的经营管理理念。

  72. 精益，关键：最大限度减少浪费。
  73. 精益，所谓消除浪费，就是最大化未开展工作
  74. 精益基于7条原则
    1. 消除浪费 Eliminate Waste
    2. 强化学习 Amplify Learning
    3. 尽可能晚决策 Decide as late as possible
    4. 尽可能快交付 Deliver as soon as possible
    5. 授权团队 Enpower Team
    6. 构建完整性 Build Integrity
    7. 全盘检视 Optimize the Whole
  75. 精益软件开发原则是：
    1. 消除浪费Eliminate Waste
    2. 创建知识 Create Knowledge
    3. 推迟决策 Delay Decision
    4. 快速交付 Quickly Deliver
    5. 对人尊重 Respect People
    6. 内建质量Build Integrity
    7. 整体优化Optimize the Whole
  76. 精益7种浪费：MITWOOD：
    1. Motion 动作
    2. Inventory 库存
    3. Transport 运输
    4. Waiting 等待
    5. Over Production 过度生产
    6. Over Process 额外流程
    7. Defect 缺陷
  77. 精益生产，估算浪费，浪费就是库存，所以必须【限制在制品WIP】
  78. 价值流图，精益生产工具，形成客户产品的材料和信息流动进行分析
  79. WIP，注意，在制品是指材料或部分已开始生产但是还未完成的产品
  80. 日本管理属于，敏捷术语，Kaizen，持续改善，谐音“改善”
  81. 执行价值流程图大致包括5个步骤
    1. 确认产品,客户和范围(即流程的始末)。
    2. 地图作为团队或者个人现时价值流,确认流程步骤,延时和信息需求。估算流程步骤的持续时长和前置期持续时长(lead time durations)。前置期是指在发生前一项流程或者事件需等待的时长。
    3. 分析价值流程图来确认浪费存在的地方(比如前置期)和流程可完善的地方(流程时间通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间)。
    4. 通过分析，总结出一份展示价值流应努力达到的前景或者目标的未来价值流程图。
    5. 通过流程完善活动(即完善)或者其他方法来达到目标的一些工作。

  82. Kaizen，就是细微变化的持续改进

    看板 Kanban Board

  83. 看板核心属性

    1. 工作流可视化 Visualize Workflow
    2. 限制在制品 Limit WIP
    3. 管理流程 Manage Flow
    4. 明确过程政策 Make Process Policies Explicit
    5. 实施反馈循环 implement PDCA
    6. 提高协作性 Improve Collaboratively
  84. 看板=及时调度系统，管控库存的，控制库存精度，消除瓶颈
  85. 累积流量图Cumulative Flow Diagram：显示了积压的、开始的、设计了的、编码的和完成的工作项
  86. 最简单的看板，将要做 To do，正在做 Doing，完成的 Done
  87. 当完成一个任务，要将他放置在看板的“准备测试”
  88. 利特尔定律是一个数学公式，它表明工作队列的持续时间取决于它的大小
  89. 限制WIP太低，容易人员空闲；限制WIP太高，任务容易空闲

    动态系统开发 DSDM

  • 生命周期
    • 可行性研究
    • 商业论证
    • 功能模型迭代
    • 创建迭代
    • 实施

      发布计划 Release Plan

  1. 发布计划有助于客户和敏捷团队决定每一个项目时间范围或者阶段内应该开发的内容和一个产品理想上准备发布的时间
  2. 创建产品路线图需：
    1. 确认需求（这些会成为产品待办事项的一部分）
    2. 将需求分类或分定主题
    3. 评估相对工作量（例如：计划扑克或者亲和估算)和优先化(价值）
    4. 评估粗略时间框架（评估高速和冲刺持续时间,以及粗略发布时间）
  3. 产品愿景 Product Vision，不是项目愿景
  4. 常识：一个发布计划Release plan包括多个迭代计划iteration plan。
  5. 发布计划：定义了能力或者特性层次的描述
  6. 初始阶段用固定总价合同；成本报销/工料合同；不超过固定费用合同

  7. 如何区别？产品路线图和发布计划

    1. 产品路线图：每个版本需要交付的主题或者高层级的功能，是高层级的计划
    2. 发布计划：显示每个版本中需要设置几个迭代
    3. 迭代计划是更细层次的计划分解

      用户故事 User Story与估算与计划 Estimate&Planning

  8. 对用户故事负责的人：客户和PO

  9. 团队需要每周花1小时以上的时间来细化故事，那么产品负责人可能会过度准备，或者团队可能缺乏评估和细化工作所需的一些关键技能
  10. 用户故事代表，客户价值，每个迭代完成越多，带好带来更大客户价值

  11. 用户故事书写原则：INVEST | Independent | 相互独立（如果相互依赖，会导致难以估算优先级，难以计划） | | —- | —- | | Negotiable | 需求可协商、可沟通，不是一成不变 | | Valuable | 对客户/用户是有价值 | | Estimable | 可估算的，如故事太大，则需解聚（分解） | | Small | 颗粒度小，便于在一个迭代可以完成 | | Testable | 可测试（注意不是，Time Bound） |

  12. 敏捷不能同时用故事点和理想时间同时估算

  13. 亲和估算（近似估算）：用S，M，L，XL来标注，而且估算速度最快。为大规模敏捷估算
  14. 计划扑克的参照点用户故事是：「中码」或者「均码」，不是小码！
  15. 安迪和他的团队正进行到迭代计划，他们从一个用户故事中识别出 8 个任务，那么每一项任务开发或者执行所需时长大约是（估算任务持续时长的一条经验是每一项任务的应大约占开发时长的四小时到两天（16小时）。）
  16. 理想时间：没有任何打扰（中断），开发一个用户故事的，真实的绝对时间
  17. 创新游戏，目的为了收集需求
  18. 创建角色，创建虚拟用户，想象用户如何与系统交互。极端人物：发现容易遗留的需求
  19. 随着开发的熟悉，一个用户故事的开发周期会越来越短。
  20. 交付周期：从放到看板到提供给客户的时间
  21. 周期时间：一个用户故事，从开发到变成功能之间的时间
  22. 响应周期：从待办到正式开始开发的等待时间
  23. 理想时间：完全不被打扰，不被中断的情况下，开发用户故事的理想时间
  24. 规模大小：史诗＞特征＞用户故事＞任务 >子任务
  25. Epic > Feature > Theme >User Story > Task > Sub-task
  26. 速度，不应跨团队比较，没有意义。
  27. 故事点：类比估算、大小和复杂性、规模
  28. 故事点代表成本，价值点代表收益
  29. 排序的纬度：价值、风险、成本
  30. 如果一个迭代有未完成的用户故事，即便是50%完成度，那么就不能被定义为完成
  31. 解聚指将大的用户故事分解为小的更易于处理的小的故事，类似分解。

  32. 开发一个用户故事：2-5天；执行一条任务：4小时-2天

    产品待办列表PBI Product Backlog

  33. PO管理产品未完成项PBI，团队管理冲刺未完成项SPI

  34. PBI的列表条目的体现形式通常不是具体需求，而是用户故事
  35. 切记！！如果用户故事用两个维度，分别是：价值、风险，来定义，应当先完成：高价值，高风险的用户故事，因此，排序的时候需要参考这条准则
  36. PBI排优先级
    • 动态的
    • 客户价值，客户意愿
  37. PBI需要梳理，但SPI通常不需要
  38. PBI最顶是高优先级，最底是已完成项
  39. PBI符合DEEP原则：
    • Detailed Appropriately, 详尽适宜
    • Estimable，可估计
    • Emergent,，涌现的
    • Prioritized，排好优先级
  40. DoD，实际上就是对应PMP里面的，质量验收标准，由团队负责定义的（不是PO也不是客户哦）
  41. MVP被定位能为客户带来价值的最小增量。
  42. PO本人是不能直接代表客户价值，只是用PBI的高优先级的用户故事代表客户价值
  43. 已提出的（但未批准的）变更，不能放到PBI中

  44. PBI可以显示全部剩余的工作，但是迭代燃尽图只能显示当前迭代的剩余工作。

    迭代/冲刺待办列表SBI Sprint Backlog

  45. 迭代待办列表SPI出现矛盾或分歧，由团队负责，PO或者SM不插手

  46. 迭代期间，是可以与PO商量调证优先级

    迭代/冲刺 Iteration/Sprint

  47. 冲刺是，每个迭代，是一个定长或不定长的时间块，又叫时间盒。

  48. 时间盒使风险从客户价值上转移到技术难度上
  49. 多次迭代的的目的是，降低不确定性和风险，快速获得客户反馈，从而通过自检和反思来快速自适应，正如门径流程，多个阶段是为了降低不确定性
  50. 如果，迭代结束，功能不被客户验收，就添加到下一个迭代的产品待办事项！不要选刺探！刺探用于最初，希望快速验证某个方案
  51. 未符合验收的功能，放到下一个迭代
  52. 敏捷的开发时间是固定的，开发成本是固定的，唯独范围是频繁变更的，质量是随着时间推移不断完善
  53. 如果当前迭代找到某问题的补救措施，先找PO评审，再决定是本迭代解决，还是放到PBI未完项
  54. 如果客户提变更，怎么办？
    1. 由PO负责协调客户需求，并由PO根据客户价值，调整PB里面用户故事的优先顺序。
    2. 注意！PO对产品功能（用户故事增加/保留/删除）具有最大决定权力
  55. 在冲刺期间，如果客户或PO提新需求，怎么办？
    1. 不允许变更，也不允许重排故事点优先顺序。除非等价变更。
    2. 与客户谈判，放弃一些与新增需求规模相同的次要（低优先级__）功能。
  56. 如果PO在冲刺期间要求删掉一个功能，SM如何处理
    1. SM支持PO的决定
  57. 敏捷定义范围：一次只能定义一个迭代期的详细范围
  58. 对于文档更新，可以再每次迭代期间分配时间执行变更，并定期确定文档更新状态
  59. 在每次迭代的后期代码都应该具备“准备发布”的质量
  60. 首次称为：迭代0，用于做计划，无直接价值产出，只有可运行软件才有价值

  61. 最终迭代：迭代H，强化迭代，没有新功能或新需求被开发

    绩效/工具/燃尽图/燃起图/累积流量图

  62. 燃尽图，燃起图。横轴表时间。竖轴是故事点（即功能）。

    1. 注意，燃尽图有可能会起伏，不完全是倾斜向下趋势的线段，反映了：任务评估不足、技术难度、开发任务
  63. 燃起图，刚好与燃尽图相反。表示已完成的故事点。
  64. 燃尽率：一个迭代中。完成的故事点除以总时间。其实就是燃尽图曲线的斜率。
  65. 敏捷EVA，对于一个迭代是测算不精确的，因为范围不明确。
  66. 敏捷EVA，只适用于当前迭代，不适用跨迭代的比较，哪怕有提升了
  67. 风险燃尽图是用于跟踪项目伴随时间风险的风险管理技能。通过风险燃尽图，干系人可迅速查看随着时间项目风险管理的绩效（比如提高，降低以及对应的量值）。严重度（影响和收益的产品）是沿着竖轴绘制，而横轴是时间。影响力的量值往往是0-5，按风险升序排列。收益率/可能性的量值往往是0-5，按收益率升序排列。例如，一项风险的最高风险度是25（5*5=25），最低风险度是0。敏捷团队和客户/产品负责人识别到风险同时分配严重度值到风险登记册，并跟踪这些值。理想情况下，风险严重度会随着时间降低。
  68. 燃尽图突然上升，唯一解释是因为待办事项有新增。
  69. 累积流量图用来追踪和预测敏捷项目

  70. KLOC 代表“千行代码”

    迭代/迭代规划会议 Iteration/Sprint Planning Meeting

  71. 任务Task明确定义了输入输出、技术指标和其他具体要求的任务说明；如果Story足够小，没必要再分解Sub-task

  72. 许多基千迭代的敏捷团队在两周的迭代中用 1 小时的时间盒讨论。 （团队选择一个迭代持续时间，为他们提供足够频繁的反馈。）
  73. 团队通常有一个目标 ， 就是每周用不超过 1 小时的时间来为下一批工作细化故事。 团队希望把时间尽可能花在工作上，而不是计划上。 如果团队需要每周花 1 小时以上的时间来细化故事，那么，产品负责人可能会过度准备，或者团队可能缺乏评估和细化工作所需的一些关键技能。

  74. 滚动式规划，一次规划未来几次的规划，不会规划太多，因为范围可能会变更。

    每日站会 Daily Scrum Meeting

  75. 每日站会，反模式：报告状态，解决尖锐问题，工作模式都不适合。应该主张：会后解决

  76. 反模式 Antipattern 就是指：不可取的工作模式或流程
  77. 每日站会，可以提问题，暴露风险，是风险管控的好工具
  78. 每日站会，切记！：可以交流问题、（暴露）提问题，提障碍。但要注意，提问题过程不便太过发散，深入，要聚焦关键问题。站会结束后可以再开详细问题解决会议。
  79. 每日站会，不一定是每日开一次哦！如果有紧急问题、突发状况，也可以随时再开！！
  80. 每日站会，不解决实际问题！只是相互沟通，信息透明化
  81. 敏捷术语，DRY，Don’t Repeat Yourself，不要重复做自己

    迭代/冲刺评审会议 Sprint Review Meeting

  • 尝试一次改进太多的事情却没有完成其中任何一件，比计划完成较少的事情并成功全部完成要糟糕得多

  • 演示是为了：获得修订/调整后的产品待办事项列表

    迭代/冲刺回顾会议 Sprint Retrospective Meeting

  • 回顾会议步骤

    • 预设会议基调（开场）
    • 收集数据
    • 分析原因
    • 采取行动
    • 回顾收尾
  • 邀请职能经理参与过程回顾，共同找到达成共识的方
  • ESVP，人员分类
    • Explorers，探索者，想学新东西
    • Shoppers，采购者，原因带着新东西回去
    • Vacationers，度假者，来休息的人，不产生价值
    • Prisoners，囚徒，被迫来参加会议的人

      组织变革

  1. 导入敏捷，选择短期的，1个月的项目进行
  2. 向敏捷转型，但不知道从哪里开始，最好从每日站会先开始
  3. 敏捷经理人，首先要舍弃事无巨细的管理，不需管理得太细；另外对于工作包分解和进度规划，需要采取滚动式规划以及渐进明细的原则，也意味着一开的规划不需要纠结细节和深度。

    冲突等级

    | Level 1 : Problem to Solve | 问题解决（解决：合作/解决） | 解释：虽然通常是不一致或误解导致的问题，但是团队倾向于合作方式来解决 | | —- | —- | —- | | Level 2 : Disagreement | 争论（解决：合作/解决） | 解释：说话开始有所保留、并且成员开始保持距离，自我保护。虽然没有所谓敌意，但都开始警惕 | | Level 3 : Contest | 竞赛（解决：包容） | 解释：出现人身攻击，带有指责的抱怨，为了胜利可以牺牲对方 | | Level 4 : Crusade or Fight/Flight | 战斗或逃跑（讨伐）（解决：第三方中立角色传达信息） | 解释：意识形态上划清界限！群体保护意识强烈，群体之间认为唯有铲除眼中的障碍才能解决问题 | | Level 5 : World War | 世界大战（解决：分开他们） | 解释：没有任何交流、没有任何建设性方案，派系斗争，直到一方被毁灭 |

积极倾听

Level I – Internal Listening 内容倾听 虽然在倾听，但只关注自己的感受，忽略真实意图
Level II – Focused Listening 专注倾听 开始关注演说者所表达内容
Level III – Global Listening 全局倾听 开始感受情绪，语调，肢体语言

价值排序

  • 功能缓冲：添加百分之多少的故事点作为，一次迭代的缓冲

  • 进度缓冲：如果错过期限，那就要在项目最后添加一个时间段的缓冲

    价值流图

  • 识别客户和确定的价值

  • 识别价值流图
  • 识别浪费
  • 响应客户需求
  • 追求最佳状态