互联网公司都流行用什么样的开发模式，比如敏捷开发(Scrum)？

常见的有瀑布式开发、迭代式开发、敏捷开发、DevOps等。

瀑布式开发，按循序展开，交付件单通道线性流动，一般分为需求-设计-编码-测试-验收几个阶段，适合项目制或是较传统的IT企业。

敏捷开发，没有明确的定义，2001年初因观察到许多的软件团队深陷不断扩大的流程之中的困境， 一群17人的业界专家聚集在一起，勾勒出一些能让软件团队迅速工作， 以及响应变化的价值观和原则。他们自称为Agile Alliance敏捷联盟

DevOps，旨在通过建立软件和IT服务的供应链，来支持业务并管理整个流程的成熟度。DevOps不仅仅是增强敏捷开发和持续交付，同时也实现和促进业务增长并保障业务连续性。

敏捷开发只是一种价值观而非具体的指导思想，团队实际落地需要具体的方法论，如Scrum、KanBan、极限编程（XP）等等，下图来自2019年stackoverflow的开发人员调查，显示54%的团队使用的是Scrum敏捷开发方法。

也有把多种方法融合在一起的，比方说XP实践偏工程，Scrum实践偏流程，可以和DevOps很好的结合起来。

PingCode是一站式敏捷研发与DevOps平台,覆盖项目管理、任务管理、需求管理、缺陷管理、迭代规划、测试管理、持续交付等场景，欢迎大家来试用产品→ PingCode 智能化研发管理工具。

在互联网行业的项目管理实践中，敏捷和精益一直是大家所提倡的思想，其中Scrum和Kanban方法作为即敏捷又精益的典型代表，许多PM都在研究，笔者近期也在学习和实施Scrum和Kanban方法，有些感触拿出来与大家一同分享。

Kanban方法最初起源于丰田的JIT（Just In Time），之后作为一种高效管理软件开发流程的技术和思想应用于互联网行业。Kanban方法以价值流动为核心，不断发现团队中的瓶颈工序，进行改进，使价值流动更加顺畅和快速。

Scrum源自于橄榄球的一种争球方式。现在作为一种迭代式增量软件开发过程，通常应用于敏捷软件开发。Scrum将工作分解成较小的功能单元，并在周期性固定的时间段内持续的交付。

在团队的项目管理实践中，我们往往将二者的优势结合起来综合的使用，以便帮助团队更好的完成目标，而不是为了使用方法而使用方法。本文简单的比较一下二者的不同，希望能帮助大家在实施过程中找到最合适的方法。

区别一：实施过程中关注核心的区别

Scrum实施的核心可以概括为“化繁为简”，从几个维度解释下：

1. 团队角色的定义，将团队人员定义为三个角色，Scrum Master（主要负责消除障碍，带领团队运作）、Product Owner（主要负责描绘产品远景，定义优先级）、Scrum Team（主要负责实现产品）
2. 工作任务的拆分，将产品需求拆分成小的用户故事，并评估优先级
3. 时间的拆分，将项目周期拆分成固定时长的迭代周期，每个迭代交付一部分可验收的功能，通常迭代长度为1到4周

Kanban方法在实施的过程中更多关注的是可视化的价值流动，从几个维度解释下：

1. 拉动式生产，下游工作完成后，主动拉动上游的任务移动
2. 限制WIP（work in progress），明确设定限制每个状态下，同一时间内有多少工作量，减少同一状态同一时间内，任务和价值的堆积
3. 可视化的价值流动通常是端到端的流动，直观的反映用户的价值（通常是可交付的用户需求），并且反映出在价值流动过程中的瓶颈和问题，不断为团队改善提供依据

区别二：限制WIP数量的方式不同

Scrum与Kanban方法都会限制在制品数量，不过限制方式有所不同，Kanban方法限制的更加直接，同一状态同一时间内的工作任务有最大限制；Scrum是间接性的通过迭代（sprint）来限制。限制WIP的核心目的是加速交付用户需求的价值流动。

区别三：对任务变更管理的不同

在Kanban方法的中，下游任务完成后，即可拉动上游任务下移，同时，只要生产力允许，即可新增需求。

在Scrum方法下，当每个迭代的sprint Backlog确认后，当前迭代是不允许新增需求的，新增加的需求可以体现在下个迭代的sprint backlog中。

区别四：改进依据的不同

Scrum是以生产率作为计划和改进的依据，以迭代（sprint）数据作为依据，分析迭代的相关数据（包括生产率、完成率等）；Kanban方法是使用生产周期作为计划和过程改进的依据。

Scrum和Kanban方法作为即敏捷又精益的典型代表，除了上述不同外，还存在很多相同点：

