迭代计划的甘特图

本文目录一览：

• 1、项目管理常用的工具推荐——WBS、甘特图、燃尽图
• 2、浅谈BurnDown Chart （原创）
• 3、如何制定产品迭代计划?
• 4、用peoject画甘特图？
• 5、甘特图提高效率的方法已经OUT了，快来试试Scrum法

项目管理常用的工具推荐——WBS、甘特图、燃尽图

01

工作分解结构（WBS）

WBS是一种常用的项目管理工具，是把一个项目，按一定的原则分解，总任务在上方，往下分解为分项目，然后进一步分解为独立的任务。再把任务分配到每个人的日常活动中，通过把项目分解成能有效安排的组成部分，有助于把工作可视化。

WBS以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。

WBS结构定义和组织项目，也可用来分解任务以外的东西。预算可根据分解计划进行计算，在分支定义不明确的情况下，甚至可以计算风险。

02

甘特图

甘特图可用于进度计划编制和进度控制，表达直观，甘特图可以体现项目完成比例、责任人和具体日期等。

使用进度猫甘特图甘特图把大型项目划分为几个小部分，从一个甘特图中，你可以清晰地看出子任务是什么，以及每个任务何时开始何时结束，每个任务都可以分配给单独的团队成员。

可视化地呈现一个项目还可以轻松地了解每个阶段会发生的事情，从而跟踪项目进程。

使用甘特图，可以确保项目遵守时限，项目经理可以查看所有正在进行的任务以及相对于某些项目里程碑的进展情况。单独使用此功能有助于使甘特图对于任何项目都是必不可少的。

03

责任矩阵图

责任矩阵就是将所分解的工作任务落实到职能部门或个人，表示出他们的关系、责任和地位的方法，它可以清楚地反映工作责任和相互关系，尤其在职能式项目组织模式中，通过责任矩阵强化分工，减少后续分工争议的风险。

04

燃尽图

燃尽图显示在一次迭代或发布中的剩余工作量。这些图可以用来追踪实际速度和预期速度的对比，评估项目绩效。燃尽图用来预测团队最可能的速度，团队按照这个速度去开发即将到来的冲刺或迭代交付物，从而促进有效计划。

发布燃尽图：项目组在迭代末期通过更新发布燃尽图来对比计划进展。当曲线达到零，项目中没有更多的故事点时，它已经准备好发布。

05

看板

看板帮助监控和管理项目，有助于项目团队更有效地协同工作，帮助团队成员将他们必须完成的工作可视化，也这方便项目经理限制正在进行的工作量，平衡工作流，避免给团队带来过重的负担。

实际中的板上卡片可以按优先级排序，因此工作流得到了改进。一旦任务完成，卡片会被移到下一栏，团队成员就会开始处理他们待办事项栏最上面的卡片。

进度猫的看板功能，显示了我们的待办任务清单、负责的任务、参与的项目及进度，通过看板我们可以知道有哪些任务没完成，每个项目的进度等

浅谈BurnDown Chart （原创）

燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。我们经常用到的燃尽图有两种类型，一是基于任务（task）的燃烧；另一种是基于故事点（Story point）的燃烧。燃尽图经常用在敏捷项目里，如果从迭代周期的维度看，还可以分成Sprint的燃尽图，用来记录Sprint的进度；也可以是release的燃尽图，用来记录整个scrum项目的进度。

上图是一个典型的sprint（iteration）燃尽图，如果迭代的Burndown Chart一直是上升状态，或当Sprint进行一段时间之后，Sprint Burndown Chart上当前点的Y值仍然与Sprint刚开始时相差无几，就说明这个Sprint中的任务过多，要拿掉一些story以保证这个迭代能顺利完成。如果Sprint Burndown Chart下降得很快，例如Sprint刚过半时Y值已经接近零了，则说明为这个Sprint分配的任务太少，还要多加一些任务进来。在迭代计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。总之，燃烧曲线是衡量团队进度的重要工具。

