本文在上半部分以伪代码的形式讲述了Scrum
的基本框架，图（一）是对该框架的总结。如此简单的框架如何能提升组织的能力？做到什么才能保障Scrum实施的成功，并从中受益？理解和贯彻Scrum框架背后的原则是关键。
图（一）Scrum 总体框架 PPT格式大图下载链接
为了说明这些原则与Scrum 框架的对应关系，在图（一）中我们以Scrum 框架为索引，列出了相对应的原则(见图中蓝色框)，它们分别是：
产品开发过程相关的原则
高度透明
不断反馈调整
团队组织相关的原则
多功能
自组织
持续改进相关的原则
将改进嵌入开发过程
不断暴露和解决问题
以下我们将分别对这三个方面原则进行讨论，并就每个方面分析Scrum实施过程中的不良症状。
产品开发过程
Scrum 是一个经验性(empirical)的过程，透明（transparent）、检验(inspect)和调整(adapt)是它的三个支柱。Scrum的产品开发过程是高度透明和不断反馈调整的自适应过程。
需要特别强调的是，与传统开发过程相比，Scrum引入了一个根本性变化 —— 在每个固定长度的迭代周期（spirnt）产出潜在可交付的产品增量（potential
shippable product incremental - PSPI）。这是透明、检验和调整的基础，能否做到这一点是Scrum实施成功与否的试金石。
Scrum产品开发过程应该做到高度透明
透明是团队合作信任，以及对产品开发过程进行检验、调整的前提。为了做到真正的透明，Scrum开发过程中影响到最终结果的各个方面都应该是可见和可信的。在Scrum实施过程中要做到：
a) 遵循共同的框架
共同的迭代和增量开发框架为开发过程的透明提供了统一的基准，Scrum框架下的制品（Artifacts）是高度透明：
Product backlog反映了用户需求，以及它们的开发工作量、优先级和当前状态；
Sprint backlog反映了sprint的目标、工作任务和当前状态；
发布燃尽图反映了项目的整体工作进展状态；
Sprint燃尽图反映了当前sprint的进展状态
Scrum的四个标准活动（event） —— sprint 计划会议、每日Scrum 会议、sprint评审和sprint回顾进一步促进了透明。
b) 信息真实可信
透明的信息为PO和团队提供了决策依据，信息可信与否直接影响决策质量的高低。敏捷开发的透明性内建于开发活动当中，保证了其真实可靠。这些信息，即时从版本层面、迭代层面和日常工作层面，反映项目的最新状态。
信息的可信还体现在，对相同信息的一致理解。例如，当声明一个需求已经完成时，PO的预期应该和团队的理解应该是一致的，这就是完成标准定义（Defintion
of Done -- DoD），它必须清晰明确，并被严格遵循。
c) 以最高效的方式及时沟通信息
良好的沟通促进透明。团队坐在一起，面对面的交流是最高效的沟通方式；有效的会议组织能改善计划、评审以及回顾活动的效果；一个良好的可视化工作空间（如白板墙等），可以促进信息的发布和交流，具体可参见《借助信息化工作空间实现高效的团队自我管理》。总之，采取一切可能的手段改善团队内部以及团队对外的沟通。
d) 持续交付带来最可靠的透明
向客户交付产品，可以让团队得到最直接和真实的反馈，可运行的软件不会撒谎。受产品特性和团队成熟度的限制，并不是所有的团队一开始就能做到每个sprint向客户交付软件。但团队应努力让迭代的结果更接近交付的标准，并力争更频繁的实际交付，每一次交付都是对产品开发成果和团队过程能力的检验，。
Scrum开发过程中应该不断反馈调整
在传统开发过程中，团队根据目标制定计划，而后严格按照计划执行以达成目标，这是所谓定义性的开发过程。然而计划可能不合理，执行过程可能出现偏差，这都会使结果偏离预设的目标。即使计划被完美的执行，目标本身也会发生迁移，实际的业务目标和最初的设想总会有差距。如图（二）所示，定义性的开发过程对于软件开发这样复杂的活动并不适用。
图（二）定义性的开发过程
Scrum 倡导“经验性”的开发过程。如图（三）所示，在开发过程中团队不断检查和汲取反馈，调整下一步的行动，动态达成目标。经验性的开发过程让团队在复杂的市场和技术环境中更好的把握和实现业务目标，取得竞争优势。为实现有效的调整和反馈，组织要做到：
图（三）经验性的开发过程
a) 周期性的检验和调整
Scrum框架中包含多个检验和调整的反馈循环。每日Scrum会议上团队检验工作进展，和sprint目标进行比较，调整接下来的工作以更好地达成目标；Sprint评审会议上，团队演示软件，获取业务人员和客户的反馈，及时调整产品的方向以及开发计划。通过不断的检验和调整，团队和客户持续修正产品开发方向和计划，更好的实现商务目标。
b) 业务人员更紧密的参与开发过程
不管业务人员还是用户，都不可能在项目一开始就准确无误地把握产品方向和定义完整的需求，它们需要在开发过程中不断的被修订、调整和完善。如果，业务人员不参与到开发过程当中去，在项目结束时就可能会出现“团队开发的产品和业务人员的定义不符”，或者“团队开发的与当初业务人员所定义相符，但却不是业务人员和市场需要的产品了”。
业务人员参与开发过程，一方面团队能够及时获得对产品目标和需求的澄清和确认，确保双方的理解一致；另一方面，通过参与开发过程，业务人员更准确地理解客户需、把握产品目标，并做出及时的调整。
针对开发过程的不良症状分析
团队组织
通过Scrum开发过程的实施，组织更快的交付价值，更灵活的适应变化。同时，Scrum的实施对团队组织提出了新的要求。典型的Scrum
团队应该是多功能和自组织的。
团队应该是多功能的
多功能是指团队具备为客户提供端到端服务的全部技能，对于Scrum团队这意味着有能力完成从需求分析到交付产品的所有工作。如果团队为了完成一个工作要严重依赖其它部门，就无法实现真正的短迭代交付；同时，因为团队仅凭自身的努力无法获取期望的结果，就会缺乏对目标的认同和责无旁贷的责任感，也会缺乏改进的动力。为了做到团队的多功能，组织需要：
a) 创建跨职能和跨组件的团队
跨职能指团队具备承担系统分析、架构、设计、开发和测试等工作的全过程能力；跨组件指团队具备完成开发工作所需各个组件的知识，如UI，中间件，底层驱动等。
b) 拓展团队成员的知识技能
需要指出的是，多功能的团队并非指团队中的每一个人都具备所有技能，这在操作上是不实际的。Scrum对团队成员的技能要求倾向于通才型的专家（Generalizing
specialist）。团队成员具备通用软件开发知识、业务领域知识、和自己的业务专长，同时应积极寻求拓展自己的技能。这有助于成员产生更全面的思考，促进团队的协作，以及消除开发过程资源的瓶颈和等待，增加开发过程中的灵活性等。
c) 团队应长期存在
一个团队从成立到高效运作需要一个过程，能力的拓展、团队的磨合、技术实践的优化、基础设施的完善都需要时间。通常建议Scrum
团队尽可能长期存在，而不是随着特定项目或开发版本成立和解散，长期存在的团队才有长期的承诺，形成对目标的认同和坚持，并激发不断改进的动力。
Scrum团队应该自组织的
自组织团队是指，由团队而不是管理者决定“怎么做”。Scrum团队被赋予并承诺组织目标，计划、执行和监控的职责则属于团队。因决策权力的充分下放，自组织团队能够对现状做出准确和及时的响应，并最大程度发挥团队成员能动性。但，简单地对一个团队说：“从今天开始，你们就自组织吧”，不会带来期望的结果。自组织的团队的形成需要：
a) 有意义和挑战的目标
有意义的目标可以协调团队成员努力方向，增加团队的凝聚力。一个通过努力可以达成的目标可以激发团队的激情和能动性。
b) 自主完成目标的潜在能力
团队有了目标，还要有与之匹配的潜在能力配置。多功能团队是自组织的前提，团队的长期性则保障了能力拓展和提升的可持续性。
c) 明确的边界
团队的自组织需要特定的边界。没有边界约束的自组织，很难确保其在执行上与组织目标的一致。Sprint周期是时间边界；Product
Backlog是范围的边界；DoD是质量的边界。边界的存在让自组织更有序的发生，边界既是对团队的约束，也是对外界干扰的约束。有了边界的约束，可以建立外面的人对团队的信心和安全感；团队则在边界之内充分自主。
d) 良好的组织环境支持
组织环境之与团队，就像土壤之与种子。团队的自组织离不开良好组织环境的支持。面向团队而非个人的奖励和认可机制、面向结果而非过程的绩效体系、简单扁平的组织结构、以及充分的授权机制，都为团队自组织提供了良好的土壤。
针对团队组织的常见不良症状分析
持续改进
对开发过程本身的持续改进是Scrum的一部分，Scrum 实施能更好地暴露组织中存在的问题，解决这些问题是Scrum成功实施的保障，也是组织能力提升的关键。
将改进融入开发过程
检验和调整针对的不仅是产品，团队还应经常对开发过程本身进行检验和调整，持续改进是Scrum框架的有机组成部分。如图（四）所示，下面的实线框内是对所开发产品的检验与调整，这一持续循环的目的是使最终的产品更好的符合实际目标；上面的虚线框内是对开发过程的检验与调整，其目的在于不断提高团队的过程能力，和长期交付的能力。
图（四）Scrum中的两个调整与检验循环
影响过程能力的要素很多，如团队协作方式、开发流程、技术实践、基础设施等。每个sprint的回顾会议都应对以上要素进行反思和调整，为保证sprint回顾及其后续活动的有效，团队要做到：
a) 让团队成员，积极参与改进的过程
“retrospective prime directive”是回顾会议的基本指导原则，它明确的指出，回顾是为了改进开发过程，而不是针对任何个人。一个被少数人主导的回顾会议，很难达到期望的效果，创造一个安全开放的氛围，让每一个人都积极参与改进过程，是确保其有效的前提。尝试不同的形式来组织回顾会议的进程，也有助于提高成员参与的积极性，Agile
Retrospective一书提供了丰富的回顾会议的组织形式。
b) 每次聚焦有限的改进项目
一次改变太多的东西是不现实的，会导致分析不够深入彻底，执行的效果打折。每次聚焦一到两点，集中力量，积累小的改进成果。
c) 找到深层次的原因
就问题解决问题是不够的，多问几个为什么，挖掘问题背后的本质原因，这样的改进才是彻底和长久的。
d) 产生具体可执行的行动方案
光发现和分析问题还不行，要制定切实可行的方案。方案必须是具体和可执行的，可以落实到人，而不是仅停留在口头或纸面。
e) 检验改进效果
改进计划落实执行后，需要检查其效果，形成改进环。每次回顾会议的开头检查上次改进方案的执行结果，是一个比较好的做法。
f) 永远不要放弃改进的努力
Scrum的改进过程没有终结，持续改进是Scrum的一部分。
在Scrum实施中暴露并解决问题
Ken Schwaber曾经对Scrum做出一个非常好的类比，他说：“Scrum象丈母娘，她希望自己的女儿好，总是对女婿不满意，不断挑他的毛病，却从来不提供改正方案”。相似之处在于，Scrum暴露问题，却不提供解决方案，因为那是团队的责任。
Scrum没有告诉你怎么开发软件，甚至也不告诉你怎么协作，这些由团队自主决定，《敏捷开发艺术》的作者James
Shore评论“Scrum是一个有意为之的半成品”。这恰恰是Scrum的生命力所在，维持了Scrum的简洁和包容性；这也是Scrum的陷阱所在，它可能误导使用者低估Scrum实施的难度，而事实上它却对组织和团队提出了很高的要求。通过Scrum实施暴露问题，然后解决它们，这是Scrum引领团队成功的不二法门，这需要团队的勇气和智慧。
a) 尽可能暴露问题，并解决这些问题
Scrum通过透明和检验使问题更易被发现。每个迭代产生潜在可交付的产品增量，暴露了过去深藏于长开发周期中的问题；团队的直接沟通，暴露了隐藏于复杂组织结构下的问题；更少并行开始的用户需求，暴露了隐藏于大量的半成品里的问题。因此选择更短的开发周期，更直接沟通，同一时间更少的并行需求开发，都有助于问题的暴露。
没有重大的改变，就不可能有重大的不同。问题暴露了，就要去解决，不管是组织的问题、团队合作的问题、工程实践的问题、还是研发基础设施的问题，都要去解决。在解决问题的过程中，团队完善自己、提高交付能力并从Scrum实施中真正获益。
b) 技术实践必须跟上
Scrum框架中并不包含任何技术实践，当然也不排除任何技术实践。问题是在实际操作中，技术实践很容易被忽略。James
Shore在“The Decline and Fall of Agile ”中表达了对许多Scrum团队忽略技术实践的深深担忧，言辞激烈，但发人深思。Robert
C. Martin 在 “The Land that Scrum Forgot”中也旗帜鲜明的指出离开技术实践的Scrum是无法长久的，他提出如果没有技术实践的支持，更快的交付软件就意味着更快的积累技术债务，这篇文章还列举了最应该被重视的技术实践，很有参考意义。
尽管，在Scrum的框架中，由团队自主决定技术实践的采用，团队在检验和调整过程中决定是否需要技术上的改变和怎样改变。但理论和实践都已经证明Scrum的成功离不开敏捷技术实践的支持，很多团队都因技术实践未跟上而走向失败。既然这是一个必然且十分重要的选择，那么，在操作上单独去强调技术实践就十分必要。
针对持续改进的常见不良症状分析
总结
掌握自己的命运：Scrum对不同组织含义是不同的， 对一个重流程的官僚组织，它可能意味着拥抱变化、紧密的合作、充分的授权、和灵活的交付模式。而对于一个缺乏必要规范的组织，它可能意味着加强团队纪律，用明确的框架来规范和拓展当前的实践。作为一个强调经验性过程的框架，在Scrum框架的基础上，组织需要探索适合自身的实施过程，掌握自己的命运！
Scrum实施策略需要考虑所处阶段：不同阶段采用不同的策略1）初始实施时，严格遵照Scrum框架进行
2）在实施过程中加深对Scrum原则的理解，在此基础上考虑创新突破。3）当对这些原则把握自如时， Scrum的形式就不再重要了，当然这可能需要好几年的时间。Alistair
Cockburn曾引用来自日本剑道的术语“守，破，离”来描述这三个阶段。
很痛苦，但非常值得：Scrum 框架非常简单，但简单不等于容易。Scrum一定会带来巨大的改变，你要做好准备，它意味着观念的转变，权力的重新分配，技术实践的配套，基础设施的优化等。改变是困难的，过程是痛苦的，但非常值得。
| 
