vlambda博客
学习文章列表

目前软件开发业界已存在多种开发合作模式，各有其特点、适用性和局限性，没有一种开发模式是通用又完美的，可以适用任何组织、任何业务的研发协作。所以每个公司研发组织要根据自身业务特点、自身组织实际情况来采用合适的开发管理模式。

对于大多数开发人员来说，对敏捷开发的思想、方法论大多略有研究。敏捷开发提到的相关原则，敏捷开发模式应用到实际开发过程中，实施起来或多或少与理论存在差异。所谓理论结合实际，作为开发人员或者开发组织来说，不可完全照搬。

敏捷开发模式，总体来说适合迭代演进的产品项目。相对来说ToC的业务应用应开发采用的比较多，因为产品需求一开始不明确、市场变化快，需要快速对客户反馈进行响应，产品需不断迭代完善调整。当然敏捷开发也适合ToB的轻流程或面向互联网相关业务应用、业务总体流程不复杂，应用业务之间关系相对比较独立，可分段式推进上线。

产品项目研发采用敏捷开发模式，首先得建立符合敏捷开发模式的组织团队，强调团队稳定、目标明确协作一体化，团队参与全过程、为质量负责。本文对相关业界提到的敏捷开发原则并总结以往实际产品项目开发实施经验进行结合，仅代表个人观点，仅供大家参考。

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

传统的瀑布式开发模式涉及到多个环节，整个研发周期过长，中间环节都可能会发生各种不可预期的因素，最后交付大批量的成果给到客户进行试运行，等待反馈，来回的周期往往超出预想的计划，对于需要敏捷响应的业务不太适合。

实际很多项目产品后期交付给客户试运行经常发生反复调整，加上中间响应过程过于繁琐，造成双发的满意度、成就感都很差。

当然传统的瀑布式开发模式运用多年，每个开发组织经过多年也积累相当的经验，形成了一定的风控经验措施，还是适合一些特定客户特定业务的产品研发，但始终存在多环节带来的周期不可控风险、风控成本不确定的弱点，不太适合目前对周期要求快速响应的业务应用。

敏捷开发中强调持续集成交付有价值的成果。把产品项目整个任务进行拆分成多个小批量目标，根据优先级进行迭代式推进，每个小批量任务完成后都是可交付给到客户使用的，缩短客户等待周期反馈周期，及时根据反馈结果进行调整，以此达到客户满意度。

在实际产品项目开发采用敏捷开发模式过程中，经常碰到很多对交付成果反馈并不敏捷的情况，ToB应用这种情况比较多，有客户因素也有团队因素。

同时，迭代划分规划也存在不够合理情况，例如：人员因素、外界因素、技术因素等等。

组织内部的迭代测试与开发过程经常性交接不顺，很多敏捷开发团队共享一个测试团队，无法持续的交付可使用的成果，，甚至最终还是采取瀑布式验收模式，ToB应用这种情况比较多，到最后才统一进行试运行使用，客户满意度也不高。

不论产品还是项目，对于敏捷开发模式运用，都需尽可能让需求提出者、敏捷开发团队组织等参与整个过程，尽早提供给最终用户（客户）使用已取得反馈进行优化调整。但这些都是现实中采用敏捷开发模式会碰到的难点。

传统项目瀑布型开发模式，基本前期阶段需求调研制定需花费大量时间，目标已基本明确，需求方基本需求已定，基本上不会发生大的变化，进入里程碑的阶段，再在进入后续阶段。

但实际很多项目产品按前期需求完成后，在交付运行期间往往存在需求变更、调整等，ToB项目因为多种因素，所以这种情况比较多，“改或不改”变成了后面与客户的博弈。但总体来说项目每一期的需求范围不会发生太大的变化，如果发生很大的变更，一般会采取商务手段，将变更纳入下一期项目的目标或者新的项目。

实际上大部分团队，目前有些应用业务产品受到市场用户反馈影响很大，长期目标并不太明确，以需求为依据，需要根据市场反馈快速反应调整，因此采用敏捷开发模式，特别对于ToC业务，需要快速迭代、持续交付，满足最终用户的需求。

为了拥抱变化，让产品有持续生命力，所以对于某个项目产品的敏捷开发，到后期也是欢迎需求调整的。

经常性地交付，交付的时间间隔越短越好，可以从几周到几个月。

