1 传统软件产品研发困境

需求变更：需求变更是软件研发中经常遇到的一种情况，传统的软件研发模式属于瀑布流，后一阶段都是在前一阶段交付后，才开始实施，流程多，周期长，变更起来比较麻烦。

质量管理：传统软件的开发模式都是在开发完成后才进行测试，时间上都会比较晚，当测出来比较大的缺陷，可能导致产品无法准时上线。

员工感受：以上的各种原因如果导致产品上线延期，项目人员加班加点，会对士气造成很大的影响，员工的感受不会太好。

产生大量用不到的功能：传统的软件开发周期比较长，功能都要想好了，想全了才上，但是有些功能并不是用户想要的，根据二八法则，80%的人只用了20%的功能，很多功能花费了大量的研发时间却没有给用户带来相应的价值。

市场瞬息万变：市场需求多样化、个性化持续上升、产品创新性要求持续提升，传统软件开发流程时间长，变更流程官僚且缓慢，对变化反映速度很慢，很难适应瞬息万变的市场。

业务面临的痛点：传统开发流程中产品人员很崩溃的事情是，当你终于赶在截止日期将功能规格说明书更新完毕！不过此时的领导已经重新调整了业务方向，这个时候需要你屁颠屁颠的更新说明书，产品经理一般会崩溃，而且最后做出来的产品有可能并不符合市场需求，这个时候还不如快速实现功能，然后拿去市场验证。

2 为什么要实施敏捷开发

跑马圈地：

随着人口红利的结束，互联网由增量市场变成存量市场，同业务模式下的产品竞争加剧，稍微慢一步，就会竞争对手超越，所以在进入市场的初期，大家都求尽快的交付产品，以求达到跑马圈地的效果。

验证需求

微信之前有做过下拉拍视频这样一个功能，但是后来经过用户反馈和数据分析在下一个版本中又去掉了，可见其反应之快，如果微信团队没有实施敏捷开发，做不到这么快的反应速度，在《张小龙最新内部演讲:警惕 KPI 和流程》这篇文章中，就讲到了敏捷开发。

3 什么是敏捷

敏捷开发的价值观

敏捷开发最大的核心就就是适应变化和快速迭代，这个才是内核，其他的一系列方法论、流程、角色等都是在这个基础上衍生出来的，如果你只学习了他的方法论、流程但没有学习内核，无法带来太大的改变，就像洋务运动，不断的买西洋武器，造工厂，但是社会结构没有变，社会细胞没有变，战场上还是打不过西方列强。

基于这个核心内核，提出敏捷开发的这个群体发表了敏捷宣言（价值观）

个体交互胜过过程与工具

流程和工具是为了更好的为人服务的，而且随着时间的推移和业务的发展，以前制定的流程和工具业务无法解决现在存在的问题，这个时候就需要发挥人的主观能动性去更新流程和工具。敏捷开发鼓励团队成员进行头脑风暴，这就意味着相对于死的流程和工具，团队更看个体与个体之间的交互，强调人的主观能动性！

可工作的软件胜过繁杂的文档

传统的软件开发是阶段性的，每个阶段都需要有相应的交付物，在需求分析阶段是产品需求说明书或者规格说明书，在设计阶段是设计文档，这些文档一般都非常复杂，文字较多，结构庞大，根据这些文档做出来的产品有可能和当初的设想偏差很大，敏捷开发就鼓励可工作的软件高于繁杂的文档，比如直接用axure制作原型并进行标注就比冗长的word文档来的效率更高一些。

客户合作胜过合同谈判

这个客户是广义上的客户，并不是某个B端公司或者C端用户才是你的客户，如果你是给自己内部部门设计产品，你内部使用你产品的部门也是你的客户。

传统软件研发模式通常会用协议记录的方式把项目确定下来，然后项目团队会严格按照协议的内容去做开发，在整个过程中比较少的去和需求方沟通验证自己做的内容是否是对方想要的，但是合同是在产品还没有任何雏形，是基于大脑的想象来设计的一些条款，到最后，客户的想法会有些变化，在这种情况下，必然会产生冲突，之前的方式是我不管，既然我们已经签订合同，我就按照合同来给你开发，做出来以后你就要接受，因为我是按照合同中的约定设计条款去开发的，这是传统软件的做法，这种做法会带来一系列问题，比如双方会变得很敌对，外包的话有可能拿不到钱，如果给公司内部做，团队成员年终奖可能就飞了，敏捷开发做法就是合作大于谈判，顾客是上帝，顾客满意了才会买单，开发商才会有回头客。

