Scrum 术语表

Burndown Charts 显示随时时间推移,还剩下多少工作未完成.通常以时间为横轴,未完成的工作为纵轴.

Daily Scrum Meeting 每天15分钟的每日例会,每个人回答下面三个问题:
1. 上次例会到现在我完成了哪些工作
2. 在下次例会前我将完成哪些工作
3. 有没有什么事情阻止我尽可能的高效地工作
如果会议的讨论超出了上面的内容, ScrumMaster要确保任何与会者可以发起其它会议再来讨论.每日例会最好做为每天早上每一件事来做,在所有与会者到达之后立刻召开.

Impediments 阻碍任何人高效工作的任何人或事.在每日会议上,每个队员都有权宣布任何的impediments,由ScrumMaster负责解决这些impediments.

Product Backlog 产品特性列表,主要由产品Owner负责维护并定义优先级.

Product Backlog Item 产品特性列表中的条目,每个条目就是一个工作单元,大小必须限制在团队可以在一个Sprint迭代内完成,同时一个工作单元可以被分解成许多任务.

Product Backlog Item Effort 每个条目的工作量,可以用人天来衡量.推荐的方式是用Story点,功能点或T-Shirt尺寸(大,中,小).

Product Burndown Chart 基本上是项目进度的'Big Picture',显示每个sprint开始时还剩多少工作未做.

Product Owner Role 相当于业务代表,负责确定backlog中各条目的优先级及业务决策,同时解决任何的需求问题.

Release 这个概念不用解释,大家都懂.基于预定的时间,每个release会平衡功能,成本,质量三个方面的需求.

Release Burndown Chart 与Product Burndown Chart比较相像,不同点在于前者展示单个release的内容,而后者会跨多个release.

Scrum Roles 在Scrum中有一些角色的划要,其中三个主要角色:Product Owner, ScrumMaster, Team.

ScrumMaster Role 是Product Owner和Team之间的桥梁,同时推动双方的合作.主要的作用在有详细描述:
· 消除业务代表和开发团队之间的障碍,帮助业务代表直接推动开发.

· 帮助业务代表最大化ROI,并通过Scrum达到目标.

· 通过促进创造力和能力提高开发效率.

· 想尽一切办法提高生产力.

· 改善工程实践和工具,提高产品的可用性.

· 确保最新的项目进度可以让所有人看到.

Sprint 一次迭代过程,通常是30天.这个过程是不可被打断的,不能增加额外的需求,确保迭代结束时能够获得预期的结果.现实中会有一些变化,一些项目每次会留出 20%左右的时间用于紧急事务及级别最高的产品bugs.这样做存在一定的风险,可能会导致Sprint原则被随意打破.

Sprint Backlog 一次迭代的特性列表,或者说工作列表.展示本次迭代的工作单元,源自产品特性列表.

Sprint Burndown Chart 参考其它的Burndown Chart,粒度更细的图,用于单次迭代过程中.

Sprint Goals 单次迭代的目标,可以被详细说明,可以被衡量,而不是很模糊的一句"改善伸缩性".

Sprint Planning Meeting 单次迭代的计划会议,由Team与Product Owner之间商讨sprint目标集,决定哪些工作会被放进来.这个会议被限制在四个小时之内.

Sprint Retrospective Meeting 在sprint末期,评审会议之后召开.Team与ScrumMaster共同讨论这次sprint中哪些地方做得比较好,哪些地方需要在下次sprint中进一步提高.会议时间被限制在三个小时之内.

Sprint Task 四到六小时内完成的工作单元,由队员主动认领.

Team 跨功能团队,人数限制在5-9人,可能包括的角色有工程师,架构师,分析师,QA,测试,UI设计师等.这是一个自发组织的团队,以满足sprint目标.他们自己决定如何最好地满足用户目标,并承担责任.ScrumMaster充当保护层,确保Product Owner不会干涉团队工作.

Team Member 为了达到sprint目标而完成sprint task的任何人.

Velocity 一个团队在单次sprint中完成多少特性的数值.可以从上一次sprint中估算出,通过一次次的sprint,这个数值会为下次的sprint提供相对准确的进度计划.

