SCRUM作为当下流行的敏捷开发方法，在业界得到了很大的推广。笔者作为一名SCRUM的实践者，带领项目团队，经历了从PM到SCRUM MASTER的转变，个中滋味与大家道来，希望能和大家一起交流分享，共同提升。

1项目背景

1.1项目

某软件产品开发项目。

1.2方法

实行敏捷SCRUM方法。项目团队整体刚接受完敏捷SCRUM培训，大家对敏捷方法跃跃欲试，但是一切处在摸索中。

1.3团队

总计16人。其中包括开发9人，测试4人，管理3人。根据所开发的软件系统特点，将全员分成5个小组，分别是管理组，开发组A,开发组B，开发组C，测试组。

2SCRUM执行概况

2.1Sprint周期

以2周为一个sprint迭代。从7月10日到9月17日，累计执行了5个Sprint。

2.2SCRUM框架

团队明确定义SM，PO角色。每日立会，计划会议1,2，演示会议，回顾会议，完全依照SCRUM框架进行，在时间盒限制内完成。

2.3SCRUM工件

Productbacklog;Sprint backlog; SprintBurn-down chart;看板。

3燃尽图实例分析

本项目采用燃尽图（Sprint Burn-down chart）对迭代进展进行监控及趋势分析，各燃尽图根据Sprint backlog每日的更新数据由EXCEL自动绘制。

燃尽图横坐标：工期。

燃尽图纵坐标：sprint内工作任务的总承诺工时。

计划曲线：假定成员工作生产率恒定情况下的进展曲线。

实际曲线：实际进展曲线。

Spring_1分析：

1.团队成员开始第一个Sprint，对于工作任务的分解掌握的不纯熟，对自身的工作生产效率不清楚。所以导致7月13日工作任务的进一步细化分解，导致实际曲线要高于计划曲线。

2.虽然，7月12日到7月18日，实际曲线高于计划曲线，但是实际曲线的趋势与计划曲线相吻合，说明团队成员的生产速率是恒定的。

3.7月19日，实际曲线回落，开发组将迭代版本提交给测试进行迭代系统测试导致。

4.最后工时仍然存在，表征成员工时预估存在问题。

5.本次sprint回顾会议上，团队成员认为“开发与测试结合紧密，版本能够及时发布与测试”。

Spring_2分析：

1.7月25日到7月29日，趋势基本正常。

2.7月30日，实际曲线上扬，经分析发现仍然存在任务分解的颗粒度不够问题，成员发现任务越做需要的工时越多。深层次的原因是任务在一开始分解时，由于需求，设计等原因，导致任务工时预估与实际存在较大偏差。

3.本次sprint回顾会议上，团队成员认为“团队工作时间把握更准确”，但是“任务颗粒度需要适当，目标要明确，不存在跨迭代。任务分解需要改进”

Spring_3分析：

1.整体趋势正常，但是真实的原因是外界涌入了大量新的任务，影响了时间盒，为了保证版本交付，原来规划的一些任务进行了搁置。

2.本次sprint回顾会议上，团队成员认为“项目内部临时增加的任务较多”，需要“sprint内的任务bug需要修改；sprint外的BUG工时较多时，需要评估，考虑建立新任务”；“项目外临时任务经常加入SPRINT”。

Spring_4分析：

1.8月24日，由于Product Backlog里面已领取的用户故事条目发生需求变更，导致预估工时大幅提升。

2.本次sprint回顾会议上，团队成员认为“需求描述需要明确到位，需求上的细节变更要沟通及时，”“PB本身不够清晰，需要在sprint之前进行细节上的细化，团队每一个成员都会参与需求的分析和细化，时间与sprint并行；团队成员对需求的明确结果应一致”

Spring_5分析：

1.9月14日以后没有记录，要求团队内部应该做好记录人员的冗余设置。

2.本次sprint回顾会议上，团队成员认为“验收测试期间经常有开发小版本更新”，希望“验收期间需要更新小版本的话，是否更新及更新后的回归测试范围需要团队评审”。

4综合

Sprint燃尽图作为SCRUM框架里面的可视化工件，数据来源客观，能够真实记录反映sprint周期内项目的进展情况，结合Sprint backlog记录，通过团队成员在回顾会议上对sprint周期的回顾，能够科学的分析出项目组存在的一些问题。从而，达到项目管理持续改进的目的。