虽然大家对燃尽图都很熟悉，但我们在实际使用燃尽图的过程中，仍然有过如下 三个疑问 ：

1. 在绘制燃尽图的时候，什么时候选择基于task度量，什么时候选择基于story point度量？

2. 谁来给出起始的故事点或者任务的estimation？

3. 在使用一些项目管理工具的时候，对于task的estimatoin，remaining time以及correction，这些不同的field代表什么意思？谁来给出这些值？何时修改这些值？

疑问1：在绘制燃尽图的时候，什么时候选择基于task度量，什么时候选择基于story point度量？

想要找到这个问题的答案，必须理解这两种燃尽图各自侧重的意义。虽然两者都是用来表示项目或者迭代进度，但story point更多体现的是业务价值的完成，比较宏观；而task关注的是具体任务的完成，较为微观。所以，基于story的燃尽，是在记录燃烧了多少业务价值，离最终交付给客户业务价值还有多远。我们知道衡量一个story是否完成还依赖于DOD（definition of Done)， 不同的团队对DOD有不同的定义，例如有的团队认为story必须经过showcase才算完成，那么会明显影响到基于story point的燃尽曲线。但task关注的是敏捷团队内部的开发情况，是基于person day的，只要这个开发或者测试的任务完成就算DONE。由此可见，story point的燃尽图体现的敏捷流程，关注业务价值的交付，可以暴露诸如测试滞后，协作子系统之间的依赖等问题；task（Person day）燃尽图体现的是开发和测试进度，关注团队内部的完成风险。

所以这两种方式有各自的侧重点，可以同时使用。但对于一个成熟度不是很高的团队来讲，使用task的burn down chart似乎更加现实；如果团队足够成熟，可以均匀地拆分user story，且每个story都比较小，整个组织也比较敏捷的话，就以用story burn down chart来取代task的burn down chart。也可以将两图合并, 同时从基于task working hours的burn down与基于story points的burn up两个视角关注项目进度。

疑问2： 谁来给出起始的故事点或者任务的起始estimation？

对于谁来给出起始故事点数来说，答案比较明显，那就是团队给出。但对于谁来给出具体任务的初始estimation，不同的团队有不同的做法，我们的实践也是团队给出。

在迭代开始的计划会议里，有很大一部分时间是团队一起拆分story，并且给出每个task的estimation。由于person hour和个体关系很大，不同的人对同一个任务预估的时间也不相同，也就说团队一起给出的这个estimation可能是取了一个平均值。

那么问题来了，这样做到底什么意义？平均值会不会不准呢？其实计划会议上所做的所有预估都是为了更好地在团队内达成对业务和工作量上的一致理解，团队不应该把关注点放在准确或不准确上。无论是故事点还是任务的PH，都应该建立在团队每个人对问题的一致理解之上。实际上，根据集体智慧的原理，多人一起预估会更加接近将要发生的实际值，也更能帮助团队做为整体对客户做出承诺。

疑问3：在使用一些项目管理工具的时候，对于task的estimation，remaining time以及correction，这些不同的field代表什么意思？谁来修改这些值？何时修改这些值？

首先要理解，敏捷里所有BVC（big visual chart），首要考虑的就是，这些图形或图表能够真实地反映项目与团队的实际情况，基于task的燃尽图也是如此。通常当进入实际开发，task的owner才会被确定，那么这个owner就可以根据自己实际的开发情况来调整时间。

