敏捷开发scrum-燃尽图.doc

“燃尽图”--保持项目可视性 “燃尽图解释与表示方法” 燃尽图，在Wiki上面没有单独的解释，只有在Scrum上面对其有基本的解释，燃尽图 燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule. 我找寻了几张燃尽图，比较具有代表性意义： 手工燃尽图  详尽“燃尽图” 中国原创的说法：燃尽图（burn down chart）是在 项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着 剩余工作的完成，“烧尽”至零。??? ?  燃尽图有多种表示方法与意义，每一个公司，每一个项目可能都不同，公司可以根据需要定制自己燃尽图，甚至进行特别的修饰与修改，但无论如何表示与修改，燃尽图具有一个共同的特点：就是可视性 ?”? ????上面展示的燃尽图的表示方法与意义，我们可以看到很多公司在实行敏捷过程都使用了这个燃尽图，显然这个燃尽图有它存在的合理与意义，在讨论这个意义之前，我们需要回答几个问题: 1.??????????“燃尽图”到底谁会关注？ 2.??????????“燃尽图”需要谁去填写？ 3.??????????“燃尽图”应该如何填写？ 上面这三个问题留给读者先去思考，随着后面章节讲述，上面三个问题会得一解决，读者可以带着以上三个看这篇文章，希望在读完文章之后，读者会自己答复以上三个问题。 ???????“燃尽图”展示了一种新的管理工作报告，他向管理者与利益相关展示了目前产品BackLog完成情况与整体进度，管理层与利益相关者可以很容易地通过燃尽图了解实时的进度以及细节，管理层更能够实时把握产品的进度并做出正确的决策，并且预计风险，同时随时调整计划。 ???????传统的项目报告一般是固定，系统的，向管理者展示了项目的进展，完成百分比，以及遇到的问题，需要解决与补救的方法，而实际上在开发过程当中，又会有不断的需求加进来，这种传统的项目报告无法应对这种需求，导致往往项目执行者将项目的失败都归咎于需求的增加与变化，并且责备管理层不能做出正确决策。 ???????如何去向应对变化以及让管理层与利益相关者做出相对比较正确的决策，就需要项目执行者向管理层与利益相关者展示项目细节，其必须具备可视性，可信性，可估量，充分展示项目执行的细节，而燃尽图可以解决这样的问题。 “什么样的燃尽图可以达到效果” 在文章开始，我们已经解释了燃尽图，并给出表示方法，可惜我们不是寻找一个包装得很好看的图表，而是寻找一种方法去解决项目当中的问题，燃尽图可以帮我们解决问题，它是一种方法，必须达到某种效果，如果甘特图也可以帮到我们，我们同样也会利用。因此我们在乎的它产生的效益与成果。 那么我们应该先想好燃尽图应该具有什么样的效果？或者说如何解决传统项目当中无法解决的问题？ 前面讲到传统项目的报告往往比较迟纯，不能够及时调整，并且一旦需求一变，项目失败的机率就会增加，往往管理者决策的时候已经无法补救，另外管理者很难看清他投资的效果。因此我们可以要求燃尽图必须具备以下几种效果： 1)????????具备可视性，直观展示项目进度与BackLog完成情况 2)????????具备风险预估，提醒管理层与利益相关者目前完成情况，瓶颈出在哪里？ 3)????????具备可估量，直观显示当前项目需要的时间 “如何绘制燃尽图” ???????燃尽图必须与整个项目的进展紧密相关，敏捷当中整个项目围绕着整个Sprint Backlog，因此燃尽图必须也体现着Sprint Backlog完成进展。设计燃尽图必须围绕着Sprint Backlog。 ???????本章重点解释燃尽图，对Sprint BackLog作一下简单的介绍。 ???????关于Sprint BackLog（冲刺订单）的介绍： Wiki当中的解释：冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单 位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。 一般情况下，Sprint BackLog是一张表格，里面详细列出本轮迭代要实现的Story故障以及Task，并对每一个Task估算都团队成员估算过了，并且在迭代开始之前，已经决定