首先强调一些Scrum的基本概念
本文只想为那些不断实验敏捷开发方法、追寻快速交付产品的IT管理者提供全套经过验证的实践经验，供之参考。我首先假设你已经理解了Scrum这种敏捷开发方法的基本概念并认同之，但是仍然，我还是要强调以下我们对Scrum达成的“共识”:-)
本文只想为那些不断实验敏捷开发方法、追寻快速交付产品的IT管理者提供全套经过验证的实践经验，供之参考。我首先假设你已经理解了Scrum这种敏捷开发方法的基本概念并认同之，但是仍然，我还是要强调以下我们对Scrum达成的“共识”:-)
Scrum开发流程通常以30 天或者更短的一段时间为一个周期，由产品经理（Product Owner） 提供新产品的需求规格开始，开发团队（Dev Team） 与产品经理于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于周期时间内交付成果，团队由开发主管（Scrum Master） 召集，每天使用15分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除之。
Scrum的重要名词
Backlog - 可以预知的任务集，包括功能性的和非功能性的所有任务。
Backlog - 可以预知的任务集，包括功能性的和非功能性的所有任务。
Sprint - 一次迭代开发的时间周期，一般最多以30天为一个周期。在这段时间内，开发团队需要完成一个制定的Backlog。
Product Owner - 这个角色被称为产品经理。他负责定义产品并向开发团队提出需求，最终验收开发团队的工作成果。
Scrum Master - 负责监督整个Scrum进程、修订计划的一个团队成员。
Sprint planning meeting - 在启动每个Sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：Product Owner和团队成员将Backlog分解成小的功能模块（即任务），决定在即将进行的Sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。
Daily scrum meeting - 开发团队成员参加，一般为15分钟。每个开发成员需要向Scrum Master汇报三个项目：今天完成了什么？ 是否遇到了障碍？ 即将要做什么？通过该会议，团队成员可以相互了解项目进度。
Sprint review meeting - 在每个Sprint结束后，将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。
Sprint retrospective meeting - 对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。
Scrum过程简单介绍
1 将整个产品的Backlog分解成若干Sprint Backlog，每个Sprint Backlog是按照目前的人力物力条件可以完成的。
2 召开Sprint planning meeting，划分、确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。
3 进入Sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
4 整个Sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner。
5 团队成员最后召开Sprint retrospective meeting，总结问题和经验。
6 周而复始，按照同样的步骤进行下一次Sprint。
下面开始进入正题——最佳实践指导思想
Scrum和极限编程（XP）都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。迭代要短、有时间限制。将注意力集中于在短时间内交付可工作的代码，这就意味着Scrum和XP团队没有时间进行理论研究。他们不会花时间用建模工具来画UML图、编写完美的需求文档，也不会为了应对在可预计的未来中所有可能发生的变化而去写代码。实际上，Scrum和XP都关注如何把事情做好。这些团队承认在开发过程中会犯错，但是他们明白：
Scrum和极限编程（XP）都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。迭代要短、有时间限制。将注意力集中于在短时间内交付可工作的代码，这就意味着Scrum和XP团队没有时间进行理论研究。他们不会花时间用建模工具来画UML图、编写完美的需求文档，也不会为了应对在可预计的未来中所有可能发生的变化而去写代码。实际上，Scrum和XP都关注如何把事情做好。这些团队承认在开发过程中会犯错，但是他们明白：
要投入实践中，动手去构建产品，这才是找出错误的最好方式；不要只是停留在理论层次上对软件进行分析和设计。
Scrum不是方法学，它是一个框架。也就是说Scrum不会告诉你到底该做些什么。因此，以下和你分享的Scrum经验，只可以说是供你参考的个案。你不需要完全仿照以下的做法。实际上如果换个不同的场景，也许某些实践方式就应该换了。
Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。
Backlog - Story
如何描述我们的“故事”（以下的“故事”等同于Backlog），最佳实践证明至少需要包括这样一些字段：
ID—— 统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。
Name—— 简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
Importance—— 重要性。产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。
提醒：我一直都想避免“优先级”这个说法，因为一般说来优先级 1 都表示“最高”优先级，但如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢？优先级0？优先级-1？思考一下吧:-)
提醒：我一直都想避免“优先级”这个说法，因为一般说来优先级 1 都表示“最高”优先级，但如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢？优先级0？优先级-1？思考一下吧:-)
Initial estimate—— 初始估算。团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。
我认为估算是最具有技术含量和不确定性的部分，当然也是Scrum过程中需要持续不断改进的部分 。
最小的单位是故事点（Story Point），一般大致相当于一个“理想的人天（man-day）”。
我认为估算是最具有技术含量和不确定性的部分，当然也是Scrum过程中需要持续不断改进的部分 。
最小的单位是故事点（Story Point），一般大致相当于一个“理想的人天（man-day）”。
什么是“理想的人天”？ 问一下你的团队：“如果可以投入最适合的人员来完成这个故事（人数要适中，通常为2个），把这些人锁到一个屋子里，有很多食物:-P 在完全没有打扰的情况下工作，那么需要几天，才能给出一个经过测试验证的、可以交付的完整实现呢？”如果答案是“把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。
一些小经验： 不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半）；区别于“人月神话”中的“人月”，Scrum方法最小的估算粒度一般为“人天”，有时候可以小到“0.5人天”，再小就值得商榷了，我是这样认为的。这足够“敏捷”了。
一些小经验： 不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半）；区别于“人月神话”中的“人月”，Scrum方法最小的估算粒度一般为“人天”，有时候可以小到“0.5人天”，再小就值得商榷了，我是这样认为的。这足够“敏捷”了。
How to demo—— 如何做演示成果。它大略描述了这个故事应该如何在Sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。如果你在使用TDD（测试驱动开发），那么这段描述就可以作为验收测试的伪码表示。
Notes—— 注解。相关信息、解释说明和对其它资料的引用等等。一般都非常简短。
利用以上的经验，我们可以设计出一个最为简单有效的Backlog描述模板，如下：
很多团队曾试过用很多字段描述“故事”，但最后发现，只有上面提到的六个字段会一直使用下去。
内部质量和外部质量
我建议尽力把内部质量和外部质量分开。
我建议尽力把内部质量和外部质量分开。
外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。
松散的沙滩上怎么可能建起精美的楼阁？
Scrum Master 把外部质量也看作Scrum范围的一部分。有时出于业务考虑，可能会先发布一个系统版本，其中用户界面给人的感觉可能比较简陋，而且反应也很慢；不过随后会发布一个干净的版本。Scrum Master 都是让 Product Owner 做权衡，因为他是负责定义项目范围的人。
不过内部质量就没什么好说的了。不管什么时候，团队都要保证系统质量，这一点毋庸置疑，也没有折扣可讲。现在如此、将来如此、一直如此，直到永远。
一个典型的Sprint计划会议时间表
Sprint 计划会议：13:00 – 17:00 （建议每小时休息10分钟）
Sprint 计划会议：13:00 – 17:00 （建议每小时休息10分钟）
13:00 – 13:30 产品负责人对Sprint目标进行总体介绍，概括产品Backlog。定下演示的时间地点。
13:30 – 15:00 团队估算时间，在必要的情况下拆分Backlog条目——把“故事”进一步拆分成“任务”。 产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”。
15:00 – 16:00 团队选择要放入Sprint中的故事。计算生产率，用作核查工作安排的基础。
16:00 – 17:00 为每日Scrum会议（简称每日例会）安排固定的时间地点——如果和上次不同的话。
Sprint应该多长才好？
时间短就好。公司会因此而变得“敏捷”，有利于随机应变。
13:30 – 15:00 团队估算时间，在必要的情况下拆分Backlog条目——把“故事”进一步拆分成“任务”。 产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”。
15:00 – 16:00 团队选择要放入Sprint中的故事。计算生产率，用作核查工作安排的基础。
16:00 – 17:00 为每日Scrum会议（简称每日例会）安排固定的时间地点——如果和上次不同的话。
Sprint应该多长才好？
时间短就好。公司会因此而变得“敏捷”，有利于随机应变。
短的Sprint = 短反馈周期 = 更频繁的交付 = 更频繁的客户反馈 = 在错误方向上花的时间更少 = 学习和改进的速度更快
众多好处接踵而至！
但是，时间长的Sprint也不错:-) 团队可以有更多时间充分准备、解决发生的问题、继续达成Sprint目标，团队成员也不会被接二连三的Sprint计划会议、演示等等压得不堪重负。
产品负责人一般会喜欢短一点的Sprint，而开发人员喜欢时间长的Sprint。所以Sprint的长度是妥协后的产物。做过多次实验后，我们最终总结出了最受欢迎的长度：三个星期 （当然，这仍然需要根据你们正在开发的产品的实际情况调整！）。绝大部分团队的Sprint长度都是三周。它不长不短，既让我们拥有足够的敏捷性，又可以让团队进入“流畅”的状态。
此外还有一个有效的经验：刚开始要根据实际情况试验Sprint的长度。不要浪费太多时间做分析。选一个可以接受的长度先开始再说，等做完一两个Sprint再进行调整。
为啥要确定Sprint的目标?
这个目标可以是“挣更多的钱”，或者“完成优先级排在最前面的三个故事”，或“让老板满意”，或“把系统做的足够好，可以作为beta版发布给真正的用户使用”，或“添加基本的后台系统支持”等等。它必须用业务术语表达，而不是技术词汇，因为需要让团队以外的人也能够理解。
这个目标可以是“挣更多的钱”，或者“完成优先级排在最前面的三个故事”，或“让老板满意”，或“把系统做的足够好，可以作为beta版发布给真正的用户使用”，或“添加基本的后台系统支持”等等。它必须用业务术语表达，而不是技术词汇，因为需要让团队以外的人也能够理解。
刚开始制定Sprint计划的时候，这个目标也许看上去即愚蠢又不合适，但它在Sprint中常常会被提到，这样，至少大家不会对自己整天忙忙碌碌究竟是为啥而感到困惑。
如何估算Sprint中该包含哪些Story
有两个经过实践验证的技术：
有两个经过实践验证的技术：
1 本能反应
2 生产率计算
2 生产率计算
有一个很简单的办法：看看团队的历史。看看他们在过去几个Sprint里面的生产率是多少，然后假定在下一个Sprint里面生产率也差不多不变。这项技术也被叫做“昨日天气（yesterday’s weather）”。要想使用该技术，必须满足两个条件：团队已经完成了几个Sprint（这样就可以得到统计数据），会以几乎完全相同的方式（团队长度不变，工作状态等条件不变）来进行下一个Sprint。
“昨日天气”用起来很方便，但需要考虑一些常识：
如果上一个Sprint干得很糟，是因为大部分成员都病了一星期，或其它很难碰上的变故。那你差不多可以放心假设这次运气不会那么坏，给这个Sprint设个高点的投入程度；
如果团队最近刚装了一个执行速度快如闪电的持续集成系统，那你也可以因此提高一下Sprint的投入程度；
如果有新人加入这个Sprint，就得把他的培训占用的精力也算进来，降低Sprint的投入程度；
如何定义“完成（done）”
有一点很重要：产品负责人和团队需要对“完成”有一致的定义。所有代码被 check in 以后，故事就算完成了吗？还是被部署到测试环境中，经过集成测试组的验证以后才算完成？
有一点很重要：产品负责人和团队需要对“完成”有一致的定义。所有代码被 check in 以后，故事就算完成了吗？还是被部署到测试环境中，经过集成测试组的验证以后才算完成？
我们尽可能使用这样的定义：“随时可以上线 ”，不过有时候我们也可以这样说：“已经部署到测试服务器上，准备进行验收测试”。
如果你常常对怎样定义完成感到困惑，或者你故事的“完成”定义是不能确定的，那么，你或许应该在每个故事上都添加一个字段，起名为“何谓完成”。
如何精确的估算
如果让整个团队进行估算，通常那个对故事理解最透彻的人会第一个发言。不幸的是，这会严重影响其他人的估算。
如果让整个团队进行估算，通常那个对故事理解最透彻的人会第一个发言。不幸的是，这会严重影响其他人的估算。
有一项很优秀的技术可以避免这一点——它的名字是“计划纸牌 ”。
每个人都会得到如上图所示的13张卡片。在估算故事的时候，每个人都选出一张卡片来表示他的时间估算（以故事点的方式表示），并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。
如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同。
如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同。
估算需要注意以下几点
1 试着避免技术故事。 努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡，因为产品负责人可能对技术知之甚少。
1 试着避免技术故事。 努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡，因为产品负责人可能对技术知之甚少。
2 如果无法把技术故事转变成普通故事，那就看看这项工作能不能当作另一个故事中的某个任务。 例如，“重构DAO层”可以作为“编辑用户”中的一个任务，因为这个故事会涉及到DAO层。
3 如果以上二者都不管用，那就把它定义为一个技术故事，用另外一个单独的列表来存放。 产品负责人能看到它，但是不能编辑它。用“投入程度”和“预估生产率”这两个参数来跟产品负责人协商，从Sprint里拨出一些时间来完成这些技术故事。
我们该如何管理Backlog
这个问题看起来有点难搞。
这个问题看起来有点难搞。
用Excel来管理产品 Backlog 很不错，不过你仍然需要一个Bug跟踪系统，这时Excel就无奈了。可以用Jira。
那我们怎么把 Jira 上的 issue 带到 Sprint 计划会议上和我们每日的工作中来呢？我的提议是：
把 Sprint Backlog 计划，贴到“白板”上！
把 Sprint Backlog 计划，贴到“白板”上！
以下不多说废话，直接上图——看图说话：
很明显，这是一张“健康”的燃尽（Burn Down）图，随着时间的推进，以 人/天 为单位的故事点基本上沿着标准线减少，直至“燃尽”……
一面典型的、简洁的、实用的“白板”。很不幸，它描述了“计划赶不上变化”的场景——临时插入的大量任务阻塞了计划，导致了燃尽图“燃而不尽”。
一般来说，我们把高优先级的任务放在上面，是为了先做之。这面“白板”很成功的描述了次序颠倒、“捡了芝麻、丢了西瓜”的错误工作顺序。
下面计划定的似乎太宽松了，作为开发人员也许很Happy:-)，但如果你是老板或管理者该怎么办？加活吧！让弟兄们的工作来的更加“充实”些吧……
最后，呼应一下前面：我们用 人/天 作为所有时间估算的基础（我们也把它叫做故事点）。它的最小值是0.5，也就是说小于0.5的任务要么被移除，要么跟其他任务合并，要么就干脆给它0.5的估算值 。干净利落。
本文转自胡奇 51CTO博客，原文链接：http://blog.51cto.com/huqicto/280957，如需转载请自行联系原作者
