【20220504】软件开发模式_软件开发二阶程序-CSDN博客

本文链接：https://blog.csdn.net/wei_wei10/article/details/124576182

时间：2022年05月04日

作者：小蒋聊技术

邮箱：wei_wei10@163.com

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

现在是五一假期，因为最近疫情的原因大家也只能线上沟通。小蒋身边一个产品经理朋友跟小蒋抱怨，说公司领导让他五一假期学习一下软件开发模式。

“我一个产品经理为何要关注开发模式？开发模式不是技术的事吗？那不是技术团队该关心的事吗？”

今天小蒋就和大家一起来看看“开发模式”究竟是个什么玩意？为什么我们要关心它？

产品经理的职责

首先我们要达成一个共识：产品经理除了收集分析需求、抛出草案、定方案、输出原型、prd、流程图、架构图等专业工作之外，还需要负责协调资源、上传下达等保障整个研发工作的顺利进行。

产品经理是贯穿始终从头走到尾并对最终结果负责的人。

软件开发流程，粗略的划分大概如下图所示：

但在实际的工作中，每个团队之间的配合绝对不是线性的，而是交叉的，如下图所示：

设计工作不仅仅是产品经理设计产品方案，拿到产品方案后研发团队需要构建同样重要的技术方案。
测试方面，测试团队肯定是主角，进行项目质量的整体验收。除了这些还有研发团队研发过程中的单元测试，提测前的整体自测，还有产品经理的辅助测试和上线后回归测试等。
至于部署方面，硬件方面的事情自然运维团队去处理，但设备选型则是技术方案的一部分。另外有的公司是技术团队负责发布代码，有的是运维团队进行发布。

各团队之间看起来相互独立，各司其职，实则紧密相连，不可分割。无论开发模式是不是技术团队该关心的事，它都不可避免地会影响整个研发过程。各团队为了消除这种影响，需要调整工作方式去配合，这样才能释放出相应模式的优势力量，达到整体最佳。

软件开发模型

软件工程是一个非常复杂的过程。在软件开发阶段要遵循不同的软件开发生命周期模型来制定和设计。这些模型也称为软件开发生命周期（SDLC，System Development Life Cycle）模型/方法。

在业内最受欢迎的软件开发生命周期模型有：

1.瀑布模型（WaterFall）

2.V型模型（V-Shaped Model）

3.迭代和增量模型（Iterative And Incremental Model）

4.螺旋模型（Spiral Development Model）

5.敏捷模型（Agile Model）

这里小蒋多补充一嘴。大家要知道一件事，大家经常听到的“敏解开发”，不是一个模型，而是一组模式的统称。

软件开发生命周期（SDLC）可以分为宏观和微观两个维度。在宏观上，软件开发生命周期（SDLC）是指的软件开发的整个生命周期。

在微观上，软件开发生命周期（SDLC）本身就是一种方法论，这是由于历史遗留的原因，当初提出这个概念的时候其实就是作为一种软件开发方法。例如，看板和Scrum都属于敏解模型。

看板和Scrum

瀑布模式 VS 敏解开发（Scrum）

今天小蒋重点挑两种经典模型分享给大家，因为这两种模型代表了两个时代。

瀑布模型

传统项目管理通常采用的是瀑布式、部分迭代开发模式。瀑布式开发是指将项目划分为N个阶段，每个阶段的工作都建立在前一阶段的基础上，从项目计划上看，就像是逐级向下的瀑布，由此得名。轮船、汽车制造业，建筑行业一般沿用此法。要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大、成本越高，影响到项目的交付质量。

敏捷开发

敏捷项目管理强调商业价值的尽早交付，项目团队的自组织，不断响应客户动态的需求变化，持续的优化项目产品和交付流程。它作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能。

区别

	瀑布式开发	敏捷式开发
工作方式	1.重点和强调过程文档，以文档驱动项目，将软件项目开发周期划分为几个固定的阶段（需求分析，系统设计，软件设计，编码，测试，交付等），每个阶段结束都有对应的文档作为输出； 2.上一个阶段的输出就是下一介阶段的输入，直至完成整个开发流程。	1.更加强调人的协调（团队之间，客户与团队之间），在高度协作的环境中使用迭代方式进行增量开发; 2.客户可对每次迭代的成果提出修改意见，开发人员进行调整和完善； 3.进行多次迭代直至完成完整产品交代，快速迭代，拥抱变化。
优点	1.每个阶段目的明确，阶段人员完全专注于该阶段的工作，有助于提高阶段效率； 2.由于存在详细的过程文档，在时期就能明确出项目的范围的概况，能够更有效的组织和调配资源开展项目。	1.阶段性成果可以在开发过程中被客户查验，从而降低项目开发的风险； 2.灵活性高，需求的变更可在任何时候进行。
缺点	1.开发过程中大量的文档，极大的增加了工作量； 2.项目后期才能展示成果给客户，增加了项目开发的风险（例如项目最终与客户预期差别很大，若要修复会造成项目的延期和成本增加）； 3.需求变更的成本较高。	1.最终交代的内容无法预测，预期和实际完成的内容经常会有很大的差异； 2.敏捷需要更高水平的协作以及开发人员和用户之间的定期沟通。业务和IT人员在沟通前需要做大量的准备工作，但很多情况下业务的沟通时间无法保证。
适合项目	软件需求十分明确并且不会有频繁变化的项目。	需求不明确、具创新性或需要抢占市场的项目。

联系

无论是敏捷开发还是瀑布开发，对于软件开发人员来说，共同点都是遵循需求、设计、开发、测试等这样的顺序。

但总的来说，在现在的项目过程中，并没有绝对严格的按照完整的敏捷或是完整的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多是起一个参考作用。

总结

瀑布和敏捷不是天然分割的，只是针对业务各有侧重，应该是你中有我，我中有你的混合体。比如微信第一版的时候，聊天是核心功能，它的迭代内部也存在瀑布模式，如果没有需求-设计-开发-测试-运维根本就无法进行下去。再比如瀑布，特别对创业团队，刚开始人手不多，分工不明，架构师有可能要去画原型图，做需求调研；产品经理业务模糊，还在探索，各种短板和不足就像黑洞一样存在你的周边，你浑然不知。如果你一定要等整个调研完成，PRD文档周全再做开发，估计项目也要歇菜。