Scrum敏捷开发实战（1）：方法介绍
先从一则故事说起：
一天，一头猪和一只鸡在路上散步
鸡对猪说：“嘿，伙计，我们合伙开一家餐馆怎么样？”
猪看了一下鸡说：“好主意，那我们给它取什么名字呢？”
鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”
猪说：“那不行，我要全身投入，而你只是参与而已”。
这是在Scrum推出的系列故事中最有代表性的一个故事，它向我们展示了两种角色：猪和鸡。
在敏捷开发中，Scrum是一种增量迭代式的开发过程，它包含了一系列的实践和角色定义的过程骨架。
主要角色包括产品负责人（Product Owner即PO）、敏捷教练（Scrum Master即SM）、开发团队成员等，他们在项目中承担实际工作，是Scrum团队中的核心成员，扮演着“猪”类的角色，是必须要全身心投入的。
而用户、客户、老板们则代表着“鸡”类角色，他们是项目的需求方和参与者，不会为项目跟进的结果负责。
但他们对产品的意见至关重要，因此也必须考虑到他们，这就要求PO和SM必须处理好两种角色的关系，这在实际操作中是最难的一个环节。
在正式介绍Scrum之前，我们先说下传统开发和敏捷开发的对比。
一、传统开发
传统的软件开发采用的是瀑布式开发流程，它把整个开发过程分成了需求、设计、编码、测试、发布等阶段，只有前面阶段达成后再进入下一个阶段，整个过程按照事先制定的计划前进。
这种预定计划的方法，带来的问题也是显而易见的，每个阶段之间都有强烈的依赖关系，前一个阶段被视为后一个阶段的输入。
如果输入的质量不高则会严重影响后续阶段的输出质量，随即带来后续一些列阶段的停滞，最终导致开发周期拉长项目延期，甚至以失败告终；
我们的市场需求瞬息万变，很难实现产品需求明确完整的收集，项目早期的承诺也导致对后期需求的变化难以调整、代价高昂。
同时，技术的发展也日新月异，对于所定义的功能可能实现也面临着多重不确定性的因素。
所以从需求的明确性和功能实现的确定性两个维度出发，当需求的不明确性和功能实现的不确定性均超出一定范围之后，呈现出复杂系统的特征，瀑布式开发这种结构化的方法便不再适用，而敏捷开发方法便是在这样的背景下诞生。
Fix Feature，Flextime（传统开发固定范围，弹性时间）
二、敏捷开发
敏捷开发的一个核心思想的转换是，从瀑布式开发所代表的“Fix Feature, Flex time”（固定范围，弹性时间）转向“Fixtime, Flex Feature”（固定时间，弹性范围）。
Fixtime，Flex Feature（敏捷开发固定时间，弹性范围）
在市场变化和技术变化的背景下，既然市场需求和产品定义所代表的“范围”无法实现固化。
因而无法确定应该投入多少资源来完成，那不妨固定好已有资源的，以资源位约束，实现“范围”的最大实现，从“计划驱动”转向为“价值驱动”。
在敏捷开发的思维模式提出后，2001年，敏捷宣言诞生。
- 个体和交互 胜过 过程和工具；
- 可工作的软件 胜过 面面俱到的文档；
- 客户合作 胜过 合同谈判；
- 响应变化 胜过 遵循计划；
- 精益求精 胜过 简单执行。
（注意：这里的胜过不是不要做，而是当两者出现冲突的时候，我们进行选择的判断依据）。
对比瀑布式开发，敏捷开发更加贴近最终的市场环境，它有着更好的适应性，同时在敏捷宣言的指引下，更强调发挥人的价值，能更好的挖掘出团队的潜能。
敏捷开发充分发挥“人”在软件开发中的价值，强调追求有价值的产品结果，发挥每个人的主动性和创造力。
在敏捷宣言的指引下，产生了很多种敏捷开发方法，而冲刺和迭代式的“Scrum”方法，更进一步通过具体的实施手段展现“敏捷宣言”所代表的敏捷价值观。
三、Scrum介绍
Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。
Sprint则是指竭尽全力的冲刺短跑，为球队争得利益，球队队员为一个整体，按照阵型发挥各自的价值，最终的结果取决于团队的配合和取胜的决心，而不是教练在场下的指挥。
- 1986年，Scrum首次应用于产品开发，竹内弘高和野中郁次郎在 《The New New Product Development Game》文章首次提到将Scrum应用于产品开发。
- 1993年，Jeff Sutherland在首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。
- 1995年，Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。
- 2001年，敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。2002年，Ken Schwaber和MikeCohn共同创办了Scrum联盟。
Scrum敏捷开发让团队以一个整体走完全程，产品开发过程从一个精心挑选的多学科团队的不断互动中产生，团队成员从开始到结束都在一起工作，该过程不是在定义好的、高度结构化的阶段中进行的，而是在团队成员的相互作用下产生的。
四、Scrum的特点
1. 内置的不稳定性
高层通过发出一个宽泛的总体战略方向的信号来启动项目，并设置了一个极具有挑战的目标，同时赋予项目团队极大的自由来完成这个项目，这样既给团队压力，同时把团队推到墙边并把他们逼到极致发挥他们的创造力。
2. 自组织的项目团队
当项目团队被驱动到“零信息”的状态时，他们就会呈现出一种自组织的特征，这种状态存在模糊性和波动性，因此需要项目团队像初创团队一样运作，承担主动性和风险，并制定独立的议程，当一个群体表现出三个条件：自治、自我超越和异花授粉，这个群体就拥有了自组织的能力。
- 自治：公司的参与仅限于在一开始的指导、资金和道义支持，日常工作中高层很少介入，团队可以自由地设定自己的方向。
- 自我超越：项目团队全神贯注于对“极限”的永无止境的追求，从总部提出的指导方针开始，他们开始建立自己的目标，并在整个开发过程中不断提升目标。
- 异花授粉：由具有不同职能专业、思想过程和行为模式的成员组成的项目团队进行新产品研发，这种多样性孕育了新的思想和概念（这里和黑客增长理念接近，多样团队的观点碰撞，获得更具创意的实验方案）。
3. 重叠的开发阶段
在瀑布式方法下，一个项目以循序渐进的方式经历几个阶段，只有在满足了前一阶段的所有需求之后，才能从一个阶段过渡到下一个阶段。
通过一些检查点控制风险，但这种方法几乎没有为集成留下空间，某个阶段的瓶颈可能会减慢甚至停止整个开发过程。
而在整体或橄榄球方法下，这些阶段有相当大的重叠，这使得团队能够吸收整个开发过程中产生的振动或“噪音”，重叠方法加强了共同责任和合作，激发了参与和承诺。
团队必须同步进度以满足最后期限，突出了解决问题的重点，鼓励主动采取行动，发展多样化的技能，并提高对市场条件变化的敏感性。
4. 多重学习
由于项目团队的成员与外部信息来源保持密切联系，他们可以快速响应变化的市场条件。
团队成员参与一个不断尝试和犯错的过程，以减少他们必须考虑的选择的数量。他们也获得了广泛的知识和多样化的技能，这有助于他们创建一个能够快速解决一系列问题的多才多艺的团队。
5. 微妙的控制
尽管项目团队在很大程度上是独立的，但他们并不是不受控制的，管理层建立了足够的检查点，以防止不稳定、含糊不清和紧张局势演变成混乱。
与此同时，管理避免了那种损害创造力和自发性的严格控制。相反，它强调的是“自我控制”、“通过同伴压力的控制”和“通过热爱的控制”，我们统称它们为“微妙的控制”。
6. 学习的组织转移
跨层次和跨职能积累知识的动力只是学习的一个方面，项目成员也有同样强烈的动力将他们的学习成果转移给小组以外的其他人，将学习内容转移到后续的新产品开发项目或组织内的其他部门。
Scrum敏捷开发的实施让开发团队有了一定自主权，已安排好的计划很大程度上不会被打断，同时上下游相互配合，为一个共同的目标而努力，每个人都清楚团队其他人的工作内容，每天都知道项目的实时进度，团队是一个整体的存在，而不是每个人独立工作下的个体，有着很强的集体荣誉感。
但Scrum能否成功实施，关键要先获得高层的认同和理解，让高层们理解Scrum的要义、利弊，如果Scrum能带来高效、优质的开发成果。
那就在制定绩效结果并在实施过程中放权，让每个成员真正意识到项目成果是自己的事，而不是领导的事。
如果是职能型的研发团队，同时也要获得各需求方的认可和支持，分享在这种方法下对整体的收益最大化，否则可能会面临各种不理解，最终可能导致实施失败。
因此，我们要落地Scrum敏捷开发，就要做好“猪”与“鸡”两种角色之间心理上的平衡与和谐，“鸡爷爷”切不可把“小猪”们看成是一群猪八戒，空有一身本领，但好吃懒做。
“小猪”们也不可把“鸡爷爷”想象成周扒皮，只会半夜鸡叫，影响正常的开发进度。
猪和鸡双方相互理解，达到项目开展过程中的平衡点，才能让整个项目顺利的完成。
作者：周武，曾就职于腾讯、边锋，现在一家上市公司产品负责人；公众号：周武说。
本文作者@ 周武 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
