两万字谈谈如何使用 Scrum 框架进行敏捷开发

两万字谈谈如何使用Scrum框架进行敏捷开发一、前言前不久我在团队做过一段时间ScrumMaster，当ScrumMaster的实践过程中，曾经很浅略地做过一些关于迭代开发的思考和总结（《关于迭代的一些思考》，不过里面关于Scrum框架和敏捷开发大多是经验和直觉上的认知，缺少相应理论知识的理解和支持。为了更深入地理解Scrum框架和敏捷开发，春节前后以及工作之余阅读了一些关于敏捷和Scrum框架的书籍和文章，从中收获颇多；恰逢3月10、11号公司作了敏捷培训，过程中我更是获益匪浅，并且自己对于敏捷和Scrum的认知和理解在培训中得到了进一步的验证和调整。所以，在这里我将敏捷和Scrum框架的相关知识做适当的取舍、调整并整合起来（做知识的搬运工），同时也把从理论和实践所得的这些认知和理解写出来，希望能就如何使用scrum框架做敏捷开发这个主题做一个足够的阐述。注：敏捷或者Scrum框架的知识浩如烟海，难以用一篇文章将其说透说全，这里主要讲解Scrum框架的重要组成部分——角色、工件与活动；另外敏捷或者Scrum不像实打实的技术，里面很多观点都可能比较主观，希望自己认知和理解的内容能尽量客观地对其作出阐述；当然，由于知识和经验有限，如有偏颇，欢迎探讨和指正。在下一章节，我们先来谈谈一下敏捷开发，往后再继续谈Scrum框架。二、敏捷开发2.1敏捷开发的含义敏捷开发是一种从上个世纪九十年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。常言道：“天下武功，唯快不破”，此言用于形容“敏捷”的威力相当合适；但我更喜欢另一句西方谚语：“Achessnovicecandefeatamasterifmovingtwiceeachround（如果允许一个新手一次走两步，那么他就可以击败象棋大师）”。敏捷意思为快，但敏捷思想不仅仅求快，它更多强调“多快好省”，产出得多，产出得快，产出得好，同时节省各种成本，既经济又实用。它们更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。2.2敏捷开发正式诞生的标志2001年，17位软件开发人员（包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者）齐聚犹他州的雪鸟镇，共同探讨一种轻量级的开发方法。雪鸟会议上，所有的与会代表就使用『敏捷』一词概括这种新型的轻量级方法达成了共识，并签署且发表了《ManifestoforAgileSoftwareDevelopment》（即《敏捷软件开发宣言》），这成为敏捷开发正式诞生的标志，他们称自己为“敏捷联盟”。那么，究竟《敏捷软件开发宣言》都宣言了些什么呢？接下来我们仔细看看。2.3敏捷开发宣言和原则2.3.1敏捷宣言的价值观雪鸟会议上发表的《敏捷软件开发宣言》摘录如下：我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值。2.3.2敏捷宣言的原则另外，宣言中还包括以下十二条原则：我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。业务人员和开发人员必须相互合作，项目中的每一天都不例外。激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。以简洁为本，它是极力减少不必要工作量的艺术。最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效，并依此调整自身的举止表现敏捷宣言中这些价值观和原则，所谓入门容易精通难，在旁人或者入门者看来也许略显空洞，所言无物；然而，敏捷精髓的实践者们一直坚信着这些理念，觉得它们字字珠玑，所言极是。不管我们是走敏捷的哪个流派，都不妨在实践敏捷的过程中，回过头来看看这些价值观和原则，想必会常看常新，大有裨益。2.3.3其他具体的敏捷原则以下思维导图是其他具体的敏捷原则的说明。作为敏捷众多流派中的被广泛实践的Scrum流派，同时也是我工作之后的两年多时间里团队中使用的敏捷开发方式，下一章我们来初步了解一下。不过正式介绍Scrum框架之前，我想有必要先谈谈一个词——『敏捷型组织』。在实践敏捷的过程中，个人要敏捷，团队要敏捷，更重要的是组织也要敏捷，而且我认为组织的敏捷是团队和个人真正实践敏捷的重要基石。2.4敏捷型组织组织结构指的是一个组织内部团队之间相互关系的布局。它包括把员工分配到不同的部门和团队，也包括为了发号施令而安排的层次结构。各公司有不同的组织结构，职能型和矩阵型两种基本结构已经使用多年，然而一种被称为敏捷型结构的组织结构更适用于软件开发行业。我们先来看看这三种组织结构：2.4.1职能型组织2.4.1.1职能型组织的含义军队和工业界曾经使用过职能型结构的组织形式，这形式的结构按照主要目的或职能来设置部门，基本上根据员工的基本职能来组织。在技术组织内，按照职能的不同分成不同的部门，如工程部，质量保证部，运维部，项目管理部等；同时，每个部门都有自己的管理层级结构，都有自己的负责人。在工程部，工程师向工程经理汇报，工程经理向工程副总汇报；在其他部门的汇报关系类似。2.4.1.2职能型组织的优缺点这种职能型组织结构很多优点，比如所有的经理几乎都是按照层级提升的；员工在专业性方面也容易取得一致，技术相关的同事们（包括经理）很容易回答涉及技术方面的问题，整个机构都是按照专业分工来组织的，经理和工作伙伴具有同质性；职责明确、容易分配任务、更好地遵循标准规范，这种简洁性使得工作分配极为容易。当然，职能型组织结构有它的问题：缺乏单一的项目负责人；跨部门的沟通效果不佳；部门间存在情感性冲突。考虑到这些利弊，当其同质性的好处超过整体协调和所有权带来的问题的时候，可以考虑采用职能型组织结构。比如，采用瀑布式开发的组织，经常能从按职能划分的组织结构中获益。因为该结构下号与瀑布型方法中固有的阶段控制相匹配。2.4.2矩阵型组织2.4.2.1矩阵型组织的含义尽管职能型组织结构有一些不可否认的优点，但仍存在弊端。为了克服这个问题，公司甚至军事机构演化出矩阵型组织。矩阵型组织机构的主要概念是层级的两个维度。在职能型组织的每个团队有一个经理，每个团队的成员向一个老板汇报；而矩阵型组织与职能型组织相反，包括至少两个管理维度，每个团队的成员或许有两个或多个老板，比如，传统的职能组织旁边增加了项目管理团队。如上图，深蓝色标注的员工，包括项目经理1、工程师1、工程师2、质量保证工程师1、质量保证工程师2、产品1、产品2组成了一个项目团队在一起工作；深蓝色标注的员工组成一个团队；橙色标注的员工又组成另一个团队；每个团队里的项目经理对任务分配和项目进度负有责任。在更大和更复杂的组织里，许多来自不同团队的人可以属于同一个项目团队。2.4.2.2矩阵型组织的优缺点职能型组织的是三个问题：缺乏单一的项目负责人；跨部门的沟通效果不佳；部门间存在情感性冲突。而在矩阵型组织里，存在以下优点：项目团队负责解决所有的问题，承担项目的所有责任；项目组会频繁地开会和邮件沟通来解决沟通不佳的问题。同样的，矩阵型组织也有其弊端：独立贡献者向多个有不同优先级的经理汇报，压力增加；比如工程师现在工程经理和项目经理之间，工程经理让他按照标准写代码，项目经理坚持必须按时完成任务，工程师面临压力和忧虑，担心自己的表现不能让经理们满意。个人精力分散，项目团队本身也需要很多会议和邮件来维持项目的进展，占用更多的个人时间。矩阵型组织结构解决了一些问题的同时，又引入了一些新的问题。假如保持职能型和矩阵型组织结构的优点，“是否有更好的办法？”答案是“有”，这就是“敏捷型组织”。2.4.3敏捷型组织2.4.3.1敏捷型组织的含义随着从提供软件向提供服务方向的发展（SaaS——软件即服务，现在还有PaaS——平台即服务和IaaS——基础架构即服务），技术人员开始思考如何做个好的服务提供者而不是软件开发者。伴随着这一演进，人们开始思考服务的质量和可靠性。另外，敏捷开发方式的出现，还有职能型和矩阵型组织弊端的存在，使被称为敏捷型的新组织结构应运而生。我们把跨职能同时符合服务架构的组织，标示为敏捷性组织。在这种组织中，团队是完全自主管理和自给自足的。从形成概念，到研发，再到生产系统中的服务支持，团队负有全部的责任。跨职能部门的额总监、副总裁以及敏捷型团队替代了工程副总裁这样的常规管理角色。2.4.3.1敏捷型组织的优缺点敏捷性组织具有如下优点：组织边界适当变小，有效地降低情感性冲突（部门或者团队之间的互相推诿和相互抱怨）；组织人员丰富多样，提高认知性冲突（经验、技能和关系的多样性带来更优的解决方案）；冲突有好坏之分，好的冲突（认知型冲突）是健康的争辩，是团队关于该做什么或者为什么要做（以及该怎么做）而发生的冲突，它涉及更大的视角和更多的经验；坏的冲突（情感型冲突）基于角色，经常涉及该谁做，纠缠不清的基于角色的讨论往往被认为是政治性或者领地性的，如果处理不当会对团队产生不良影响。认知型冲突有助于团队扩大行动的可能范围，不同的见解和经验凑在一起有机会从多角度出发解决难题；情感型冲突会带来组织的创伤，结果会在战术和战略上限制选择，争斗关闭了我们思维的选择空间，意味着结果可能不是最佳的。通过营造开发、尊重的文化氛围，推动健康的争辩，吸纳各类人在技能和视野上互补，最大化策略的选择范围，把认知性冲突最大化，情感型冲突最小化，让团队快速成长。团队共享一个目标，荣辱与共，不再争论谁负责什么或谁应该执行哪些任务，个体对提供高质量、高可用性并能满足商业目标的服务负有更多的责任，并有能力处理产品或服务的全生命周期；团队被充分授权，有权力做出决定，高效地完成高质量的任务的动力更足，能进行产品的自主研发；团队沟通协作更为充分和顺畅，信息共享更为实时，提高团队的创造力与表现水平。敏捷性组织的缺点：敏捷性组织去除了部门传统的管理角色，比如“工程副总裁”，有组织架构调整的缓冲期；敏捷性组织需要原来团队按照组织设计中面向用户的服务重新组织。没有一个组织结构是完美的，即便敏捷型组织存在着弊端，那些正在挣扎着试图解决不良的服务支持、大量的冲突、员工自我驱动力不强和整体缺乏创新的公司来说，敏捷型组织模式是个理想的选择。我个人一个浅薄的观点：公司内部建设走“战区主战，军种主建”之路，其中的“战区”正是由相应的业务、产品，研发，测试、运维，设计等主力提供智能投顾和余额代偿服务的相关人员共同组成的敏捷型组织的阵地。敏捷的相关知识介绍到此，接下来主要是介绍Scrum框架，首先从Scrum的含义、起源和发展开始。三、Scrum含义、起源和发展3.1Scrum的原意和隐喻3.1.1Scrum英语单词的含义——原意Scrum在英语中是『英式橄榄球运动中争球』的意思，在争球过程中，两个队的前锋在球前面围成一圈，彼此的胳膊架在一起，低头争夺球权，此时球队两军对垒，剑拔弩张，环境变化很快，如果团队没有共同目标和方向，力量分散，很难抢到球。当抢到球后，必须把球往后场传递以便得分，这又需要球队作为一个整体具有高度的默契与高超的技巧才办得到。最后赛场上所有球员处于同一时间和空间，赛场的秋毫变化（球的位置、队友的位置、敌对人员的位置、观众的加油声、团队士气与人员状况、天气与球场的状况、裁判的表现和教练的