敏捷与pmp的结合

敏捷与PMP的结合，详细的总结了整体管理，范围管理，进度管理， 成本管理，资源管理，相关方管理，敏捷和迭代的区别。

敏捷与PMP的结合

• 整体管理
  • 在敏捷场景中，整合管理体现的特征有
    • 1.范围动态
      • 为了适应易变的场量，项目范围从来不会一成不变， 而是在产品待办事项列表的不断被更新、维护、分析和排序。团队根据吞吐能力确定在一个Sprint中要完成的待办事项。在工作范围中，不但工作内容可以变，而且优先级也可以变。
    • 2.过程精简
      • 敏捷开发不再拘泥于49个管理过程、五大过程组，不需要冗长而苛刻的整体变更控制程序;进度、成本和范围也不是按照三大基准来控制，对文档的要求也更务实和简约。总之，在敏捷开发中，团队的注意力从过程的规范性转向产品最终的价值。也就是说，团队必须给自己“减负”和“松绑”，才能更好地创造价值。
    • 3.状态可视
      • 开发之前的原型设计，需求分析中的卡诺模型，每日站会中的看板、燃尽图，评审中的实际效果展示，回顾中的价值流图，无不体现了可视化的思想。
    • 4.质量内建
      • 结对编程( Pair Programming )、测试驱动开发( Test-Driven Development, TDD)等方法都强调产品质量不能依赖事后的检查，开发工程师在开发产品功能之前会先开发自动化测试脚本，质量内建在产品开发过程中。
    • 5.团队自组织
      • 整合的工作不再是以项目经理为主。在敏捷团队中， Scrum Maste只是为团队创造一个充分参与、高效互动、集体决策的开发环境和氛围，而关于干什么、怎么干、由谁来干，都是由团队自己协商决定。
  • 敏捷场景下的变更管理
    • 变更要简便得多，因为敏捷就是为了应对变化而生。项目的全生命周期都可以接受变更，哪怕已经到了产品开发的末期，也一样不拒绝变更。因为需求变了，哪怕产品按原计划做得再完美，也失去了价值。
    • 工作的事项由产品负责人根据轻重缓急确定优先级
    • 原则上，除非特殊、紧急的情况，否则冲制周期内开发团队不允许被打扰
• 范围管理
  • 不同生命周期的范围管理对比
    • undefined
  • 活应型(敏捷)生命周期的范围最为灵活
    • 通过用户故事来描述范围内的工作
    • 用产品代办事项列表( Product Backlog )来控制工作范围
    • Product Backlog里的内容随时可加、可减、可改，而且优先级也可以动态调整
    • 团队完成的工作是否满足用户需求是可以随时得到反馈的
    • 发起人或用户在项目生命周期中是持续参与的
  • 精益思想
    • 精益的思想渐渐被重视起来
    • 玛丽·帕蓬迪克(Mary Ppdie)提出的精益软件开发原则
      • 1.优化全局;2.以客户为中心;3.赋能工作者;4.减少浪费;5.增强学习;6.加速流动;7.质量内建;8.持续改善.
      • “不能为客户/用户创造价值的工作都是浪费。”精益思想赋予了项目范围管理新的内涵。
  • 敏捷场景下的需求管理
    • 在敏捷实践中，对需求的管理有两种常见方法：完全解析和滚动解析。需求管理体现于一个重要活动： Product Backlog梳理
    • 1.完全解析
      • 完全解析后，项目的需求变得一目了然
        • 1. 需求优先级十分明确， 能够画出细致的路线图；
        • 2. 项目的工作量和工期能够较精确地估算；
        • 3. 能让团队形成项目一切尽在掌握中的自信。
      • 对于需求简单的小项目而言
        • 完全解析有助于全面、 完整地把握项目， 控制项目进度， 并且也比较容易梳理和保持 Product Backlog 的条理性
      • 对于复杂度规模的项目而言
        • 完全解析可能导致Product Backlog管理混乱。长长的Backlog 列表难以组织和梳理，难以对需求进行解耦和确定优先级。并且由于需求是涌现的，频繁的需求变更往往会加重 Backlog的混乱程度， 增加无效工作
    • 2.滚动解析
      • 滚动解析是将需求分解和增量交付有机结合起来。
      • 滚动解析是为了在保证需求的完整性、 合理性和一致性的前提下， 尽可能缩短需求定义和开发之间的时间间隔， 降低管理难度， 控制风险和成本。
    • 3.Product Backlog梳理
      • 该活动包含但不限于这些内容
        • 1. 保持产品待办事项列表有序；
        • 2. 把看起来不再重要的事项移除或者降级；
        • 3. 增加或提升涌现出来的或变得更重要的事项；
        • 4. 将事项分解成更小的事项；
        • 5. 将事项归并为更大的事项；
        • 6. 对事项进行估算。
      • 排序越靠前， 优先级越高， 描述和解析越细致