响应变化胜过遵循计划文档

合作的方式尽量去响应变化，用户需要改变什么，我们就尽量配合做调整，当然也不是说来者不拒，不能说今天晚上要做功能A，明天早上起来，就说A不要了，要做功能B，要紧急的把它替换掉，这样的话会打乱研发的节奏，响应变化并不是说随叫随改，当然态度上需要接受这种变化，在需求管理的方式，项目排期的方式上也要能够适应这种变化，然后评估考量，这个需求能不能发布到条目化的列表里面，去替换也好，去提升优先级也好，来适应这种变化，如果实在做不了，可能因为时间原因，亦或者技术原因，然后和客户商量，确实做不了，这种情况下客户也会理解我们。这种合作方式也可以用来和内部的运营、技术、测试团队合作，以达到双赢的效果。

敏捷开发原则

最优先要做的是：通过尽早地、持续地交付有价值的软件来使客户满意。

客户的期望值管理

即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 （关于态度的声明）

态度上要迎接变化，但也不是说变就变，要灵活应对。

经常交付可工作的软件，其时间间隔可以是几周到几个月。 交付的时间间隔越短越好

版本迭代节奏做好保持2周一个版本。这样一可以保持研发迭代的节奏，提高效率，如果时间太长，比如一个月，会把开发人员的心气给耗尽。其次可以保证每个版本都有让用户体验的新东西，以及符合各大市场申请首发的条件，获得免费的推广资源（ps：一般首发活动可以获得几千到几万的免费用户，还是挺吸引人的）。如果有重要的功能，也可延长到一个月，但是最好不要超过一个月，有重大功能上线的时候可采用灰度发布的形式上线，确保版本的稳定性！

在整个项目开发期间，业务人员和开发人员必须天天在一起工作。

工作在一起有三个好处，1是大家经常工作在一起，会拉近彼此的情感距离，2是利于沟通，面对面沟通>打电话沟通>邮件沟通，3是可以加深各相关方对彼此业务的理解，让技术更懂业务，业务更懂技术。

不断激励开发人员，开展项目的有关工作。给他们提供　所需要的环境和支持，并信任他们能够完成所承担的工作。

给开发人员努力提供资源支持，并进行精神鼓励，比如针对需求分析和实现大家头脑风暴，鼓励每个人发言，比如采取任务主动领取，而不是被动分配，团队的氛围是民主和开放的。

在团队内部，最有效果的、最有效率的传递信息的方法，就是面对面的交谈。

这也是为什么团队工作在一起的目的，主要是为了沟通方便，降低沟通成本。

首要的进度度量标准是工作的软件。

每一个节点都要是可用的软件，功能可以少做，但上线的功能一定要形成闭环，不能有bug。

敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。（项目“持续发展”的能力）

保持开发的节奏。理想情况产品需求文档要领先前端开发2个版本，设计领先前端开发1个版本，后端开发领先前端开发半个版本。即在当前项目启动同时，产品经理已经在调研讨论下下版本需求；设计开始搞下版本的稿子；当前项目进行到一大半时，后端已经完成当前版本的需求，并开始准备下版本的需求预研。

不断关注优秀的技能和设计，增强敏捷能力。

每个人都要有自我学习的意识和能力，比如可以组织团队内部轮流培训。

简单是根本的。

大道至简

最好的体系结构、需求和设计，出自自己组织的团队。

去中心化。最新的区块链技术就是一种去中心化的技术。

每隔一段时间，团队对如何才能有效的工作进行反省，然后对自己的行为进行适当的调整。

“实践—反省-修炼—成长”，不论在工作还是生活中，都是自我成长的一种有效路径。

4 敏捷实践

敏捷开发是一种思想，scrum是承载这种思想的一种实践。

scrum框架

scrum角色和职责

产品负责人（Product Owner）：定义需求，定义ROI，需求优先级排序，把握产品发展方向，产品上线前的测试验收。

开发团队：作战小分队，他首先要求是跨职能的（就是团队可以做端到端的交付，不是说我这个团队只能做前端或者只能做后端，在整个团队内部成员的合作下就能够去交付一个完整的产品）负责估算产品开发工作量、帮助产品经理评估风险，排列顺序，负责把产品经理所定义的需求分成开发任务，并对开发任务工作量进行估算，然后开始实施。