1. 二者都和敏捷与精益相对应。敏捷中的持续改进思想在Scrum和Kanban都有所体现，而且是很核心的一个内容；精益中的拉动式生产在Scrum和Kanban中也都分别覆盖，Kanban方法体现的更加直接，下游直接拉动上游的工作任务。
2. 二者都关注尽早的交付价值，尽可能频繁的发布可使用的软件。Scrum将整个项目周期拆分成多个迭代，每个迭代发布可验收的软件；Kanban方法在每个功能开发测试完成后就可以进行部署和发布。
3. 团队状态都直观的反应在Scrum board和Kanban Board上，方便找到问题和瓶颈，并进行改善。

比较了Scrum与Kanban方法之后，如何结合二者在团队中进行项目管理实践呢？笔者结合自己的经验从迭代、版本、变更、改进四个方面给大家进行一个简单的介绍。

迭代：在Kanban方法中，并未规定明确的迭代，而在Scrum中是规定了固定的迭代周期。在我们的团队中，迭代周期从一月一迭代，逐步变为一月两迭代，到现在的两个自然周一个迭代，完全固化了迭代周期的概念。

将复杂开发周期很长的开发任务，分解成多个迭代周期，每个迭代周期交付一些可验收的软件或者功能。有利于减少风险，并更好的适应变化，及时的根据反馈调整工作目标。

版本：在迭代中，我们以排入版本计划的功能点（story）作为工作重点，排入版本的story为交互已经完成的功能点（story），这些功能点可以直接进入开发和测试环节。这些story便是我们当前迭代可以交付的功能或者软件。与此同时，产品、交互和视觉同学会继续拉取需求池中的功能点，开始进行设计，准备下个迭代版本中的内容。使整个价值流动更加顺畅。

变更：对待变更，我们同样有自己的一套流程规范，既没有像Kanban方法一样，只要生产力允许，便可以新增需求；也没有像Scrum一样，版本内容确定，当前迭代基本不允许变更。在实际过程中，当存在紧急需求，由产品经理发起，和各个角色进行评估风险和对现有版本的影响，并采取相应措施降低由于需求变更对整个系统产生的影响，最后由项目经理发出变更通知的邮件。

改进：我们改进的依据之一是团队数据，由于我们所有的任务都是通过JIRA进行管理，可以方便的拿个团队各种数据，包括：总工作量、总完成工作量、完成率、有效工作量、有效工作率、bug数、bug率等，对这些数据进行分析，发现团队的问题，帮助团队进行改进。

对于Scrum与Kanban方法的应用，笔者还在实践中不断的探索和思考，还有许多需要迭代改进的内容，期待与大家一起沟通交流。

以上答案来自我厂屈鹏飞老师的博文 巧用Scrum与Kanban-社区博客-网易云

网易云 免费体验馆，0成本体验20+款云产品！

更多网易研发、产品、运营经验分享请访问 网易云社区。

目前最流行的开发模式：Scrum+XP

结合2020年度敏捷状态报告的一份数据，可以看出在所有敏捷实践中，Scrum和极限编程占绝对优势。

然而国内除了上培训课程、专门书籍解读等占据大块时间的相关知识，网络上对这两项敏捷实践的系统性解读寥寥无几。

于是我们把培训、书籍、实践中学习、总结的Scrum和极限编程的知识和实践，通过短视频的形式传达给更多人，让大家看得开心的同时还看得明白。视频时长大多在三分钟左右，适宜等车、通勤、等电梯等碎片化时间观看。（当然，一次性系统性看完更有收获！）

Scrum小视频

Scrum 小视频共计9期，主要为大家讲解一些 Scrum 中的术语，和一些 Scrum 中的故事。用包袱段子解说Scrum框架，在干货中增加了一些趣味性。

点击蓝字即可观看：

1.《论牧羊犬如何混迹于Scrum圈》

2.《Scrum回顾会议：有话好好说》

3.《Scrum验收会议：攻城狮的秀场》

4.《站立会议：猪与鸡的故事》

5.《敏捷估算扑克牌的正确玩法》

6.《Scrum计划会议到底怎么开（上）》

7.《Scrum计划会议到底怎么开（下）》

8.《敏捷中的仪式感》

9.《项目经理生存指南》

极限编程系列视频

极限编程系列视频共计13期，以动画形式为主，主要讲解极限编程中的最佳实践。

点击蓝字即可观看：

1.《论代码规范的重要性》

2.《结对编程怎么结对》

3.《程序员：这个代码命名太难了》

4.《为什么要实施代码集体所有？》

5.《持续集成——Linux内核项目30年不崩不乱的秘密》