• 进度管理
  • 敏捷中是按需进度计划
    • 指根据团队的交付能力来规划承接的任务量，限制正在开展的工作数量，防止超过团队能力。按需进度计划来自看板方法中的拉动式生产。
  • 拉动式生产
    • 益生产遵循“内部客户”原则，上道工序把下道工序看作自己的客户，让下道工序根据“客户”的需求来“取货”。从最后一道工序反向进行刀第一道工序，即形成拉动式生产。
    • 例如：顾客在超市买走了商品，货架上的商品减少，工作人员从小库房补充，小库房缺货从大仓库补充，大仓库缺货由工厂生产补充。理想的情况是，工厂接到顾客订单后再开始生产，将浪费降到最低。
  • 在制品（WIP)
    • 在制品是指正在加工、尚未完成的工作
    • 平均周期时间(Average Lead Time)=在制品（WIP）数量/吞吐率（Throughput Rate)
    • 例如：Backlog里有50个特性在排队，而你们团队的吞吐率是5个特性/周，如果你的需求不插队，那么你要等待10周才能排上。
    • 我们常常把“加人和加班”当作救命稻草，一直在吞吐率上下功夫，可为什么不琢磨一下在制品的数量呢?在制品堆积会让产品开发进入恶性循环，让团队陷入万劫不复的泥沼。限制在制品数量才是结束这个噩梦的关键。
      • undefined
  • 重新整理看板的步骤
    • 第1步：把尚未启动的工作项退回到 Backlog。
    • 第2步：把已经启动但进展不畅的工作项悬挂起来单独评估。
    • 第3步：限制在制品数量，每次迭代通过回顾来调整，渐进式地调整到与团队的吞吐率相适应。
  • 敏捷场景下的进度管理
    • 敏捷发布规划
      • 在敏捷发布规划中，软件是按版本发布的，每个版本由若干个迭代组成，每个迭代又包含了若干个功能（用户故事），每个功能可分解为若干个任务。
      • 看板方法
        • undefined
      • 敏捷发版规划图
        • undefined
    • 洋葱圈规则
      • 在敏捷开发中，团队按照层次做滚动式规则，也叫洋葱圈规则
      • 层次越低，周期越短，规划越细。如每日站会（1天）、 Sprint计划（1~4周）、版本计划（几周或几个月）、产品路线图计划（产品生命周期）、投资组合计划（组织战略周期）。
      • undefined
  • 敏捷场景下的活动历时估算
    • 敏捷估算扑克
      • 由一组斐波纳契数列的数字和符号组成。这些数字包括0、 1/2、 1、 2、 3、 5、 8、13、 20、 40、 ? 、 ∞，其中，“?”代表无法判断。
        • undefined
      • 每副扑克都有四组这样的数字，可供4个人便用。
      • 如果参与估算的人数多于4个人，那么可以用两副扑克。
      • 人数最好控制在3~8人,因为如果人太少，估算准确度低
      • 如果人太多，估算效率低
    • 敏捷估算扑克的使用方法
      • 1.每个团队成员拿到一组卡片,包括0、 1/2、 1、 2、 3、 5、 8、 13、20、 40、 ?、 ∞ ，共计12张。
      • 2.寻找一个大家都熟悉的一个最小的功能作为参考基准,例如，每个软件几乎都要用到的“用户注册”功能，把它的工作量定义为1个故事点。
      • 3.产品负责人或者一名团队成员扮演阅读者的角色，负责阅读需要估算的产品待办事项列表中的条目，并且询问大家是否有疑问。
      • 4. 团队讨论这个条目。
      • 5.当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌。例如，如果团队成员认为这个条目的开发工作量是参考基准“用户注册” (1个故事点)的5倍，就选数字为5的扑克牌，表示5故事点。团队成员先不公开估算结果，而是将牌面朝下扣在桌面上。
      • 6.阅读者向大家确认是否都已估算完毕，在所有人都出牌之后，大家同时亮牌展示估算结果。
      • 7.出最小牌和最大牌的两位成员分别向大家阐述理由。
      • 8.回到第4步，重复第4步至第7步，直到大家的结果一致或只剩下相邻的两个数字，比如5和8,就取较大值8结束这个条目的估算。
    • 使用敏捷估算扑克这种方法的好处
      • 团队成员都能平等参与、独立思考并表达自己的观点;
      • 通过每一位团队成员的参与，使知识和经验得到更好的分享;
      • 采用故事点的方式便于团队成员理解，可以更高效地达成共识。
  • 敏捷场景下的进度控制
    • 敏捷场景下最常用的控制工具燃尽图
      • undefined
    • 例如：在敏捷开发中，假设一个冲刺(（Sprint） 21天，有250个故事点的总工作量，如果团队匀速开发，每天完成的故事点都一样多，那么剩余故事点的数量就应该按照虚线（灰色)持续减少，这条虚线就是理想燃尽线。