敏捷开发强调持续集成并推进持续交付，使用分解成小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。

开发团队通过提供最小化可用产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到一个相对稳定的阶段产品。因此交付的周期间隔越短，持续迭代收集的反馈速度越快，及时对产品项目进行调整，则能快速提升产品的市场竞争力。

通常敏捷开发每个迭代周期基本一致，便于定位每次迭代的主要目标。对于迭代的规划、目标任务项分配和调整产品组织者或项目开发团队的能力，迭代周期基本保持一致主要为了控制开发的节奏。

现实中我们在产品项目采用敏捷开发模式后，我们更多采用先业务模块垂直划分，再考虑业务模块协作，以此为基础来进行细化定义任务项。根据优先级分配到不同迭代中去，每个迭代周期可以沿用目前大部分公司保留的工作管理模式和习惯，结合关键里程碑，一周一个小迭代，一月一个大迭代，而不是全面推倒以往的工作计划管理模式，同时引入版本概念。

如果要保证不同业务模块可以分配到不同小团队，那需要把模块协作的点在关键迭代中合理分配，同时关注关键里程碑，尽可能保证每次交付成果有成效，也缩短每次交付的间隔时间。

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

采用敏捷开发模式，原来按职能规划的团队组织必须调整，全部团队成员必须贯穿项目，对项目最终质量负责。

由于敏捷开发强调持续迭代开发、快速交付，因此人员角色职能可以模糊化，一起做好软件的质量保证。例如业务人员不再是一个需求提出者，需要全程持续的对项目产品阶段性目标提出建议，也需参与到项目产品阶段的设计评审、质量的验证测试等。

敏捷的组织文化中，相对以往的瀑布流程，敏捷更关注人，因此敏捷测试组织应该以人为导向，是一种驱动、自组织、协作式的文化氛围。

实际上每个公司在敏捷模式实施过程中，根据的自身实际情况和成本考虑，要求组织成员天天在一起工作难免过于理想，经常会作一些妥协（包括组织成员可能属于多个敏捷团队、地点因素、任务时间因素），但总体要求敏捷团队所有成员能够做到高频率、高效的沟通，例如必须参与每日站立会沟通等。

敏捷的组织文化对很多开发组织是一个持续改进过程。

围绕被激励的个人来构建项目。

敏捷开发模式要求打破团队成员以往的职能划分、团队共同协作，都为了项目质量负责。因此势必需要搭建好的工具链或者完善DevOps平台，实现持续集成、持续交付自动化，人人都可构建，快速验证，提供可交付使用的产物。

实际中很多开发组织的工具链不完善或环节割裂，无法做到全链路打通、自动化，缺乏统一的DevOps工具平台等，后续需要不断的优化过程和工具平台等。

以往项目的传统开发模式，项目每个阶段涉及其对应的职能专业人员，每个阶段的主要成员通常在很少参与其他不同阶段，不排除有些成员身兼多角色。因此在每个环节间沟通流程上会存在一些瓶颈风险，例如：文档不明确、人员协调、时间协调等，导致效率低下，沟通繁琐周期过长。

对于敏捷开发，要求不断的迭代式往前推，每个迭代周期都不长，所以要求讲究高效，简化沟通流程，减少各环节间的时间浪费。由于敏捷团队成员经常性在一起，可以通过每日站立会等方式进行面对面沟通，这样反而是最节约时间、最有效率的方式。

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

在现实中，任何项目产品是否达成目标，必须交付给客户使用，取得了反馈才是代表开发进度完成。

对于敏捷开发模式来说，不断的持续迭代交付，不断持续提供的阶段性可使用、可运行起来的产品成果，才是评估敏捷开发的迭代进度是否有效，同时交付作为敏捷开发其完成度的度量评审依据之一。

对于产品来说，用户反馈结果也是决定产品设计和后续计划的调整依据，敏捷开发要求缩短每次交付的周期，持续增量发布工作软件，以取得用户的反馈，以此作为产品项目是否达到效果和后续调整的依据。因此产品的敏捷开发整个过程，要时刻关注交付成果；未运行未被用户使用，则不能称之为交付成功。

敏捷过程提倡平稳的开发节奏，发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

具体每个项目开展，在现实开发过程中，要求每个迭代都是恒定的周期，这对于产品规划和实施开发迭代计划有一定能力要求和难度；敏捷开发组织在全程都要时刻关注迭代规划周期合理性，保证敏捷团队可持续交付、用户可持续快速反馈等。

