《敏捷实践指南》-5 价值胜过约束

这是一篇关于《敏捷实践指南》-5 价值胜过约束的思维导图

《敏捷实践指南》-5 价值胜过约束

• 传统与敏捷的差异
  • 传统项目
    • 专注于明确的项目需求（定于范围），确保在明确需求范围内完成项目
    • 可测量的指标（进度、范围和成本），把完成铁三角当作项目成功
    • 团队只对铁三角的约束条件负责，通过对流程的管理控制变更
    • 传统项目通常由项目经理主导，弱化了产品经理的职能价值
  • 敏捷项目
    • 聚焦于交付产品的实际价值，试图首先强调交付的产品是否能够带来应用价值
    • 团队追求交付最能满足客户的产品价值，并平衡铁三角的约束
    • 项目进度仍然为关键性约束，但通过时间盒的迭代周期来适应需求变更
    • 敏捷项目需要产品经理和项目经理共同主导项目需求的优先级、功能清单、成本/效益分析，从价值的角度产品经理具有更重要的角色
    • 项目领导者需要具备与利益相关方进行沟通管理的商业头脑
• 持续流动的价值
  • 价值理念
    • 企业或组织的成果，往往与财务收益有关，必比如提高市场占有率就能带来财务收益
    • 交付的产品价值要能具备持续的流动性，除了交付的高质量以外，还应该能够适应未来的客户需求
    • 客户定义产品应该具备的能力，带来的价值和实现量化的商业目标，并且产品价值随着产品功能的不断演变而产生
    • 产品的未来收益取决该产品能否迅速、低成本适应新出现的能力要求，如果产品仅符合当前的客户需求，而不容易适应未来变化的需求，注定其生命周期会很短
    • 客户是使用创造的产品来产生商业价值的个人和群体
    • 客户定义价值，他们通过产品的使用体验来判断产品价值
    • 如果希望交付的产品具有重大客户价值，就必须和客户建立长久的伙伴关系——一种双方共同承担责任和义务的关系，强调是的对客户的业务提供实际帮助
  • 创新理念
    • 我们生活在一个由创造力、创新力和想象力推动世界发展的时代
    • 从交付文档到交付真正产品的迭代版本，是创新思想和实践的重要转变
    • 创新不拘泥于形式，可以是新的产品，新的商业模式，新的工作流程，或者新的提升绩效的举措，创新和创造力是敏捷项目的助推器。效率和优化可以交付我们能够想象得到的产品和服务，而创新交付的是我们想象不到的产品
    • 基于敏捷的创新，核心要求就是要持续的技术变革，增加竞争力，产生新的创意和不断的缩短产品开发周期
  • 专注执行
    • 将精力聚焦于交付产品相关的活动，就能够为项目项目增加价值，而将精力聚焦于计划和控制，则只是增加项目的开销。敏捷项目中，计划和控制仍然是一个重要部分，只是它强调精力放在如何专注于执行来交付价值
    • 传统计划的不足
      • 计划的动机来自于项目之外，做计划往往是为了满足法律法规或者管理要求，而不是基于项目本身的需求
      • 制定计划往往与控制欲有关，而不是实际的项目需求，为了控制目的而制定任务计划，与工程师实际工作往往无关，或者关系不大
      • 无法让项目更好的聚焦执行，交付更大的产品价值
      • 脱离现实的计划不能让计划更好的执行
    • 制定计划要为了更好的促进创建产品愿景并实现该愿景，而不是制定计划和进度表，控制进度，保证计划得以实现
    • 控制计划，关注的是如何进行纠偏，它首先认为计划是合理的，然后考虑如何把计划通过简单的流程能够转化为可预见某种结果的行动，遵从计划是传统项目的最大魅力和陷阱，因为软件开发是创造力而不是依章照搬的机械工作
  • 精益思想
    • 精益的基本原则就是减少浪费，做较少的事但做正确的事，消除瓶颈更好的交付价值，避免为了项目过程的合规而让团队沉迷在文档当中
    • 过多的合规性要求和文档，不仅仅是消耗了大量的时间，而且扼杀团队的主动性和创造力，大量的表格、流程，不是这些举措本身没有价值，而是组织让这些流程凌驾于个人知识和能力之上，凌驾于价值交付之上
    • 项目领导者应该协助团队做出关键的决策，他才能为项目交付做出贡献，而不是只是为了交付报告
• 敏捷要求快速交付
  • 迭代的目的，就是为了尽快的交付产品，并获取早期的财务收益，而不必等到全部特性完成后才能获得财务回报
  • 证实项目团队向客户交付了成果，应该是获得了多少客户值得信赖的反馈，而不只是需求文档，敏捷的终极目标是为了帮助客户获得成果，而不只是为了完成工作
  • 敏捷迭代的4个关键词
    • 迭代开发
      • 通过连续性的短期开发、评审和调整，来扩展交付版本的能力
    • 基于产品特性
      • 始终交付的是满足客户实际应用场景的产品功能，而不是为了项目任务
    • 时间盒
      • 以1~4周为周期的时间盒强制迭代结束，要求在限定的范围做好准备
    • 增量
      • 产品能够经过一次或者多次迭代后都能够及时部署
    • 客户不了解，也不关心项目的工程任务，但他们知道他们想要的产品特性
  • 在项目过程中，让客户评审结果使其尽可能的接近实际的业务场景需求，是应对不确定性的环境下项目需求随着时间推移而演变的恰当策略
  • 客户很难在一大堆项目文档中找到真正所需要的东西，而迭代开发的策略能够不断的自我纠正和完善，而时间盒的应用会在实际工作中强制项目领导者做出困难的决策
• 敏捷追求卓越的技术
  • 大多数的项目和组织，都把精力聚焦在行政管理的卓越，而不是技术的卓越，他们很难去鼓励技术卓越和个人的责任感，因为这一类的组织始终关注的是传统项目的金三角约束考核指标
  • 敏捷项目领导者必须关注技术的卓越，因为它是适应能力和低成本迭代的关键，项目领导者需要和团队一起，讨论和决定项目的技术方法，而且在解决技术问题时，要让团队始终聚焦在业务目标上，而不只是为了完成任务
  • 需要软件都苦于深陷技术债务的泥潭，历史上的低质量的技术开发方法累积的问题严重的拖累了项目交付，但他们罔顾现实，继续累积技术债务，而不是尝试解决根本问题
• 敏捷倡导简洁的产品
  • 以简洁为本，极力减少不必要的工作量是一种艺术，速度不是简化的结果，但简化能提高速度，并且降低成本，从而增加价值
  • 过于烦琐的结构和流程，给了团队不去思考的借口，敏捷项目的管理机制和流程是生成性的，而不是规定性，它试图避免描述团队成员应该做的每个活动细节
  • 敏捷原则推动团队去裁剪和调整一套和实际情况接近的规则并加以实践，从最小集合开始，然后明智的随着需求而增加，这比一开始从全面规定然后逐步精简要更为有效
  • 传统项目始终是盲目性的把合规性的文档、要求作为他们首要的重点，他们忽略了这些活动充其量只能减少错误、欺骗、劣绩和成本透支的风险，而无法确保交付高质量的成果（或者他们始终都不把最终的产品成果作为重点）