转自http://samuelray.javaeye.com/blog/231373

阅读详细......

[Scrum工具] Scrum Checklists中文版

作者 Sprint-IT译者 SpringSide团队 发布于 2007年12月20日 下午8时0分http://www.infoq.com/cn/minibooks/scrum-checklists

SPRiNT-iT的 敏捷教练，包括Scrum培训师Boris Gloger，从主流Scrum书籍中抽取了Scrum的基本要素，并融入他们集体的长期实践经验，从而为大家带来《Scrum Checklists》这本精简概炼的迷你书。这本小册子为大家带来一整套准则和行为，帮助项目团队的成员更有效地推动所有的Scrum会议并创造 Scrum成果。

本书在InfoQ中文站上提供独家免费下载。

本书的英文印刷版以封面纸印刷并用螺旋管装订， 让这本书更具吸引力，而且也很容易翻阅。英文版成书“概述”页中的彩色索引与书右侧的彩色标签相对应，帮助您更快地定位和翻阅书中的页面。本书每一个清单 的背后都有一页空白纸，方便读者记录个人习惯和具体适应情况。如果您喜欢这本书，请支持我们的作者和InfoQ今后的迷你书，购买本书的印刷版（本书的中文印刷版也在筹备中，请耐心等候我们的通知）。

您也可以 免费下载这本书（PDF） 免费下载这本书（PDF） 。

关于此书

本书并不打算详细介绍Scrum，而且没有哪本书有能力取代开发团队巧妙的自组织能力。相反，这本书是为了给接受过培训的团队带来信心，让他们轻车 上路，成功启动最初的Sprints——这些成功将帮助他们的组织更亲密地拥抱Scrum。您可以在“概述”一页找到本书的完整主题列表。另外，本书印刷 版右侧的彩色主题标签能帮您快速翻阅到相应主题：

• 清单：障碍Backlog（让大洋两岸的团队都活跃起来的一项创新）
• 清单：全员会议（帮助团队从抱佛脚或者混乱的过程中走出来的基本规矩）
• 清单：评估会议（产品Backlog）
• 清单：Sprint计划会议1
• 清单：Sprint计划会议2
• 清单：Scrum每日例会
• 清单：Sprint评审会议
• 清单：Sprint回顾会议
• Scrum团队角色
• Scrum典型产物

作者指出，Scrum的新手应当严格遵循《Scrum Checklists》这本书。这样做将为他们带来信心，帮助他们成功完成最初的Sprints，而这些最初的Sprints将提升Scrum在他们组织 中的接受程度。有丰富经验的Scrum教练也可以使用这本小册子作为培训的辅助材料。

本书中文译本是在SpringSide开源项目团队的肖桦、陈俊、林仪明、彭青、田淼和张礼六人的倾情努力下共同完成的，InfoQ中文站编辑赖翥翔（Jason Lai）、霍泰稳和熊节对本书译稿进行了审校，赖翥翔为本书的责任编辑，并负责排版工作。

阅读英文原书：Scrum Checklists

阅读详细......

敏捷精灵日记18

[敏捷精灵日记]

1. Daily Scrum主要还是为了加强团队交流和信息共享。互相了解彼此都在做什么工作，完成了什么任务。这样，每日的信息传递，可以让每个人可以更多的了解整个项目的业务和技术状况。并 且如果在工作中遇到障碍或问题，也可以在这时候提出来，请求大家的帮助。
2. Daily Scrum晨会不是每天的工作报告，更不是项目经理进行工作检查，甚至考核。项目经理有责任营造一个安全（Safe）的会议氛围，让每个人都乐意说出真正发生的事情，就算是昨天遇到技术问题，没有任何的工作成果，也能得到谅解，而不是胆颤心惊。
3. 敏捷方法，需要有一个英明的领导（也许就是Scrum Master），以身作则，带领着团队向前冲锋，大家齐心协力，以项目的成功作为最高奋斗目标。只有这样，才能发挥敏捷方法的威力，只有这样项目才可能获得成功。
4. 明 确的短期目标。如果让一个团队做半年的详细工作计划，一定非常困难，但如果是2周，那就完全不一样。假设，客户有100个东西要做，但团队在一个迭代（一 般是2周左右）中，只能完成20个东西。那么就明确的告诉客户，一个迭代的时间，我们只可以完成20个东西，那么我们先开发其中20个最有价值的东西。不 要为100个东西做半年/一年的计划,因为那不是敏捷开发，还是瀑布模式开发。
   

