主要记录下在敏捷项目管理中，我们参考的图表可能会有哪些，哪些图表是我们可以关注的；
大家都知道，在敏捷项目中，主要有三部分：Epic, User story, Task；
Epic（史诗）： 一个整体功能，可以跨越多个版本；
User story（用户故事）：用户特性，用户提出的需求，或站在用户角度上，想要实现的功能点（三要素：用户、功能、价值）；
Task（任务）：可以包含在特定用户故事下拆分的任务（用户故事->实施），也可以是为了实现某些功能（非用户提出，重构等），而建立的任务；
具体如何拆分Epic（到特性）到用户故事，用户故事如何拆分到任务，我们就先不说了；
今天主要想看看有哪些图表在我们敏捷项目管理当中会用到的：
主要从项目、迭代、需求和缺陷四个角度来梳理；
项目：
团队速度图：通过对过去数个冲刺的用户故事数量评估，预测后续冲刺所能完成用户故事数；
不足：如果单纯只是考虑用户故事数量，会忽略用户故事难易程度；
个人观点：单纯对团队速度进行评估的话，可以考虑在估算用户故事时，引入故事点估算；故事点估算已经包含了对用户故事难易度的评估，需要注意的是在项目中基准是不变的，也是大家认可的，4个故事点的用户故事工作量是1个故事点的用户故事的4倍。也就是说，以后可以说我们团队的单一迭代的速度是20个故事点，未来先估算用户故事故事点数，然后根据预测以往经验，纳入相应用户故事至版本当中。
迭代：
燃尽图：跟踪冲刺剩余工作量，根据与预期的偏离程度，及时识别风险；
不足：1.无法呈现所有信息（优先级等），依赖成员的精准的评估，压迫感;2. 出现延误，无法区分范围蔓延还是团队出现延误的问题，不直观；
个人观点：可以采用燃起图觉得第二类问题，范围与进展独立开；
燃起图：能够直观的展示项目时间与完成工作的关系，可以区分不同角色展现工作量的完成情况，更容易跟踪和理解；
个人观点：燃起图做为完成工作的统计，能够非常清晰的统计团队的速率，发现团队的问题。当然明确清晰的看板也可以达到燃起图类似的效果，燃起图是个统计图表；
成员负荷图：成员现有所承载的用户故事数（已完成&未完成），可以看出当前时间点，项目成员的负荷；
个人观点：员工出现并行任务情况下，需要多多关注其他任务的依赖风险，提前预知；凡事只统计用户故事，不统计故事点的，都会存在忽略难易度的问题，所以不妨在成员负荷图中加入故事点的维度展示；
需求：
需求属性分布：根据优先级进行需求属性（优先级、来源、分类）分布的统计；
个人观点：需求纬度的基本统计，全面了解现阶段需求的情况，从来源（客户、产品、自研等）和分类角度上，进行数据分析，为后续能够更好的掌握需求提供数据支撑。
需求状态分布：对当前时间点，需求状态分布的统计；
个人观点：单纯的状态分布大致能看出当前（项目整体/迭代）需求的处理状态，也能看出未来需要处理的需求量，与团队速率进行配合，可以大致预估未来的版本数量。
需求每日趋势：跟踪一段时间内，新增需求&修改需求的统计；
个人观点：可以在项目回顾会上，把范围定在一段时间内，查看新增需求&修改需求的数量和频率，分析问题并加以解决，达到渐进明细的效果。
需求累积流图：跟踪一段时间内，各种状态下的需求累积情况，监控需求的变化趋势；
个人观点：包含了每日趋势的需求，同时考虑到需求的状态，能够宏观的看出需求pending、正在解决和被解决数量，找到项目瓶颈；同样能够预测需求完成时间，及时做好项目规划；
需求年龄报告：统计所有需求按照年龄的分布情况，跟踪需求的生命周期和响应情况；
个人观点：通过提供需求年龄报告，能够让客户&管理者更清晰的了解需求被关注&实现的速率；可以分优先级等纬度统计需求的生命周期，预估我们相关优先级的需求的响应情况。
缺陷：
缺陷属性分布：根据优先级进行需求属性（优先级、严重程度、复现概率、类别、原因分析、解决方案）分布的统计；
个人观点：冲刺过程中，应该每日关注缺陷，尤其是优先级高、严重程度高、经常复现的Bug，并且给予充分的重视，无需等到回顾会议才去回顾，尽早处理和解决；
缺陷状态分布：对当前时间点，缺陷状态分布的统计；
个人观点：相对于属性分布，与每日趋势图配合，结合迭代进程来判断可能出现的风险，在迭代初期暴露风险何尝不是个好消息？
缺陷每日趋势：跟踪一段时间内，新增缺陷的统计；
个人观点：同上；
缺陷累积流图：跟踪一段时间内，各种程度和类别的缺陷累积情况，监控缺陷的变化趋势；
个人观点：与需求累积流图类似，能够比每日趋势图更多的发现冲刺的瓶颈与风险，并为解决时间做预测；
缺陷年龄报告：统计所有缺陷按照年龄的分布情况，跟踪缺陷的生命周期和响应情况；
个人观点：关注缺陷的严重程度、处理人和处理人当前的负荷情况，综合考量和计划如何实施缺陷修复；也可以做为回顾会议上的议题来讨论，为什么会出现缺陷长期被阻碍的情况，是工作量巨大还是单元测试工作做的不够。
缺陷回归分布：统计项目中缺陷在回归测试中分布情况，跟踪缺陷的重新打开率；
个人观点：与自动化测试关系很大，没有做好代码管理&自动化测试&持续集成，这种问题应该今早修复，否则会严重影响后续的交付能力。
大家可以在项目管理中多多尝试，并没有好坏之分，而是真正辅助到我们项目，有益于项目的进展，那才是好的图表。
