文章详细阐述了作者学习ACP（敏捷认证从业者）过程中的理解和感悟，介绍了敏捷宣言的四大价值观和十二原则，以及敏捷方法如Scrum、XP等的实践要点。文中强调了人与人之间的互动、工作的软件、客户合作和响应变化的重要性，并探讨了各种敏捷工具如燃尽图、看板图的应用。此外，还讨论了如何通过持续交付和反馈来适应变化，以及团队的自我组织和持续改进在项目管理中的关键作用。
ACP学后感
一开始学习ACP知识，总和PMP知识区分不开，到底什么是敏捷？怎样做是敏捷？现在工作中所说的敏捷到底有哪些因地制宜的做了剪裁？带着一堆问题，举步维艰的学习着，经过好几个月的反反复复的学习，以下是近期学习后对ACP的学习理解。
-
目录
5、 累积流图（CFD: Cumulative Flow Diagram)
什么是ACP
ACP其实是从PMP知识体系长期运行后的一种衍生方案。只是它更加适应多变、不确定项目的管理。
它是一种思维，
它是一种应对复杂项目的模式库（包含scrum、XP极限编程、精益软件开发、水晶、FDD等）。里面有各种工具（燃尽图、鱼骨图等），可以拨开迷雾让管理者和团队更加清晰的看清当前阶段问题点，采用行之有效的短期应对方案。
-
ACP思想
2-1 敏捷宣言-四大价值观
2-1-1 个体和互动 高于 流程和工具
a. 项目是通过人来完成的，流程和工具可以帮助人，但绝不能自行完成工作。
虽然，过程和工具都是好东西，但是它们有时也会成为障碍。面对面的直接沟通，比一些流程性的文件和工具沟通，效率要高出很多。（经常沟通）
当然最好的是，在沟通后就多方达成的共识形成一个简要性的文档备录（做好记录）。
b. 沟通和交流：沟通的目的是进行思想碰撞。在沟通当中了解别人的思维方式，表达自己的思维方式，然后达到共同的目的
2-1-2 工作的软件 高于 详尽的文档
看文档是一件让人头疼的事，无论是需求或技术文档，撰写和维护都需要耗费大量的人力，文档的不灵活性让其地位在敏捷开发中地位降低，因此这里的文档要尽可能精简，能用软件替代文档的任务首选软件。（但是文档不是不写，而是写了之后留作记录）
2-1-3 客户合作 高于 合同谈判
这个价值观的核心是越接近你的客户越好。客户最清楚他想要什么，即使在需求明确过程中也会包含一些试验和错误。在合同谈判期间，试图避免所有的尝试和错误不发生是不现实的，也是徒劳的。（了解客户，让客户去使用，提问题，解决问题）
2-1-4 响应变化 高于 遵循计划
a. 和瀑布流中将产品的功能完全规划好后集中开发不同，不断变化的需求让敏捷从业者制定计划时尽可能的简化
b. 每次迭代交付一个可用的最小功能，这个功能时是不完美的、简陋的，只能满足用户最基本的需求，然后通过后期客户的正反馈慢慢完善功能。这种方式试错成本低，能快速应对需求变化。
2-2 敏捷的原则的解读
2-2-1 我们的最高目标是通过尽早和持续地交付有价值的软件来满足客户
第一点 是要满足客户需求。如果我们只创造了完美的项目计划和文档来让公司的项目管理办公室(PMO)或者质量保证工程师(QA)满意，那么我们就是失败的。我们关注的焦点应该是客户，客户满意是衡量项目成功的关键因素。
第二点 是要尽早和持续交付。我们必须让我们的项目和项目团队尽早交付及频繁交付，鼓励和支持团队成员认同这个观点。早起发现错误会有足够的时间去修正，修正的成本也是最低的。
第三点 是要交付有价值的软件，而不是未完成的工作产品、工作分解结构(WBS)术语、文档或者项目计划。应该有具有目标驱动，对软件项目而言，目标就是可工作的软件；对于其他类型的项目而言，目标是产出的产品和服务或者成果。
2-2-2 即使在项目开发的后期，仍欢迎对需求提出变更。敏捷过程通过拥抱变化，帮助客户创造竞争优势。
如果是为了交付更好的成果和更高优先级的产品，那么变更对项目就是好事。对于传统项目管理而言，变通通常被认为是负面的，这意味着项目范围蔓延和偏离了项目的计划，需要引发变更成本。所以传统项目中变更控制流程非常严格，只有最高优先级的更变可以被批准。在传统项目中，项目团队大量的时间和精力都用在记录和管理变更请求上。
在软件项目或者其他类型的有高变更比率的项目而言，严格的变更管理流程会带来很多问题。相比而言，敏捷项目管理允许变更的发生，比如极限变成(XP)提倡"拥抱变化"。敏捷使用轻便、高可视化的方法来处理待办事项的优先级排序的变更。
高效处理变更可以帮助项目团队把更多的时间投入在产品开发商，而不是处理变更商。敏捷方法就是利用易理解、高可视的方法来处理变更，使项目更加灵活。
2-2-3 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
虽然我们倡导越早反馈越有价值，但是每个人都会要求完美，把工作长时间抓在受伤反而会适得其反。最好的方式是尽早并且要经常得到对工作产品的反馈，以避免在错误的道路上越走越远。
本条准则重点强调了将工作产品投入到测试环境从而获得反馈。频繁测试和反馈对敏捷项目非常重要，团队需要根据已完成的产品反馈来确定如何继续。当然，反馈中也会存在变更的要求。
短时间的交付有利于团队和业务人员之间的互动。频繁的交付使得项目团队可以得到更多的商业机会和反馈。通常在演示会上，团队会得业务优先级高的变更请求。这都是有价值的。
2-2-4 在项目过程中，业务人员与开发人员要每天在一起工作
频繁的演示是业务代表和开发人员在项目共同工作的一个很好的切入点。在实际工作中，开发人员每日和业务代表采用面对面的沟通往往比较困难，但是值得去推动。面对面的交流可以更好的观察肢体语言，相比而言，文档、电子邮件或者打电话都不能有效地传递信息。
每天和业务代表共同工作，开发团队对业务的学习程度和速度都远超在需求收集会议中对业务的理解。因此，开发团队可以提出多种有价值的解决方案来代替直接的业务申请。业务代表也可以学习到那些类型的解决方案或成本高或者开发速度慢，那些功能成本低，进而通过反馈来调整需求。
如果业务代表和开发团队不能每日在一起工作，那么也应该尽量将两个工作小组安排在一起，没两天或者频繁的互动参与工作。有些团队使用"代理客户"(PO或者BA有时候就会成为代理客户)，将"代理客户"作为商业代表的替身。
2-2-5 要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务
正如软件估算模型性成本模型(COCOMO)所显示的，好的团队成员和好的流程工具，这两个因素影响之间的比例关系是10:1。这意味着员工对一个项目能否成功会起到更重要的作用，而不是工具和流程。
显示中，我们虽然不能确保每个团队都是被精挑细选出来的理想组合，就像中国跳水团队——梦之队，但是我们可以尝试去激发团队成员，让他们成为一个可以自我驱动的理想团队。自组织团队作为项目的一个重要因素，一旦员工开始自组织和计划工作，其工作会更加高效。敏捷方法主张将团队从微观管理和甘特图中的任务式管理中脱离出来，聚焦工作技巧和团队协作从而提高生产率。
知识性项目也包含有特殊经验和技能的成员。如果开发团队可以更好地做出日常决定以及处理好计划的工作，那么项目团队中每个成员都会是专家，可以为项目的成功予以支持。
2-2-6 团队内部和各个团队之间，最有效的沟通方法是面对面的沟通。
写文档可以很好地做记录，但是速度缓慢会造成高成本。面对面的沟通可以快速传达大量的信息，包括表情和肢体语言。梅拉宾法则曾经提出：“在信息沟通中，除了语言的表达方式外，信息还可以许多方式表达。说话的内容尽占用7%，语音语调占38%，肢体语言占55%”。
在面对面的会谈中，问题可以立刻得到解决，而不是被暂时搁置或者过一段时间再被反馈。但是面对面会谈不能用于所有的沟通场所，是提倡尽量遵循。随着团队规模的扩大，面对面的沟通很难实现，此时我们就需要引入适当的文档要求。
2-2-7 可工作的软件是衡量进度的首要指标
首先，要将可工作的软件作为项目的关注目标，努力将创建文档等活动作为支持目标的手段而不是首要任务。如果产品不能工作，就不能被认为已完成了。强调"可工作"的软件是为了提醒团队功能特性只有被接受才算完成。项目是以结果为导向的，中间过程的可交付成果(比如文档和部分完成的工作)都不会得到外部的认可，被客户使用的产品才是项目的关注点。
2-2-8 敏捷过程提倡可持续的发展。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度。
一些快速应用开发技术并非已达到可持续开发的水平，很可能会由于工作时间过长而导致工作人员过度疲劳，从而造成不必要的错误。针对周期长且紧张的开发阶段，敏捷方法认为应保持稳定的进展速度，其价值在于允许团队成员维持工作和生活的平衡。可持续的速度不仅对团队有好处，也会对整个组织带来益处。过程的工作时间会导致员工辞职，组织也会失去很多资源。重新雇佣和整合新的成员会是一个缓慢且高成本的过程。
因此，保持恒定的开发速度可以创造一个更加和谐、高效的团队，较小的压力会提高工作效率、促进团队之间的协作。
2-2-9 对技术卓越和好的设计的持续关注有助于增强敏捷性。
当我们想开发团队可以努力工作并且交付大量有价值的产品时，我们也必须注意保持设计的清晰、高效和变更的灵活性。精益求精的技术和良好的设计会使产品或开发团队更好地理解与更新设计。
在软件世界中，一旦编程的基础紊乱，组织将丧失对变更响应的能力，失去其敏捷性。因此，我们需要给开发团队足够的时间进行重构，重构使编程更加稳定从而维持更长的时间。
2-2-10 尽量做到简洁、尽最大可能减少不必要的工作。这是一门艺术。
在软件行业，多达60%的功能很少被使用或者从来没有被使用过。因为很多功能并没有被使用，而且复杂的系统会隐匿很多不确定性，所以敏捷方法专注于简洁，只完成必要的元素。
复杂的项目耗时长，暴露的风险相对比较多，从而带来更多潜在的失败风险。因此，敏捷方法寻求"允许工作的最简介产品"，并将其推荐为首先的解决方案。这种方法在减轻风险的同时也帮助团队建立信息。
2-2-11 最佳的架构、需求和设计出自自组织团队。
人们喜欢自我组织，因为他们通过自己的方法最佳地完成工作、协调关系以及适应环境，同时他们也非常理解和支持这种方式。
为什么最佳架构、需求和设计来自项目团队，而不是来自项目团队外部的组织中的最佳架构师、商业分析师和设计师？因为外部的建议可能存在很多优点，但是如果技术团队对其难以实施也是一个问题。
自组织团队由更高的所有权以及对架构、需求和设计的荣誉感，团队所创建的观点如果已经通过审查，就不要再去验证。相反，如果一些观点来自团队外部，那么需要团队来验证是否可以成功使用，这又将是一个富有挑战的任务。
此外，自组织团队更加贴近项目的技术细节，因此最适合去识别实施中的问题。虽然可以尝试采纳外部的建议，但是敏捷依然采用团队的能力去打造最好的架构、需求和设计。团队成员是最了解项目的人，所以最应该去授权参与项目。
2-2-12 团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为
团队在项目进展中要不断地学习，对已经完成的任务进行反思和调整，从而为余下的项目工作做好准备。
敏捷项目通常会在每个迭代的最后用回顾会的方式反映在项目工作中的一些机会以及待改进的工作项上。一个项目会有多次的回顾，而不是每个项目仅有一次复盘，这样可以注意到很多可能被遗忘的细节，团队也会相应地区调整和适应行为。
-
ACP模式
1、Scrum
Scrum是敏捷项目管理的框架，它是一个冲刺和增量型的框架，它的基石是“一直存在一个理论上可传输的产品”。
1-1 Scrum的三大支柱：
A) Transparency 透明：为项目结果的负责人提供可见度。
B) Inspection 检查：适时检查项目进度顺利地向目标推进，找寻问题的偏差。
C) Adaption 适应：假设检验发现问题或是不合意的趋势，调整流程。
1-2 Scrum团队
由Team、PO和SM组成，包含几种不同的活动类型：冲刺、冲刺计划会、每日立会、冲刺评审会和冲刺回顾会。
1-3 一个健全的站立会议的重点特征包括
同辈压力(因为团队靠大家,所以同辈的期望可带动进步)、密切的配合(团队应当理解对专注的必要性并独立工作)、细在专注(团队应当理解每日站立会议中简洁的必要性,由此团队才有效益)、每日承诺(团队应当理解对每人每日承诺的价值所在,并兑现这些承诺)、辨别障碍(团队应当集体意识到每个人的困难,由此团队可集体尝试解决)。在每日立会中可讨论调整团队的工作量。
1-4 团队规模
Scrum开发团队应保持5~9人的规模（不含PO和SM），开发团队不含测试或业务分析等子团队，它强调跨职能的，自组织的。
1-5 PO
产品负责人主要职责是对产品待开发项进行管理，梳理产品待开发项，并对其进行优先级排序，确保开发团队所执行工作的价值，确保产品待开发项对所有人可见、清晰、透明，以及开发团队对其有一定程度的了解。
1-6 Scrum Master
首要职责是确保Scrum被正确地理解和实施，确保团队遵循Scrum的理论、实践和规则，保护团队免受干扰，排除障碍，他以各种方式服务于PO、Team和组织。
1-7 产品待开发项
产品负责人应在会议前准备好产品待开发列表，缺少产品负责人的情况下，Scrum Master应该在会议前创建符合要求的产品待开发项，并代理产品负责人一职。
1-8 时间盒
冲刺（24周）、冲刺规划会（48小时）、每日立会（约15分钟）、冲刺评审会（4个小时）、冲刺回顾会（1~3小时）、先前迭代回顾会不超60分钟。
1-9 Scrum三个工件
产品Backlog、Sprint Backlog、燃尽图。
1-10 Scrum的五个价值
承诺、专注、开放、尊重、勇气。
1-11 在进入首个Sprint之前，需要举行一个发布计划会议，发布计划会议输出
发布计划、发布Backlog、行动项目、风险、假设、依赖。
1-12 产品待办事项(product backlog)的 DEEP 原则
A) 详略得当（D etailed Appropriately）
B) 做过估算的（E stimated）
C) 涌现的（E mergent）
D) 排列优先级的（P rioritized）
1-13 SOS
每 5~9个Scrum TEAM为一个Scrum-of-Scrum。
1-14 Sashimi
Sashimi的原意是“生鱼片”，在Scrum中是团队用来表达“完成”的一种说法；不同团队对于“完成”的定义可以是不一样的，但在一个团队内必须统一，在Scrum中一个团队需要定义不同级别的“完成规范”来统一这个概念，“完成规范”可是是任务级别的，团队级别的或者产品特定级别的。
1-15 Impediments
Impediments的意思是“障碍”，是团队在向着“完成规范”所定义的状态努力过程中遇到的阻碍，一般来说，Scrum Master需要作为消除障碍的主要负责人！
2、XP极限编程
XP极限编程是敏捷方法中的一中软件开发方法，相对于Scrum关注项目管理工作，XP更加关注软件开发的良好实践。它要求至少有一名客户代表在整个项目周期在现场负责确定需求、回答问题和功能验收测试。
2-1 XP的核心价值是
简单、沟通、反馈、勇气、尊重。
2-2 XP的13个核心实践是
完整的团队、规划游戏、小型发布、客户测试、共同所有权、编码标准、可持续的速度、隐喻、持续集成、测试先行/测试驱动开发、重构、简单设计、结对编程。
2-3 肯特.贝克概念中简单设计如下
A） 能够通过所有的测试程序；
B） 没有包括任何重复的代码；
C） 清楚地表现了程序员赋予的所有意图；
D） 包括尽可能少的类和方法。
2-4 Demeter（迪米特）法则
也称为LoD法则、最少知识原则，指一个对象应当对其它对象尽可能少地了解，通俗地说就是“只与你的朋友通讯”、“不要和陌生人说话”。
2-5 优点
结对编程技术优点被誉为XP保持工作质量、强调人文主义的一个典型实践，有助于协作的流畅、知识的交流共享和提高团队的稳定性。
2-6原则
原则是代码建立后即集成到完整代码库。由此集成后，代码库和整个系统即建成和测试完成。持续整合只是提高快速软件交付和集成缺陷早期探测的一个极限编程的原 则。持续整合理论上是指随时有可传输的工作产品。
2-7 “caves 和 common”
XP 极限编程用语中“caves 和 common”指的是，为团队成员创造的两个分区。公共范围是一个公共的空间，在此常有渗透沟通和协作。 洞穴区域是一个私人的交易预留空间，需要一个孤立且安静的环境。 为了维护公共领域，每一名团队成员应当工作于一个且是同一个的项目上。
3、特征驱动开发（FDD）
特征驱动开发（FDD）是一种简单的便于理解的构建产品或者解决方案的方法。其已经成为最广泛应用的快速软件开发方法。
3-1 特征驱动开发（FDD）有一系列良好的实践
领域对象建模、按照特性开发、类（代码）拥有权、特性小组、审查、配置管理、定期构建、可视性进度报告。
3-2 特征驱动开发（FDD）的五个步骤
A) 开发整体模型；
B) 建立特征清单；
C) 依特征做规划；
D) 依特征做设计；
E) 依特征进行建立。
4、动态系统开发方法（DSDM）
动态系统开发方法（DSDM），也称为业务中心框架开发方法。它倡导以业务为核心，快速而有效地进行系统开发。它的基本观点是任何事情都不可能一次性圆满完成，应遵循二八原则；实施思路是在固定的时间进度和可用资源情况下，力争最大化满足业务要求。
4-1 DSDM开发周期
DSDM开发周期过程被形象地称为“两张披萨和一块奶酪”，它的有以下7个阶段：
A) 项目准备阶段；
B) 可行性研究阶段；
C) 业务研究阶段；
D) 功能建模阶段（冲刺式）；
E) 系统设计编程阶段（冲刺式）；
F) 实施阶段；
G) 项目后期。
4-2 DSDM的哲学是
“足够就好，无须过多！”。
4-3 DSDM在功能建模阶段会产生以下产物
带有优先级的功能、功能性原型的评审文档、非功能需求、实施计划。
5、水晶(Crystal)方法体系
水晶(Crystal)方法体系与XP一样，都有以人为中心的理念，但在实践中有所不同，它探索了用最少纪律约束而仍能成功的方法。
5-1 Crystal系列方法分类
Crystal Clear（透明水晶）
Crystal Yellow（黄水晶）
Crystal Orange（橙水晶）
Crystal Red（红水晶）
重要性根据项目中的错误引发的后果分为：
C-不舒适、D-经济损失、E-严重经济损失、L生命危险。
5-2 水晶敏捷原则
水晶方法采用了一种比例的方式以匹配项目，它拥抱很多其它的敏捷原则
A) 频繁地交付；
B) 反思改进；
C) 渗透式沟通；
D) 个人安全；
E) 焦点；
F) 与专家用户建立方便的联系；
G) 配有自动测试。
5-3 反思提高研讨会是水晶方法论的基石。
5-4 水晶架构是迭代的，它的三个基本过程：
A) 章程；
B) 交付迭代；
C) 项目总结。
5-5 水晶纲领包括：
A) 建设团队；
B) 做探索性的360；
C) 为团队定义实践标准；
D) 建立初始项目计划。
6、精益开发（LEAN）
精益开发（LEAN）不是一种敏捷的方法，但是精益和敏捷的价值观是密切相关的。Lean是系统的思想，Kaizen（持续改善）是一个手段。
6-1 精益的7大原则：
A) 消除浪费；
B) 加强学习；
C) 尽量晚一点做决定；
D) 尽快交付；
E) 授权给团队；
F) 建立无暇的产品；
G) 窥其全貌。
6-2价值流程图5个执行步骤
精益生产理论是指估算浪费，价值流程图是敏捷采用的精益生产分析技能，用于价值的流动分析。
A) 确认产品，客户和范围（即流程的始末）；
B) 地图作为团队或者个人现时价值流，确认流程步骤，延时和信息需求。估算流程步骤的持续时长和前置期持续时长（lead time durations）。前置期是指在发生前一项流程或者事件需等待的时长；
C) 分析价值流程图来确认浪费存在的地方（比如前置期）和流程可完善的地方（流程时间通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间）；
D) 通过分析，总结出一份展示价值流应努力达到的前景或者目标的未来价值流程图；
E) 通过流程完善活动或者其他方法来达到目标的一些工作。
6-3 WIDETOM
价值流程图识别出来的可完善的地方和浪费的形式非常多，可用WIDETOM来记忆：
W-waiting 等待；
I-inventory库存；
D-defects 缺陷；
E-extra processing 额外流程；
T-transportation 运输；
O-over production 过度生产；
M-motion 动态。
6-4 精益投资组合管理(Lean Portfolio Management )
精益投资组合管理(Lean Portfolio Management ) –选择项目以最大化投资回报的方法：
A) 投资组合应包括最低市场特征（MMF），以便快速交付；
B) 尽量减少在制品。
6-5 最小化可交付的特性（MMF）
最小化可交付的特性（MMF）–为最终用户提供价值的最小功能集. 一个 MMF是最小粒度且有商业价值的特性。MMF 被放在一个队列中维护，（很像 Scrum中的产品 Backlog） ，但对队列的大小有严格的限制（James 认为应该是两到三个，最多七个） 。
7、看板开发
规则简单，但其有效实施依赖于对原理的理解、对原则的坚持和实践的应变。
7-1 看板开发优点
方法使用一个拉动系统进行工作，它限制了在制品（WIP）的数量，这样可以帮助识别开发过程中产生的问题和最小化浪费。
7-2 看板开发方法的5个核心实践如下
A) 可视化工作（价值）流；
B) 限制在制品的数量；
C) 度量和管理流动；
D) 协同改进；
E) 显式化流程规则。
8、测试驱动开发（TDD）
测试驱动开发（TDD）要求先编写测试代码，然后只编写使测试通过的功能代码。它有助于编写简洁可用和高质量的代码，并加速开发过程。
8-1 测试驱动开发的基本过程如下
A) 快速新增一个测试；
B) 运行所有测试（有时候是部分），发现新增的测试不能通过；
C) 做一些小改动，尽快让测试程序运行，为此可以在程序中使用一些不合情理的方法；
D) 运行所有的测试，并全部通过；
E) 重构代码，以消除重复设计，优化设计结构。
8-2 测试驱动开发优势
测试驱动开发不是一种测试技术，而是一种分析技术、设计技术，更是一种组织所有开发活动的技术。它具有以下优势：
A) TDD根据用户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。
B) 出于易测试和测试独立性的要求，将促使我们实现松耦合设计，并更多地依赖接口，提供系统的可扩展性和抗变性；
C) 将测试工作提到编码之前，并频繁地运行测试，可尽量避免和尽早发现错误，降低了后期测试和修复的成本，提高了代码质量；
D) TDD提供了持续的回归测试，可以重构代码；
E) TDD所产生的单元测试代码就是最完美的开发者文档，它展示了所有的API是如何工作的，并且是同步的、最新的；
F) TDD可以减轻压力、降低忧虑，提高团队对代码的信心和对代码重构的勇气；
G) 快速地提高了开发效率。
9、验收测试驱动开发（ATDD）
验收测试驱动开发（ATDD）技术使得测试的焦点从代码本身转向业务需求，它的测试案例代表了功能在验收测试水平上所被期望的行为。它包含讨论、提炼、开发和演示四个阶段：
9-1 Discuss 讨论
敏捷团队和客户或者商业干系人详细讨论用户故事,包含用户故事应有和不应有的预期行为；
9-2 Distill 提取
开发团队研习讨论中的条目并提取成可验证和确认这些行为的测试。提取流程中, 整个团队应充分认识“完成”对用户故事的意义,这正是验收标准所在；
9-3 Develop 开发
提取后,团队开发测试代码和产品代码以产生产品特性；
9-4 Demo 示范
产品特性开发后,团队向客户或商业干系人展示以获得反馈。
-
ACP图表
1、 燃尽图（Burndown Chart）
可以直观地展现项目总体进度，它展示了时间和项目剩余总体工作量间的关系，有效的描绘了团队进展的速度和生产能力。燃尽图可以判别完成的时间，但不能判别完成的内容。有发布燃尽图和迭代燃尽图等。
2、 燃起图（Burnup Chart）
它能够直观展现项目时间与已完成的工作间的关系的一种图表，根据每天完成的story情况动态展现工作成果的曲线。
3、 停车场图表
用来对用户故事按主题进行分类和管理。包括确定主题的名称、用户故事的数量、其包含的故事点、展现故事点完成百分比的进度图表。
4、 看板图
是一个拉动式的图表，用来帮助团队理解当前做得如何，以及下一步要做什么，令团队能够自我指导。在看板图、燃尽图和停车场图三者之中，看板图的信息最详细。看板方法关注的是价值的流动效率。
5、 累积流图（CFD: Cumulative Flow Diagram)
是看板方法里的核心度量，可以很好地反映工作项在每个流程环节的流动问题。累积流图可以用来分析在制品、平均周期时间、吞吐率(Throughput)、需求范围的变化、预测交付日期。
6、 价值流程图
是敏捷采用的精益生产分析技能，用于对形成客户产品或服务的原料和信息（即价值）的流动进行分析。一张价值流程图可能用于分析信息或者材料的流动，从它们的源地到终点，以此来识别浪费区域，识别出的区域成为流程可完善的地方。
7、停车场图
快速的看一下已经完成的特性的等级。
8、信息雷达图
上是记录所有团队成员在规定日期内完成任务的板；“信息雷达图”是一台高大，可见的显示器，软件开发团队用它来跟踪进展；“信息雷达图”和精益方法中的“可规划控制”类似。
9、故事地图
故事地图中显示每个版本中用户故事/史诗的分类方式：
A) 主线(backbone)：基本功能
B) 行走的骨骼(walking skeleton) Walking Skeleton：最小的功能集
C) 附加功能：其他功能
10、石川图（鱼骨图，因果图）
识别问题的主要原因或者是根本原因
11、帕累托图
识别造成大多数问题的少数原因
12、直方图
展示数字数据的图，展示可交付成果的缺陷数量，成因排列，各个过程的不合格次数
13、控制图
确定过程是否是否稳定
14、流程图
可帮助改进过程并世界可能出现的质量缺陷
15、思维导图
发散思维，引发更多创意
16、亲和图
对大量的创意进行分类
17、核对单
用来核实所要求的一系列是否得到执行，（防止遗漏）
18、散点图
用来表示两个事物之间可能存在的关系（比较主观性）
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