6.《敏捷开发——如何写好用户故事？》

7.《极限编程——计划游戏怎么玩？》

8.《极限编程中的现场客户怎么实践？》

9.《极限编程中的系统隐喻到底在隐喻什么？》

10.《40小时工作制：早该告别996了》

11.《极限编程中的简单设计，其实不简单》

12.《你的技术债务解决了吗？试试重构》

13.《测试驱动开发——让你的代码更简洁》

除了这两个完整系列，这一年我们还制作了《程序员修炼之道》、《程序员英文发音》等系列视频，虽然未完待续，但都是干货满满，帮助多多。这些内容都放在“ 禅道学院”里啦，还有更多其他内容，等着你来解锁！

送福利：想要系列视频的本地版，可联系禅道项目管理软件的班长——阿道获取哦！（扫描二维码加阿道）

如题主所提问，敏捷开发确实是大多数互联网公司都在用的一种开发模式。

敏捷开发，其实是伴随着互联网在我们生活中的普及而流行的，互联技术促进了互联网创业的繁荣，使得以迭代的形式发布产品并在与用户的互动过程中不断打磨完善升级产品成为了大多数企业能够存在下去的前提和基本生存状态。

敏捷开发作为一种应对快速变化的需求的软件开发模式，同时更是一种理念，更强调程序员团队与业务专家之间的紧密协作，持续性的根据用户反馈和需求优先级来频繁发布和迭代产品版本，不断完善产品。它的核心就是小步快跑，快速迭代。

过去，企业开发的需求是完整的、清晰的、固定的，产品定义也是稳定的，因此企业在项目开发当中经常采用自上而下、相互衔接且固定次序的瀑布开发模式。而在当今，中国互联网快速发展时代，几周内都可能发生翻天覆地的变化。

无论是初创型企业还是大型企业，都会面临需求变化越来越频繁的问题，更需要有一支高效能的团队来推动产品快速迭代。相比起瀑布开发的线性开发模式，敏捷开发能够更加灵活适应用户的需求和变化，更适用于当今互联网的快速发展节奏，因此也越来越受到企业研发的重视和应用。

而在敏捷开发模式中最核心的便是：人、产品、协作和迭代。这其中，敏捷开发提倡以迭代式开发的方式开发产品，即一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程，所有的阶段都可以细分为迭代，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。通过这样持续不断地在较短周期内迭代、完善和交付产品，令客户感到满意。

在 ONES 中，企业可以系统和高效地落地敏捷开发框架，提高组织的响应和交付能力，从而更顺畅、高质量地交付产品，实现业务敏捷，助力业务成功。

以敏捷开发（Scrum）的经典业务场景为例，ONES 可以帮助企业实现人、产品、协作和迭代的高效管理。

1、需求池管理

团队可使用 ONES 工单收集和整理来自各方的反馈，处理工单并快速转化为需求，整理出产品 Backlog，根据实际场景，自定义需求工作流，打通从需求提出到流转到各职能进行处理的流程。功能复杂的需求，可以利用「子工作项」进行细化和拆解，并关联研发和测试任务，将需求到研发和测试过程串联起来。

2、迭代规划

产品负责人根据需求优先级，将产品待办列表中的需求规划至对应迭代，在迭代计划会议上与团队一起进行迭代评审，确定好当前迭代要完成哪些需求之后，即可对其分解，拆分成各类子任务和关联任务指派给设计、研发人员。

3、迭代开发

开发阶段，团队通过流水线管理工具 ONES Pipeline，将构建、部署与项目、迭代整合到一起，实现可视化交付管理。

4、缺陷追踪

通过 ONES TestCase，测试人员可以创建迭代的相关用例，安排测试计划。测试用例未通过可一键提交缺陷至项目，使得缺陷在测试和研发部门之间高效流转

5、迭代进度跟进

迭代过程中，团队在每日站立会议中通过敏捷看板和燃尽图直观地查看任务当前的状态和完成情况，跟踪迭代进度。管理者还可以通过 ONES Plan 的甘特图跟进多个迭代的进度，通过资源管理监督工时消耗情况，了解整体进度。

6、迭代回顾

当一个迭代完成并发布之后，可以召开全员迭代回顾会议，复盘迭代过程的问题，讨论改进建议等。通过迭代燃尽图、工时、持续集成报告等各类数据报表，复盘迭代进度、质量和成本偏差，寻找改进方案。迭代结束后，还可以将迭代分析和总结用 ONES Wiki 记录下来，形成团队知识库。

以上，欢迎大家在 ONES 中进行高效的敏捷开发体验～

这题我会！目前我们公司使用的是 Scrum。