不同的项目管理工具有不同的设置，例如IBM的RTC，task有三个与时间相关的field，其中estimation就是计划会议上大家一起给定的那个person hours，这个值不会再去修改；第二个是remaining time，这个值相当关键，它直接影响到燃尽图的实际曲线，owner应该频繁地对剩余时间进行修改，以便真实地反应任务的实际进度，一般至少是在下班前或者任务切换时修改；第三个值是correction，代表实际可能要花费的时间，越是接近任务完成的尾声，值越接近实际。这是一个非常令人迷惑的field，因为它十分容易让人联想到事后度量，甚至是绩效评估，而敏捷是反对这类度量的。实际上，correction本意是为了真实的得出remaining hours，在实际的开发过程中，随着时间的推进，owner越来越清楚可能的实际时间花费，这个值也许比计划会议上预计的estimation大，也许比estimation小，owner通过不断调整correction，将它与已经耗费的小时数做减法，从而得出剩余时间，使得燃尽图始终保持能够真实反映迭代进度的能力。此外，IBM RTC 自动生成的燃尽图也会有一条线是专门反映预估与实际的差距，可以用于帮助团队逐渐改进自己的计划会议。所以，correction也应该是随时可以修改的，并且修改的人是task owner。

举一个极端的例子来说明一下，假设一个迭代有6天，这个迭代里只有一个任务，estimation是24ph。进行到第三天的时候（已花费12小时），程序员突然意识这个任务要比原来想象中复杂，于是调整correction为30ph，remaining time变成18ph （correction - 已花费）。由下图一可知，更改correction是会影响planned以及Remaining这两条曲线。当然在实际的操作上，尤其是团队采用物理看板，由人工去维护燃尽图的时候，通常只需要简化成图二。当然，一个迭代是由多个task组成，那么整个燃尽图实际上是所有task不断更改correction与remaining time的效果叠加，籍此将Risk和Progress透明化，指导团队及时做出适应与调整。

一个敏捷团队在开始使用燃尽图的时候，容易陷入一个误区，就是将注意力放在生成漂亮的曲线上，而不是项目本身，这就失去了燃尽图的意义。所以作为管理层绝对不能过分依赖它作为监督和考核的依据，否则就会产生bed smell。

如何制定产品迭代计划?

产品进行迭代的流程计划如下：

1.需求选定阶段

先从需求池中提取需求，作为本周期内需要开发的内容，并进行优先级排序；排序顺序如下：

符合产品定位的需求优先开发

ROI(投资回报率)高的优先开发

严重影响用户体验的优先开发

2.需求评估阶段

召集相关部门和人员进行本周期的需求评估，以确定最终的开发内容，以及各部门工作的排期。开发文档越详细越细致越好，有利于项目的推进。

3.需求落地（设计与开发）

这是一个至关重要的环节，直接决定着本周期内的需求迭代能否成功。掌握项目的实际进度至关重要，在进度缓慢的时候向相关负责人做出反馈。

4.需求测试

在这个环节，我们要将本周期内开发完成的需求全部提交测试。需求测试分为两部分，第一部分整体逻辑测试，第二部分是提交QA测试。跟进测试进度，在测试同事对提测内容和逻辑有疑问时，需要及时解答。

5.产品上线

到需求测试为止的工作全部完成，即意味着本周期内需要开发的需求已经全部实现，且没有任何问题，产品可以上线，迭代完成！不过迭代完成后，还需要进行一次线上回测，最大限度地确保产品不存在任何问题。如果出现问题需要修复请快速联系技术部门进行修复，不能修复需要告知运营部门给用户合理的解释。

一个产品的迭代实际上是循环往复不间断的。要在连续更替的迭代周期当中做好每一个阶段的工作也不是一件容易的事情。有一些需要注意的事项：

科学设置迭代周期长度

将信息传达落实到位

合理地跟进项目进度

建立应急机制

适当地贡献出你的碎片时间

关于正确的心态与做法

用peoject画甘特图？

专业的甘特图，不应该是 photoshop、 illustrator、coreldraw 等做到，除非是ps 高手。因为里面的信息量，图片素材太多太杂了。

用这些软件太费事。应该有这样一个软件可以包含大量的，图标素材和背景模板供调用。比如visio和亿图图示edrawmax就不错，都有大量的模板可以使用，visio有3000多个模板，亿图图示更是有12000个模板可以使用。

扩展资料：

Microsoft Project 2013

在最新版本的Project中，微软提供了更佳的用户体验。提供了以下新特性：

用于Project报表的艺术字

