scrum的学习以及我的团队介绍
时间： 19:45:26
&&&& 阅读：36
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&一.心得体会
scrum是学习敏捷开发的一种具体的方式，我们说敏捷开发要理解，它不是理解为一门技术，而是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发。此外，这种开发方式的主要驱动核心是人；它采用的是迭代式开发。
1.&&& 为什么说以人为核心
因为我们或许都学习过瀑布模型，它就是以文档为中心的一种开发方法。在这个开发的过程中，我们需要写大量的文档，把这些需求的文档写出来之后，我们再来根据这些文档进行整理，开发，设计，一切从文档出发。
然而，scrum就不需要如此，因为敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
2.&&& 什么叫做迭代
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
然而，scrum又叫做超级快速迭代。
3.&&&& 什么又是深刻意义上的scrum
scrum的意思应该是说一个团队就是要像比赛场上的橄榄球队伍一样，需要充满激情
和热火，人人迅速，富有战斗激情。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
二.思维导图
三.团队介绍
1.小组成员：
&&&&&&&&&&&&&&&&&&&&& 陈坤，李枫，宁林，刘健，潘启超，宋坤远，蒋薇尘，周维
2.团队会议
2.1.计划：
&&&&&&&&&&&&&&&&& 制定项目，实现项目
2.2.周例会：
&&&&&&&&&&&&&&&&&& 报告团队各个成员的工作进度，以及一周以来所遇到的问题和解决的问题，以及下一周的目标展望
3.我在团队中的任务和责任：
&&&&&&&&&&&&&&&&&& 我是团队中的负责人，对于团队中的产品具有接受和拒绝的权利，负责确定产品的功能和达到要求的标准。
&&&&&&&&&&&&&&&&& 在团队中指挥并和大家一起完善思维导图的设计，明确我们app的具体需求，并详细执行，根据scrum中的设定，区分团队中的成员工作。分成一个个小的周期，每一周都要报告和计划下一周的计划，如此迭代，循序渐进。发现问题解决问题，最终完成项目。&&
&标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&原文：/1244a/p/7647099.html
教程昨日排行
&&国之画&&&& &&&&&&
&& &&&&&&&&&&&&&&
鲁ICP备号-4
打开技术之扣，分享程序人生！注册 | 登录
不逗比不产品，个人产品微信公众号：killifer
产品经理就业特训营，专门为大学生和准备转型做产品的人量身定制，60天线下培训，包就业！
前段时间，我们发现开发过程有些混乱并且不容易管理。为了团队更好的协作，我们在顾问的引导下，开始尝试使用Scrum敏捷开发。（Scrum相对官方的资料，附在文章最后）
几轮Sprint下来，有点个人体会，和大家share之。立场当然是是不褒不贬，纯客观描述啦！不过，每个团队情况不一致；因此，这个“客观”针对的是我们团队。啊哈~
首先，Scrum的官方流程如下：
我们的Scrum流程如下：
接下来会详细讲解每个步骤中应当注意的点：
阐述&调整需求：
产品要在这之前需要考虑清楚每个需求的逻辑、页面交互展示，不然在这一步就会造成很多讨论，延长开会时长，影响效果。至于如何思考清楚内在逻辑，有多钟方法，这又是一个topic；
对于优先级的确认，一定要明确，这是后面实现的先后基础；
如果程序猿们对某个需求逻辑提出质疑的话，最好不要太任由发散讨论，能立刻调整的，那么就调整；不能立刻确认调整的，先保留，然后在真正开发前要确认；
如果产品汪在阐述需求的同时，开发人员们开始相互沟通如何实现的问题，那么建议开发们先听完所有内容，在后面的需求分解中再进行详细讨论，不然在需求源头错过就容易有需求上的认知偏差；
需求分解为任务：
小团队没有项目经理的情况下，建议项目负责人（Scrum Master）是经验比较丰富的技术人，这样对项目进度比较容易有把控，同时对需求的分解以及后期的追踪会有很大的帮助；
要强化需求追踪人（Owner）追踪需求的意识，不要流于形式：有个这么个角色，但是并没有发挥作用这种情况。owner的存在可以分担SM的责任的同时让开发人员之间关联性更强，因为一般某个需求会同时涉及到前端、后端、API、移动端，让开发去推动开发；
开发人员们要适当把需求拆的细一些，这样在拆的过程中更容易吃透需求、理清逻辑，发现逻辑上的问题。针对需求，相关的人进行技术讨论，有疑问的地方要及时和产品这边沟通，问题越早发现越好。最后，要把每个任务对应的人以及需要的完成时间都记录下来。
有关于时间预估问题，我暂时还不知道哪种方法比较好。在文末最后有个敏捷估算的方法，乃们可以参考看看。
在拆分的过程中，SM最好能够根据需求的难易程度，进行辅助沟通。这样，能够相对避免因为具体代码人员因为经验/能力不够而导致的拆分、预估问题；
产品汪要在讨论过程中，时刻穿插在其中，尽量保证需求理解的正确性；
确认该期目标：
完整过一遍每个需求的分解情况，看是否有遗漏或者误差，有疑问即刻提；
必须按照需求的优先级来确认目标；
要明确目标，确认哪些一定要做完（这里有个argue/挖坑的地方，会在下文“开发中”-“3其他”-2中进行描述）；
有关中期会议：
一定要在一期sprint的中间进行进度回顾和确认，如果进度偏差很大的话，要适当的调整目标，以免最终跟预期相差太大；
中期的时候，可以check下人力分配，如果有相对空闲，那么可以再安排一些任务。看不同情况，是安排产品线的新任务还是基础建设任务或是代码优化任务等等；
有关测试：
在开发过程中，建议开发完一个功能就跟进一个功能的测试，以免最终测试任务都堆积起来；
提测可以在项目结束的前2-3天开始，这样可以保证有足够的时间进行修正；
如果功能和业务强关联，可以让业务人员在提测阶段使用测试版本，一起发现问题；
开发人员在开发新功能过程中，可能会遇到之前存在的bug或者突然发现了之前没发现的bug，这时候应该要告诉测试人员跟进，而不是自己直接修掉。因为你以为的修掉并不一定真正没问题，一定要进行回测，同时留下记录，可能会给以后的追溯带来帮助；
团队每天开站会，目的在于描述自己的进度情况。一定要明确！要明确！要明确！如果不明确表述，其实等于没有开站会；
在适应新开发流程的初期，SM最好能够每天or每两天确认下组员们的真实开发情况，包括进度and需求理解上；
一开始尝试Scrum敏捷开发时，容易预估（目标、时间）不准确，导致2周一个迭代版本比较困难，可能会经常延迟。面对这种情况，我目前是倾向砍掉部分需求，先满足2周一个版本，让团队先形成这么一个周期惯性，再去优化惯性内的效率问题（也就是之后再提高目标的要求)；
Scrum要求是：
目标、质量验收标准不能改变；
完成目标的要求不能过低；（文末有相关资料）
关于如何解决这个问题，也还在摸索状态 T_T，大家如果有好的建议和想法，求沟通呀~
组员们要一定总结下这期开发中存在哪些问题，如何解决或者减弱这些问题的影响，不要流于形式。毕竟对团队来说，这是新的开发流程，不适应或者做的不好很正常，不要怕说不要的地方，大家在错误中磨合、改善、成长才是最重要的；
结合上一点，每期也要对上期提出来的问题进行回顾，看在这期中是否有改善这个问题。只记录不回顾，等于什么都没干；
以上，是目前的一些体会和总结，希望在不断实践中，能够得到新的解决方法和体会…
最后附Scrum的官方资料:
什么是Scrum？
Scrum团队的三个角色？
Scrum的三个工件？
Scrum的五个活动？
敏捷估算？
每日站会？
完成的“定义”？
本文由华尔街见闻产品经理 @梁露瑶（微信公众号killifer） 原创发布于人人都是产品经理 ，未经许可，禁止转载。
原创不易，欢迎赞赏(*^▽^*)
收藏已收藏 | 184赞已赞 | 12
不逗比不产品，个人产品微信公众号：killifer
产品经理群运营交流群求职招聘群
Axure交流群
PM要学点技术
关注微信公众号
10个回答15人关注
0个回答0人关注
8个回答25人关注
9个回答8人关注
8个回答72人关注
13个回答20人关注我的图书馆
继以前关于Scrum培训的总结之后，有人提出总结不够全面。所以依据自己更深入的了解与实践之后，进行一个更全面的总结。
什么是Scrum？
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint
backlog 。&&在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。
一个简单的框架
Scrum由三个角色，六个时间箱，四个工件组成：
1. 产品负责人（Product Owner）
2. Scrum Master
3. Scrum团队
六个时间箱
2. 发布计划会议（Release Planning Meeting）
3. Sprint计划会议（Sprint Planning Meeting）
4. 每日站会（Daily Scrum Meeting）
5. Sprint评审会议（Sprint Review Meeting）
6. Sprint回顾会议（Sprint Retrospective Meeting）
1. 产品Backlog（Product Backlog）
2. 发布燃尽图（Release Burndown Chart）
3. SprintBacklog（Sprint Backlog）
4. Sprint燃尽图（Sprint Burndown Chart）
SCRUM理论基础
Agile is NOT a methodology, process or framework. It's a thought to deal with the challenges faced by software developing.
&challenges:
1) unstable requirements
2) uncertainity
3) unacceptable quality
4) demoralized team
To resolve the problems. Agile&has&the famous manifesto:
Individual and interactions&&&&&&& Over&&&&&&& process and tools
Working software&&&&&&&&&&&&&&&&&&&&&&& Over&&&&&&& comprehensive documentation
Customer collaboration&&&&&&&&&&&& Over&&&&&&& contract negotiation
Responding to change&&&&&&&&&&&&& Over&&&&&&&& following a plan
Please pay attention that it is "Over", but not "replace". Agile trys to emphasis some key points but do not reject documentation, plan, contract those kinds of things. :-)
&应用Scrum不要死记框架，更重要的是理解背后的Aigle思想和对应的Scrum理论基础。
Scrum是以经验过程控制理论作为理论基础，通过迭代、增量的方法来增强产品开发的可预见性，并控制风险。Scrum经验过程控制理论的实施由三大支柱支撑：
第一：透明性（Transparency）
透明性要确保生产过程中影响工作成果的各个方面对管理工作成果的人来说是透明的。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成定义。
第二：检验（Inspection）
开发过程中的各方面必须做到足够频繁地的检验，确保能够及时发现过程中的重大偏差。
第三：适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么检验员就必须对过程或是材料进行调整。调整工作必须尽快实施以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：每日站会是用来检验完成Sprint目标的工作进展，调整以优化次日的工作价值。另外，Sprint评审和计划会议是用来检验完成发布目标的工作进展，调整以优化下一个Sprint的工作价值。最后，Sprint回顾会议是用来评审已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
Scrum的特点
Scrum规定了一个非常简单的开发流程。
Scrum是现有设计流程的总结。
Scrum以团队为基础，是一种在需求迅速变化情况下迭代地、增量地开发系统和产品的方法。
Scrum是一个控制由利益和需求冲突导致的混乱的流程。
Scrum是改善交流并最优化合作的方式。
Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。
Scrum是最大化生产率的一种方法。
Scrum适用于单一的项目到整个组织。Scrum可以控制并组织多个具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
Scrum能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。
Scrum三个角色及其职责介绍
每个Scrum团队包括3个角色： 产品负责人（Product Owner）, ScrumMaster和 Scrum 团队。
产品负责人--作为产品的owner，代表客户决定产品需求以及优先级，是Team对于需求的唯一诉求人，帮助团队屏蔽传统的需求纠纷干扰。迅速的需求解释反馈，提高团队的效率。
产品负责人的职责：
确定产品的功能，负责维护产品Backlog。
决定产品的发布日期和发布内容。
为产品的投资回报率(ROI)负责。
根据市场价值确定功能优先级。
在每个Sprint开始前调整功能和调整功能优先级。
在Sprint结束时接受或拒绝接受开发团队的工作成果。
产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。
为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。
ScrumMaster--帮助团队屏蔽外接干扰，热别是team内外的管理干扰。使团队focus在开发生产中。
ScrumMaster 作为Team Leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:
保证团队资源完全可被利用并且全部是高产出的。
保证各个角色及职责的良好协作。
解决团队开发中的障碍。
做为团队和外部的接口，屏蔽外界对团队成员的干扰。
保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。
ScrumMaster 除了主持每日站会（Daily Scrum Meeting）之外，还有三个主要职责：
ScrumMaster 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。ScrumMaster 需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图（Burndown Chart）。
ScrumMaster 还必须仔细考虑同时在进行开发的任务数，同时进行的工作需要做到最小化，以实现精益生产率的收益。
该ScrumMaster 需要找出阻碍团队的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如：一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其他的全是公司的问题需要管理层关注。
最后但并非最不重要， ScrumMaster 可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决。ScrumMaster 必须注意去确保团队资源完全可被利用并且全部是高产出的。
Scrum 团队--专注的，心无杂念的开发团队
Scrum团队的职责是在每个Sprint中将产品Backlog中的条目转化成为潜在可交付的功能增量。
Scrum团队的一些特点：
1. Scrum团队的规模控制在5-9个人。
如果成员少于5人，那么相互交流就减少了，团队的生产力也会下降。更重要的是，团队在Sprint中可能会受到技能限制，从而导致无法交付可发布的产品模块。如果成员多于9人，那么成员之间就需要太多的协调沟通工作。大型团队会产生太多复杂性，不便于经验过程控制。对于大型项目来说，可以采用多个小的Scrum团队，通过Scrum of Scrums解决团队间的沟通协调问题。
2. Scrum团队是跨职能的团队。
团队成员必须具备交付产品增量所需要的各种技能。团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。在Scrum团队中没有头衔的概念，每个人都必须尽心尽力完成Sprint目标。团队中不允许包括测试或业务分析等在特定领域工作的子团队。
3. Scrum团队是自组织的。
任何人，包括ScrumMaster都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队自己确定。每个团队成员利用自己的专业技能，解决遇到的问题。这种协同配合提高了团队整体效率。
团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。
什么是用户故事？
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
1.& &&&角色：谁要使用这个功能。
2.& &&&活动：需要完成什么样的功能。
3.& &&&商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
As a &Role&, I want to &Activity&, so that &Business Value&.
作为一个&角色&, 我想要&活动&, 以便于&商业价值&
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
用户故事的六个特性- INVEST
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
一个好的用户故事应该遵循INVEST原则。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
任务板（墙）Task Boards
任务板（墙）展现了我们在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。–如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。
通常的任务板是下面这个样子:
任务墙被横竖分割成许多格子，每一行代表一个Prouct backlog项也可以称作一个用户故事，在Sprint计划会议期间，Scrum团队会分解每个用户故事得到许多的Sprint backlog项，每一项作为一个任务卡放到任务墙上。
每个任务卡从To Do这一列开始。常用的列如下：
& && &&&用户故事–根据产品需求分解出的一个个用户故事.
& && &&&To Do–需要完成的，但还未开始的任务。
& && &&&Doing–刚刚开始，或正在进行中的任务。
& && && && && && & doing这一栏还是可以细分的，如下是可选的一些栏：
& && && && && && & Coding: 正在编码
& && && && && && & Testing: 正在进行测试
& && &&&Done–所有已经完成的任务卡都会放在这里，Sprint结束的时候可以拿掉它们。
Scrum的四个工件
在Scrum中有四个工件:&&产品Backlog（Product Backlog），发布燃尽图（Release Burndown Chart），Sprint Backlog 和Sprint燃尽图（Sprint Burndown Chart）。
产品Backlog（Product Backlog）
产品backlog是一个产品或项目期望的、排列好优先级的功能列表。优先级由商业价值、风险、和必要性决定。产品负责人负责产品Backlog的内容、可用性和优先级。产品Backlog永远不会是完整的，最初的版本只列出最基本的和非常明确的需求，这些需求至少要足够一个Sprint开发。随着团队对产品，以及它的客户或用户的了解，产品Backlog在不断的演进，所以产品Backlog是动态的，它经常发生变化以确保产品更合理、更具竞争力和更有用。只要产品存在，产品Backlog就存在。
产品Backlog中包含开发和交付成功产品需要的所有条件和因素。 产品Backlog条目的属性包括描述、优先级和估算。产品Backlog的条目可以包括功能性需求（使用业务语言描述，以用户为中心），也包括非功能性需求（从技术层面出发，产品需要具备的能力）。使用用户故事来描述产品Backlog条目是一个非常有效的实践，我们通常也把验收条件或验收测试作为产品Backlog条目的一个属性。
优先级高的产品Backlog条目需要立即进行开发。优先级越高的条目越详细，优先级越低的条目越概括。
发布燃尽图（Release Burndown Chart）
在Scrum项目中，团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期，以Sprint为单位， Y轴代表的是剩余工作量，通常以用户故事点、理想人天或者team-days为单位。
Sprint Backlog
Sprint Backlog 是团队承诺在当前Sprint完成的任务列表。Sprint Backlog中的任务是由产品Backlog选取的需求条目细化和分解而来，这些任务要确保将产品Backlog条目转化为潜在可交付的产品增量。在Sprint的中选择完成哪些产品Backlog条目取决于产品Backlog中条目的优先级以及团队完成这些不同条目所花费时间。选择哪些条目和多少条目放入Sprint Backlog由团队决定。因为由团队承诺去完成这些任务，所有必须由他们自己来做决定。
在整个Sprint过程中，团队持续的修改Sprint Backlog，一些新的任务也会在Sprint过程中涌现出来。因为它涉及到个体要完成的任务，所以有时候会遗漏一些任务，或者一些任务不再需要了，亦或某项任务耗费的时间超出了估算或者低于估算。当出现新任务时或者工作量发生变化时，团队需要将其更新到Sprint Backlog中去。随着任务进行或者被完成，需要更新每项任务的剩余工作估算小时数。如果某项任务失去开发的意义，就可以将其除去。在Sprint内只有团队可以对Sprint Backlog进行修改，也只有团队可以对列表的内容或估算进行修改。Sprint
Backlog是高可见度的，是对团队计划在当前Sprint内完成工作的实时反映，并且，该列表只属于团队。（评估永远不能代替实际，实际的变动需要实际的反馈。如果新发现的工作量大到超出了当前Sprint的容量，有可能需要调整到下一个Sprint）
Sprint燃尽图（Sprint Burndown Chart）
Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。
在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，Scrum master 会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。
Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会因为如下原因发生变化:
1. 随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到Sprint Backlog中。
2. 程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作，这些也许可以分开进行跟踪。
Product Owner也许会和Scrum team一起工作，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更多商业价值。
由于在Sprint的刚开始的时候，增加的任务工作量可能大于完成的任务工作量，所以燃尽图有可能呈上升趋势。
Scrum项目管理工具
VersionOne
VersionOne市场排名第一。支持SaaS模式和本地安装模式，web客户端，支持Scrum, Extreme Programming, DSDM and Agile UP等多种敏捷开发方法。团队可以使用“V1：敏捷团队”来管理产品和sprint backlog，通过交互式的“任务板（taskboards）“和"测试板（testboards）" 进行每日开发活动，藉由报表和燃烧图查看进度，以及其他活动。通过这些功能，“V1：敏捷团队”的用户可以做到：
从电子表格中快速导入故事与缺陷，管理合并后的产品backlog。
利用简单的多条目拖放操作，方便地完成计划制定、对故事划分优先级。
使用电子白板界面同时制定多个版本的发布计划，提高效率。
通过交互式的任务板（Taskboard）、测试板（Testboard）、每日Scrum dashboard来对版本和sprint进行可视化追踪。
针对版本和sprints的关键敏捷度量数据生成图表，如Burndown、Velocity、Estimate trends、Cumulative Flow Reports。
Rally市场排名第二！SaaS模式，支持用户需求的筛选、扩展的筛选标准、改进版本剩余时间表、新的通知规则（notification rules），以及用于Eclipse和CruiseControl.NET的连接器。功能：
产品支持管理
ScrumWorks
ScrumWorks市场排名前3甲，有两个种版本，Basic是免费版，Pro是收费版。支持BS和CS两种模式，服务器端是要安装的。支持对Bugzilla和Jira的集成，带有主题过滤功能的burndown图表，以及其他辅助了解项目状况和走势的功能，还有众多别的特性。ScrumWorks Pro与Bugzilla和Jira的集成，体现在它可以导入两者中的条目作为backlog条目，并且可以像对其他backlog条目一样，对这些条目 进行操作。可以使用搜索来选择感兴趣的条目，并进行单独或多项导入操作。Burndown图表现在可以按照主题
进行分组。将backlog按照主题进行组织后（类似于web 2.0中使用标签），你可以高亮或是过滤这些backlog，并且能够使用同样的主题针对burndown图进行过滤。
Scrum希望最大限度的减少项目开发中的纠纷，使团队专注于项目开发和任务提交。但是现实永远比理想残酷，Scrum并不能完全避免纠纷。如果纠纷发生了，请用敏捷的思想面对问题并加以解决。 :-)
TA的最新馆藏
喜欢该文的人也喜欢