首先先来简要介绍一下 Scrum，再来说说我们公司的具体实践。

Scrum是什么？
Scrum是基于敏捷开发思想的开发框架，用于迭代式增量软件开发过程。 它适用于需求变化频繁、内外部环境变化快、需要快速交付和验证的场景。

实际上，Scrum这个英文字母来源于橄榄球运动的一个专业术语，表示“争球”的动作。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。可以想象，当开发团队在用Scrum这种开发方法开发项目时，大家像打橄榄球一样迅速、富有战斗激情、且灵活而高效地完成工作，因此受到非常多开发部门的推崇。
那么，灵活高效的Scrum是怎样的流程呢？

Scrum开发流程和「343」原则

Scrum流程可以分为以下阶段：
① 由PO（产品负责人）负责，确定一个Product Backlog（产品需求池）；
② Scrum Team（敏捷团队）根据Product Backlog，做工作量的预估和安排；
③ 有了Product Backlog，我们需要通过Sprint Planning Meeting（迭代计划会议）来从中挑选一些Product Backlog加入Sprint（迭代），形成Sprint Backlog（迭代需求池）。这个目标的时间周期是1~4个星期；
④ Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
⑤ 在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟内。Daily Scrum Meeting根据看板的内容，每个人进行发言，并且向所有成员当面汇报昨天完成了什么、今天要完成什么，如果遇到不能解决的问题也可以提出。每个人回答完成后，都要更新Burn Down Chart（燃尽图）；
⑥ 当Sprint Backlog已完成，也就表示一次Sprint完成。这时，我们要进行Srpint Review Meeting（迭代评审会议），PO和客户都要参加。每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
⑦ 最后就是Sprint Retrospective Meeting（迭代回顾会议），该会议以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。
在Scrum开发流程当中，应当严格遵循“343”原则，即Scrum框架中的3个产出物、4个仪式、3种角色。

3个产出物

• Product Backlog（产品需求池）：是产品待办事项的集合。其中，事务有优先级判断，先处理优先级高的事项。
• Sprint Backlog（迭代需求池）：在迭代计划会议期间，团队选择一些产品待办事项，并且确认完成每个用户故事所需完成的任务。
• Burn Down Chart（燃尽图）：燃尽图是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。

4个仪式

• Sprint Planning Meeting（迭代计划会议）：迭代计划会议在每个迭代周期开始之前召开，目的是为了制定当前迭代周期的开发目标以及需要完成的工作。
• Daily Scrum Meeting（每日站立会议）：日常站立会议是每天早上举行的短期会议，用时一般严格控制在十五分钟内，会议的目的是更新团队的状态。站立会欢迎所有人参加，但只有团队成员（开发、测试、产品经理等核心角色）可以发言。
• Srpint Review Meeting（迭代评审会议）：Sprint评审会议在Sprint结束时举行，用以检视所交付的产品增量并按需调整产品待办事项列表。评审会议的会议时长限时为 4 小时。
• Sprint Retrospective Meeting（迭代回顾会议）：在每个Sprint结束后，Scrum团队会聚在一起开Sprint回顾会议，目的是回顾一下团队在流程、人际关系以及工具使用方面哪些做得好，哪些做得不好，并找出潜在的改进事项，为将来的改进制定计划。

PS.插播一句：关于迭代回顾会议，可以看看我的另一篇文章～

3种角色

• PO（产品负责人）：PO 在敏捷Scrum开发的过程中起着至关重要的作用。PO 代表客户的意愿，从业务角度上保证Scrum团队做正确的事；同时代表项目的全体利益干系人，负责Product Backlog，排出优先级，编写条目化的需求（也叫“Story”，指用户故事），从而使项目价值最大化的人。
• Scrum Master（Scrum教练）：Scrum教练的主要工作是去除那些影响团队交付冲刺目标的障碍，并负责屏蔽外界对开发团队的干扰。Scrum教练是规则的执行者，确保Scrum过程按照Scrum流程来执行。
• Scrum Team（团队成员）：Scrum团队负责交付产品的团队。

其他名词解析

• Sprint（迭代）：原义是短距离赛跑的意思，这里指的是一次迭代。一次迭代的周期一般是1-4周，也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。
• Kanban（看板）：是指敏捷看板。“看板”一词出自日语“看板”（读音かんばん，kanban），源于日本丰田生产的精益生产实践，敏捷开发将其背后的可视化管理理念借鉴过来。看板可以把研发的过程进行管理，记录下用户故事研发过程中的细节和历程。

为什么要用Scrum？