Project 2013在报表中支持艺术字。您可以在Project报表中包含图片、表格、图表、形状和文本框。使用艺术字，您可以创建数据的动态视觉效果，甚至可以在动画和超链接中包含这样的效果。此功能帮助您创建专业报表，而无需Project数据导出到其他程序。

Project中的艺术字的工作方式与它在Microsoft Word、Excel、PowerPoint和Outlook中的工作方式相同。您甚至可以在这些程序之间共享艺术字内容。

更好的即用型报表

至于报表，我们已使用OfficeArt基础结构创建全新的一组预安装可视报表模板。这些报表模板替换之前Project版本中的预安装报表。使用这些新模板，您可以创建鲜艳的动态报表，无需数据导出到其他程序。

丰富的项目报表（燃尽报表）

Project用户早已能够通过将Project数据导出Excel数据透视表创建燃尽报表。您可以在Project中快速创建亮丽的燃尽报表。燃尽报表将计划工时、完成工时和剩余工时显示为图表上的线，使项目经理可以一眼看出项目是否能准时完成。

燃尽报表是灵活项目管理方法的关键要求。（敏捷项目管理:一种项目管理方法，该方法的迭代时间较短（最长四个星期），采用自适应策略及团队成员协同工作方式。敏捷项目管理的类型包括齐心协力、关键链和极限编程。）

任务路径

查看任务的整个“链接链”比较困难，尤其在任务的链接直接影响该任务或直接受该任务的影响时更是如此。Project 2013允许您突出显示任何任务的链接链，即任务路径。若要查看任务路径，请转到甘特图。单击“格式”“任务路径”，然后选择您要查看的链接类型。

扩展日期支持

Project 2013支持的任务和项目日期可达2149年12月31日。比以前长了整整一个世纪！

Backstage检查

单击“文件”即可转到Backstage，它是用于管理Project文件的一站式目的地。我们已针对几个目标检查了Backstage：

使其更易于查找所需内容。

使Project与您已熟悉的其他Office程序一致。

为打开文件以及将文件保存到您的计算机、Web、Project Server或者与SharePoint网站保持同步提供统一位置。

更新的视觉效果

Project 2013的外观有了改善，像MicrosoftOffice套件的其他程序一样。它具有新颖的外观，但不会妨碍您的工作简洁而时尚。我们更关注如何帮助您完成工作，不想让界面变得过于花哨。

甘特图以图示通过活动列表和时间刻度表示出特定项目的顺序与持续时间。一条线条图，横轴表示时间，纵轴表示项目，线条表示期间计划和实际完成情况。直观表明计划何时进行，进展与要求的对比。便于管理者弄清项目的剩余任务，评估工作进度。

甘特图是以作业排序为目的，将活动与时间联系起来的最早尝试的工具之一，帮助企业描述工作中心、超时工作等资源的使用。

甘特图包含以下三个含义：

1、以图形或表格的形式显示活动；

2、通用的显示进度的方法；

3、构造时含日历天和持续时间，不将周末节假算在进度内。

简单、醒目、便于编制，在管理中广泛应用。

甘特图按内容不同，分为计划图表、负荷图表、机器闲置图表、人员闲置图表和进度表五种形式。

参考资料来源：百度百科-project

参考资料来源：百度百科-甘特图

甘特图提高效率的方法已经OUT了，快来试试Scrum法

商业的本质就是效率，包括创新的效率、生产的效率、迭代的效率、资金的效率等等。长久以来，提高效率的方法大多以命令和控制为主，科学管理、过程控制等管理技术就是其中的代表。 传统的“甘特图” 比较直观地展现了这种模式，首先定义并解释了每一件必须做的事情，然后以环环相扣的方式展示整个项目的各个部分，每一个步骤、每一个里程碑式的事件以及每一个交付日期都详细地列了出来，整个示意图就像一道瀑布一样倾泻而下。从表面上看，一切尽在掌握，只要按图索骥、逐项推进就能够按期完成任务。事实上，这 往往是错误的，甚至是一厢情愿的设想，根本无法真正得到落实。 一方面，详细而严格的计划进度缓慢，进展往往滞后于计划，造成预算超支；另一方面，突发事件的发生、需求的改变、政策的调整等内外部因素共同发力，便会导致“甘特图”成为一张废纸，原有的意图要么被延后，要么被更改。