后记

• 羊群是一种很散乱的组织，平时在一起也是盲目地左冲右撞，但一旦有一只头羊动起来，其他的羊也会不假思索地一哄而上，全然不顾前面可能有狼或者不远处有更好的草。这就是“羊群效应”，也称“从众心理”。在一个组织中，特别对具有决策能力的管理者而言，“共同承担责备效应”(Blame 　Sharing　Effect)的存在是导致了“羊群效应”的根本原因。如果某决策者逆流而动，一旦他失败了，这一行为通常被视为是其能力不够的表现， 并因此而受到责备；但是如果他的行为与大多数人一致，即使失败了，他会因看到其他许多人与他有相同的命运而不那么难堪，而他的上级也会考虑到其他的人也同 样失败了而不过分责备他。这样，决策者具有与别人趋同的愿望，以推卸自己承担决策错误的责任。
• 作为组织的高层管理者，一定要对底层管理决策人员的这种“羊群效应”保持足够的警惕，减少这种非理性的行为的发生。

阅读详细......

敏捷精灵日记17

[敏捷精灵日记]

1。同步进行的sprint有如下优点：

· 可以利用sprint之间的时间来重新组织团队！如果各个sprint重叠的话，要想重新组织团队，就必须打断至少一个团队的sprint进程。

· 所有团队都可以在一个sprint中向同一个目标努力，他们可以有更好的协作。

· 更小的管理压力，即更少的sprint计划会议、sprint演示和发布。

2。最佳的团队尺寸

· 5到9个人被公认为是“最佳的”团队构成人数。

3。在Scrum中，团队分割确实很困难。不要想的太多，也别费太大劲儿做优化。先做实验，观察虚拟团队，然后确保在回顾会议上有足够的时间来讨论这种问题。迟早就会发现针对你所在环境的解决方案。需要重视的是，必须要让团队对所处环境感到舒适，而且不会常常彼此干扰。

4。宁可团队数量少，人数多，也比弄上一大堆总在互相干扰的小团队强。要想拆分小团队，必须确保他们彼此之间不会产生互相干扰！

5。 在Scrum团队中含有兼职成员一般都不是什么好主意。如果有一个人需要把他的时间分配给多个团队，就像DBA一样，那最好让他有一个主要从属的团队。找 出最需要他的团队，把它当作他的“主队”。如果没有其他人把他拖走，那他就得参加这个团队的每日scrum会议、sprint计划会议、回顾等等。

阅读详细......

Scrum介绍系列9--- 产品发布计划(release plan)

Sprint 持续直至产品所有者决定产品已经可以准备发布，此时会有“发布Sprint“来进行最后的整合和发布产品前的检测。如果开发团队一直贯彻很好的开发方法，不断地重构和持续集成，在每一Sprint 中的有效测试，就不会存在许多遗留问题需要清除。

有这样一个问题有时会被提到，是怎样在一个迭代的模式中产生长期的发布计划。在一个项目的起始阶段，开发团队会作出粗线条的发布计划；他们不可能预先得知工作的结果，其重点是创建一个大体的计划提供给项目发展一个大体的方向，并阐明交易决策如何形成（比如范围相对于进度表）。以此作为路标来指引你向目标迈进；在行程中你实际挑选的路程和所做的决策都是途中决定的。


有一些产品发布是以日期界定的；比如：“我们会在11 月10 日的产品展示会上发布我们项目的2.0 版。“在此种情况下，开发团队会在现有的可利用时间内完成尽可能多的Sprint（构建尽可能多的功能）。有些产品要求某部分构建完成才可以说明整个产品的完成，产品不会在这些要求满足前被发布，无论周期长短。Scrum 强调在每一Sprint 中都生产出可以随时交付的编码，开发团队可以进行中间的发布，使客户可以更快的收到产品的效益。


