| 编辑推荐: |
| 本文来自于csdn，本文主要讲述如何采用scrum敏捷框架快速响应市场变化。 |
|
产品在面对同类型产品竞争时,快速响应市场是最核心的竞争力;尤其是在互联网环境下的产品,市场机遇稍纵即逝,一旦不能快速响应需求,在存在可替代同类产品竞争时,用户很快就会有大批量的流失（产品的用户黏度，在于产品的很多指标，包括产品的良性互动、反馈、社交属性、心理满足等；即使产品已经让用户“离不开你”，你也一定不希望给竞争对手机会来超越自己）。
一、为什么要敏捷转型？
传统软件工程方法论，更看重流程、文档、合同范围以及遵循计划控制进度、质量、成本。其中最有代表性的是统一软件开发过程（RUP），如下图：
在RUP中，定义了4个阶段、9大核心工作流、六个最佳实践、10大要素。通过严格的流程、输入输出的文档，严格管理范围变更，按照计划控制产品高质量、有序、可控的开发。在传统软件工程领域，通过CMM/CMMI衡量一个组织的软件开发能力成熟度。这些类似的方法论和衡量标准是软件工程领域非常巨大的成就：让软件开发不再是依赖于特定的环境和特定人的偶然性成功，软件开发是可以预期和控制的。核心思想就是将复杂的软件开发过程分解成各个方面，通过流程、输入/输出文档、规范的审核、评审制度，确保在指定的框架下，具备特定技能的人员角色，按照流程的活动，规范的生产工件，软件产品可以可控、可重复的生产出来。
传统软件工程框架，优点巨大，但是缺点也一样明显。如下：
1，重量级的方法论实施难度大，在小型组织中投入过大，生产率低下；（虽然大都支持裁剪，但是裁剪意味着降低质量或者降低过程的可控性。）
2，重量级的方法论天然就是风险厌恶型的，任何变化都要付出巨大的代价和时间成本，创新变得那么艰难。
3，传统的软件工程框架不是不能接受需求的变化，只是需求变化的影响大，流程响应缓慢，不能快速响应。（比如RUP的6条最佳实践中，有管理需求、控制变更，这两条都是针对需求变更的，可见有多么不欢迎需求变更了。）
如果组织想要改变这种状态，那么不妨来试试敏捷方法论。说到敏捷，我们先来看看敏捷宣言：
1.个体和互动 高于 流程和工具
2.工作的软件 高于 尽的文档
3.客户合作 高于 合同谈判
4.响应变化 高于 遵循计划
不同于传统软件工程方法论，敏捷强调人、强调合作，强调快速响应变化。敏捷方法通常是轻量级的方法，基于简单的流程，高素质的团队成员，经过验证的高效的优秀实践，有效快速的响应产品开发中的需求变化，并保证持续的交付能力。
敏捷的目的并不是减少工作量，并不是不写文档，不遵守流程，懒惰只会让你的产品一团糟；
敏捷的目的并不是不用计划，脚踏西瓜皮，滑到哪里是哪里，没有那个公司的高层能够忍受他完全不知道他的研发团队在干嘛，也没有团队可以稀里糊涂成功；
敏捷的目的是减少僵化的模式，由团队自己选择合适、高效的方式解决团队面对的问题；
敏捷的目的是优化流程，尽可能快的响应需求的变化，将团队的注意力集中在使产品具有更高价值的功能的实现上。
那么，如果你的组织面对激烈的竞争，或者希望快速占领市场，需要不断创新，需要快速响应市场需求，不妨让你的团队更敏捷一些吧。
二、为什么选择scrum？
敏捷的框架有很多，scrum有什么特点，有什么优势？下面选择业界影响比较大，比较有名的敏捷框架来简单比较分析：XP（极限编程）、scrum、精益软件开发。
这三个代表性的敏捷框架，差别极大。XP是高度定义的，通过相互依赖、相互支撑的13个核心实践，共同协作，完成软件产品开发；精益软件则是定义出基本的七大原则，软件研发团队，根据自身的情况，在指导原则下，自由选择实践，完成软件产品开发；scrum则是定义简单的角色、流程、活动实践，在此基础上，由团队逐步选择优化提升，形成适应组织的研发过程实践。
下面从实施难易程度、获取支持的难易程度来对比一下三种框架；
定义了完整的核心实践，团队可以直接模仿使用，但是由于核心实践之间，本身相互依赖，缺一不可，一个环节出现问题就会有连锁反应，这导致对团队成员的技术能力、素质、协作等要求非常高，只有已经非常优秀的团队才能尝试XP，这也导致组织敏捷转型时甚少有敢于直接尝试XP的。（这不是说XP不够优秀，只是我们不够优秀而已；相信即使你没有做过XP，也一定听说过她；而且你一定接触过因XP而流行起来的各种实践：测试驱动开发、结对编程、持续集成、重构等；还有所有程序猿的终极梦想：每周40小时工作制；）
精益软件开发与XP则完全相反，她完全不定义具体的实践，敏捷团队可以任意选择实践，只要证明实际的过程与其原则思想保持一致，任何实践都可以采用。这灵活度很高，但是整个研发过程、实践都需要根据环境从无到有的建设，这显然不是个很容易的事情。
scrum由于定义了简单的角色、流程、活动实践，敏捷团队可以直接简单上手，在一个个冲刺中逐步优化，一步步前进。（比较类似于以架构为中心，基于框架的开发，易于上手、可扩展。^_^）
敏捷的各种方法论、框架之间可以相互借鉴，scrum一样可以引入XP的实践，精益软件开发也可以使用scrum的活动，没有谁一定比谁优秀，只是scrum在实施学习曲线、转型过渡上都相对平滑，易于获得公司高层和团队的支持，更容易转型成功。
三、scrum基本框架
scrum的基本框架非常的简单：
1，三个角色：产品负责人、scrum教练、团队<高度自治的团队>；
2，四个活动：sprint计划会议、每日站会、sprint评审会议、sprint回顾会议；
3，三个物件：产品待办列表、sprint 待办列表、燃尽图；
4，五个价值观：承诺、专注、开放、尊重、勇气；
基本流程也很简单，如下图：
流程简要描述如下：
产品发布计划确定以后，进入产品研发阶段，产品负责人收集各方信息，排定优先级，制定产品待办列表；产品负责人、scrum教练、团队成员在冲刺计划会议上，澄清需求，根据团队的实际产能确定冲刺待办列表，分解任务，团队成员认领任务；进入为期1-4周的冲刺阶段，scrum教练指导整个团队在冲刺中分工协作完成任务；整个冲刺中，每天站会，明确冲刺任务完成情况、本日工作、遇到的障碍等；冲刺待办列表完成后，通过sprint评审会议，向相关人员演示产品（作为出口评审），审视通过后，形成增量产品成果发布；冲刺最后，通过回顾会，团队分析讨论优缺点，制定改进计划用于在下个冲刺中逐步优化研发过程。
四、scrum如何组织、计划、控制、改进：
scrum框架是如此简单，但实际上要采用scrum做好产品远不是如此容易。scrum框架是刨除了管理或者说默认团队各角色具备高度的管理和自我管理能力的。如果你向公司高层推荐使用scrum来做敏捷转型，但是你告诉他scrum不管风险、质量、进度、成本，那么你不会得到哪怕一指甲盖大的支持；而没有高层的支持，还谈什么敏捷转型呢？
那么，scrum如何开展组织、计划、控制、改进这些活动呢？
组织:
组织就是将团队全部成员整合成一个协作的系统，互相合作完成任务、实现目标。传统的组织方式的核心是：职位、职责、负责，是有明显负责层级关系的，有清晰的自上而下分解，自下而上的负责。scrum组织的方式是扁平的，没有层级负责关系，只是通过角色划分各自需要完成的任务，团队成员更专注于自身角色的工作，同时共同为产品负责。这种组织方式，通过透明公开的信息，全员负责，激发所有人员都自发思考、协作，采用更高质量、高效率的方式完成产品任务。（目标管理总是能激发team的主观能动性，使团队具备更高的创造性和更好的效率。）（宝剑双锋，高收益伴随着高风险，高风险带来高收益；必须要有这个认识！）
scrum角色及主要专注的工作：（定义来源于书本）
产品负责人 ProductOwner：负责维护产品订单的人，代表利益相关者的利益。（这是明显受到PMP影响的一个定义，希望兼顾所有干系人的利益。但是实际上，产品负责人并不是谁的代表，产品负责人专注于定义更优秀的产品，关注于软件产品在公司整个运营中更大的价值；同时产品负责人是产品团队的第一道防火墙，是屏蔽干扰项，让团队更专注于产品本身的首要保证。）
Scrum教练 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。（直白点说，就是协调指导团队更好的实践scrum，推动过程不断优化。）
开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。（自我管理、主动协作是衡量开发团队的重要标准。）
计划：
计划在所有管理活动中是处于最首位的，同时是最普遍的。可以说，如果没有计划一切都是虚无缥缈的妄想。传统管理活动中，计划由产品经理（或项目经理）统一制定，然后统一协调各个人员的计划安排等；但是scrum的团队是自管理的，计划不再由谁统一制定，而是团队成员自己制定，自己管理；sprint计划会议中，team成员都参与，完成用户故事的拆解，形成小的、可度量的task，识别task之间的相互依赖，成员领取任务，共同协作排定各自计划。
控制：
控制就是保证计划保质保量完成；传统管理活动中，由产品经理（或项目经理）来完成团队的质量、进度、成本等控制，不管是采用现场控制、反馈控制、关键点控制还是其他各种控制方式，归根结底就是：检查、检查、检查，检查是否出现问题，是否需要纠正，以及决定措施。而scrum的团队是自管理的，控制不来源于检查，而是来自于自我管理、自我控制；从sprint计划会议开始，其实控制就已经开始了。由于任务、计划是团队成员自己制定，在每个成员将主动领取的任务、排定的计划向团队公布是就是对团队做出承诺，而成员会自发的实现承诺。（承诺一致原理是心理学原理在生活工作中应用非常多的一个原理。这并不是scrum独创，但是这的确是一个优秀的实践）。每日站会给成员审视自己和每个人员的任务进展情况，这相当于每日都要做自我检查、控制；公开透明、抬头可见的燃尽图、任务看板，诱导成员时时可以审视任务、时时控制。scrum中，控制并不是弱化，只是采用了另一种更主动的方式。
改进：
所有管理活动优化的基础思想都脱不开戴明环的影响，scrum也不例外，scrum优化改进的特点就是每次改进一点点，积跬步以至千里。每个sprint的最后，team最重要的事情spint回顾会，这个回顾会其实核心就是两件事：1，享受sprint的成功吧；2，共同寻找可优化的二三事，用于下个sprint实践。第二点，这个就是清晰的检查、行动，只是scrum只关注切实可行的优化。（这不是说回顾会的重点是寻找改进点；其实我认为享受sprint的成功和真诚感谢表现突出的人员是更重要的事，你或许可以把优异表现专门记录入团队内部的备忘录。）
五、实施scrum中常见的坑：
scrum是非常优秀的敏捷框架，也支持你将以往的各种类型产品、项目中优秀的实践、经验引入到scrum的实践中，但是正所谓好事多磨，在实施scrum的过程中也会遇到各种各样需要我们解决的问题。下面我们来一起看看一些常见的“坑”：
1，高层领导的需求
在产品的研发中，相关高层领导总有各种各样的需求被提出来，产品负责人完全无法抵挡，导致高价值的用例总是排不进冲刺计划，一个个迭代的延后，敏捷的价值完全无法体现。这种情况恐怕是很多产品头疼的问题。
面对这个问题，产品负责人必须要有清晰的认识：产品负责人，首先是对产品负责，而不是首先对人负责。在有清晰认识的基础上，我们可以分下面步骤来处理问题：
1）首先确定是否真正理解了领导提出的需求，真正明白了这个需求的价值；产品负责人千万不能先入为主的认为：这是外行领导内行，这些需求的价值是不高的。高层领导关注产品是一件好事，他希望对产品的建设更多参与，这是求之不得的好事，他参与的越多，对产品的支持力度就会越大，这本身就对产品和团队具有很大的价值。而且，高层领导信息来源更广，对市场、公司运营、产品在公司整体运营中的价值认识本身就很高，更兼他们思考的高度、大局观通常都更优秀，产品负责人有什么理由轻易否定高层领导提出的需求呢？
2）在确实理解了高层领导提出的需求后，分析需求在产品中的价值；根据价值的高低，大概会有两种处理方式；
（如何判断需求的价值、优先级？从产品立项，产品在组织的整体运营目标中就是具有其核心价值的，是从组织整体的运营目标中拆分出来的，是承担了服务整体运营的任务的，这就是产品的基本原则来源。产品原则确定什么最重要，是对团队信仰和价值观的总结，用来指导对US价值、优先级的衡量。）
3）如果领导提出的需求具有很高的价值，那么产品负责人可以高高兴兴的记入产品待办列表，并适当提高优先级。
4）如果领导提出的需求价值有限，那么产品负责人必须慎重以对，一方面需要尽量的保护团队的注意力，一方面要尽力获取领导的支持。通常尽量预约好时间，在私下比较轻松的环境，沟通引导，将需求引导到更有价值的方向上会比较值得尝试。领导关注产品、参与产品，不管怎么样，这都值得产品负责人为此付出更多的努力，尽力获取领导的参与与支持。
产品负责人应该更积极的获取各方领导的需求，并尽量建立信任，让领导直接对产品负责人提出需求，尽量提前了解和引导需求，而不应该让领导对中间转达人提出需求，即不利于沟通和掌握需求，也难于获得信任。
2，无法完结的计划会
scrum的计划会包含很多议程，在一天会议上就达成一致并不容易；很容易就导致计划会无休无止；通常在团队初期，这个问题比较严重，大家更慎重也更不够开发。这个时候，scrum
master需要有充分的准备，一般可以将部分可以提前沟通的议题在计划会之间就完成，同时要注意议程的时间安排，明白合理性的决策标准，不能让团队试图在计划会上解决所有冲刺可能遇到的问题。
3，团队成员不具备足够的技能和自我管理能力
罗马不是一天建成的，敏捷团队的建设也需要经过充分的磨合和提升才能逐渐完善。敏捷转型中，任何一蹴而就的期望都是不现实的。
技能可以人员选择、培训等方式尽快满足要去，但是团队的自我管理能力需要逐步培养，刚开始的时候，scrum
master应该承担更多传统项目经理的任务，并在逐渐培养团队自我管理能力的同时，逐步向理想的scrum
master转变。
4，团队成员没有人监督，总有人能偷懒就偷懒，其进度和质量完全无法得到保证
scrum的管理是高度自管理的，如果结合管理理论来讲，主要采用的是：y理论、双因素理论、马斯洛需求层次理论的高级阶段、目标管理、学习型组织理论。scrum
master在初期团队普遍还不能很好自我管理的时候，承担更多管理任务；逐渐转型中，如果个别团队成员经过培养始终不能自管理，这是组织都不希望出现的情况，但是敏捷的文化本身也不是所有人都能适应，而团队的组织，最基本是将合适的人放在合适的位置，少量个别人员或许更适合其他团队，scrum
master也不能过多将注意力集中在个别人员上面，个别人员的更新或许是最好的选择。
5，站会报喜不报忧，等到问题暴露出来，已经无法收拾
scrum团队的价值观中开放、尊重；所有问题都鼓励暴露出来，所有信息公开，成员相互尊重，开放协作；团队一起完成task拆分、风险识别，在冲刺迭代中发现没有识别的任务、问题，这是团队共同需要解决的问题，不是某个人的问题。
scrummaster在团队建设初期，要特别关注这个问题，这个时候团队成员还不够开放，scrum
master要尽可能的识别问题、风险，鼓励和引导团队成员在站会中提出来，记录障碍或添加新识别的任务，大家共同协作解决。
6，项目合同金额有限，但是用户的总有各种各样的想法和要求
在固定价格的项目中，使用scrum敏捷开发，试图给用户提供更有价值的产品。这本身并没有问题，但是项目范围会随着用户的参与，不断扩大，直接导致项目成本不断攀升。
如果这个项目不是以盈利为目的的，在得到许可的范围内，接受更有价值的需求。
如果这个项目是以盈利为目的的，最好不要使用敏捷框架，踏踏实实做好范围管理、变更控制；如果慎重考虑后，采用敏捷框架来实施项目，那么需要做好合同谈判的准备，并且要明白，这已经不那么敏捷了。
六、总结：
敏捷转型不是一蹴而就的，需要足够长的过程。scrum是一个很容易上手实施敏捷转型的框架，但是在转型过程中也需要一步步逐步完善。敏捷转型并不只在于怎么做敏捷，文化、价值观的转变的才是真的转变。
|