• 成本管理
  • 在敏提场景下，不为用户创造价值的活动才是浪费
  • 如果企业做一款创新型产品，而客户是谁、客户的需求都是未知的，也是快速变化的。在这样不确定的环境中，耗费在产品特性、工作优先级、技术路线上的争论都是实在在的浪费。
  • 不要急着投入大量的资源去开发产品，而是要先开发一个最小可行性产品(MVP)，将MVP带到早期客户中去验证概念的价值，然后依据早期客户的反馈来调整产品概念。 MVP不一定是真实的产品，而是以最少的精力投人和最快的速度完成一次“开发—测量—认知” 反馈循环的试验品。
  • MVP的原则就是用最少的资源、最短的时间做试验，获得早期用户的反馈，验证产品的价值。
• 资源管理
  • 敏捷场景下的项目团队
    • 自组织团队，虚拟团队/分布式团队
    • 打造高效能团队的经验有
      • 1.短期加班可以临时提高生产力，但长期加班反而会降低生产力。团队成员每周工作时间应不超过40个小时，脑力劳动者应不超计35小时。
        • undefined
      • 2.每天上班8个小时，只安排6个小时的工作，因为团队成员要有思考的时间。
      • 3.结果( Outcome )比产出( Output )重要，要让团队成员创造1个让人尖叫的功能，而不是10个可有可无的功能；
      • 4.团队成员应专职而不是兼职工作，因为切换成本远比你想象的高。
      • 5. 团队需要集中办公。
      • 6.团队保持精干， 7±2个人是合适的范围，如图9-9所示。人太多，沟通成本太高；人太少，解决问题的能力有限。我们要掌握“两个比萨原则”，如果两个比萨都不足以喂饱一个项目团队，那么这个团队就太大了。
  • 敏捷场景中的采购管理
    • 因为甲乙双方对项目的范围无法确定， 需要根据现实的开发情况和外部反馈实时地做出调整， 所以适合采取敏捷方法或混合开发模式。可是不确定范围， 怎么签订采购合同呢?甲乙双方往往通过主要服务协议( MSA )来管辖整体协作关系， 用附录或补充文件记录适应型的工作内容。变更只针对适应型工作， 不会对主体协议造成影响。
• 相关方管理
  • 敏捷场景中的项目需求、环境都在变化之中， 更需要项目相关方的有效互动和积极参与。敏捷团队应直接与相关方互动， 而不需要通过各层级管理者。
  • 客户、用户和团队在动态的共创过程中及时、充分地交换信息， 通常能实现更高的相关方参与度和满意度。
  • 在整个项目期间， 团队保持与相关方的互动， 有利于降低风险、建立信任和及时做出调整， 从而节约成本， 提高项目成功的可能性。
  • 为了让相关方更好地参与项目并与团队互动， 敏捷方法提倡高度透明。例如：邀请相关方参与项目会议和审查， 将代表事项、看板等项目信息发布在公共空间，以便各相关方及时发现分歧或问题。
    • undefined
• 敏捷和迭代的区别
  • 敏捷和迭代有联系， 但也有明显的不同。很多敏捷实践都具有迭代的特征， 比如，在 Scrum 框架中， 每一个冲刺( Sprint )都可以被认为是一个迭代的过程。
  • 敏捷并不等于迭代，具体区别有
    • undefined