大多数产品所有者会选择一个发布方式，但是会通知其他的——比如，他们会决定发布日期，他们会与开发团队成员一起对Backlog 中项目的完成日期做一大体的估算。在“固定价格/固定日期/固定交货期”的情况下——比如，合同制开发——在这些变量中至少有一个内部存在缓冲区，可以容许不确定因素和变更；在此方面，Scrum 于其他的开发方法并无区别。
阅读详细......

Scrum介绍系列8--- 如何开始下一个Sprint

在Sprint 评审会议之后，产品所有者将提取所有建议，和在Sprint 中产生的新的优先权项目，并将这些项目合并于Product Backlog 之中；增加新的项目，现有项目进行了更改，重新排序或删除。当Product Backlog 的更新完毕，循环周期可以再次开始，以下一个Sprint 计划会议为开端。

许多开发团队感觉在每个Sprint 末期进行优先化的会议很有意义，和产品所有者一起对下一Sprint 中的Product Backlog 项目进行评审。除了给开发团队的一个机会提醒产品所有者其未注意的事项——技术维护，比如——此会议也开始了在Sprint 计划会议之前所需的初步想法。

在各Sprint 之间没有间隔期——开发团队通常在下午时间进行了Sprint 评审，第二天上午就进行下一Sprint 计划会议。Agile 开发的价值观之一是“可持续性“，只有在正常的工作时间和劳动强度下，开发团队才可以继续此周期的持续。
阅读详细......

敏捷精灵日记16

[敏捷精灵日记]

1。产品层次的Scrum-of-Scrums

议程安排：由每个团队的Scrum Master描述一下上次开会以来各自的团队都完成了什么事情，下次开会前计划完成什么事情，遇到了什么障碍。除了这些常规话题外，尤其应该交流跟跨团队协作相关的的问题，例如集成问题，团队平衡问题。

2。团体层次的Scrum-of-Scrums

会议形式为：
1) 开发主管介绍最新情况。例如即将发生的事件信息。
2) 大循环。每个产品组都有一个人汇报他们上周完成的工作，这周计划完成的工作，及碰到的问题。其他人也会作报告（配置管理领导，QA领导等）
3) 其他人都可以自由补充任何信息，或者提问问题。

会议组织：

建议全体开发人员都来参加，让每个人了解其他团队在做些什么。主要以报告形式进行，由每个组的Scrum Master负责自己团队的报告。会议主持人要严格控制会议的时间，尽量避免出现真正的讨论。

3。 Scrum-of-Scrums的议程无关紧要，关键在于要有定期召开的Scrum-of-Scrums会议，进行沟通交流。

阅读详细......

Scrum介绍系列7--- Sprint 回顾(sprint retrsopective)

同学门，请注意！这个阶段也是Scrum的核心之一，只有回顾，才能真正做到六个西格玛里面的PDCA！

在Sprint 评审之后,开发团队会进行Sprint 回顾。有些开发团队会跳过此过程, 这是不合适的,因为它是使Scrum 成功的重要方法之一。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。Scrum 开发团队，产品所有者和ScrumMaster 都将参加会议，会议由外部中立者主持；一个很好的方法是由ScrumMaster 互相主持对方的回顾会议，可以起到各团队间信息传播的作用。

组织Sprint 回顾的最简单方法是在墙上挂两张张贴画大小的白板纸，纸上注明“哪些项工作顺利”，“哪些项不成功或者哪些项可以做的更好”——让与会者在每一类别下增加些项目。当项目重复时，可以在该项旁边记正字累计，这样一些比较普遍出现的项目就一目了然了。然后团队成员共同讨论找寻这些项目出现的根本原因，同意在下一个Sprint 中的改进计划，并负责在下一个Sprint 回顾会议上评审项目结果。