敏捷大师和Scrum发明人 Jeff Sutherland：Scrum是一门让研发管理事半功倍的艺术。
① Scrum能够快速响应变化，以轻量级的Story（用户故事）作为需求进行迭代式开发，保证最重要的事情优先做，更高效产出交付物。
② 可以持续向用户交付有价值的软件产品，以及短的软件交付周期：这是现在的互联网开发的基本要求，就是不停的通过每次迭代和升级，进行产品的优化和提升。
③ Scrum过程要求大家做更多例行的沟通，包括每日演示、设计讨论、提出问题和找到帮助者、定期总结，团队所有成员都可以完全了解当前的项目进展和问题，从而促进大家的沟通、快速的解决问题。
④ Scrum开发可以让产品快速试错，试错成本低；以较低的成本，和高效的模式进行产品的迭代，回报率也高。

如何利用工具帮助Scrum落地？
我们公司主要是通过研发管理工具来落地 Scrum 流程的。那么Scrum流程如何落地？研发管理工具能提供什么帮助？

1. 团队管理
ONES通过「项目角色」对参与项目的成员进行分组和权限管理。

在敏捷项目中，系统管理员可建立PO、Scrum Master、Scrum Team三种角色，应用到实际项目团队中，配置不同角色不同的管理和查看项目、工作项类型等权限。项目成员亦可拥有多个角色，便于跨职能协同与管理。

2. Product backlog
在ONES中，可使用「需求」这一任务类型及其组件来管理Product Backlog。

• 产品负责人在需求池中录入需求单、设置优先级。可以通过自定义需求状态、补充各类属性字段，编写完整描述，上传相关产品文档、高保真原型等方式，形成完整的故事结构，便于进行评审及后续研发过程的流转。
• 根据实际场景，自定义需求工作流，实现从提出反馈、转化为用户故事、安排迭代到功能上线的全生命周期历程。
• 功能复杂的故事，可以利用「子工作项」进行细化和拆解，拆分为颗粒度较小的需求。
• 需求也可与用户反馈、研发任务、测试结果等工作项相关联，便于其它成员查找引用、追溯来源。

3. 迭代规划与评审
ONES通过「迭代」组件对开发过程进行管理，项目团队可通过这一组件创建和规划迭代。

• 产品负责人先将需求按确定的优先级顺序，从Product Backlog规划至对应迭代。产品负责人可创建新的迭代，并设置迭代周期和迭代阶段，可自定义多种属性字段，丰富迭代信息。
• 在Sprint Planning Meeting上，产品负责人按优先级一一讲解用户故事、补充故事描述或调整优先级，和团队一起估算故事规模。如果需求评审不通过，可以规划至后续的迭代或移回需求池。
• 确定好当前迭代要完成哪些需求之后，即可对其分解、登记预估工时，拆分成各类子任务和关联任务，指派给相关团队成员。

4. 跟踪迭代进度
ONES系统提供燃尽图、敏捷看板、仪表盘、甘特图等工具技术，直观反映各成员工作状况、当前迭代进度的健康程度。

每日站立会议可通过ONES敏捷看板轻松实践。敏捷看板可基于实际工作场景，把各项工作项状态放进不同泳道。成员在每日站会上可以直观的查看不同任务的进度，并支持直接在敏捷看板上拖动任务来更新状态。ONES也支持显示普通任务看板，以任务卡片和状态分布的形式跟踪项目进度。

• 燃尽图是敏捷项目追踪的有效工具，是迭代完成之前，对剩余工作量的可视化表示。每个成员回答完成后，都要更新燃尽图，预测预计结束时间、判断迭代能否如期完成。
• 迭代基础统计与燃尽图可被添加至仪表盘中快速浏览。也能通过甘特图快速获取多个迭代的进度、通过工时消耗情况了解整体项目情况。

5. 迭代回顾
每个迭代结束后，Scrum 团队会一起开迭代回顾会议，把整个开发阶段流程拎出来进行分析，回顾一下团队在流程、人际关系以及在工具方面上使用得如何，总结哪些事情做得好、找出潜在的改进事项，为将来改进制定计划。

• ONES系统中可根据研发场景需要，生成相应的质量报告。使用报表统计迭代范围内的缺陷分布，任务滞留时间等。

• 迭代分析、总结结果可以用 ONES Wiki 进行记录，将相应的经验以文档的方式沉淀下来，精准至附件级别的全局搜索，便于团队快速定位、获取有用的信息。

以上就是 Scrum 实践的完整流程。

目前国外的互联网公司大多采用敏捷或者类似于敏捷的开发模式。

国内采用敏捷，伪敏捷，瀑布式或者无组织的混乱形式。

互联网开发推荐使用敏捷方法，参见我在百度Web app大会上的演讲《用敏捷玩转Web开发》

