敏捷开发模型是现代软件开发的通用模型。根据统计数据，从2018年开始，超过90％的软件开发采用了敏捷开发模型。请勿讨论敏捷开发模型和瀑布发展模型的优势和自卑。至于当前的数据统计数据和主要公司，尤其是SpaceX公司的转型结果，甚至超级硬件（例如整个火箭）都使用敏捷开发。它具有一定的优势。
作者本人已经参与了软件开发已有20年了，经历了传统的瀑布发展模式，参加了专业的敏捷开发培训，获得了认证证书，导致团队体验了瀑布的整个过程。参与了多人团队合作。首先，请分享一个非常有趣的体验。最早的公司试图做敏捷。老板在不同领域的10-12人（我是兼职PM，QA兼职SM）中添加了质量检查，老板的要求这是该团队可以从需求，设计，研究和开发中完成所有内容和测试（当时，DevOps当时并不流行，操作和维护并未返回我们）。收到的第一个项目是跨越网络，服务器，客户端和复杂场景的测试。由于其自己项目领域的劳动分裂不平衡，此时，在整个领域学习新知识的同时，需要在项目中工作。三个月后，该团队在此过程中迅速发展。在特殊活动中，我带了这个团队来接一个新项目，并且该项目的开发管理过程与整个公司不同。整个团队添加了PM（PM管有很多事情，我们只是一个），我们本身就是End2nd的功能，包括客户端（太多）和服务器和Web API（少），以及在同一timecross的多个平台（Win/Mac/ios/Android）处的客户端，没有为我们测试的特殊团队。我们的团队必须在发布前完成所有测试工作（开发人员测试+系统级测试）。通过研究和开发过程，有必要与美国爱尔兰团队合作。对于团队中的每个人来说，体验都很丰富。那个时候， 现在，一位普通的开发人员在短短几年内就处于微软的职位。这篇文章不是敏捷过程本身应该做的，而是从个人经验中谈论一些您必须知道的事情。
敏捷发展与瀑布发展之间的基本差异是“迭代发展” +“增量发展”。在这里，我们必须专注于渐进发展。如果您的团队开发了项目或产品是敏捷的，但不是通过增量开发而开发的，那么团队将非常困惑为什么它是敏捷的，什么是敏捷？当转向敏捷时，团队最大的鼓励是客户的肯定，因为6个月的项目（2个月）可以尝试原始功能的原始版本。即使他们遇到了许多使用的问题，他们仍然很高兴使用它并提出许多意见和反馈。这些反馈对团队有很大帮助。在每个月的迭代中，客户会逐步看到功能的改进和变化。在产品发布之前，客户已经拥有有关即将推出的产品所获得的产品的全面产品。对他们来说，对他们来说，该产品是他们想要的，甚至是某些产品功能和习惯，也是他们自己提出的。这种开发模型带来的变化是许多团队敏捷的根本原因。如果您使用团队敏捷，然后开发模型仅将产品开发的6个月工作划分为每1-2周。实际上，它并不真正了解敏捷性并享受敏捷性的好处。目前，如果您变得敏捷，可以说这是毫无意义的。
我在不同文章中多次说过，产品的质量与开发过程无关，至少它与敏捷瀑布模型无关。产品的质量需要人员+时间。足够的时间可以提高产品质量。我以前曾经从事在线协作产品（Welink+视频会议）。我们的产品发行模型是每月的功能释放（送达），并且每周一个贴片释放（FixBug）。在去年的流行病中，基于流行病的产品的需求增加了。为了迎合市场，加班，整个开发功能的功能比平常高100％以上。在这种情况下，可以想象产品的质量。发行前已知许多问题。由于市场的需求，在副总裁批准下很多次，该产品在生产线上有数百个错误。然后遵循补丁程序以慢慢修复这些错误。最终确定产品的质量和不良状态已确定在您的测试中。无论是开发人员测试还是质量检查团队测试，都可以在产品发布之前在发布产品之前保证质量。当然，开发人员测试的重要性将不再在这里讨论。
敏捷开发的重要一点是，要做的事情总是在改变，确定变化将来要做什么。我们要做的是我们经常称呼的积压，而管理您的积压非常重要。整个敏捷高速操作的基础是积压的管理。
积压的管理通常是指以下方面：
从积压管理的角度来看，产品经理和建筑师是非常重要的角色。除了正常的迭代过程外，两者还进行了整个迭代的准备。整个团队更像是一台高速机器，可以一一“生产”“产品”。说，您可能会理解为什么这样做许多公司必须转向敏捷发展。除了第一点，它是最大程度地利用人力资源来产生价值。
通常，公司将按照某些规则对组织结构进行划分。以我以前的公司为例，最早的地区分为区域（上海，Hefei，Hangzhou，Suzhou），后来根据领域，Web，Server，Server，Server）进行分割。，制作产品功能涉及不同领域的不同子字段，在同一字段中。很难实现组织结构内的所有内容。一起完成多个字段的函数。这样的项目将遇到许多问题。
我以前的经验是一个大型项目。每次迭代都会计划许多不同的功能。它分配给不同的Scrum团队。每个Scrum团队都根据功能组合在一起，以确保每个团队都可以相对于亲戚。Complec.plandeend2end的交付功能。这次，该团队的组成有两个主要特征：1是来到不同的组织（不同的LMS（不同的LMS）），第二个通常是在改变团队的工作人员。这种模式实际上非常具有挑战性，并且对人们的协作工作有很高的要求。
在整个产品的迭代过程中，许多事情都很麻烦，同时也受到各种干扰的干扰，并且有各个方面的压力。这次，PO和SM是整个团队的核心手术。对于PO来说，只要责任可以抵抗，他就会抵抗。不要让团队有任何担忧。通常，可以管理职位的人将成为PO.SM的角色，可以帮助团队管理该项目，这是适当的妇女强烈推荐的。
对于SM，只要她可以做与项目相关的事情，请不要推动它，采取主动性帮助团队完成，例如会议的组织，国家的更新，小组建筑物和其他使团队的能量更加焦点的事情更大。PO + SM的共同任务是确保团队在迭代周期中的全部能量正在做事。
当我们说3、4和5时，您会发现我们谈论PM，建筑师，PO，SM和团队。我们在谈论人而不是过程。敏捷过程使整个团队更加自治，并要求团队从意义到能力更强大。
说到这一点，您会发现该团队与一个小型企业家团队非常相似，是的，这就是为什么企业家团队高效的原因。原因，因此该过程本身需要根据自己的情况进行调整。
如果您去不同的公司，在敏捷发展过程中，每个公司的团队都会有所不同，并且正在不断发展。原因是不同的公司具有不同的文化，人员组成也不同。即使一个团队都是牛，他们也可能无法使敏捷。敏捷团队本身也根据自己的成长，人员变化，甚至根据其自身的增长来调整组织结构，也正在发展随着人员的变化，甚至组织结构的调整。
以我以前的团队为例，我们的Scrum团队没有PO的定义，其职责由ProductManager，送货经理和建筑师共同完成。有了SM，这四个人将组成固定的比赛，然后根据该项目领导该项目以领导更多。A团队组成了多个Scrum团队。这与传统敏捷团队有很大不同，并且可能不可再现。
因此，在本文中，我无法告诉您如何从瀑布中转变敏捷，也无法告诉您提高团队敏捷效率的特定方法。但是您可以理解，一个人是敏捷团队的基础。团队（PO+Architect+SM+PM+成员）是成功的关键。
而且您团队的合理组合允许这些团队为产品服务。当这些团队在一起时，他们可以迭代并迭代以实现产品的各种功能，以满足用户的需求并为企业带来价值，从而证明了他们价值！交点发出