现实中在项目产品开展后，每个项目的敏捷开发团队成员基本可确定和稳定扩展。为保证项目产品开展顺利、每个迭代规划是否合理十分重要。恒定的迭代周期很重要，可保证团队的节奏，但这并不容易，比较理想化。

实际中还是存在一些预期周期的deadline、关键里程碑的检查点，所以根据这些前提反推，对于业务规划迭代涉及的任务项取舍很重要，关注每个迭代的业务重点和目标。

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

敏捷组织是以人为导向的，注重团队协作，一起为质量负责，为持续交付高质量的软件成果给到客户使用、而不是持续交付质量不好的软件。

现实中不可能每次交付都能达到一个完美的成果让客户满意，造成新迭代推迟，这要求敏捷团队成员不断的在实施过程中进行学习、总结经验，提升团队自身技能，完善问题处理跟踪机制，不断增强团队技术能力等，同时也要依据敏捷组织的技能方向推进深度学习研究。

敏捷开发要求快速迭代，快速交付周期性成果，增强敏捷团队自身能力以便缩短每个迭代周期，增强应对能力，快速应对市场反馈。同时敏捷组织也是不断改进成长演进的，因此提升团队能力也是一个持续不间断的过程。

以简单化为根本，不做过度设计和预测。

传统项目的瀑布开发模式，由于项目需求范围基本明确确定，所以完善的设计阶段是一个关键环节，后续具体开发环节以此为标准来开展。

而敏捷开发强调迭代式开发、持续交付，产品项目的目标预期和需求存在不确定性，需要能根据市场或用户反馈及时调整发生变更，因此过渡设计或预测不适合，只作适度的设计便于后续迭代快速响应调整，同时节约一些不必要的资源投入和时间成本。

把过程简单化是敏捷开发模式推进的一个原则。由于团队常驻在一起、面对面沟通高效，不像以往瀑布式开发流程，所以不需要过度详细的设计，有问题就直接面对面沟通，避免迭代中需求变更造成设计调整而引发的时间人力成本的过渡浪费。

在现实当中，实际产品或项目实施开发完成后，到达了一定运行稳定阶段后，还是需要补充相关的设计文档等，只是把该过程后置了。因为验收需要、宣传需要、知识转移需要、归档文档需求、未来团队内部培训等，因而实际敏捷开发推广、工作协作过程可以简化，但有些关键性结果产物还是不可简化。

最好的构架、需求和设计出自于自组织的团队。

敏捷要求根据反馈及时响应，不断快速迭代调整。为达到目标，保证敏捷高效，往往自身的团队参与整个产品项目全过程是最优的模式，也可保质保量。自身团队的需求规划、设计更容易高效的快速调整，减少不必要的间接沟通成本。对于敏捷开发模式来说要求精益化，减少不必要的过程和周期。

团队外人员存在不稳定性，在很多公司，项目间的人员复用是很常见，跟公司成本、资源有关，有可能在时间、工作安排上存在冲突，会给敏捷开发团队协作带来一定不可控风险。沟通流程不顺畅、协调周期长带来沟通成本等，都会对敏捷开发造成影响。

总结一句：自己的总是最可控的。

每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。

实际在推进敏捷开发的模式时，完全按照敏捷开发的敏捷理念及方法论进行团队搭建、改造和实施，一步到位是不可能的。存在团队组织因素、职责转换因素、人员能力因素、产品项目业务因素等，包括公司的组织架构和管理制度规范都涉及可能调整。

只有产品项目开发实施过程中逐步的进行敏捷开发模式推进，不断迭代调整，对问题进行收集，总结出每次存在问题的原因，后续进行改进。例如：如何推广敏捷文化、搭建合理敏捷组织、规划资源安排、协调各角色的工作安排、问题管理、平台搭建改进、协作规范制定等等。

总之敏捷组织团队定期自我反思和调整改进是很有必要的。

产品项目实施开发模式有很多种，敏捷开发模式只是其中一种，有其前提条件、适用性和约束条件，是目前大多数公司采用的方式，每家公司落地成效也不尽相同。总之，敏捷开发模式落地是一个不断持续改进和优化的过程。

以上分享的是将敏捷开发相关的原则进行自己的理解阐述，如有更多的想法和更进一步的学习，欢迎联系我们交流探讨。