另一种方法是让团队成员在每一类下的项目中，用“C”标记如果其根源是Scrum，或用“V”标记如果其是由Scrum 显现出来的（换句话说，无论Scrum 存在与否该项目都会发生，但是Scrum 使开发团队注意到了该项目的产生）。开发团队会在“哪些项目工作顺利”下发现许多的C 标记，在“哪些项目不成功”下有许多的V 标记；这是个非常好的现象，即使“哪些项目不成功“是比较长的列表，因为解决问题根本原因的第一步就是让其显现出来，Scrum 正是此作用的强有力的促进因素。
阅读详细......

Scrum介绍系列6--- Sprint 评审(sprint review)

在Sprint 结束后，将进行Sprint 评审，团队在此期间展示他们所构造的产品。出席此会议的有产品所有者，开发团队成员，ScrumMaster，加上客户，项目管理者，专家，高层人士和任何对此感兴趣的人。这不是开发团队做成果“演讲”——会议上不会有PowerPoints 图片文件，通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。会议可以持续10 分钟，也可以是两个小时——会议目的只是对工作结果的展示和听取反馈
阅读详细......

Scrum介绍系列5--- 每日站立例会（Daily standup meeting）

每当Sprint 开始, Scrum 开发团队将会实施另一个Scrum 的重要实践方法:每日（站立）例会。这是在每个工作日特定的时间举行的短小（15 分钟）的会议，Scrum 开发团队的每一成员都将参与；为了保证其短小精悍，与会成员都保持站立（因此为“站立会议”）。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。

一个接一个，每个团队成员只可以向其他人汇报三件事情：

• 从上次会议之后完成了哪些工作，
• 在下次会议之前准备完成哪些工作，
• 在工作进行中存在哪些障碍。

ScrumMaster 将会把障碍内容记录下来，在会后协助团队成员铲除障碍。在每日的（站立）例会中不容许讨论，只是将以上三个重点信息做一汇报；如果需要讨论，将在会后进行。产品所有者，经理和项目管理者可以参加会议，但是他们应该在会议结束以前避免问问题或提出讨论——每一与会者应该清楚的是开发团队是在互相汇报和交流情况，并不是向产品所有者，经理或ScrumMaster 汇报。这个会议并没有标准形式，有些团队感觉邀请产品所有者参加并将其每日工作做一简要阐述，是对团队工作极其有意义的。

在会议结束后，开发团队成员将对其负责的Sprint Backlog 中的项目做剩余时间的更新。这些信息会记录在Sprint Burndown Chart 图表中（图示5）。它是用来显示每日直至开发团队完成全部任务的剩余工作量（以小时或天计算）。理想的情况下，抛物线轨道在Sprint 的最后一天应该接触零点。有些时候会是这样，但是大多数情况不是这样。重要的是它体现了团队在相对于他们的目标的实际进展情况——并不是目前花费了的时间的多少（对于Scrum 来说这是不太相关的事项），而是仍剩余多少工作量——开发团队仍距离完成任务多远。如果此曲线的轨道在Sprint 末期不是趋于结束，那么开发团队应该加快速度，或简化和削减其工作内容。此图表也可以使用Excel 表格管理，许多团队认为在他们工作室的墙上用图纸标明更为简单和有效，并可以用笔随时更新；这个技术含量不高的做法比电子表格更快速，简易和更可见。
Scrum 的核心原则之一是Sprint 的周期不可以延长——其结束于指定的时间不论开发团队完成任务与否。如果开发团队未完成其Sprint 目标，他们将在Sprint 的末期声明他们没有完成预期的任务。这个方法创造了反馈循环的可视性，并强制开发团队在Sprint 预期估算时做出更好的判断，并确保可以按时完成任务不会失败。开发团队通常在前几个Sprint 时试图完成许多任务，但实际上并不可以达到Sprint 目标；然后他们可能会过度小心而挑选较少的任务，结果会提前完成；在第三或第四个Sprint 时，开发团队通常会了解自己的工作效率，他们会按时完成Sprint 的目标。鼓励开发团队在某一Sprint 中挑选一个周期（比如两周）并且不经常变化——固定的周期可以帮助开发团队了解他们的实际工作效率，并且可以帮助其达到工作的节奏性（此指团队的统一“心跳”）。
阅读详细......