1、瀑布式开发是一种老旧的计算机软件开发方法。瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。

2、迭代式是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代。迭代式，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

3、敏捷开发是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织 型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

您想在开发过程中立即看到可用部分吗？使用Scrum，让您的开发过程变得更加灵活和精益。

一种更好的产品构建方式

Scrum作为一个管理软件开发的框架，可以帮助您实现现代、高效、敏捷的产品和项目管理。在其中您可以解决复杂的适应性问题，同时高效和创造性地交付具有最高价值的产品。团队可以对于项目过程中产生的数据、结果进行讨论，这种方法不但可以灵活地应对不可预测的变化而且检测生产性能。

Scrum框架基于几个工作周期。 Sprint Planning（计划制定）会为每个团队成员制定计划任务，也是每日Scrum的一部分，每日Scrum是一次交换信息的简短日常会议。产品Backlog（待办事项）列出了完成项目所必须完成的所有任务，它是Scrum框架的一部分，Sprint Retrospective（计划回顾）也是如此，其中评估了最新sprint期间的团队合作。

Scrum团队

Scrum的基本单位是一个小团队，即 Scrum团队。Scrum团队通常由一名Scrum Master、一名产品负责人和其他开发人员组成。在 Scrum 团队中，没有子团队或层次结构，它是团队专业成员凝聚而成的单位，一次专注于一个目标，即产品目标。

专业 Scrum

SCRUM流程简单，优点在于定期审查，具备高透明度和自适应规划的灵活性，客户服务始终是SCRUM的核心。

W4的应用程序和网络开发人员已经为复杂的IT项目找到了理想的解决方案。准备好从智能解决方案和创新产品中受益了吗？准备好参与数字化和优化数据管理了吗？W4非常乐意帮忙！

—————— W4是欧洲老牌数字营销企业，我们的国际化专业团队有超过25年的品牌营销经验。在内容管理方面，我们与HubSpot、Drupal、Wordpress、Typo3等顶级CMS的供应商建立合作，已帮助多家企业量身打造优质的网站。

点击了解更多网络开发相关信息

互联网产品，更注重“快鱼吃慢鱼”、“更快的切中客户需求”，敏捷开发强调根据反馈的快速迭代，是比较适合互联网产品的开发。除了好的团队外，我认为最重要的三点：迭代0（即正式开发迭代之前的准备）中的架构、产品需求的拆分、一个高效透明的流程。对于流程，互联网公司一般人员较多，大产品用Scrum可行，但需要大团队的拆分协作；可以尝试Kanban。

主流的软件开发模式主要有瀑布式开发，也称之为传统开发模式，还有敏捷开发，迭代是开发，DevOps、极限编程等。

其中以瀑布式开发和Scrum敏捷开发为主流，最近几年DevOps也比较受欢迎。

对于他们的具体实现形式和开发模式，其他回答已经说的非常之详细，这里就简单补一点DevOps吧。

说DevOps，其实绕不开敏捷和精益开发，因为DevOps是在它们的基础上发展而来，借鉴了其中的方法、理念，并发展和完善而来它们的实践体系。

DevOps继承了敏捷开发的理念，又补上了运维的部分，但DevOps却也不是开发和运维的简单叠加。

在《DevOps实践指南》中，DevOps实施的三步工作法，分别是：

• 流动原则：聚焦IT系统的整体价值流，全局优化，保证价值从左到右的快速流动。
• 反馈原则：创建从做到右的反馈循环，并缩短反馈周期和放大反馈效果，这样，就可以更快的响应和理解内外部客户，并即时获取改进所需要的知识。
• 持续的实验和学习原则：创建承担风险、持续实验并从错误中学习的文化，在不断尝试中精进能力，并提高系统的韧性。

书本的作者认为，这三步工作法是其他一切DevOps流程、实践的价值和哲学根基，所有DevOps都可以从这三个原则派生而来。

简而言之，DevOps意味着组织中开发（Dev）和运维（Ops）团队之间的协作，通过持续集成和持续交付，为用户提供更好的产品。

持续集成（CI）是一个开发过程，每天多次将代码集成到共享存储库中，借助自动化测试，CI帮助团队及早识别错误，高效定位问题，提高软件质量并缩短交付时间。

持续交付（CD）与持续集成相集成，以向用户顺利交付产品。它旨在确保代码可以安全部署到生产环境中。

持续部署是软件交付流水线的一部分。在CI/CD工作流中，构建往往以小批量进行。持续测试借助自动化手段，尽早、逐步和充分地执行测试，从而减轻手动工作的负担。

典型的DevOps工作流程，可以分为四个阶段：

