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计划会议、回顾等等。

阅读详细......