Scrum introduction

Scrum的第一步是产品所有者清晰地展示产品的未来景象（vision）。这些是以按需求的优先列表展示的，按客户和商业价值排序，最高价值的项目排在列表顶端。这就是Product Backlog，它存在（并发展）于产品的整个生命周期。在项目开发的任何时候，Product Backlog是唯一具有权威性的“以优先权排序为准，需要完成的所有任务“的概况。只可以存在唯一一个Product Backlog，这就意味着产品有着需要在所有的工作范围中作为优先项的决策。

Product Backlog包括许多的不同项目，例如功能（“加入购物车“），开发需求（“重新改进处理流程模块，使其可以升级”），探索式的工作（“研究关于加速信用卡确认过程的方法”），和一致的Bugs（“判断并修复定单流程中的错误”）。

Product Backlog是由产品所有者随时更新，以反映客户需求的变化，新的想法和见识，竞争对手的发布，出现的技术障碍等等。团队提供给产品所有者在Product Backlog中每一项所需的相对工作的粗略估计，这可以帮助产品所有者作出优先权项的决策（一些项成为非优先权项，是当产品所有者了解到其交付需要花费大量的工作）。以上这些估计是相对的，因此他们可以用“点”来衡量，而不是用现实的工作单位如人员－星期：一段时间之后，团队收集对于其工作效率的数据（在一段时间内有多少这些相对的“点”可以被完成），可以使用这些数据计划发布日期和进行其他长期的计划。

Product Backlog中的项目在规模上会相差甚远，有些大的项目通常在Sprint计划会议上被划分为许多较小的项目，而小的项目有些会被合并为一。一般的建议是，在所需的最小的空间中说明最重要的事情――换而言之，不需要苗粟某一项目的所有可能的详细资料，只需要阐述清楚产品被认为是完成品所具备的要求就可以了。在Product Backlog列表中越底端的是更大和粗略的项目；当它们接近被开发时，产品所有者会添加更多的详细资料。

Scrum不是一种过程，也不是一项构建产品的技术，而是一个框架，在这个框架理可以应用各种过程和技术。Scrum的作用就是让开发实践方法的相对功效显现出来以便随时改进，同时也为开发复杂产品提供了框架。

Scrum是以经验过程控制理论为依据，采用迭代，增量的方法来提高产品的可预见性并控制风险。Scrum的三大支柱支撑起每个经验过程控制的实现。

第一大支柱是高透明度：高透明度确保管理结果的人看得到那些影响结果的过程方面。这些过程方面不仅要透明，而且那些被观察到的方面也必须被充分了解。这就是说，当某人检验某个过程并认为完成了某些任务时，这个完成必须等同于他们的完成定义。

第二大支柱是检验：开发过程中的各方面必须做到经常性的检验，以确保及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能允许的程度，那么就会发生问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和勤勉程度。

第三大支柱是应用：如果检验员经检验发现过程中的一个或多个方面不满足可接受标准，并且最终产品是不合格的，那么检验员就必须对过程或是材料进行调整。调整工作必须尽快实施以减少进一步的偏差。Scrum中有三个进行检验和使用的时刻：每日站会是用来检验朝向Sprint目标的工作过程，调整以优化次日的工作价值。另外，Sprint评审和计划会议是用来检验朝向发布目标的工作过程，调整以优化下一个Sprint的价值。最后，Sprint回顾会议是用来评审完成的Sprint,并确定什么样的调整可以使下一Sprint的效率更高，结果更令人满意和更易于工作。

Scrum不是流程，它是提供给团队可视性的框架，并且容许他们相应的“检验和适应”的技巧。Scrum试图让许多存在于开发团队中的问题显示出来。比如，大多数的开发团队并不擅长于计算在固定期间内完成的工作量，因此在第一个Sprint结束时不可能交付他们预计完成的工作。对于开发团队来说，这个是工作的失败。事实上，这个经验正是能更好预计工作量所需的第一步，并促使其对承诺的任务更加负责。这种模式可以使机能失调更易显现出来，让团队切实可以解决问题，是实用基础的技巧产生出最有意义的收益，是团队实用Scrum的经验之一。

一个开发团队普遍犯的错误是当他们在Scrum实践中遇到挑战，他们会改变实践方法，而不是改变自身的问题。比如，开发团队有困难完成Sprint任务时，会延长Sprint的周期，这样会破坏了Scrum真正的意义：使优点和缺点都显示出来，给开发团队自我的提高提供机会。

另一个普遍存在的错误是人们意味某一实践方法是被禁止的或不提倡的，只是因为Scrum没有明确的提出此方法。比如，Scrum并不特别要求产品所有者对于他或她的产品作出长远的目标计划；也没有要求工程师请教更有经验的人员关于比较复杂的技术问题。Scrum将这些问题留给个人作出正确的处理；在很多情况下，以上两个方法会被建议。做个比喻吧：“Scrum没有提出早餐的问题，难道你要饿着？”

另一个需要注意的问题是有时候经理会强制开发团队使用Scrum；Scrum是为开发团队提供自我组织的空间和工具，由上层强加于开发团队恐怕不是取得成功的良方。比较好的方法是让开发团队从同事或经理处了解到Scrum，并通过专业系统的培训，在开发团队实验此方法后作出决定。