1. 版本控制：存储和管理不同版本的源代码；
2. 持续集成：该阶段使开发人员能够在进行单元测试和集成测试之前，构建组件、组装和验证它们；
3. 持续交付：持续集成的下一步骤，使发布和测试过程完全自动化，目标是快速、可持续地发布更新软件；
4. 持续部署：在每个应用程序满足所有测试要求后，它会自动部署到生产环境中，以进行更小、更频繁的发布，无需任何人工干预。

这里列举一些优秀的DevOps工具：

• 配置管理工具：Puppet（一种开源配置管理和部署工具），Ansible；
• 持续集成工具：Jenkins，Jenkins是一种用Java编写的自动化服务，它可以充当CI的工具。
• 代码管理工具，常见的有GitHub、Git Lab等，
• 持续部署工具：Spinnaker（一个开源的CD软件平台）；
• 漏洞管理：Twist Lock（基于容器的应用程序提供威胁和漏洞检查）；
• 系统数据：Sysdig（基于云基础架构、服务和应用程序的监控工具）、Anchore一个完整的容器安全工作流解决方案）;
• 质量/测试：JMeter（用于测试Web应用程序的负载测试工具）、JUnit（单元测试框架）
• 记录和监控：Nagios（开源软件，可以监控系统、网络和基础设施）
• 项目管理和协作： 鲸舟研发管理（敏捷研发管理工具，30人以下团队永久免费），Microsoft Teams，一种通信协作工具。

欢迎注册试用！！

敏捷、精益敏捷和DevOps之间的区别？

敏捷旨在优化软件开发、构建持续交付、最小反馈循环并在软件开发生命周期中促进团队协作。精益是精益原则的延申，用于简化产品开发周期，精益强调消除冗余工作流程以最大化整个产品的价值，与此同时，DevOps打破了软件开发过程中Dev和Ops团队之间的壁垒。
它旨在实现自动化工具和IT专业人员之间有效合作，创建更简单的自动化流程。

敏捷开发的定义是一种面对不断变化的外界环境，快速适应并持续短周期迭代的开发能力。

核心思想是：缩短周期，快速验证，不断改进。

需要注意的是，敏捷开发的目的不是帮助团队在最短时间内完成项目，而是让团队能开发出顺应需求变化的真正有价值的产品。

敏捷开发并不是一个固定式的开发流程，而是能让团队更好更快的开发的所有方法理念的集合。所以团队不应该被所谓的敏捷开发方法束缚，而是以敏捷开发的核心思想切入，不断更迭出属于团队自己的开发流程和方法。

快速启动敏捷开发的一般步骤如下：

• 准备产品需求列表
• 确定迭代周期
• 明确迭代内要做的事（四个迭代会议）
• 在实践中不断改进

1、准备产品需求列表（Product Backlog）

产品需求列表是一个长期存在列表，可以并且鼓励根据内外部因素，不断的调整列表内容及优先级。 产品需求列表建议由产品经理负责管理，团队共同商议并且决定列表内容及优先级。

2、确定迭代周期：
迭代的定义：承诺完成一部分需求开发的固定时间周期。 团队考虑产品性质，团队基本情况等因素，共同决定一个迭代的周期，通常以周为单位，2-4周最佳。

3、明确迭代内要做的事（四个迭代会议）：
需求开发过程中，无非包含下面事项：计划，跟踪，验收，总结。Scrum框架定义了四个标准会议来进行这些工作，分别为：
1)迭代计划会议： 于每个迭代前开始，开发团队按照优先级从产品需求列表中接受需求，选择出能在一个迭代周期内能完成的工作；
2)每日站会： 整个团队每天进行，同步当天的开发进度，及时反馈风险解决阻塞问题，会议上仅提出问题和风险，不延伸讨论解决方案；
3)迭代评审会议： 迭代结束前，开发团队向 产品经理或客户代表演示完成的功能，接受评价和改进建议；
4)迭代回顾会议： 迭代结束后，团队就本次迭代的过程，提出任何可以改进迭代过程的建议，包括流程、成员合作、工具改进等方面。

4、在实践中不断改进

敏捷开发不应该过多的被流程和工具束缚，在实践当中不断的优化才是真正的敏捷。现在开始敏捷起来吧。

轻雀协作为广大用户提供新一代办公协作平台，目标打造最有效率的办公协同工具，助力合作伙伴跑得更快，跑得更好。期待您的试用反馈与意见建议。

目前市场上比较主流的开发模式，如低代码开发平台。如引擎式开发模式，是目前最先进的软件快速开发方式之一，只需在开发后台进行配置，即可完成软件开发的过程，由于过程中没有生成或修改底层源码，平台可以统一维护和升级，轻松实现复杂的业务逻辑。