只有改掉旧习惯和老的工作方法，采用更先进、更灵活的工作方法，才能真正地提高效率。这种方法就是萨瑟兰博士的 “Scrum”方法 。Scrum原本是一套新的软件开发方法，与传统的那种规范性、自上而下逐步实施的瀑布式软件开发办法相比，是一种彻底的变革。它 先进灵活，具有自我修正能力，自问世以来，这种开发框架已经成为科技行业开发新软件和新产品的主要方式。 随着方法的有效性一再被验证，在全球掀起了一场敏捷革命，成为微信、京东、华为、通用电气、Twitter、FBI一致采用的管理方法， 在某些案例中，一些纪律性非常强的团队的工作效率能够改善8倍。 因此，Scrum方法被誉为“管理学的诺贝尔奖”。萨瑟兰博士的 《敏捷革命》 一书，便深入浅出地讲解了敏捷管理的精髓，精彩地阐述这套管理体系。

Scrum原本是橄榄球运动的一个专业术语，愿意为团队通力合作，在场地内传球。这个过程需要认真配合、信念一致和目标明确。这与Scrum工作方法是基本一致的。于是，萨瑟兰博士将这种敏捷开发流程命名为Scrum。这种方法能够帮助公司改变固有的工作方式、创新方式，规划方式以及思考方式，从而达到提高效率、降低成本的目的。

Scrum方法充分考虑了可能出现的不确定性因素，同时具有鲜明的创造性。结构上是围绕着学习过程建立的。能够做到在项目执行过程中及时加以调整和改进，而不是刻板地遵循计划。这样一来，团队既可以评估已经取得的成果，也可以评估取得这些成果的方法。这种架构能够为团队提供更加高效的工作方式，帮助他们更好地自我组织，提高工作速度，改进工作质量。萨瑟兰博士指出，每个人都是制度的产物，而Scrum方法会承认和接受这个现实，进而审视导致失败的制度，最后着力改良制度，从根本上去除影响项目进展问题的根本原因，而不是非要找出一个人来承担责任，进而从根本上消除影响、拖累项目的不利因素。为了直观地展现团队人员的进度，增加项目推进的透明度，萨瑟兰博士提出了 “Scrum板”的方法。这只是一面张贴许多便笺纸的白板而已，上面会有三种不同的任务状态：待办、在办、完成。 可以很清晰地看出谁负责哪些任务以及进展情况。任何人只要走进办公室看一眼白板，就能够精确制导团队运作的情况。如果任何成员、任何环节出现了问题，团队能够及时调整策略，集中时间、集中精力加以解决，从而确保项目进展“航向正确”。

OODA循环是指Observe-Orient-Decide-Act，意为观察-导向-决定-行动。 在战争或商业中，这个循环能产生生死攸关的影响。了解对方的决策回路可以导致他们陷入困惑和疑惑，从而反应过度或反应不足。正如博伊德所讲解的那样：谁的应变速度最快，谁就能幸存下来。“观察”就是要摆脱自身的局限性，看到周围所有情况的变化，而不仅仅从自己的视角去观察。“导向”与你能够为自己创造多少行动选项有关。这一环节不仅反映出你如何看待这个世界，以及你处于什么位置，也反映出你能看到什么样的世界。“观察”与“导向”结合在一起，产生了“决定”，从而催生了“行动”。然后，新的循环从“观察”开始。这次观察的则是你与对手的行动产生的后果。在商业方面，观察对象就是市场的反应。在博伊德OODA的持续循环下，效率将得到不断提升，与竞争对手的博弈则更加游刃有余。这就是所谓的“战略上着眼全局，策略上迅速行动。”

