アジャイル会社の使用では、我々は通常、数メートル離れたあなたは、チームワークスペースの様々なノートの色、ホワイトボード、およびその他の各種のチャートを見ることができますから。敏捷性では、情報の情報ラジエーターのこれらの排出源を呼び出します。これは、プロジェクトの状況を提示するために、通信のプロジェクトのために非常に良いことができます。呼ばれるこれらの曲げ曲線のひとつ：バーンダウンは、それが私たちのプロジェクトでは非常に重要な役割を果たしている、それが現在のスプリント性能、スケジュールやリスクを反映することができます。また、これはアジャイルコーチであり、すべてのチームメンバーがマップを「読む」ことができる必要があります。そこで質問です：
何バーンダウン？バーンダウンチャートを描画するには？典型的に共通の問題をバーンダウンと応答のタイプを反映していますか？どのように、どのようなプロセスのFAQバーンダウン？実用的なプロジェクト分析の例はありませんか？上記の、コンテンツを共有するために話を今日ここにあります。
多くのゴシップは、エリック・バティが起動するように、古いドライバをあなたのシートベルトを締めてくださいと言います！
どのようなバーンダウン
毎日レンガとレンガを移動する人々が少なくなりますがあります。すなわち、作業の総量は、毎日時間をかけて減少するであろう、それは斜め右下に延びる直線（理想状態）を形成します。高い力格子点パターンの幾何学的特徴の同様の表現がある：Y = KX + B（K <0、B> 0）。
我々は、通常座標系のXY軸でそれらを発現します。ここで、X軸は、一般に、時間（日）を表し、Y軸は、残りの作業を表します。バーンダウン：私たちは、これを命名しました。
理想的には、我々は時間にレンガ、ない醤油を移動する毎日です。以下に示すように、それは直線状になります。
しかし、現実には、どのように我々は、醤油を戦うことができません！だから、それが曲がっ割引となり、実際の曲線を持つことになりますと言います。我々は通常、毎日の作業負荷の実際の完了を識別するために、実際の曲線を使用しています。
これは、進行状況を表示し、前に私たちのプロジェクトのスケジュールを考える、いずれかのPMのコンピュータの存在、またはPMの心の存在中には良いツールです...ない週PMは、現在のスケジュールで会議を説明を受け、ゴーストは今のスケジュールを知っていますどのように。誰もが今、プロジェクトの進捗状況を見ることができるように今、私たちは、バーンダウンチームワークスペースにこれを置きます。あなたがチームに緊張感を与えることができますので、しかし、また、毎日のミーティングでは、同時にバーンダウンチャートを更新されます。PMの指示管理よりも、自己刺激をもたらすためにチーム内の情報の透明性がはるかに優れています。だから、これは非常に重要な役割を燃やす1つの図です。
バーンダウンを描画する方法
現在の時間を取得するために、残りの作業の実際の完了 - 私たちは、各チームメンバーが合計金額と、これらの統計は実際にライブ完了したことを、昨日完成事をご紹介します、毎日毎日ミーティングを満たしています。Y軸は、90％が行った作業の現在の残量を表し、そして1％、呼び出さないか、ということに留意されたいです。
バーンダウンの一般的な種類は何ですか
図ケイン月は7ケースに燃焼する、理解と実際の状況に基づいて、次のように個人的ないくつかの変更：
ケース1：完璧なタイプ。前記直線。次のようにグラフィックスは、以下のとおりです。
このような状況がない限り、起こりそうでない場合は基本的に不可能あなたのチームの神です。あなたのチームはグラフがある場合、偽のチームに遭遇する可能性がある：バーンダウン純粋に架空と任意の完璧な純粋な偶然！
パフォーマンスについて過度に心配いくつかのチームリーダー、批判されてバーンダウン完璧ではないチームを参照してください。だから、チームは完璧なマップを描画します、リーダーシップを見て、叫んだ：666を、このスプリント私たちは仕事の後、私は夕食こんにちは皮膚に行ってきました、非常に一生懸命働いています！
ケース2：ビール腹。前記弓形、およびライン上の実際の曲線上にありました。次のようにグラフィックスは、以下のとおりです。
このような状況の理由：
予備的需要が不正確に推定しています。チームの障害は、チームメンバーが容量を制限しました。チームは強い自己調整能力を持っている、あなたは余分な作業の多くを行うことができ、家に来ていない目標のビジョンを完了していません。このような状況に注意しなければならない、スプリントの目標が達成できない可能性があり、我々はハイリスクであり、早期にこの質問を発見されました。半ばSMでそのように、調整する必要があります。
当前需求，有没有其他优化方法可以实现。某一个人或某几个人在一个问题上卡住了，移除障碍。能不能跟PO协商，减少当前sprint承诺的内容，如果一定做不完那就跟PO协商，做高优先级的，其他的放到下个sprint。Case3：大S型。特征：前期啤酒肚，后期快速下降且在直线下方。图形如下：
这种情况说明团队的应变能力强，不断调整速度来完成目标。当然，也有一种可能是大家看到现在风险比较高，然后加班（多么痛的领悟，谁说敏捷没加班的，那得看是谁在做…），不把曲线降下来谁都别回家！！
Case4：小S型。特征：摇摆摇摆…我摇摆摇摆…… 图形如下：
这种情况属于正常情况，团队不断的在修正自己的速率，而且最终完成了目标。如果你的团队实际燃尽图与此类似，恭喜你。
Case5：TBD。特征：没终点，剩一些活做不完了。 图形如下：
可能情况：
领导压迫给活多，每天都有新需求。团队开黑打酱油去了，很少人做事。SM打酱油，无风险预估及处理能力。团队不能合理安排工作。遇到这种问题，还是要做风险预判。实在做不完的推到下个sprint，但千万别给这个sprint延长周期（比如2周调成3周）。规则一旦被打破，下次团队会不再遵守Timebox（时间盒），也就没有固有的节奏感了。
Case6：开挂。特征：直线下降，一直处于理想曲线下方。 图形如下：
可能情况：
需求被高估了，实际并没有这么多的活做。需求被删减了。公司来了新的鼓励师，程序员玩命工作，效率很高。这种情况最看不下去的就是PO，通常会鼓（ya）励（po）大家多领一些任务，同样，作为一名专（da）业（za）的SM，也应当鼓励团队多搬砖多领钱，这样才能给妹子买包包啊！ SM要优化团队效率，保持稳定的节奏感。
Case7：上天了。特征：一直上翘。 图形如下：
这种情况曲线没有下降，反而一直上升，最可能的情况是每天都有新需求加入到当前sprint中。当然，也有可能是开发人员评估工作的时候太过于乐观，导致工作量不断膨胀，最后的结果是当前sprint必须终止。
以上情况描述了绝大多数情况下的燃尽图类型，SM要做的就是提前预判，风险预防，而不是等到了问题发生才去解决。
燃尽图常见问题
Q1：不知道怎么画
这种情况可能有：
团队成员都是新成员，没接触过敏捷，所以前期都是交由SM来绘制燃尽图，但是后期，最好是让团队成员来进行更新。没有工时估算，也自然就没办法知道做了多少活，所以最好是估算每个活动的工时。Q2：颗粒度大小问题
这种情况可能有：
一般来说Y轴常用小时数或者故事点数。颗粒度最好是1天可以完成的事情。这样不至于每天Daily Meeting都说同一句话：“我昨天做这部分的代码编写，今天继续……”。二来，可以更好的跟踪任务项，减少进度风险。这里面还有个问题是story数量的问题。如果story太少，我们画燃尽图的时候会发现折现非常明显，可能会让我们错误的认为当前速度及风险比较大。
Q3：测试背锅
燃尽图变成了Case5:TBD的情况，领导一问，开发同学异口同声：测试不给力，我们的活都干完了。
很多时候开发和测试是敌对的双方。研发小伙伴在sprint最后一刻才提交给测试，测试自然就没有时间来做测试的工作。然后就很无辜的做了背锅侠…
又或者，开发质量不过关，测试测出来很多bug，然后开发返工，导致sprint延期，开发小伙伴同声：你丫测试不给力，这么晚才告诉我有问题。测试同学继续背锅… 这种情况，我们最好不要把所有的故事都在同一个时间完成，同样，也要提倡团队跨职能发展，打造T型团队人才。
Q4：燃尽图日期加了1天
当还差1天的工作就可以完成这个sprint的时候（此时团队24h工作无休），你会怎么做？很多Team会在燃尽图加1天，这样就可以完美的抵达Y=0的点。
切记不可这么做！一旦规则被打破，团队成员也会认为这个时间都是可协商的，也会破坏固有的节奏感。这次加了，那下次还剩1.5天的工作量的时候，要不要加？
Q5：只统计某个工作量
燃尽图显示的是整个team的工作实际统计情况，而非单独开发或者测试的工作量（排除单一组件团队的特例）
Q6：燃尽图比较
如果公司有几个敏捷项目同时在运作，领导看到A组同学的燃尽图说到：“你看B组，他们速度多快啊，你们这速度太慢了，你们这周过来加加班吧，把速度搞上去…” 这种情况很明显是被 “懂”敏捷的领导给坑了。遇到个完全不懂的倒还好，最怕的就是一知半解的。
不同team甚至是同一个team，燃尽图都可能无法比较。比如有如下原因都可能导致燃尽图不同：
Story拆分的粒度是否统一。团队成员是否有变化。时间周期是否一致。story point的基准是否一致。燃尽图实例剖析
实例1：是否会画燃尽图？下图是某项目2天的执行情况，请问A B C三个点分别应该是多少？
分析：燃尽图中Y轴代表的是剩余工作量，掌握这个即可知道是多少数值。只有放到Done列表的，叫完成。
A=5+3+8+5+7=28 B=28-7=21 C=21-5-(8-3)=11，因为No.6这个编号的工作，8个点的活变成了3个点，所以剩余少了5个。再加上No.5完成了。故总计完成10个点的活。
实例2：截取了IT事业部某软件外包项目燃尽图实例，跟大家一起分享我们出了什么情况以及如何解决的。（2周为一个sprint，团队已经运用敏捷一段时间）
我们在每日站会上进行数据的收集和更新，然后根据SBI（sprint backlog items）来更新数据。
迭代1分析：
在2.27-28这一天实际曲线不但没有下降，反而上升。主要原因：（a）开始第一个sprint，需求梳理的不是很清楚，有新需求新增到SPI中（团队一开始是拒绝的，但PO比较强势，必须得加进来…）。
（b）工作项的分解不熟悉。task重新估算之后，用时有所增加。
此时项目已经出现了风险，而且有将近30个点新增。所以为了解决问题，符合预期。在2.28-3.1，我们采用了加班的方式。
3.1-3.2，仅下降了10个点，主要原因：（a）前一晚加班太晚，今天效率不高，还有几个同事休假。也可以看出，加班过猛也不是好事…效率最重要。
（b）有个技术坑阻碍了当前的项目进度，team研究好久都没搞定。
3.3-3.4 休息日。开发小伙伴顺便在周末研究了一下技术难题。3.5-3.9，从曲线的斜率可以看出，团队的实际速度高于理想速度，逐步贴近我们的理想曲线。到3.10号，我们还剩10个点的活没干完，只要原因：开发组将迭代版本提交给测试进行迭代系统测试导致。（a）开发将迭代版本提交给测试，遇到一些重要bug需要处理，导致待开发项也没有时间安排处理。
（b）估算存在一些问题，项目设置的冗余时间也已经用完。
迭代2分析：
鉴于在迭代1中最终有故事没有完成，而且团队在整个sprint中工作压力较大，所以我们在估算工作量总工时的时候，只挑选了400个点的工作，相比迭代1少了20个。这也说明在敏捷中，即使是同一个团队，每次能完成的工作量，也会有不同。3.17-3.20期间，从250点直落到150点，主要是由于抽调了部分的需求，放到下个迭代中。所以曲线直接掉到理想曲线下方。3.20-3.25，速率正常，3.25刚好完成所有的工作。总结
燃尽图作为敏捷可视化管理的工具，发挥着重要的作用。一叶知秋，作为敏捷教练应当能够从每一张图表、每一条折线，分析出项目背后的问题，防范于未然。燃尽图的数据来源于日常工作，出自于团队本身。所以数据的准确性，直接决定了燃尽图的价值。
怎么样的燃尽图才是有价值的呢？
数据要真实，统计全面。这样才能反映出task的执行情况。对于工作量的预估要尽量准确，这就对团队的技术水平有一定的要求。粒度的分解要尽量落实到每一天。太大的粒度无法跟踪，而且不利于工作的估计。