这种模式的 低代码平台主要成功代表参考

产品完全采用引擎式开发模式，整个过程都是可视化操作模式，不需要编码即可进行打包、编译及发布，开发和效率得到了极大的提高。

低代码开发平台即可以快速构建出OA协同、公文督办、KM文库、项目管理、采购管理、生产管理、供应链管理等一些列职能类和业务类管理系统。

互联网公司团队在践行敏捷的过程中，会有多种选择，比如Scrum、XP（极限编程）、Kanban、Crystal、精益生产、规模化敏捷等，其中最流程的敏捷开发方法当属Scrum。

2020年，该行业首个智能价值流创造者——Digital.ai最近发布了第14届敏捷状态报告，以及一份反映2020年现状的调查附录。报告中调查了企业、公司正在实施的敏捷技术，它们的收益以及趋势。

调查显示，Scrum及其变体是用于敏捷实施的最常用方法。

报告中，也对团队为何采用Scrum敏捷实施进行调查，受访者回答了它们实施敏捷技术的首要原因。

采用敏捷的五大理由

• 加速软件交付（70%）
• 增强管理不断变化的优先级的能力（63%）
• 提高生产力（51%）
• 提高业务/IT一致性（47%）
• 提高软件质量（42%）

最常用的五种敏捷技术

除此而外，报告中还表示了帮助团队坚持敏捷十二原则的五种常用的策略。

它们分别是：日常站会、回顾会议、迭代计划会、短期迭代、Kanban等

每日站会是组织中最常见的敏捷技术。

从报告中，我们可以看到互联网公司主要流行的敏捷开发模式，但这里需要纠正问题中的一个小错误，即认为敏捷就是Scrum。实施敏捷就是套用Scrum方法。实际上并非如此，敏捷并非等于Scrum，敏捷作为一种软件开发运动，其发起人试图以一种更为敏捷的新方式来思考软件开发、方法论以及组织架构，从而帮助行业中的人们。Scrum作为一种方法论，并不是详细的操作规范，而是一套行为框架，在此框架基础上，个团队根据自己团队实际情况指定合适的迭代任务。

鲸舟是如何践行精益敏捷的呢？

鲸舟是有效落地精益敏捷思想和实践的一体化研发管理平台，为敏捷团队提供专业的敏捷咨询和知识社区，帮助团队实现“更快响应力、更好质量、更高效能、更大价值”的产品开发，支持企业的数字化业务快速发展。

鲸舟覆盖研发管理全流程，包括故事管理、迭代管理、迭代仪表盘、缺陷管理、用例管理、、测试计划管理、日程管理、度量看板等。目前全部免费，欢迎大家进主页官网试用。

另外非敏捷的开发模式有瀑布式开发、迭代式开发、Devops等。

瀑布式是开发是传统的开发软件开发模式，主要出发点是需求，流程是需求调研、分析、方案设计、产品开发、上线测试等。这里不多展开赘述，说一下DevOps。

DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。

实际上，DevOps与Scrum并不冲突，从性质上来讲，Scrum偏向于基础框架，DevOps偏向于文化理念，Scrum更注重每一个Sprite结束后的成果交付，DevOps则注重构建、开发、运维等阶段的整体运行、前后的衔接与持续交付。

欢迎大家留言交流！

敏捷开发一般是借助一些成熟的平台工具，完成整体的部署落地：

据说现在软件开发有超过半数的人在用敏捷开发模式，敏捷开发的高适应性，以人为本的特性。更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

适合在人多的大公司，一开始实行这个开发模式，大家兴致很高，也有一些可以改进的点：

1、对于全新的软件，资料人员过早参与，后期返工工作量大，原因同第一点。

2、自动化系统测试工作量大，测试人员投入大量的精力在使测试自动化起来，而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样，自动化系统测试脚本也多流于形式，测不出深层次的问题。

3、代码动态检查工具执行不理想，流于形式。没有人对Purify有深刻的理解和应用经验，报告中查出来很多告警，但不知如何消除。

4、由于快速搭建原型，没有在架构上进行严谨的设计，导致后期一直堆砌代码。

5、异地开发模式下无法实现快速构建、快速交付，团队普遍感觉很疲惫。

总之适用于竞争激烈，快速变化的市场。 敏捷的客户协作观念，快速迭代能帮助团队以最小成本，最快速度满足客户真正的需求，这点就应运类似快速开发软件公司兴起，在天翎，普元，红讯，G2这些十几年厂家都在不断技术更新，实行敏捷开发也好，迭代式开发都是让业务和技术达到平衡点。

做一个最懂技术人员的需求分析师。

————————————————