与其他方法不同，Scrum强调以下两点： 一是一次只做一件事情。 专家指出：人们之所以同时执行多项任务，并不是因为他们擅长这样做，而是因为他们容易分心，难以克制自己去做另一件事的冲动。换句话说，那些最喜欢同时执行多项任务的人自制能力相对较弱，没有办法让自己长时间集中精力。而且，在任务的转换中，将造成更多的时间和精力的浪费，造成极大损失损失。同时进行多任务处理，势必导致部分项目止步不前，甚至半半途而废。半途而废等于丝毫没做，一辆半成品的汽车只是消耗了原本可以用来创造价值或节约资金的资源而已。任何在制品都是一样，只会消耗资金和能源，而不会产生任何有价值的成果。

二是“二八法则”。 在产品开发中，有一条反复得到证明的铁律： 即一个产品80%的价值来自20%的功能。 在你购买的任何东西中，大部分价值，也就是说人们需要的大部分功能，只是所有功能的1/5。 Scrum的魔力就在于能帮你找出如何先着手创建那20%的功能。 在传统的产品开发过程中，开发团队直到最后交付产品也不清楚客户真正需要的20%的功能究竟是什么。这就意味着他们80%的努力浪费掉了。重要的事情要优先做，Scrum则围绕20%的核心目标，优先突破，逐级迭代，最终完成项目。但是，优先顺序处在不停地变动之中，这一周的顺序是正确的，但未必适用于下一周，因为你面临的环境可能已经改变。所以，萨瑟兰博士提出，要认识到不确定性因素的存在，充分接受自己目前确定的优先顺序和创造的价值仅仅在当前是相对正确的，它将会持续不断地改变。

在Scrum中，共有三类角色：开发团队成员，负责开展具体的开发工作；Scrum主管，协助开发团队把事情做得更好；产品负责人，决定应该做什么工作，拟定待办事项清单的内容，最终有要的是，确定各个事项的优先顺序。Scrum主管与团队成员的职责是确保工作快速完成，看看是否能进一步加快速度、提高效率，而产品负责人的职责是把团队的效率转换成实实在在的价值。这种组织结构的沟通饱和度曾经达到90%，而大多数公司的沟通饱和度大约在20%。沟通饱和度高则直接决定了沟通的效率以及执行的效率，对于项目整体大有裨益。

首先是拟定待办事项清单和组建团队。 将产品或服务必须做的事情分解成小的待办事项，并确定优先顺序。待办事项清单只有一份，产品负责人从头到尾必须不断地对优先顺序加以调整，改进和评估待办事项清单。

其次，召开冲刺规划会，规划冲刺的内容，确定为期1-2周的的冲刺周期 ，并做好每个冲刺完成事项的记录，并努力在每一个冲刺阶段中提高完成记录。

第三，要采取“Scrum白板”+“每日立会”的方式，让整个团队清楚地知道每个冲刺周期内各项任务的进展，以及相互之间需要克服的障碍。

第四，做好每次冲刺。 既要展示之前冲刺中创造的成果，还要提出下一冲刺阶段要做出的改善和成果，集思广益，共同寻求解决问题的方法。其中的精髓在于，团队的任务不是自上而下分派的，而是自主决定、自助完成的，也不需要向上司做详细的汇报。换句话说，就是要激发团队成员的自主能动性，实现个人创造力和企业效率的有效结合。

通过萨瑟兰博士在书中的大量操作实例，我们不难看出，Scrum是一种务实的、可以付诸实施的方法，开创了提升个人创造力与企业效率的全新协作模式，不但对于商业组织、政府机关具有借鉴意义，对于个人而言也能够帮助解决前进路上的各种障碍，最大限度地发挥出自己的能力。正如维尔福软件公司创办者格雷格·库默所说的： “如同工业领域的很多创新一样，这种管理架构的创新也产生了强大的影响力，改变了我们工作的性质。这非常有用，非常成功，所以，它堪称一种变革世界的力量。”