承担起把控质量的责任。以前的产品质量是由测试团队验证，现在不是，现在测试也属于开发团队的一员。同时开发人员也要从代码的角度进行自测，团队所有的成员都要为质量负责。

开发团队成员控制在5-9人。如果团队成员少于5人，则交流变少，开发的效率也会下降，更重要的是团队成员过少，受限于团队成员的技能有限，无法交付成熟的可使用的产品，但是如果团队成员大于9人，那团队成员之间就需要太多的沟通协调工作，沟通成本会提高，需要制定复杂的流程来解决可能出现的流程问题，所以采用小的研发团队，可以既保证效率又降低沟通成本。

流程管理员（Scrum Master）：作为项目经理和产品经理紧密的工作在一起，他需要及时的为团队成员提供帮助，必须：

指导团队成员用正确的方式实行scrum。

保证各个角色和职责的良好协作

保证开发过程按照计划进行，组织每日站会，项目迭代会、项目总结会等。

为团队提供支持，让团队成员各司其职，不会被外界事情所打扰打扰。

任何人想给团队增加任务和需求都不能绕过Scrum Master，加需求的时候也并不是Scrum Master通过就行，当Scrum Master通过以后，Scrum Master再去和产品经理沟通，然后和团队成员沟通，最后以一种合适的方式来处理需求，比如说放到下一个版本还是在当前版本增加进去。

制定愿景

在做发布计划的过程中，首先要有一个愿景，为什么要做这个产品？目标用户是谁？满足用户什么需求？能够带来多少效益的增长？为了实现目标需要分几次迭代？

路线图

根据愿景制定产品路线图，分为几次产品迭代达到目标。

需求列表

建立需求池，收集老板、运营、技术、测试、运营等各方提出的需求。

进行需求分析，将需求排好优先级，确定每个版本要做的需求。

迭代计划

通过迭代的方式把需求列表的内容迭代完成。

1、迭代计划第一部分

确定迭代目标：每个版本都要有每个版本的迭代目标，你这个版本是为了拉新、还是促活、还是转化，还是......

优化调整：根绝目标和研发团队对本次迭代需求进行确认，一般程序员也会有自己想法，他们会从人力成本和时间的角度评估是否支持迭代这么多的需求。

澄清需求：确定团队每个成员对需求的理解是一致的。

确认范围：确认本次迭代的功能范围。

2、迭代计划第二部分：

原型设计：产品经理制作产品原型，一般用axure。

拆分任务：设计需要做那些任务，前端需要做那些任务，后端需要做那些任务，各自开发工作量是多少，具体由那个人负责，这就是拆解任务。

估算任务：各个成员根据自己领到的任务估算开发量，一般用人/日来进行衡量。预留一些不buff,毕竟估算的工作量和实际的会有点出入，如果给领导太高的预期，但实际没有完成，也会比较尴尬。

每日站会

项目开始以后，同一时间，同一地点，相同的一群人，每天举行

产品经理可以去参加，去旁听，但不是主角，主要发言的人是开发团队。Scrum Master是主持这个会议的人，也不是主角。

时间不能超过15分钟，不然说明现在团队遇到一些较大的问题，会议太长也会占用开发人员写代码时间。

开会的时候每个人说一下昨天的工作，看那些人任务正常实施，哪些人任务进度落后，落后的情况下该如何挽救，是砍任务，还是增加人力资源，加班加点赶进度。

如果团队成员需要支持，也可以在会议上提出来。

同时这也是一个仪式，代表今天战斗开始了。

验收测试

产品经理进行最后的验收测试，如果这个版本因为时间原因有些需求没有做，那就放到下一个版本里面去。有的时候是给运营做活动，运营也要参与最终的产品验收！

回顾总结

了解工作方式是不是合理，需不需要调整。

团队氛围：反思团队氛围，团队成员彼此之间能否坦诚相待，能否互相说真心话，好的团队氛围，才能保证团队的战斗力。

收集数据：功能实际完成了多少，产生缺陷是什么，系统有几次崩溃，出现了几个风险点，有几位成员休假了.....，这些都是真实的数据

挖掘洞察力：比如团队成员在讨论过程中是否产生冲突，如果产生冲突就需要制定流程和机制来解决这类问题。

决定改进行动：针对需要改进的点，制定相关的流程，以免下次再犯同样的错误。