Draft version 0.5
Scrum 简介
作者：Pete Deemer 与Gabrielle Benefield
Pete Deemer 是Yahoo!印度研发中心的首席产品执行官。Gabrielle Benefield是负责Yahoo!公司敏捷开发的高级总监。他们共同致力于Scrum在Yahoo! 公司全球范围的大型推广工作。
读者提示：目前在互联网上有很多关于Scrum的简短介绍，本简介旨在提供更深入一步的研究。此简介并不是学习Scrum的最终阶段；我们建议那些考虑采用Scrum的团队借鉴Ken Schwaber的著作《Agile Project Management with Scrum》和《Agile Software Development with Scrum》，并积极利用和参与目前众多优秀的Scrum培训和咨询活动；详细情况请参考https://www.doczj.com/doc/4e8991825.html,. 在此对Ken Schwaber, Jeff Sutherland和Mike Cohn 所做的帮助和贡献表示感谢。
传统的软件开发
各类大中小型企业所运用的传统软件构建方法，即是众人皆知的“瀑布”型开发方法。此模型存在很多变体，但其典型性是在开发初期制定详细的计划，在计划中最终产品己被仔细研究，设计，并且一切详细资料都记录在案。任务已设计制定，并且在工作中使用如Gantt (根特)图表等工具和Microsoft Project项目管理软件。开发团队预计开发项目的时间是以累计其相关每一步骤而得出的。当项目管理者(stakeholder)全面审核开发计划并表示赞同，开发团队即时开始工作。团队成员完成他们所专长的部分工作，即刻转交给其他成员，形成生产流水线的形式。当全部工作都已完成，成品将会转交给产品质量控制部门，在这里将会进行在产品到达客户手中之前的全面检测。在整个流程中，所有相对于原始计划的分歧都将受到严格的控制，以保证生产的成品与原始设计保持一致。
此种模式有优点但也有不足之处。它的最大的优点是非常有逻辑性：在构建之前思考，并全部记录下来，按照计划实施，保持各项事务尽可能的有组织性。它有一个最大的弱点就是：人的参与,人对于此种工作方式并不适合。
比如：此种方式要求所有的建议和想法都要在开发周期的最启始阶段提出，此时建议和想法将可以被容入开发计划之中。但是众所周知，好的想法和建议的出现会贯穿整个开发过程——在开发最启始阶段，在开发中期，有时可以在产品交付使用的前一天，如果整个开发过程中不容许变化的产生，那么将会遏制创新的产生。在使用“瀑布”型开发方式时，开发末期出现的创新将不是好的征兆，而是对整个产品开发产生的危机。
Draft version 0.5 1
Draft version 0.5
瀑布型开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此最合理的假定是如果我可以把我的想法尽可能都记录下来，这样将会使信息更可靠的传输到团队每一个成员的头脑中；另外，因为所有东西都记录在案，这将是我完成任务的最实际的证据。但是实际上，在大多数情况下，没人会读这些100页左右的详细规格要求资料。同样，如果有人读取该资料，那么将会产生许多的误解。记录的资料只是我头脑中想法的抽象提取；当你阅读此资料时，你将会产生另一个抽象的概念，此时与我的真正想法已经相距甚远了。所以严重误解的产生也就不足为奇了。
当人参与时,还有一种情况会发生——“实际应用中产生的灵感”——在第一次实际应用产品时，你可能会立刻产生20种方法以使产品更加完美的灵感。但是遗憾的是，这些非常有价值的想法通常会在产品开发的末期产生，这时创新是最困难和最具有分裂性的——换句话说，是做正确抉择最昂贵的时刻。
人的预知未来的能力是有限的。比如，某场比赛的最终结果是出人意料的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们往往非常欠缺对于未来作出长远计划的能力——今天猜测未来八个月中每周你如何工作将如幻觉般渺茫，这正是Gantt (根特)图表的衰败表现。
另外，瀑布型方式将会促使团队成员在交接工作时产生敌对的关系。“他要求我构建在规范要求中不存在的东西。”“她经常改变主意。”“我不可能对我不能控制的东西负任何的责任。”这些指引我们对瀑布方式的另一思考——在此种方式中工作毫无兴趣可言。事实上，进一步说，瀑布型方式是造成产品开发人员苦恼的根源，并且最终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。
一个僵硬的，拒绝变革的流程也会造成低劣产品的产生。客户可能会得到根据他们第一需求所生产的产品，但是在产品在形成阶段时还是客户真正需要的吗？在开发之前收集所有的需求并将它们嵌入毫无改变可言的顽石般的计划中，此产品将被宣告只会和最起始的想法保持一致，而不是开发团队在实践中不断发现可能性而使其尽善尽美。
许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是一个极其付有逻辑性的方式，所以第一的自然反应就是对内部工作的谴责：“如果我们尝试更好的使用它，它将会发挥作用”——如果我们计划的更详尽，记录更详细，更严格的拒绝任何变革，一切将会很顺利地进行。遗憾的是，许多开发团队只得到的相反的效果：他们越竭尽全力尝试此方法，得到的结果越差！
Agile (敏捷) 开发和Scrum
Agile (敏捷)开发整体概念的产生是基于一种方法更接近人类活动现实情况, 以便取得更好效果的信念上。Agile强调构建可以即时操作的软件，相对于在构建前花费许多时间记录规格要求。Agile注重授于小型多职能的团队决策权，相对于大型层次和部门职能的划分，Agile注重快速迭代，并且其中结合尽可能多的客户反馈。在学习了解Agile的时候，经常会有这样的公认—Draft version 0.5 2
Draft version 0.5
Draft version 0.5 3 —感觉非常像回到了开发启始的阶段，我们曾经”做过”。
Scrum 是众多快速发展的Agile 方式之一。Scrum 是在十多年前由Ken Schwaber 和Jeff Sutherland 博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo! ,
Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE Medical, CapitalOne 和 US Federal Reserve. 许多使用Scrum 的团队取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。对于产品开发者——许多曾受到“管理层每月的一时狂热”的伤害——这是非常重要的。Scrum 是简单的，强有力的，并立足于常识之中的。
图示1 Scrum
Scrum 基础知识
Scrum 是迭代的，增量型的流程。Scrum 构造的产品迭代周期为Sprints , 工作的迭代时间一般为一到四周。Sprints 是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。在每一Sprint 的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint 的末期完成这些项目。每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint 的末期，团队将对这一阶段工作结果作一展示并取得相关的反馈，为下一Sprint 做好准备。Scrum 强调生产可以使用的产品，意指在Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。
Scrum 中的角色
在Scrum 中有三个基本的角色：产品所有者，开发团队成员和ScrumMaster 。
产品所有者产品所有者（（Product Owner ）负责收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为产品的形式。在一些情况下，产品所有者正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者
Draft version 0.5
Draft version 0.5 4 这一角色在许多企业中是由产品经理或产品市场经理担任。
开发团队成员
开发团队成员构建客户将会购买的产品：软件，网站，或者是任何一种产品。Scrum 团队通常包括五到十个成员，尽管团队大到15个成员和小到3个成员也有很好的收效。团队应该包括所有交付工作所需的专门人员——例如，一个软件项目的开发团队包括程序员，界面设计师，检测员，市场人员和研究人员。开发团队不仅构建产品，他们也向产品所有者提供让产品尽善尽美的建议和想法。开发项目包括15个或以上的人员时，通常会被划分为若干的Scrum 团队，每一团队注重于产品开发的不同方面，并相互紧密的协作。团队成员同时可以参与其他项目开发，这样比只限制开发团队致力于Scrum 更能提高生产效率。团队内部成员也可以在不同Sprint 中变化，但是这样会减少整个团队的生产效率。
ScrumMaster 的任务是以任何方式帮助整个团队取得成功。ScrumMaster 不是团队中的经理；他或她是服务于整个团队，帮助团队铲除壁垒而取得成功。协助团队会议，并支持Scrum 的实践。在一些团队中会有某一人专心致力于担任ScrumMaster ，而另一些团队可以是其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的ScrumMaster 可以有不同的背景和学科：项目管理，工程技术，设计，检测。ScrumMaster 和产品所有者不应是同一人；有时，ScrumMaster 可能会号召拒绝产品所有者（例如，他们有时会在某一Sprint 中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster 不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。
除以上三个角色之外，还有其他对于项目成功作出重要贡献的人员：可能其中最重要的是经经理。他们的角色在Scrum 中的发展, 他们仍保持了相当重要的位置——他们支持开发团队使用Scrum ，他们为整个项目的开发提供知识，技术和各种必要的协助。在Scrum 中，这些人转化了以前“保姆”式的角色（布置任务，收取进程报告，和其他一些谨小慎微的管理方式），取而代之的是承担起更多的“指导“作用（指导职业发展，在职辅导培训，扮演魔鬼的代言人，协助铲除障碍，帮助解决问题，提供创新的建议和指导团队成员的技能发展）。为了能更好地实现这一变化，经理们需要改进他们的管理方式方法；比如，运用苏格拉底哲学提问方式来帮助开发团队找寻问题的解决办法，而不是简单地决定解决方法并分配给开发团队。
Scrum 启始
Scrum 的第一步是产品所有者清晰地展示产品的未来景象（vision ）。这些是以按需求的优先列表展示的，按客户和商业价值排序，最高价值的项目排在列表顶端。这就是Product Backlog, 它存在（并发展）于产品的整个生命周期（图示2）。Product Backlog 包括许多的不同项目，例如功能（“使用户可以把所选书籍放入购物车”），开发需求（“重新改进处理流程模块，使其可以升级”），探索式的工作（“研究关于加速信用卡确认过程的方法”），和已知的bugs （“判断并修复定单流程中的错误”）。
Product Backlog 是由产品所有者随时更新，以反映客户需求的变化，竞争对手的发布，新的想法和见识，出现的技术障碍等等。
Draft version 0.5
Draft version 0.5
5
图示2 Product Backlog
在项目开发的任何时候，Product Backlog 是唯一具有权威性的“需要完成的所有任务”的概况。只可以存在唯一一个Product Backlog ；这就意味着产品所有者需要在所有的工作范围中作出优先项的决策。
Product Backlog 中的项目在规模上会相差甚远；有些大的项目通常在Sprint 计划会议上被划分为许多较小的项目，而小的项目有些会被合并为一。关于Scrum 的误解之一是它会阻止你记录详细的规范说明；而现实中，这是由产品所有者和开发团队共同决定详细资料的多少，这些从其中一个Product Backlog 到另一个有可能存在不同。一般的建议是，在所需的最少的空间中说明最重要的事情——换而言之，不需要描述某一项目的所有可能的详细资料，只需要阐述清楚产品被认为是完成品所具备的要求。在Product Backlog 列表中越底端的是更大和粗略的项目；当它们接近被开发时，产品所有者会添加更多的详细资料。
Sprint 计划会议
Sprint 计划会议在每一Sprint 的启始阶段进行。在Sprint 计划会议的第一部分，产品所有者和Scrum 开发团队（在ScrumMaster 的协助下）共同评审Product Backlog ，讨论Backlog 中各项目的目标和背景，并提供Scrum 开发团队深入了解产品所有者想法的机会。在会议的第二部分，Scrum 开发团队从Product Backlog 中挑选项目并承诺在Sprint 的末期完成任务，从Product Backlog 的顶端开始（换而言之，从对产品所有者具有最高优先权的项目开始）并按列表顺序依次工作。这是Scrum 的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由产品所有者安排工作量。这就使任务的交付更可靠；第一，因为开发团队承诺工作量，而不是其他人代替其“承诺”工作量；第二，开发团队自己决定所需要的工作量，而不是其他人决定工作量“应该”是多少。产品的所有者对于开发团队承诺任务多少没有控制权，他或她只知道开发团队负责的项目是由Product Backlog 中按顺序从上至下进行的——换而言之，是从他或她选择的最重要的项目开始。开发团队可以从列表底层选择项目提前完成，如果其对于整个开发具有
Draft version 0.5
意义（比如，提升和快速完成较低优先权的项目，作为完成较高优先权项目的一部分）。
图示3 预测可利用时间
Sprint计划会议通常会持续几个小时——开发团队对于承诺完成的任务作出认真地抉择，这些责任要求通过仔细地考虑以达到成功的目标。团队将从估算每一成员拥有的完成Sprint相关工作的时间开始——换句话说，是团队成员平均的工作时间减去他们花费在检修bug和其他必要的维护工作，参加各种会议，回复电子邮件，午休等的时间。大多数人会有4到6个小时每个工作日可以完成Sprint相关的工作。（图示3）
当可利用时间确定下来，开发团队会从Product Backlog的顶端第一项开始工作——换句话说，从产品所有者的最高优先权项开始——团队共同工作，将其分配为小块任务，并记录在Sprint Backlog中（图示4）。当任务确定后，团队成员可以自愿承担任务，在考虑任务间依赖关系和次序的情况下，给每一项任务估算时间，并保证每一个人的工作量合理。在此流程中将会和产品所有者有往复交流，阐明要点，核实交易，将较大型Backlog分割成小块，并保证开发团队真正全面了解开发的需求。开发团队将按Product Backlog序列继续计划，直至消耗所有可利用时间。在会议的末期，开发团队将提供所有任务的列表，并写明每一项工作由谁完成和他们的估算时间（一般以小时计算或每天的一小部分）。许多开发团队也使用可视任务跟踪工具，利用墙体面积大小的任务板，任务（写在便签上）在Sprint中跨越栏目，“未开始”，“在进行”，“需校验”，和“已完成”。
Draft version 0.5 6
Draft version 0.5
Draft version 0.5
7
图示4 Sprint Backlog
Scrum 的重要支柱之一是当Scrum 开发团队确认承诺任务后，产品所有者在此Sprint 期间不可以添加新的需求。这就意味着即使在Sprint 中途，产品所有者想要添加新要求，他或她在下一新的Sprint 开始前不可能作出任何变更的决定。如果一个外部情况出现致使项目优先级的变化，意味着如果开发团队按原计划工作将会是浪费时间，产品所有者此时可以结束该Sprint ；意味着开发团队停止一切工作，重新开始Sprint 计划会议等等。此种决断会产生很大的影响, 除非在非常特别情况下，不会采用这种方式。
保证开发团队在Sprint 中目标不被变换有着正面影响。首先，开发团队确信在工作开始时的承诺是不会变化，这样会集中开发团队的注意力。第二，这样也可以培养产品所有者在安排Product Backlog 中项目的优先权时，适时作出正确的抉择。他们知道任务的承诺是在整个Sprint 中不可变更的，使其在决定从哪一项目开始工作更为细心。
作为回报，产品所有者也可以得到两个好处。首先，他或她有充分的信心，开发团队对所承诺任务强烈负责，并随着时间推移，Scrum 开发团队将会做的很好。第二，产品所有者可以在下一Sprint 开始前，提出他或她希望的变动。在这一点上，增加条件，删减条件，更改条件和重新排列优先权都可以被接受。但产品所有者不可以在Sprint 进行中提出任何变更，他或她只是需要等待一个Sprint 的完成时间或更短。不再僵持于是否变化——方向的变更，条件的变更，或只是简单的想法的变更——可能正式此原因，使得产品所有者成为Scrum 拥护者中最热衷的成员。
每日每日（（站立站立））例会
每当Sprint 开始, Scrum 开发团队将会实施另一个Scrum 的重要实践方法:每日每日（（站立站立））例会例会。这是在每个工作日特定的时间举行的短小（15分钟）的会议，Scrum 开发团队的每一成员都将参与；为了保证其短小精悍，与会成员都保持站立（因此为“站立会议”）。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。一个接一个，每个团队成员只可以向其他人汇报三件事情：从上次会议之后完成了哪些工作，在下次会议之前准备完成哪些工作，在工作进行中存在哪些障碍。ScrumMaster 将会把障碍内容记录下来，在会后协助团队成员铲除障碍。在每日的（站立）例会中不容许讨论，只是将以上三个重点信息做一汇报；如果需要讨
Draft version 0.5
论，将在会后进行。产品所有者，经理和项目管理者可以参加会议，但是他们应该在会议结束以前避免问问题或提出讨论——每一与会者应该清楚的是开发团队是在互相汇报和交流情况，并不是向产品所有者，经理或ScrumMaster汇报。这个会议并没有标准形式，有些团队感觉邀请产品所有者参加并将其每日工作做一简要阐述，是对团队工作极其有意义的。
在会议结束后，开发团队成员将对其负责的Sprint Backlog中的项目做剩余时间的更新。这些信息会记录在Sprint Burndown Chart图表中（图示5）。它是用来显示每日直至开发团队完成
全部任务的剩余工作量（以小时或天计算）。理想的情况下，抛物线轨道在Sprint的最后一天应该接触零点。有些时候会是这样，但是大多数情况不是这样。重要的是它体现了团队在相对于他们的目标的实际进展情况——并不是目前花费了的时间的多少（对于Scrum来说这是不太相关的事项），而是仍剩余多少工作量——开发团队仍距离完成任务多远。如果此曲线的轨道在Sprint末期不是趋于结束，那么开发团队应该加快速度，或简化和削减其工作内容。此图表也可以使用Excel表格管理，许多团队认为在他们工作室的墙上用图纸标明更为简单和有效，并可以用笔随时更新；这个技术含量不高的做法比电子表格更快速，简易和更可见。
图示5 每日估算和Burndown图表
Draft version 0.5 8
Draft version 0.5
Scrum的核心原则之一是Sprint的周期不可以延长——其结束于指定的时间不论开发团队完成任务与否。如果开发团队未完成其Sprint目标，他们将在Sprint的末期声明他们没有完成预期的任务。这个方法创造了反馈循环的可视性，并强制开发团队在Sprint预期估算时做出更好的判断，并确保可以按时完成任务不会失败。开发团队通常在前几个Sprint时试图完成许多任务，但实际上并不可以达到Sprint目标；然后他们可能会过度小心而挑选较少的任务，结果会提前完成；在第三或第四个Sprint时，开发团队通常会了解自己的工作效率，他们会按时完成Sprint的目标。鼓励开发团队在某一Sprint中挑选一个周期（比如两周）并且不经常变化——
固定的周期可以帮助开发团队了解他们的实际工作效率，并且可以帮助其达到工作的节奏性（此指团队的统一“心跳”）。
Sprint评审
在Sprint结束后，将进行Sprint评审，团队在此期间展示他们所构造的产品。出席此会议的有产品所有者，开发团队成员，ScrumMaster，加上客户，项目管理者，专家，高层人士和任何对此感兴趣的人。这不是开发团队做成果“演讲”——会议上不会有PowerPoints图片文件，通
常会议不会需要超过30分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。会议可以持续10分钟，也可以是两个小时——会议目的只是对工作结果的展示和听取反馈。
Sprint回顾
在Sprint评审之后,开发团队会进行Sprint回顾。有些开发团队会跳过此过程, 这是不合适的,
因为它是使Scrum成功的重要方法之一。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。Scrum开发团队，产品所有者和ScrumMaster都将参加会议，会议由外部中立者主持；一个很好的方法是由ScrumMaster互相主持对方的回顾会议，可以起到各团队间信息传播的作用。
组织Sprint回顾的最简单方法是在墙上挂两张张贴画大小的白板纸，纸上注明“哪些项工作顺利”，“哪些项不成功或者哪些项可以做的更好”——让与会者在每一类别下增加些项目。当项目重复时，可以在该项旁边记正字累计，这样一些比较普遍出现的项目就一目了然了。然后团队成员共同讨论找寻这些项目出现的根本原因，同意在下一个Sprint中的改进计划，并负责在下一个Sprint回顾会议上评审项目结果。另一种方法是让团队成员在每一类下的项目中，用“C”标记如果其根源是Scrum，或用“V”标记如果其是由Scrum显现出来的（换句话说，无论Scrum存在与否该项目都会发生，但是Scrum使开发团队注意到了该项目的产生）。开发团队会在“哪些项目工作顺利”下发现许多的C标记，在“哪些项目不成功”下有许多的V标记；这是个非常好的现象，即使“哪些项目不成功“是比较长的列表，因为解决问题根本原因的第一步就是让其显现出来，Scrum正是此作用的强有力的促进因素。
Draft version 0.5 9
Draft version 0.5
开始下一个Sprint
在Sprint评审会议之后，产品所有者将提取所有建议，和在Sprint中产生的新的优先权项目，并将这些项目合并于Product Backlog之中；增加新的项目，现有项目进行了更改，重新排序或删除。当Product Backlog的更新完毕，循环周期可以再次开始，以下一个Sprint计划会议为开端。
许多开发团队感觉在每个Sprint末期进行优先化的会议很有意义，和产品所有者一起对下一Sprint中的Product Backlog项目进行评审。除了给开发团队的一个机会提醒产品所有者其未注意的事项——技术维护，比如——此会议也开始了在Sprint计划会议之前所需的初步想法。
在各Sprint之间没有间隔期——开发团队通常在下午时间进行了Sprint评审，第二天上午就进行下一Sprint计划会议。Agile开发的价值观之一是“可持续性“，只有在正常的工作时间和劳动强度下，开发团队才可以继续此周期的持续。
产品发布计划
Sprint持续直至产品所有者决定产品已经可以准备发布，此时会有“发布Sprint“来进行最后的整合和发布产品前的检测。如果开发团队一直贯彻很好的开发方法，不断地重构和持续集成，在每一Sprint中的有效测试，就不会存在许多遗留问题需要清除。
有这样一个问题有时会被提到，是怎样在一个迭代的模式中产生长期的发布计划。在一个项目的起始阶段，开发团队会作出粗线条的发布计划；他们不可能预先得知工作的结果，其重点是创建一个大体的计划提供给项目发展一个大体的方向，并阐明交易决策如何形成（比如范围相对于进度表）。以此作为路标来指引你向目标迈进；在行程中你实际挑选的路程和所做的决策都是途中决定的。
有一些产品发布是以日期界定的；比如：“我们会在11月10日的产品展示会上发布我们项目的2.0版。“在此种情况下，开发团队会在现有的可利用时间内完成尽可能多的Sprint（构建尽可能多的功能）。有些产品要求某部分构建完成才可以说明整个产品的完成，产品不会在这些要求满足前被发布，无论周期长短。Scrum强调在每一Sprint中都生产出可以随时交付的编码，开发团队可以进行中间的发布，使客户可以更快的收到产品的效益。
大多数产品所有者会选择一个发布方式，但是会通知其他的——比如，他们会决定发布日期，他们会与开发团队成员一起对Backlog中项目的完成日期做一大体的估算。在“固定价格/固定日期/固定交货期”的情况下——比如，合同制开发——在这些变量中至少有一个内部存在缓冲区，可以容许不确定因素和变更；在此方面，Scrum于其他的开发方法并无区别。
普遍存在的挑战
Scrum试图让许多存在于开发团队中的问题显现出来，特别是在开发的前期。比如，大多数的开发团队并不擅长于估算在固定期间内完成的工作量，因此在第一个Sprint结束时不可能交付Draft version 0.5 10
Draft version 0.5
Draft version 0.5 11 他们预计完成的工作。对于开发团队来说，这个是工作的失败，可能会导致他们对采用Scrum 方法的质疑。事实上，这个经验正是能更好预计工作量所需的第一步，在经验丰富的Scrum 实践者的帮助下，开发团队可以正确地认识到这一点。开发团队可能会遇到的另一个难题是每日（站立）例会——让开发团队的每一个成员承诺在特定的时间参加会议，准时并且每日参加，这就需要开发团队比通常有更高的要求，有些团队可能达不到此标准。
一个开发团队普遍犯的错误是，当他们在Scrum 实践中遇到挑战，他们会改变实践方法，而不是改变自身的问题。比如，开发团队有困难完成Sprint 任务时，会延长Sprint 的周期，这样他们就会有充足的时间完成任务——在流程中，确保自身不用提高工作预测的技能和更好的管理时间。这样，在没有经验丰富的Scrum 培训师的指导下，开发团队只会将Scrum 作为自身弱点和机能失调的映射，并破坏了Scrum 真正的意义：使优点和缺点都显现出来，给开发团队自我的提高提供机会。
另一个普遍存在的错误是，人们以为某一实践方法是被禁止或不提倡的，只是因为Scrum 没有明确的提出此方法。比如，Scrum 并不特别要求产品所有者对于他或她的产品作出长远的目标计划；也没有要求工程师请教更有经验的人员（比如，他们的经理）关于比较复杂的技术问题。Scrum 将这些问题留给个人作出正确的处理；在很多情况下，以上两个方法（和其他许多的方法）会被建议。做个正确的比喻：“因为Scrum 没有提到早餐的问题，并不意味着你就得挨饿！”
另一个需要留意的问题是有时经理会强制开发团队使用Scrum ；Scrum 是为开发团队提供自我组织的空间和工具，由上层强加于开发团队恐怕不是取得成功的良方。比较好的方法是让开发团队从同辈或经理处了解到Scrum ，并通过专业系统的培训，在开发团队实验此方法（比如90天）后作出决定；在实验周期后，开发团队通过经验的总结来决定是否继续采用此方法。
在第一个Sprint 之后，结果往往会对开发团队产生很大的挑战，采用Scrum 的好处也会在其尾声显现出来，使得许多新的Scrum 团队宣称：“Scrum 是困难的，但是它比我们以前采用的方法要好许多！”
Scrum 的成果
Scrum 产生的收益在开发团队经验中体现在不同的方面。在Yahoo!公司，在上18个月中我们将近50个开发项目采用Scrum ，一共近600人参与，采用Scrum 的团队数量在快速发展。这些项目从客户界面，网页设计如Yahoo! Photos, 到后端基础构造服务如服务上百万客户的Yahoo! Mail ；从全新的产品如Yahoo! Podcasts ，其利用Scrum 作为从构思到发布的流程（并获得该年度同类产品的Webby 奖），到一些增量的项目，包括开发新的部件并维修bug 和其他的维护工作；我们也利用Scrum 来分配分布式项目。每一个季度，我们对Yahoo!公司每一位Scrum 的使用者进行调查（包括产品所有者，开发团队成员，ScrumMaster 和这些人员的经理），并让他们将Scrum 于以前的开发方式做一对比。我们正在准备Yahoo!公司的深入调查报告，以下是相关的资料显示：
? 生产效率生产效率：：68%回复显示采用Scrum 后生产效率提高（4分或5分在以5分为衡量标准
Draft version 0.5
Draft version 0.5 12 上）；5%显示采用Scrum 后生产效率降低（1分或2分在以5分为衡量标准上）；27%显示采用Scrum 后无变化（3分在以5分为衡量标准上）。
? 团队精神团队精神：：52%回复显示采用Scrum 后团队精神加强；9%显示采用Scrum 后团队精神减
弱；39%显示采用Scrum 后无变化。
? 适应性适应性：：63%回复显示采用Scrum 后适应性加强；4%显示采用Scrum 后适应性减弱；
33%显示采用Scrum 后无变化。
? 责任性责任性：：62%回复显示采用Scrum 后责任性加强；6%显示采用Scrum 后责任性减弱；
32%显示采用Scrum 后无变化。
? 协作能力协作能力：：81%回复显示采用Scrum 后协作能力加强；1%显示采用Scrum 后协作能力减
弱；18%显示采用Scrum 后无变化。
? 在产品所有者估算下在产品所有者估算下，，开发团队的生产效率平均提高了36%
? 85%的开发团队成员表示如果其拥有决策权的前提下的开发团队成员表示如果其拥有决策权的前提下，，将会继续使用Scrum 。
Scrum介绍 新领航创新事业部 吴楠 广东亿迅-新领航创新事业部/ 2013 . 10
功能的对比 许多企业面临的问题与挑战敏捷宣言敏捷原则Scrum 1234
许多企业面临的问题与挑战 产品投放市场的时间太慢 项目失败的比例高的离谱 对变化与变更的响应，难度大且成本高 客户体验及客户为导向很差 生产力需要大幅提高 员工士气，动力及责任感很低 人员流失率引起的问题
> 个体与交互过程与工具 > 可用的软件完备的文档 > 客户协助合同谈判 > 相应变化遵循计划
?我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 ?欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。?要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 ?项目过程中，业务人员与开发人员必须在一起工作。 ?要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 ?无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 ?可用的软件是衡量进度的主要指标。 ?敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 ?对技术的精益求精以及对设计的不断完善将提升敏捷性。 ?要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 ?最佳的架构、需求和设计出自于自组织的团队。 ?团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
Scrum （重点）的简单框架 Product Backlog Sprint Backlog Potentially Shippable Product Increment 2-4weeks 24 hours
关于腾讯敏捷框架TAPD（Tencent Agile Product Development） 腾讯是一家典型的互联网企业，互联网行业有其鲜明的特点： 1．关注用户行为 2．追求创新（腾讯有一个创新中心部门） 3．需求不确定性高 4．快速适应变化 5．快鱼吃慢鱼 腾讯在敏捷开发方面的实践大致包括3个部分： 1．产品：采用FDD，即产品特性开发驱动的一种模式，腾讯的产品会有一个明确的产品经理这样一个角色，他会负责整个产品，包括产品的验证、产品的方向、市场调研、用户调研等。FDD模式是一种非常适合产品经理来对产品做一些滚动的要求，腾讯在产品设计上引入了类似FDD这样的模式，但是也不完全是FDD，只是参考FDD，所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。 2．项目管理过程：腾讯采取了SCRUM，但也不完全是SCRUM，有腾讯根据自己的特点去总结的一些实践，大概的项目管理过程同SCRUM的过程是比较类似的，包括每天的晨会、迭代、timebox、每个迭代完成的时候会有showcase、回顾总结等。 3．开发实践：参考了很多XP的实践，就XP完整的实践来说会比较理想化，很多东西不一定在实际开发中能够采纳，所以腾讯也是采纳其中的某些实践，比如自动化测试和持续集成，通过这样的实践就能保证产品有一个快速发布的过程。 在腾讯的敏捷实践中，具体的实践情况是这样的： 1．故事墙：就是白板story wall，平时工作中很多团队都会使用，这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来，整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程，包括整个产品特性的过程。 2．迭代总结：在每一个产品发布的时候都会有一个总结。具体的做法是，把做得好的、不好的总结出来，做得好的在下一次迭代发扬光大，做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加，包括项目的开发人员、测试人员、QA、项目经理、产品经理等，每个人都要去去总结他在上一个迭代中碰到了什么问题，通过便签纸的方式贴出来，项目经理实际上可以看成是SCRUM Master，包括站起来总结这样一些东西，包括我们下一次迭代继续发扬什么，必须要注意什么东西，最后就会得出一个excel的文档，包括上一个迭代中出的问题，具体的解决办法，都会有。 3．每日晨会：每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作（特点：是站着开会）。最早是通过白板的方式去做，就是每天项目经理组织团队成员对着白板，白板上体现项目的进展情况，通过会议可以很明确的知道昨天大家做到什么样子，今天大家计划做什么，最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题，第一、对于一个20、30人的团队，每天要怎样做晨会，这是目前遇到的比较大的困惑；第二、晨会很容易形式化，究竟带来什么样的效率和效果，目前也在通过一些方式去研究，去探讨。第三、有一些形式上的呆板，刚开始做会觉得比较有意思，觉得这跟传统做法不一样，每天这样做并且做多了就感觉很枯燥，这也是面临一个挑战。后来腾讯也做了一些改进，比如为了让成员的参与程度更强一些，包括形式上会更强一些，现在有些团队就会采取每个人轮流主持的方式，刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西，但是现在看来的话，感觉改进的还是不是很透。
Scrum在中国——企业实施情况调查实录 最近，InfoQ中文站就Scrum实施情况对国内一些企业的相关人士进行了问卷调查。从调查结果中我们选出了5个比较有代表性的案例，其中既有来自大型企业的，也有来自创业型公司的；既有采取自底向上的实施方式的，也有自顶向下实施的；有成功，也有失败。 尽管这仅仅是一个小范围调查，每个企业的具体情况也不尽相同，而成功案例所讲述的做法仅能说明在具体情况下使用者认为最合适的某种实施方式，（实际上，他们的做法都是迥异的），但通过了解其他人如何实施Scrum（无论成功也好，失败也罢），我们都可以从中汲取营养。正如Mike Cohn（《敏捷估计与规划》和《User Stories Applied for Agile Software Development》的作者）在《Scrum and XP from the Trenches》一书的代序中所说的：“我们应该了解的是哪些是优秀的实践，它们的应用范围是什么……在读过足够多成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻”。出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下： 在交流中谈到的主要问题包括： 1. 在项目中使用Scrum的原因是什么？ 2. 在实施Scrum时采用了怎样的路线，为什么这样做？ 3. 在实施时遇到的最大的困难是什么，你又是如何解决的？ 4. 实施Scrum以后，给项目、公司带来了哪些收益？ 5. Scrum实施为何遭遇失败？ Q1. 在项目中使用Scrum的原因是什么？ 璎珞天色：
需求变化太快；产品路线图不明；提高效率；增强交流；尽快让业务部门看到结果。kaverjody： 由于当前组织中使用的瀑布开发模型所固有的一些缺陷，以及我们研发部门当前的一些问题，沿用当前的方法无法有效地解决问题或改变现状。上层经过研究论证后决定采用Scrum模式，同时通过其他的一些手段辅助，来解决当前的这些问题。包括交付新的软件发布版本时间太长、软件维护效率低成本高，等等。 张汉东： 我在07年10月份到NibiruTech的时候，初次接触敏捷。当时团队内部普遍的敏捷做法是每天按时召开的例会。当时我不太明白这个例会有什么作用？一直到11月底，强烈的好奇心让我想搞清楚这个问题。于是我找到了Scrum。因为创业团队嘛，刚开始项目管理方面只是用Trac 和我们公司自己写的管理系统。Scrum先进的思想让我们当时的管理现状黯然失色。于是我就决心在公司推广Scrum。 Q2. 在实施Scrum时采用了怎样的路线，为什么这样做？ 璎珞天色： 我们不是采用纯粹的Scrum，而是将Agile中的很多理念，包括XP的部分做法，然后结合现有的开发环境与要求，用Scrum的回顾不断地做改进，从而趟出自己的一条路。如果这个Sprint 我们回顾时觉得自己代码Review（审查）做的不好，下个Sprint就会引入新的代码Review 机制。这个Sprint觉得重复性的bug较多，下个Sprint就会引入缺陷预防机制。 我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进： 06年3月——06年6月（1个团队，8人左右采用） 06年6月——07年12月（3个团队，25人左右采用） 07年12月——08年1月（一个部门，6个团队，50人左右采用） 08年1月——至今（异地开发，原有团队的Scrum继续走下去。异地的配合方式，工具，流程等建设中……）
https://www.doczj.com/doc/4e8991825.html, 个人管理－使用Scrum来敏捷自己 每个人都有自己的生活和自己的职业或事业，如果把经营个人成长作为一个项目来看，那么在这个个人管理项目中，我们每个人都是这个项目的管理者和执行者。 Scrum敏捷开发方法 如果你是一名开发人员，那么现在还不知道Scrum方法，那么你就out了。Scrum是一种现在普遍流行并且很好的一种基于管理为主的敏捷项目开发方法。我之前blog中全面概要的介绍了一下Scrum方法，如果你不熟悉的而又想了解下面内容，请你最好去去仔细看看我这篇文章《流程－从IT方法论来谈Scrum》，因为下面我将描述我们如何基于Scrum方法来进行个人管理项目的执行。 价值观 在Agile Software Development with Scrum一书中指出，Scrum的核心价值观是：承诺、专注、公开、敬重和勇气，它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则，这些价值观对个人管理依然非常有效。 1. 承诺（Commitment）：我们是否经常暗下决心，一定要戒掉游戏，一定要完成这 个任务，但是最后是不是仍旧还存在脑子里。如果你有这种现象，那么你需要做的就是自己对自己承诺，自己相信自己，如果自己都不能相信自己，那么谁又能相信你呢？ 2. 专注（Focus）：要事第一，对一件事情投入100％去做好 3. 公开（Openness）：有人说，能力就像怀孕一样，时间久了才能看出来，你个人 的学习、个人的Open都需要公开的表达才能让别人知道 4. 敬重（Respect）：三人行必有我师，空杯心态，尊重每一个人，向不同的学习
一、Scrum开发流程介绍 SCRUM 方法是由Ken Schwaber 和Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM 方法最初实践于Easel 公司(1993 年) ，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。SCRUM 提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master 、SCRUM Team 、Demo 等模式已被PLOP 作为组织和过程模式（Organizational and Process Pattern）的标准。 SCRUM 的基本假设是：开发软件就像开发新产品，无法一开始就能定义Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。Scrum 有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进，因此，SCRUM 非常适用于产品开发项目。 SCRUM 开发流程通常以1-6 周为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于每个周期后交付成果，团队每天用15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做scrum meeting。 SCRUM 较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。SCRUM方法的开发过程包括三个过程：(1) 计划和体系结构设计（确定性过程）Backlog；(2) Sprint（经验性过程）(3) 交付和巩固（确定性过程）SCRUM 过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint 期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。SCRUM 对过程的管理有很多独特的方法。SCRUM 在实践中大大提高了生产率（据软件生产率组织的Capers Jones 称可提高 6 倍）。 名词解释: 1、SCRUM Meeting:团队每天用15 分钟开会检视每个成员的进度与计划，了 解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做
Copyright ? 2010 https://www.doczj.com/doc/4e8991825.html, 专业的敏捷开发社区 Scrum 中文网 Scrum介绍 Scrum中文网 https://www.doczj.com/doc/4e8991825.html, 版权说明：本文部分资料及图片翻译自Pete Deemer 的Introduction to Scrum for Managers and Executives 以及Mike Cohn 的An Introduction to Scrum.
专业的敏捷开发社区 Scrum 中文网 许多企业面临的问题与挑战 ? 产品投放市场的时间太慢 ? 项目失败的比例高的离谱 ? 投资回报低，经常失败 ? 对变化与变更的响应，难度大且成本高 ? 客户体验及客户为导向很差 ? 软件质量不过关 ? 生产力需要大幅提高 ? 员工士气，动力及责任感很低 ? 需要普遍的微观管理 ? 人员流失率特别高 ......
专业的敏捷开发社区 Scrum 中文网 越来越多的企业开始使用Scrum 解决这些问题 ?Google ?IBM ?Nokia ?Siemens ?Philips ?Accenture ?Sun ?UbisoB ?Bleum ?SAP ? Microsoft ? Infosys ? Oracle ? Wipro ? Motorola ? Yahoo! ? Schneider ? Agilent ? Irdeto ? Double Click ? Autodesk ? Tencent ? Plenware ? Trendmicro ? Moody ’s ? StarCite
专业的敏捷开发社区 Scrum 中文网 哪些类型的项目已经在使用Scrum ?大型企业级软件项目 ?商业软件产品 ?消费者软件项目/大型网站 ?美国FDA批准的应用于X射线和MRI的软件 ?高可靠性系统（99.9999％以上） ?财务支付系统 ?智能家居项目 ?战斗机项目 ?大型数据库应用 ?嵌入式电信系统 ?手机项目 ?CMMI5级的组织 ?多地点同步开发 ?支撑和维护项目 ?非软件项目 ? ……
敏捷开发简介 2009-04-21 17:46:34.0 来源:https://www.doczj.com/doc/4e8991825.html, 关键词：Scrum精益开发敏捷开发 在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐，在全球一百强的企业中，敏捷也已大行其道，受到许多资深项目管理者和开发人员的推崇。欧美软件企业中，有近半企业已采用敏捷方法进行开发。大多数尚未应用敏捷的企业，也都对其有所了解，而且很多在计划实施。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。例如，腾讯内部几乎所有的开发团队都在实施敏捷。 敏捷方法给这些企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3-10倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到响应的提高。敏捷的成功来源于其方法本身的适用性和团队对它的深入理解和合理运用。下面我们就对敏捷开发做一个简单的介绍和讨论。 敏捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等。所有这些方法都具有以下共同特征，它们也是敏捷开发的原则和方法：1.迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周 期持续的时间一般较短，通常为一到六周。 2.增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使 用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。3.开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化 和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。 4.持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候 集成，有些项目则每天都在这么做。 5.开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给 人。 简史 许多人认为，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。但是，实际上敏捷方法，特别是迭代和增量开发方法（IID）起源于20世纪30年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是20世纪60年代初的美国航天局水星计划。在这个项目中，一些极限编程方法如测试先行等也被使用。此后，迭代和增量开发被IBM联邦系统部（FSD）和沃森研究中心（Watson Research Center）采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中，温斯顿.罗伊斯（Winston Royce）建议在一个项目中使用两次瀑布模式，也就是使用两次迭代。 20世纪70年代，最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。迭代和增量开发从此开始稳步发展，越来越多的项目开始使用这种开发模式。在1976年，Tom Gilb在他的著作《软件度量》（“Soft ware Metrics”）一书中阐述了他的迭代和增量开发实践，这可能就是第一部阐述这种方法的书籍。迭代和增量开发的另一次出色发挥，是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。改项目由IBM联邦系统部（IBM FSD）在1977至1980年完成。一些典型的敏捷做法，如使用8个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。 20世纪80年代，更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型（Spiral model）。80年代初，在美国国防部发生
ScrumWorks 使用简介 1.ScrumWroks客户端支持两种模式：一种是WEB客户端登录，在浏览器中输入： http://172.20.32.72:8080/scrumworks/login； 2.另一种是运行JAVA客户端程序，本机需要提前安装jdk1.6；点击“运行”－>“cmd” －>“javaws http://172.20.32.72:8080/scrumworks/jnlp/scrumworkspro.jnlp”。默认的用户名和密码是：administrator, password； 3.登录用户名为姓名全拼，密码是6个1。 1.JAVA客户端简介 JAVA客户端允许用户操作所有的Scrum数据，譬如添加、修改、删除、移动Backlog条目，从Excel中导入或导出数据到Execl，后台数据备份，阻碍(Impediment)管理等。
JAVA客户端桌面视图： 右侧是未分配的Product Backlog，通过Release Version进行分类。 左侧是以时间排序的Sprint列表以及对应的Sprint Backlog。可以查看多个团队的迭代列表。 左侧的Backlog和右侧的Backlog可以根据需要，用鼠标来回拖动，非常方便。 Web客户端提供了一个轻量级的基于浏览器的访问方式，可以从任何一台装有Web浏览器的设备上访问。它提供了一个非常个性化的总结性的Web页面，不仅有Sprint 的Burndown Chart，还单独区分“用户自己的任务”、“全部任务”及“所有阻塞”, 方便单个用户更新任务状态、剩余工作量，添加备注，查看阻碍等。 简单高效的Sprint管理 ScrumWorks Basic提供了一个单独的Sprint管理接口，让我们的每个Sprint 都变得有条不紊。 每次新开一个Sprint时，会有一个单独的对话框，只需要输入起止时间、Sprint 名称、Sprint目标，以及选择对应的Scrum 团队即可。在Scrum开发模式下，为每个Sprint起一个名字，不但可以增加团队软件开发的乐趣，提高大家的参与程度，还可以记录下Scrum Team当时的心情，这点非常重要，而ScrumWorks Basic正好提供了这个接口。列举我们的几个Sprint名称，创意来自于《加里森敢死队》： ?Sprint1---"兵不厌诈（the Big Con）" 因为大家第一次采用Scrum, 对这个Agile流程都很期待，同时呢，对于怎么做，如何用，还很模糊 ?Sprint2---"越狱记（Breakout） 经过了第一个Sprint后，大家干劲十足，士气高涨，认为我们可以在第 二个Sprint取得重大突破（breakout） ?Sprint3---"虎口余生（Hours to doom day）" 这个Sprint里面有很多技术难点需要破解，如果解决不了，那么后面的 工作就无法进行，将是非常关键的一次攻坚战。 ?Sprint4---"大结局(The Big End)" 这次计划会议，作为Scrum Master，自己因为有事没有参加，汗！但大 家认为工作基本差不多可以做完了，起了个结局的名字。 每天开站立例会时，可以把如下图所示的Sprint明细窗口用投影仪直接投放到墙上。让大家可以看到Sprint目标、Burndown Chart、Sprint Backlog 条目的状态及剩余时间等，提高沟通的效率和紧迫感。
指南 Scrum Scrum指南 2010年2月 Scrum由Ken Schwaber和Jeff Sutherland开发并维护 版权说明：本文由社区志愿者翻译，版权归原著者所有，Scrum中文网仅对其中的用词进行了统一和部分错误进行了更正。 概要 Scrum基于业界认可的最佳实践，这些实践已在过去的几十年被使用并证实有效。之后，Scrum被置于基于经验过程的理论中。正如Jim Coplien一次对Jeff所说：“每个人都会喜欢Scrum；因为这是当我们被逼到墙角时的自然反应。” 人 在千千万万对Scrum做出贡献的人中，我们要特别感谢那些在其最初10年提供帮助的人们。首先，要提到Jeff Sutherland及与之工作的Jeff McKenna，Ken Schwaber和Mike Smith 还有Chris Martin。Scrum在1995年的OOPSLA上首次被正式介绍和发布。在之后5年中，Mike Beedle和Martine Devos做出了重大贡献。还有所有其他人，没有你们的帮助，Scrum不会被提炼至今天的高度。 历史 在软件开发的世界中，Scrum的历史已经算是很长了。我们对首批尝试和提炼Scrum的公司：Individual，Inc.，、Fidelity Investments和IDX（现在的GE医疗）表示致敬。目标 自从上世纪90年代初期，Scrum方法就已经应用于开发复杂的产品。本篇文章介绍了如何应用Scrum构建产品。Scrum不是一种过程，也不是一项构建产品的技术，而是一个框架，在这个框架里可以应用各种过程和技术。Scrum的作用就是让开发实践方法的相对功效显现出来以便随时改进，同时也为开发复杂产品提供了框架。 Scrum理论 Scrum是以经验过程控制理论为依据，采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum的三大支柱支撑起每个经验过程控制的实现。
SCRUM敏捷管理知识 一、什么是scrum Scrum是一种用于开发和维持复杂产品框架，是一种增量、迭代开发过程。在这个框架中，整个开发过程由若干个短迭代周期构成，一种短迭代周期称为一种Sprint，每个Sprint 建议长度是2到4周(互联网产品研发可以使用1周Sprint)。在Scrum中，使用产品Backlog 来管理产品需求，产品backlog是一种按照商业价值排序需求列表，列表条目体现形式普通为顾客故事。Scrum团队总是先开发对客户具备较高价值需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级需求进行开发。挑选需求在Sprint筹划会议上通过讨论、分析和估算得到相应任务列表，咱们称它为Sprintbacklog。在每个迭代结束时，Scrum团队将递交潜在可交付产品增量。Scrum来源于软件开发项目，但它合用于任何复杂或是创新性项目。 Scrum流程如下图： SCRUM框架涉及3个角色、3个工件、5个活动、5个价值，详细阐明如下： 3个角色 1.产品负责人（ProductOwner） 2.ScrumMaster 3.Scrum团队
3个工件 1.产品Backlog（ProductBacklog） 2.SprintBacklog 3.产品增量（Increment） 5个活动 1.产品Backlog梳理睬议（ProductBacklogRefinement） 2.Sprint筹划会议（SprintPlanningMeeting） 3.每日站会（DailyScrumMeeting） 4.Sprint评审会议（SprintReviewMeeting） 5.Sprint回顾会议（SprintRetrospectiveMeeting） 5个价值 1.承诺–乐意对目的做出承诺 2.专注–把你心思和能力都用到你承诺工作上去 3.开放–Scrum把项目中一切开放给每个人看 4.尊重–每个人均有她独特背景和经验 5.勇气–有勇气做出承诺，履行承诺，接受别人尊重 SCRUM理论基本 Scrum以经验性过程控制理论（经验主义）做为理论基本过程。经验主义主张知识源于经验,以及基于已知东西做决定。Scrum采用迭代、增量办法来优化可预见性并控制风险。Scrum三大支柱支撑起每个经验性过程控制实现:透明性、检查和适应。Scrum三大支柱如下：第一：透明性（Transparency） 透明度是指，在软件开发过程各个环节保持高度可见性，影响交付成果各个方面对于参加交付所有人、管理生产成果人保持透明。管理生产成果人不但要可以看到过程这些方面，并且必要理解她们看到内容。也就是说，当某个人在检查一种过程，并确信某一种任务已经完毕时，这个完毕必要等同于她们对完毕定义。
Scrum指南 Scrum的权威指南: 游戏规则 2013年7月由Ken Schwaber和Jeff Sutherland开发并维护
目录 Scrum指南的目的 (3) Scrum的定义 (3) Scrum理论 (3) 透明性 (3) 检视 (4) 调整 (4) Scrum团队 (4) 产品负责人 (4) 开发团队 (5) Scrum Master (5) Scrum事件 (6) Sprint (7) Sprint计划会议 (8) 每日Scrum站会 (9) Sprint评审会议 (9) Sprint回顾会议 (10) Scrum工件 (11) 产品待办列表 (11) Sprint待办列表 (12) 增量 (12) 工件的透明性 (12) “完成”的定义 (13) 结束语 (13) 致谢 (13) 人们 (14) 历史 (14) 翻译 (14) ?2014 https://www.doczj.com/doc/4e8991825.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Scrum指南的目的 Scrum是用于开发和支持复杂产品的框架。这份指南包含了Scrum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织到一起的规则。Ken Schwaber和Jeff Sutherland创造了Scrum，Scrum指南也由他们撰写提供。他们是Scrum指南的后盾。 Scrum的定义 Scrum: Scrum是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。 Scrum是： ?轻量级的 ?容易理解的 ?难以精通的 自上世纪90年代初期以来，Scrum就已经应用于管理复杂产品的开发。Scrum不是开发产品的一种流程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。Scrum能使产品管理和开发实践的相对功效（relative efficacy）显现出来，以便进行改进。 Scrum框架由Scrum团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的，对Scrum的成功实施和运用都至关重要。 Scrum的规则把事件、角色和工件组织在一起，管理着它们之间的关系和交互。Scrum 的规则会贯穿这份文档。 实施Scrum的方案根据情况不同而不同，在这里不作介绍。 Scrum理论 Scrum基于经验型流程控制理论，或者称为经验主义。经验主义主张知识源于经验，而决策基于已知的事物。Scrum采用迭代增量式的方法来优化可预测性和管理风险。 透明性、检视、调整是经验型流程的三大支柱，支撑起每个经验型控制流程的实施。 透明性 流程中的关键环节必须为那些对产出负责的人可见。要拥有透明性，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事情有统一的理解。 例如： ?2014 https://www.doczj.com/doc/4e8991825.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
?Sprint 计划会议1：原始需求者、产品负责人及团队一起，确定任务优先级，定出Sprint 目标和既定产品Backlog。?Sprint 计划会议2：团队将既定产品Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。?Scrum 每日例会：项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在15 分钟内。?Sprint 验收会议：由原始需求者或产品负责人断定实际所发布的功能是否与既定的Sprint 目标一致。 ?Sprint 回顾会议：项目团队分析Sprint中的成功经验和所遇到的障碍。 整个Sprint的周期（时间盒）确定为10天（两周），具体的时间安排为： ?Sprint会议（0.5天） ?开发（8天） ?验收&总结（0.5天） ?技术提升日（1天），自主学习技术 1、需求收集 1.1 需求的分类 需求可与分为业务团队的，也可以包括团度内部的，比如性能优化。 1.2 需求提交模板 ?–任务 ?–可用性问题（Bug） ?–性能问题 ?–概念想法 注意：即使是概念性的想法，目前技术上无法实现的想法都可以收集。
②优先级可从以下五种情况中选择 ?–特别的严重 ?–非常重要 ?–很重要 ?–普通 ?–低 注意：切忌将所有的任务的优先级都设置的非常的高，这里不提供非常紧急这样的表述。我们只会根据重要程度去执行任务，所以紧急的任务需要业务部门及需求方尽早的提出。 ③需求类型可以是两种类型 ?–详细需求 ?–毛坯需求 注意：我们的需求并不是要求一定要完整的，及时是一些非常毛坯的需求，也可以提交过来，毛坯的需求由产品负责人进行分析和梳理，暂不清楚的可选择搁置。 ④需求标题有自己进行书写，但是需要遵守的规范是采用动宾短语格式。 比如：―导出+CN酒店每天的PV、UV等流量数据‖ 注意：这里的需求内容一定是站长使用者角度是提出的，切勿出现专业的程序方面的表述：如添加一个导出的按钮。还有需要注意的是动词切忌使用大而宽泛的词，比如―管理‖，类似―管理关键词‖这样的需求是严格避免的，这样会使得要开发的内容变得没有清晰的边界。 ⑤详细描述需要按照用户故事的格式进行书写。具体用户故事格式的要求如下： 用户故事是从用户的角度来描述用户渴望得到的功能。需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。一个好的用户故事包括三个要素： ?角色：谁要使用这个功能。 ?活动：需要完成什么样的功能。 ?商业价值：为什么需要这个功能，这个功能带来什么样的价值。
1什么是SCRUM 一个轻量级的软件开发方法 Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程.。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。 一个简单的开发框架 图表 1 一个简单的开发框架 Scrum由三个角色，六个时间箱，四个工件组成： 三个角色： 1. 产品负责人（Product Owner） 2. Scrum Master 3. Scrum团队 六个时间箱: 1. Sprint 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最早由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。之后，Scrum成为领先的敏捷开发方法之一，目前世界上有超过500家公司在使用Scrum。 2Scrum三个角色及其职责介绍 每个Scrum团队包括3个角色：产品负责人（Product Owner）, ScrumMaster和 Scrum 团队。产品负责人 产品负责人的职责： 确定产品的功能，负责维护产品Backlog。 决定产品的发布日期和发布内容。 为产品的投资回报率(ROI)负责。 根据市场价值确定功能优先级。 在每个Sprint开始前调整功能和调整功能优先级。 在Sprint结束时接受或拒绝接受开发团队的工作成果。 产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。 为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人
目的 针对我们目前的现状： ●整体比较松散，相互之间的协作和有效的沟通缺乏 ●事情繁杂，虽然疲于奔命但效率却不高 ●员工自身缺乏自组织性，纪律性，规范性，计划性和责任性 ●员工工作效率不高且有反复性和重复性 需要一个统一的过程和模型来约束，规范和引导大家，scrum也许能有一些作用，但任何事物的都有其优缺点，关键看我们如何使用它，任何新的事物的引入都会有一个适应期，甚至在开始会有困难南，但只要终点不变，目标不变，就要坚持，贵在坚持。 Srum的介绍 Scrum属于敏捷方法(Alile)的一种，虽然Scrum最初只应用于软件开发，但目前它也广泛成功地应用于其他产业。现在Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。 其实scrum是一个很复杂的方法和过程，需要整本书来介绍，但可以归结为4个价值系统和12条指导原则 四个价值： （1）较之于过程和工具，更注重人及其相互作用的价值。
（2）较之于无所不及的各类文档，更注重可运行的软件的价值。 （3）较之于合同谈判，更注重与客户合作的价值。 （4）较之于按计划行事，更注重响应需求变化的价值。 Agile方法的指导原则： （1）在快速不断地交付用户可运行软件的过程中，将使用户满意放在第一位。 （2）以积极的态度对待需求的变化（不管该变化出现在开发早期还是后期）。Agile过程紧密围绕变化展开并利用变化来实现客户的竞争优势。 （3）以几周到几个月为周期，尽快、不断地交付可运行的软件供用户使用。 （4）在项目过程中，业务人员和开发人员最好能一起工作。 （5）以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任。 （6）在项目组中，最有用、最有效的信息沟通手段是面对面的交谈。 （7）项目进度度量的首要依据是可运行的软件。 （8）Agile过程高度重视可持续开发。项目发起者、开发者和用户应能始终保持步调一致。 （9）应时刻关注技术上的精益求精和设计的合理，这样能提高软件的快速应变力。 （10）简单化（尽可能减少不必要工作的艺术）是基本原则。
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之间的桥梁,同时推动双方的合作.主要的作用在
S C R U M敏捷开发基础及失败成功案例分析 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998
什么是敏捷开发方法什么是SCRUM 有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。 那么，敏捷这个词到底由何而来呢在九十世纪中期，涌现了一批软件行业的激进人士，他们反对那些以过程为本的重型软件开发方法（例如：传统的瀑布开发方法）。在2001年，17位软件业界的专家们齐聚一堂，讨论正在兴起的轻量级开发方法（Lightweight methods）。专家们给这类轻量级的方法学起了一个新的名字叫做敏捷，并发布了敏捷开发者宣言。 敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。 敏捷开发方法是这些轻量级方法的总称，它旗下有很多具体的开发过程和方法。主要的有：极限编程（XP）、特征驱动软件开发（FDD）、SCRUM开发方法等等。SCRUM开发方法是由Jeff Sutherland在1993年创立，Jeff也是制定敏捷宣言的17位专家之一。SCRUM借用了橄榄球运动中的术语——一个团队拿球向前冲。 严格的说，SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中，融入敏捷开发的精神和思想，就被称作SCRUM开发方法。SCRUM是一个什么样的开发框架呢简单说，它由三个角色（Role），三种会议（Ceremonie），三项工件（Artifact）组成。 ·角色（Role）：产品主管（Procuct Owner），他负责项目的商业价值；SCRUM师傅（ScrumMaster），他负责团队的运转和生产；以及自组织的团队。 ·会议（Ceremonie）：迭代计划会议，每日晨会（daily scrum meetings），迭代回顾会议。